Ben - Inline.
> -----Original Message----- > From: Ben Campbell [mailto:[email protected]] > Sent: Tuesday, January 02, 2018 4:17 PM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: The IESG <[email protected]>; [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected] > Subject: Re: [spring] Ben Campbell's No Objection on draft-ietf-spring- > segment-routing-13: (with COMMENT) > > Hi, thanks for the response. Comments inline: > > > On Dec 20, 2017, at 5:35 PM, Les Ginsberg (ginsberg) > <[email protected]> wrote: > > > > Ben - > > > > Thanx for the review. > > V14 has been published and it attempts to address the Security concerns. > > Look forward to your feedback. > > It’s not clear to me how the new version addresses Adam’s major comment > or Alissa’s second DISCUSS point. But it’s probably best to discuss those > points directly with Adam and Alissa. > [Les:] Adam has already responded positively. He made a suggestion for clarifying text which I agreed to put into the next version. Will wait to hear from Alissa. > […] > > >> > >> > >> --------------------------------------------------------------------- > >> - > >> COMMENT: > >> --------------------------------------------------------------------- > >> - > >> > >> Substantive Comments: > >> > >> - I support Alissa's discuss and Adam's major comment. > >> > >> - Requirements Language: There are lower case instances of 2119 > keywords. > >> Unless you mean for those to also be normative, please use the > >> boilerplate from RFC 8174. > >> > >> -3.1.1, last paragraph: Why are the SHOULDs not MUSTs? > >> > > [Les:] Failure to do the validation will result in the packet being dropped > when it reaches a node which does not support the algorithm i.e., the > algorithm specific label will not match any installed incoming label. This is > sub- > optimal but not fatal - hence SHOULD rather than MUST. > > Do you think that would ever be a reasonable implementation choice? If so, > it would help to add a sentence or two about the consequences into the > text. > [Les:] I can add some text. > > > >> -12.2: The citations to the following references seem to be used > normatively: > >> I-D.ietf-6man-segment-routing-header > >> I-D.ietf-isis-segment-routing-extensions > >> I-D.ietf-ospf-ospfv3-segment-routing-extensions > >> I-D.ietf-ospf-segment-routing-extensions > >> > > [Les:] I respectfully disagree. > > The architecture document is NOT dependent upon the IGP/6man > documents - the dependency is the other way around. > > The referenced documents are useful for readers who wish to better > understand how the architecture is supported by routing protocols/IPv6 - but > there is no dependency that the architecture definition has on the > implementation specifics. > > A reference is normative if reading it is necessary to understand or > implement this draft. I-D.ietf-6man-segment-routing-header is referenced > several times in the security considerations section in a way that seems to > make the security considerations incomplete unless you read that. The other > 3 seem necessary to implement IGP segment advertising as described in > section 3. > [Les:] This is still a point of disagreement. This is an architecture document - not an implementation document. Solely using this document it is not possible to implement anything because the document does not specify any implementation. It does provide the framework for all implementation related SR drafts. The architecture draft stands on its own. We could eliminate all of the SR draft references and the document would still be complete. But, it is certainly helpful to one's understanding of the architecture to read about how it is implemented - and we therefore have provided informational references for those documents which currently exist(sic) and seem relevant as an aid to the reader. But that does not make the architecture document dependent on these references. To do what you suggest would create a two way dependency between the architecture document and every other segment routing specification. As per https://www.ietf.org/iesg/statement/normative-informative.html " An RFC cannot be published until all of the documents that it lists as normative references have been published." Given that there are many implementation related SR related drafts which are in various stages of being written - as well as many such drafts which have yet to be written, at what point can we declare the architecture document publishable? Les > […] _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
