More on the one point: > On Jan 2, 2018, at 7:00 PM, Les Ginsberg (ginsberg) <[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.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
