Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)
RFC 6916
Yes
No Objection
Recuse
Note: This ballot was opened for revision 10 and is now closed.
(Stewart Bryant; former steering group member) Yes
(Adrian Farrel; former steering group member) (was Discuss) No Objection
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.
(Barry Leiba; former steering group member) No Objection
I support Russ's DISCUSS about making this BCP, rather than PS.
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
I support Adrian's DISCUSS point on the ability of the IETF to mandate transition dates and have them mean anything.
(Gonzalo Camarillo; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
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.
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
(Stephen Farrell; former steering group member) No Objection
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?
(Wesley Eddy; former steering group member) No Objection
(Sean Turner; former steering group member) Recuse