Robert/John - I have posted a new version which addresses this issue. I hope this clears the discussion. I also (as promised) made the same change to https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8920bis/ and posted a new version of that document. Les > -----Original Message----- > From: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx> > Sent: Wednesday, May 3, 2023 1:00 PM > To: Robert Sparks <rjsparks@xxxxxxxxxxx>; John Scudder > <jgs@xxxxxxxxxxx> > Cc: gen-art@xxxxxxxx; draft-ietf-lsr-rfc8919bis.all@xxxxxxxx; last-call@xxxxxxxx; > lsr@xxxxxxxx > Subject: RE: Genart last call review of draft-ietf-lsr-rfc8919bis-01 > > John - > > The solution you propose is fine with me. > I will update it in the next version. > As we are still waiting for a few reviews I will wait a bit in case other changes > are needed. > > I will do the same to https://datatracker.ietf.org/doc/draft-ietf-lsr- > rfc8920bis/ as well. > > Les > > > -----Original Message----- > > From: Robert Sparks <rjsparks@xxxxxxxxxxx> > > Sent: Wednesday, May 3, 2023 11:18 AM > > To: John Scudder <jgs@xxxxxxxxxxx>; Les Ginsberg (ginsberg) > > <ginsberg@xxxxxxxxx> > > Cc: gen-art@xxxxxxxx; draft-ietf-lsr-rfc8919bis.all@xxxxxxxx; last- > call@xxxxxxxx; > > lsr@xxxxxxxx > > Subject: Re: Genart last call review of draft-ietf-lsr-rfc8919bis-01 > > > > > > On 5/3/23 1:12 PM, John Scudder wrote: > > >> On May 3, 2023, at 11:04 AM, Les Ginsberg (ginsberg) > > <ginsberg@xxxxxxxxx> wrote: > > >> > > >>> 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. > > > Yeah, I don’t see how adding another layer of indirection makes the > > problem go away. Perhaps it would be reasonable, though, to change the > > reference from a bare URL, presented inline, to an Informative reference, > to > > the effect of > > > > > > [LSR-MAIL] IETF LSR Mailing List Archive, Tue, 15 June 2021 15:25 UTC, > > "[Lsr] Proposed Errata for RFCs 8919/8920”, and follow-up messages. > > > > > > I don’t know if there is a standard style for this kind of reference, but it > > seems like it might be a cleaner solution. It doesn’t provide one-click access > > to the mailing list thread, but neither do some other references, and it > > should be easy enough for anyone familiar with our mailing list archives or > > frankly, even anyone who knows how to use a search engine. Also, > ironically > > the bare URL doesn’t provide one-click access either, because of how it’s > > line-broken in the txt rendering. > > > > > > Robert, Les, would that approach work for both of you? > > Yes. > > > > > > —John -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
