Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)
RFC 6916

I have downgraded my Discuss to a Comment after useful input from Stephen Farrell.

As Stephen Kent points out, the Abstract contains suitable language that scopes the document to CAs participating in the RPKI. Making a similar statement in the Introduction would be helpful.

I continue to feel that the IETF is not in a position to dictate how the RPKI will be run, but I agree that the IETF can dcument the process it believes should be run. I should be happier if the document took a tone more consistent with guidance than with requirement.

I support Russ's DISCUSS about making this BCP, rather than PS.

I support Adrian's DISCUSS point on the ability of the IETF to mandate transition dates and have them mean anything.

I concur that this document ought to be a BCP.

The use of 2119 in this document tickles me, and for weird reasons I think most of it is OK. The IETF procedural MUSTs (like updating documents) I find a bit goofy, but I find the steps like "CAs MUST have reissued all of their signed product sets" to be rather interoperability oriented, albeit about the interoperation of things at an operational level where the endpoints of the "protocol" are humans and organizations. (If you don't do some of these things, interoperability does seem to fail.) Although I agree with Stephen that most of these MUSTs are unnecessary, and I certainly think they're weird, they don't violate my sensibilities. I will use this document as an interesting example in  an upcoming discussion we're going to have at the WG Chairs lunch.

This isn't a DISCUSS, since I assume the IETF has to keep the
ability to ignore process rules such as the ones embedded in
this draft when the need arises, and those rules turn out to
be problematic. I think you could lose all the process MUSTs
if you wanted to, and the idea of the timeline as an RFC, but
I don't object to you having them since if they become badly
problematic, that'll have to be sensibly handled at the time
of a real transition. Put another way - this plan for the
future assumes our current processes remain in place, which
seems fragile to me. 

Overall, I think this would be better re-written as "here's
our best idea for a plan for this transition" and doing so is
good whilst the SIDR WG are active, but I would not expect
this to be interpreted as other than guidance once a few
years have passed and some part(s) of our proceses have
changed and the reality of operating the RPKI demonstrates
that this document got a couple of details wrong. 

Another alternative might be to call for a "phase 0.9999..."
where this RFC MUST be updated as a BCP just before phase 1,
but that might be too self-referential:-)

All that makes me sympathetic to Adrian's discuss but not
supportive of blocking the document on that basis.

- Section 2 says that 6485 "MUST be updated," but that the CP
policy OID will not change. This assumes that RFC meta-data
relationships do not change. 

- The transition timeline as a BCP depends on the concept of
BCP being roughly the same. It could be that a document like
that would not be considered a sensible BCP by then.

- What happens if the dates set out as goals in the
transition timeline document slip? What happens if they slip
by less than the time it takes to update the transition
timeline document? Saying "MUST be re-issued" doesn't seem so
good a plan to me.

- "Suite B" seems like an unfortunate name for an example as
its a term of art that exists in this space but is different.

- 4.5 requires action from "every CA" which also seems
fragile. What if some CA ignores this? What if that one is
too big to fail? 

- 4.7 - what if this date slips signicantly? Are you calling
for the timeline to be re-issued?