LGTM, thanks. —John
> On Aug 19, 2022, at 1:38 AM, Les Ginsberg (ginsberg) <[email protected]> > wrote: > > 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 <[email protected]> >> Sent: Thursday, August 18, 2022 8:46 AM >> To: Les Ginsberg (ginsberg) <[email protected]> >> Cc: [email protected]; [email protected] >> 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) >> <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
