John - V3 of the draft has been posted which I believe addresses all of your comments.
Please let me know if there are remaining issues. Note that a few additional format diffs were introduced by the new author tools (not directly by me). Les > -----Original Message----- > From: John Scudder <j...@juniper.net> > Sent: Thursday, August 18, 2022 8:46 AM > To: Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org> > Cc: draft-ietf-lsr-isis-rfc5316...@ietf.org; lsr@ietf.org > Subject: Re: AD review of draft-ietf-lsr-isis-rfc5316bis-02 > > Hi Les, > > Thanks for your prompt reply. My comments in line below. > > > On Aug 18, 2022, at 12:49 AM, Les Ginsberg (ginsberg) > <ginsberg=40cisco....@dmarc.ietf.org> wrote: > > [snipped] > > > I have a couple of other points I’ll raise here instead of in line. > > > > 1. I was a little surprised in the Acknowledgements to see that Les is > thanking Les. :-) It’s OK of course if you want to do it that way, but maybe > you want to give that section one more look? > > > > [LES:] As you no doubt surmised; we simply copied that text verbatim from > RFC 5316 – on which I was not an author. That statement is true as regards > RFC 5316, which is explicitly mentioned in the paragraph. > > I have no particular preference here – if the IETF has a policy on this I am > happy to follow it. 😊 > > [JGS] > > There’s no IETF-wide policy, Acks are at the author’s discretion more than > any other section. I’m not going to go dig up other bis documents but I seem > to recall seeing a format more like this used in others — > > --- > NN. Acknowledgements > > The authors of the present document would like to thank (authors’ > discretion; if nobody then just leave this out). > > RFC 5316 included the following Acknowledgements section: > > The authors would like to thank Adrian Farrel, Jean-Louis Le Roux, > Christian Hopps, Les Ginsberg, and Hannes Gredler for their review > and comments on this document. > — > > Or sometimes the old acks are not carried forward but left to decorate the > original document only, although in this case where you’re doing a tightly- > scoped update I can see why you want to retain them. > > [/JGS] > > > 2. More substantively, the phrase “… when the TE Router ID is needed to > reach all routers …” or one like it, occurs many places in the document. I see > that this was part of the base RFC 5306 but it did introduce some confusion > for me, because there’s more than one possible reading, including > > > > - when the TE Router ID has to be known by all routers > > - when in order to establish reachability to all routers, the TE Router ID > > is > needed > > > > [LES:] I think the latter interpretation is the correct one. And I think the > existing text conveys that when the text is “the TE Router ID is needed to > reach all routers”. But there are some places where the text is “the TE Router > ID needs to reach all > > Routers” – the use of the active tense (“needs”) is inappropriate. > > Would it be acceptable to change only the places where the in appropriate > text is used? > > [JGS] > > That seems fine. I continue to think that the passive voice text is > unnecessarily ambiguous too, but it’s at worst a minor impediment to > consuming the spec so I’m happy to leave it to your discretion. > > [/JGS] > > > I leave it to you to decide whether or not to fix this. Clearly RFC 5306 > > stood > for years with that wording and presumably it didn’t create a problem (or at > least nobody raised an erratum) so I’m comfortable with either outcome. > > > > Thanks, > > > > —John > > > > --- draft-ietf-lsr-isis-rfc5316bis-02.txt 2022-08-17 > > 14:21:33.000000000 - > 0400 > > +++ draft-ietf-lsr-isis-rfc5316bis-02-jgs-comments.txt 2022-08-17 > 14:42:45.000000000 -0400 > > @@ -22,14 +22,15 @@ > > This document describes extensions to the Intermediate System to > > Intermediate System (IS-IS) protocol to support Multiprotocol Label > > Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering > > - (TE) for multiple Autonomous Systems (ASs). It defines IS-IS > > + (TE) for multiple Autonomous Systems (ASes). It defines IS-IS > > extensions for the flooding of TE information about inter-AS links, > > which can be used to perform inter-AS TE path computation. > > > > No support for flooding information from within one AS to another AS > > is proposed or defined in this document. > > > > - This document obsoletes RFC 5316. > > + This document builds on RFC 5316 by adding support for IPv6-only > > + operation. This document obsoletes RFC 5316. > > > > [LES:] Accepted – but I prefer to use a separate paragraph for each > sentence. > > ?? > > [JGS] > > Totally fine. > > [/JGS] > > [remainder snipped] > > Thanks, > > —John _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
