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
