On Tue, Oct 30, 2018 at 03:33:21PM +0000, Acee Lindem (acee) wrote: > Hi Les, > > On 10/30/18, 11:15 AM, "Les Ginsberg (ginsberg)" <ginsb...@cisco.com> wrote: > > Acee - > > > > Section 3.2 > > > > > > "When a router receives multiple overlapping ranges, it MUST > > > conform to the procedures defined in > > > [I-D.ietf-spring-segment-routing-mpls]." > > > > > > It would be useful to include a section pointer here. I think > your referring > > > to Section 2.3 where the router ignores the range? Is it likely > that will > > > change to something other than "ignore?" If not, maybe it's just > worth > > > mentioning that here. > > > > ##PP > > I don't think it is good to specify the behavior which is described > > somewhere else. Regarding the section, the > > ietf-spring-segment-routing-mpls is still being worked on and the > > section may changes. We used the same text in OSPFv2 and ISIS SR > drafts. > > I would like to be consistent here. > > > > Given that this is a normative reference, I don't think it would create > too > > much of a dependency to include the section in the reference. We've had > a > > protracted discussion (1-2 years) on the whole SID overlap topic in > SPRING > > and I believe we've finally come up with behavior and the specification > of > > such behavior with which everyone agree (or at least doesn't strongly > > disagree). > > > [Les:] I strongly agree with Peter (and disagree with you). > Why would we want to risk having an incorrect section reference to a > document which is still being revised? This needlessly introduces a > dependency such that if the section numbering changes in the SR-MPLS draft we > would then have to update the dependent document(s). > Note this has nothing to do with the SID overlap discussion itself. The > compelling reason to NOT discuss this in the IGP documents but simply refer > to the document that defines the solution is so that whatever the outcome in > SPRING the IGP documents do not also have to be changed. > > While I don't feel as strongly as either of you, this could improve the > readability. For example, if you read RFC 8362 you'll see that I have > referred extensively to sections in RFC 5340. I may be overoptimistic but I'm > hoping we are finally done with the SR-MPLS draft as it is blocking all our > LSR SR documents.
I also agree that specific section references can (in general) aid readability. And there's always "[RFC Editor: please check with authors during AUTH48 that the section reference remains correct]"; we've done essentially that on a document I was shepherding in the past. -Benjamin _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
