Re: [Last-Call] Last Call: <draft-ietf-sidrops-6486bis-08.txt> (Manifests for the Resource Public Key Infrastructure (RPKI)) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux