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

From: The IESG <[email-masked]>
Date: Thu, 16 Dec 2021 12:13:35 -0800

The IESG has received a request from the SIDR Operations WG (sidrops) to
consider the following document: - 'Manifests for the Resource Public Key
Infrastructure (RPKI)'
  <draft-ietf-sidrops-6486bis-08.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2021-12-30. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

   This document defines a "manifest" for use in the Resource Public Key
   Infrastructure (RPKI).  A manifest is a signed object (file) that
   contains a listing of all the signed objects (files) in the
   repository publication point (directory) associated with an authority
   responsible for publishing in the repository.  For each certificate,
   Certificate Revocation List (CRL), or other type of signed objects
   issued by the authority that are published at this repository
   publication point, the manifest contains both the name of the file
   containing the object and a hash of the file content.  Manifests are
   intended to enable a relying party (RP) to detect certain forms of
   attacks against a repository.  Specifically, if an RP checks a
   manifest's contents against the signed objects retrieved from a
   repository publication point, then the RP can detect "stale" (valid)
   data and deletion of signed objects.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/

No IPR declarations have been submitted directly on this I-D.

The document contains these normative downward references.
See RFC 3967 for additional information: 
    rfc8488: RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation (Informational - Internet Engineering Task Force (IETF))

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 16 Dec 2021 19:55:23 -0800

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:".

Also, I would recommend including a "changes since RFC 6486" section that
motivates why the document is being updated or replaced.

-Ben

---

From: Chris Morrow <[email-masked]>
Date: Fri, 17 Dec 2021 21:08:04 +0000

( Clarifying question(s) )

On Fri, 17 Dec 2021 03:55:23 +0000,
> 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?

> 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)

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.

thanks!
-chris

---

From: Job Snijders <[email-masked]>
Date: Fri, 17 Dec 2021 22:54:14 +0100

Hi,

> -bis just be the original with the 'new' content stitched into it

I understand Benjamin's message to more be a matter of publication
procedure: draft-ietf-sidrops-6486bis is a complete specification, to me
it makes sense to change the XML header to something along the lines of:

   <rfc category="std"
       docName="draft-ietf-sidrops-6486bis-08"
       obsoletes="6486"
       ipr="trust200902">

> > Also, I would recommend including a "changes since RFC 6486" section
> > that motivates why the document is being updated or replaced.
> 

If 6486 is to be obsoleted, Benjamin's suggestion to add a section
"chanes since" makes sense and should be added. I can take a stab at
some draft text if there are no other volunteers.

Chris - can you check with authors to avoid duplicate work?

Kind regards,

Job

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 17 Dec 2021 13:54:42 -0800

> -bis just be the original with the 'new' content stitched into it

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.)

> theory / practice align better and leave us less balded yaks?" (and

An excellent reason to do a "bis" document, then! :)

> 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

---

From: Stephen Kent <[email-masked]>
Date: Fri, 17 Dec 2021 17:06:12 -0500

Benjamin,

I agree with your reasoning. I believe this should be labelled as 
"Obsoletes" vs. "Updates".

I also agree that we should have a list of the differences from 6486, 
which probably can be generated via a diff plus some editing. If Job 
wants to take on that task, fine with me!

Steve

---

From: Job Snijders <[email-masked]>
Date: Wed, 22 Dec 2021 12:16:11 +0100

> motivates why the document is being updated or replaced.

This has been added.

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-6486bis-09

Kind regards,

Job

---

From: S Moonesamy <[email-masked]>
Date: Wed, 22 Dec 2021 06:47:27 -0800

Hi Job,
At 03:14 AM 22-12-2021, Job Snijders wrote:
>The -09 version proposes to obsolete 6486.
>
>There is an htmlized version available at:
>https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-6486bis-09
>

Thank you for following up on the comment.

Regards,
S. Moonesamy

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 22 Dec 2021 12:02:06 -0500

thanks Stephen and Job (and probably sekret-editor-in-chef?)
and thanks Benjamin for the clarification :)

On Wed, Dec 22, 2021 at 11:50 AM S Moonesamy <[email-masked]> wrote:

> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 22 Dec 2021 09:18:42 -0800

> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-6486bis-09

Thanks!

-Ben