Ben -
I want to emphasize that we have a common goal - we both want the document to be clear on its scope and relationship to other documents. I think the document as written is clear (more on that below) - but as I am one of the authors it may be that I do not see omissions as clearly as a reader who comes without the underlying context that document writers develop. Your fresh perspective is a valuable input that I do not want to ignore. The title of the document is "Segment Routing Architecture". The phrase "SR Architecture" is used numerous times throughout the document. I am not sure how we could be more clear about the intent. Certainly stating that this is an architecture document would be redundant and I am not sure what value that adds. You are concerned that the relationship between this document and the numerous documents which define how to implement portions of the architecture is not clear - but to me this is implicit in the notion of "architecture" - which defines the structure and design of something. Is it necessary to make it explicit that an architecture document is NOT defining implementation nor does it need to do so? For example, does it make a difference to the architecture in what container a protocol advertises a SID? It certainly could make a significant difference as to the ease of maintaining a database (for example), but redefining a protocol advertisement makes no difference to the architecture definition. That said, here is some proposed text that could be inserted into the Introduction. I am not fully convinced this is needed and/or is truly helpful, but if it helps you as a reader to have a clearer understanding then that may be sufficient justification. Let me know what you think. If it seems helpful to you then it can be reviewed by the other co-authors. "This document defines the architecture for Segment Routing, including definitions of basic objects and functions and a description of the overall design. It does NOT define the means of implementing the architecture - that is contained in numerous referencing documents, some of which are mentioned in this document as a convenience to the reader." Les > -----Original Message----- > From: Ben Campbell [mailto:[email protected]] > Sent: Tuesday, January 02, 2018 6:44 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) > > More on the one point: > > > On Jan 2, 2018, at 7:00 PM, Les Ginsberg (ginsberg) > > <[email protected]<mailto:[email protected]>> > wrote: > > > >>> > >>> > >>>> -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. > > It’s fairly common to have a standard track document that describes things at > a high level and normatively depends on other drafts for details. On re- > scanning the draft, I don’t see text to indicate that this was not the intent. > It’s entirely possible I missed something. > > I think the issue is that the draft is not clear about it’s purpose and > relation to > the extension drafts. As far as I can tell, there is no text in the abstract > or > introduction that says that this is an architecture draft. Some text in the > abstract to say that this is an architecture, and some text in the > introduction > to expand on that and to talk about it’s relationship to the extension drafts > would help. > > For example, as the text stands now I have trouble reading section 3 any way > except to say “Segment routing requires advertising IGP segments. You can > do that using one of these referenced drafts”. That’s why I thought the > references should be normative. > > Now, if what you mean to say is “Defining segment routing requires defining > how you reference IGP segments. That work is ongoing at the time of this > writing. See the referenced drafts for the status of that work”, then the > references would seem informational. > > > > 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? > > As mentioned above, I would not object to calling these informational > references with some clarifying text about the purpose of this draft and it’s > relationship to the referenced drafts. > > Ben. > > > > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
