Robert - Thanx for your review - apologies for the delay in responding. Please see inline. > -----Original Message----- > From: Robert Sparks via Datatracker <noreply@xxxxxxxx> > Sent: Thursday, April 27, 2023 1:09 PM > To: gen-art@xxxxxxxx > Cc: draft-ietf-lsr-rfc8919bis.all@xxxxxxxx; last-call@xxxxxxxx; lsr@xxxxxxxx > Subject: Genart last call review of draft-ietf-lsr-rfc8919bis-01 > > Reviewer: Robert Sparks > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-lsr-rfc8919bis-01 > Reviewer: Robert Sparks > Review Date: 2023-04-27 > IETF LC End Date: 2023-05-03 > IESG Telechat date: Not scheduled for a telechat > > Summary: > Ready for publication as a proposed standard rfc but with nits to consider > before publication. > > Nits: > 1) It would be nice to explain when/how the registries got renamed? [LES:] I do not see that as within scope for this document. Registry renaming was done across the full set of registries under https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml about a year and a half ago to make them easier to maintain and to provide greater consistency in the naming. It was not done specifically to the registry referenced by this document. > > 2) Please reconsider the link to the mailarchive in the RFC. Put it in the > shepherd writeup or in the history in the datatracker as a comment (chairs > can > do this). Otherwise it adds to the list of URLs that we have to keep alive > forever. [LES:] I am open to whatever the chairs/AD think is appropriate. But very few people actually look at the shepherd writeup or Datatracker history. Having it in the document provides context for those readers who are curious as to why the bis changes were made. I don’t think it would be as effective if it were removed from the document. I take your point that the URL may someday become stale - but if it did that would apply to the other locations as well. The section in which it appears is informational only - it is not a normative part of the document - so I am inclined to leave it as is. But again, happy to follow consensus on this. Les > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
