Dear Ron, While authors may address your other questions allow me to express an opinion regarding your observation:
"conflict with RFC 8200 [1] [2]" As written today RFC 8200 provides rules for insertion and handling of those extension headers which are enumerated in said RFC and are listed in IANA IPv6 Extension Header Types registry. SRH is not part of either of those lists. It also has been communicated very clearly by 6man chairs and ADs when RFC8200 was proceeding that any future document can update it when it defines new types of extension headers therefor I find your reasoning of "conflict" quite bizarre. Kind regards, R. On Sun, Mar 17, 2019 at 9:52 PM Ron Bonica <rbonica= 40juniper....@dmarc.ietf.org> wrote: > 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
