On Fri, Dec 17, 2021 at 09:08:04PM +0000, Chris Morrow wrote: > ( Clarifying question(s) ) > > On Fri, 17 Dec 2021 03:55:23 +0000, > Benjamin Kaduk <kaduk@xxxxxxx> wrote: > > > > This draft is marked with an "Updates:" relationship to RFC 6486 both in > > the document header and in the shepherd writeup. But the actual contents > > of the document contain substantial portions of text that are identical to > > RFC 6486, as would be expected from a "bis" document (per the draft name) > > that would replace entirely the original RFC; that relationship is > > typically indicated by an "Obsoletes:" relationship rather than "Updates:". > > It sounds like you are saying; > > "Hey, you included a ton of 'copy/paste' text in this -bis, > stylistically/historically people only put in the -bis the CHANGED > text, and whatever is required to link it into the original" > > I have no idea about this... but does it matter? I mean, won't the > -bis just be the original with the 'new' content stitched into it > properly? It sounds like my point got muddled (perhaps unsurprising, as I was writing it in a hurry...) Basically, when I see a "bis" document, I expect that it's going to be a "complete replacement" or "totally new version" of the original, with some changes based on experience gained since the original. Sometimes it will also be progressing on the maturity level front as well (experimental->Proposed Standard, or Proposed Standard->Internet Standard), though not always. In this case I'm used to seeing basically all the original content remain in the "bis" version (except for things intentionally being changed), perhaps modulo IANA considerations that create new registries. That type of document is typically also going to be marked as obsoleting the original, since you're expected to just read the new one and the original would only be of historical interest. The "updates" relationship (while admittedly much less well defined than the "obsoletes" one, see discussion around draft-kuehlewind-update-tag), is intrinsically of the form "the original stays around and the new document is just adding stuff or making changes". In that case, the expectation is that someone will read both documents, and so the new document just describes the changes being made, and doesn't repeat much text from the original. I would summarize my point here as being "I think this document should have an 'obsoletes' relationship to 6486, not an 'updates' one". (I'm happy to be proven wrong, as I didn't actually read the contents in much detail.) > > Also, I would recommend including a "changes since RFC 6486" section that > > motivates why the document is being updated or replaced. > > Ok, this doesn't seem bad :) I think most of the reasoning is stuck in > mailing-list discussions like: "Hey, we did what you said, lots of > sadness... how about we shave the yak a little differently so ops / > theory / practice align better and leave us less balded yaks?" (and > lost packets) An excellent reason to do a "bis" document, then! :) > I think we need to either re-engage the author(s) or pawn this off > on the sekret-pen-holder, provided we can provide some linkage text. The most generic/boilerplate text one might see would be along the lines of "the specification was updated in light of deployment experience to avoid problematic cases and streamline implementation". Thanks, Ben -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
