Fernando, > Ron, > > On 5/9/19 06:01, Ron Bonica wrote: > > Fernando, Zhenqiang, > > > > You both have valid points. Maybe I am becoming too tolerant of > > deviations from the specification. > > This is not a deviation in the spec. It's an outright violation of the spec. > > This topic has a rich history in 6man, which I will summarize as follows: > > 1) Folks proposed the segment routing header I-D with the argument that > it wasn't clear whether EH-insertion was allowed in RFC2460 or not -- > when it was clear to virtually everyone else that it was forbidden > > 2) The segment-routing header I-D was adopted on the condition that all > text related to EH insertion should be removed. > > 3) Since we were in the process of doing rfc2460bis, we had the > discussion to make the text crystal-clear that EH-insertion was > forbidden. -- in fact, it already was. But based on 1) we discussed to > make it 200% clear. > > 4) Some folks argued not to add text on the topic, leaving, from their > pov, the spec ambiguous. This "version" of rfc2460bis was shipped from > the wg. > > 5) During IETF LC of rfc2460bis, the issue was raised again, and there > was finally consensus to add very explicit text noting that EH insertion > is forbidden. And this became RFC8200. > > > My question to the spring wg chairs and routing area ADs therefore is: > how come the wg adopted a document (e.g.: > https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01) > when it contains outright violations of specs (RFC8200) that are not in > the charter of spring wg to update? (as far as I understand).
1) draft-ietf-spring-srv6-network-programming has a normative reference to [I-D.voyer-6man-extension-header-insertion]. As such, from a process standpoint, it's clear that it would not going to be published before [I-D.voyer-6man-extension-header-insertion] be published as RFC. And from its name, the latter is intended to be discussed and within control of the 6MAN WG. 2) When writing a specification (i.e. changing the standard), there is the question of whether we directly define the new behavior, or whether we need to motivate the change from a usage perspective. Aka do we need use cases documents or is this a waste of IETF time? When the point is difficult or subject to debate, the proposed change is easily dismissed based on the absence of a written need for that change. Hence it looks to me reasonable that the SPRING WG explicitly states that SRH insertion would be useful, rather than some individual brings this to the 6MAN WG, individually claiming that it's useful for SR. If you are fine with this, AFAIK, this is done with a WG adoption. Again, draft-ietf-spring-srv6-network-programming has a normative reference that would automatically block RFC publication. I'm not sure what additional safety you would want? The SPRING WG is not to be point of asking publication of draft-ietf-spring-srv6-network-programming. It's in a WG for discussion. If your point is that you don't want the spring WG to discuss the usage of EH insertion, then you are welcome to contribute to the SPRING WG. And thank you for doing that. --Bruno > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fg...@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _________________________________________________________________________________________________________________________ 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
