So a reference to draft-voyer-6man-extension-header-insertion in
draft-filsfils-spring-srv6-network-programming sections 4.13 et al. would be
useful to keep that relationship clear.
Darren
On 2019-03-20, 1:50 PM, "Joel M. Halpern" <j...@joelhalpern.com> wrote:
In my experience, if there is a requirement for collaborating with
another working group on a topic, it is both helpful and important to
spell that out and have it agreed as part of the adoption process. If
it is not dealt with then, it is MUCH harder to deal with later.
Yours,
Joel
On 3/20/19 6:39 PM, Darren Dukes (ddukes) wrote:
> Hi Ron, the authors are suggesting this document for working group
> adoption, not for last call.
>
> When the working group adopts it, the working group starts to work on it.
>
> If the working group decides to address header insertion and address
> that with 6man then the working group can take on that work, but it does
> not need to block this document being adopted.
>
> Darren
>
> *From: *spring <spring-boun...@ietf.org> on behalf of Ron Bonica
> <rbonica=40juniper....@dmarc.ietf.org>
> *Date: *Sunday, March 17, 2019 at 4:53 PM
> *To: *"bruno.decra...@orange.com" <bruno.decra...@orange.com>, SPRING WG
> <spring@ietf.org>
> *Cc: *"draft-filsfils-spring-srv6-network-programm...@ietf.org"
> <draft-filsfils-spring-srv6-network-programm...@ietf.org>
> *Subject: *Re: [spring] IPR Poll for
> draft-filsfils-spring-srv6-network-programming
>
> Bruno,
>
> While I like many things about this draft, I don’t think that it is
> ready for adoption. Reasons follow:
>
> * Section 4.1 appears to contradict Section 4.3.1 of
> draft-ietf-6man-segment-routing-header. In particular, consider the
> behavior when Segments Left equals 0.
> * Sections 4.13, 4.14. 4.21.1 and 4.21.2 appear to be in conflict with
> RFC 8200 [1] [2].
> * The intent of section 4.19 is unclear.
> * As Adrian points out, the draft extends the semantics of the IPv6
> address. Such a decision may have wide-reaching impact, and should
> be socialized with a wider community (6man, INTAREA WG, V6OPS)
> * The draft appears to be in conflict with
> draft-ietf-6man-segment-routing-header regarding how extension
> headers after the SRH are processed. According to
> draft-ietf-6man-segment-routing-header, subsequent extension headers
> are processed out of order, potentially in conflict with RFC 8200.
> According to this draft, subsequent extension headers are ignored.
>
> [1] According to RFC 8200, “Each extension header should occur at most
> once, except for the Destination Options header, which should occur at
> most twice (once before a Routing header and once before the upper-layer
> header).”
>
> [2] According to RFC 8200, “extension headers must be processed strictly
> in the order they appear in the packet” . Sections 4.13 and 4.14
> violate this rule by prepending an SRH before the SRH that is currently
> being processed.
>
>
Ron
>
> *From:* spring <spring-boun...@ietf.org> *On Behalf Of
> *bruno.decra...@orange.com
> *Sent:* Wednesday, March 13, 2019 2:50 PM
> *To:* SPRING WG <spring@ietf.org>
> *Cc:* draft-filsfils-spring-srv6-network-programm...@ietf.org
> *Subject:* [spring] IPR Poll for
> draft-filsfils-spring-srv6-network-programming
>
> Hi authors, SPRING WG,
>
>
>
> In parallel to the call for adoption for
draft-filsfils-spring-srv6-network-programming (1), we would like to poll for
IPR.
>
>
>
> If you are aware of IPR that applies to
draft-filsfils-spring-srv6-network-programming please respond to this email.
>
> If you are aware of IPR, please indicate whether it has been disclosed in
accordance with IETF IPR rules (RFCs 3979, 4879, 3669 and 5378 provide more
details).
>
>
>
> If you are an *author or contributor* please respond to this email
regardless of whether or not you're aware of any IPR.
>
> If you are not an author or contributor, please explicitly respond only
if you are aware of IPR that has not yet been disclosed.
>
>
>
> This document will not advance into the working group until IPR
confirmations have been received from all authors and contributors.
>
>
>
> Thank you,
>
>
>
>
(1)https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfilsfils-2Dspring-2Dsrv6-2Dnetwork-2Dprogramming-2D07&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=g5euhKG6OY3m1hMFewvX_AhsPNPcaeHrTSLS3oY3KoM&s=5KlDTs7QncIP0FnevaMhAHEIjoQLlCw9xVVUrR40dqY&e=>
>
>
>
>
>
> --Bruno & Rob.
>
>
_________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme
> ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
>
> Thank you.
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
