An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services
Note: This ballot was opened for revision 06 and is now closed.
Alvaro Retana Yes
(Joel Jaeggli; former steering group member) Yes
(Alexey Melnikov; former steering group member) No Objection
I have a small list of minor issues that should be addressed before this document is approved: Base64 needs a normative reference (including the section number, as there are 2 variants). HTTP URI need a normative reference. Are HTTPS URIs allowed where HTTP URIs are mentioned in the document? In 5.3: id-ct-xml needs a reference.
(Alia Atlas; former steering group member) No Objection
(Alissa Cooper; former steering group member) (was Discuss) No Objection
Thanks for addressing my DISCUSS points, keeping COMMENTs below for posterity. 5.2.4: Per my comment on draft-ietf-sidr-publication, it would be good if service_uri accommodated either HTTPS or HTTP URLs, if HTTP URLs must be supported. 5.4: If it becomes obvious that a new reason code needs to be added to the <error /> element in the future, will that require a new version of the protocol? That seems like a bit of a heavy lift as compared to, say, creating a registry for these with an appropriate registration policy.
(Ben Campbell; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
The title is misleading with "setup protocol". From RFC 2026: 3.1 Technical Specification (TS) A Technical Specification is any description of a protocol, service, procedure, convention, or format We deal with a "format" here or maybe messages definition. Thankfully, the abstract is rather clear that is the protocol is unspecified. So it's not THAT bad.
(Deborah Brungard; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
High level comment: I'm not sure if 'protocol' is the right term for this spec. For me this doc rather defines a set of messages, however given it does not specify any action that must follow as a reaction to a message (as well as no choice of the publication nor BPKI protocol), I find the term 'protocol' here rather confusing. Smaller comments: - Some more abbreviations could be spelled out, e.g. CMS - section 2 is not needed - sec 5: "Appendix A is a [RelaxNG] schema for this protocol. The schema is normative: in the event of a disagreement between the schema and the following textual description, the schema is authoritative." I guess in this case the schema should not be in the appendix. And would it be possible to make sure the schema does not disagree with the text...?
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
- abstract: would it be better to replace "agreeable secure means" here with "agreeable means that provides acceptable data integrity and authentication" ? Just a suggestion. - all examples: the xmlns attribute value gets me a 404. (I mean for "http://www.hactrn.net/uris/rpki/rpki-setup/") While that's ok since we don't want folks to de-reference that at run-time, it might be better if it returned the schema or something useful. And would https be even better there? (Not sure, been a while since I've xml'd;-) - examples would be better with Figure numbers and brief captions. - 5.2.1: Do we really want references to mathematical deities in examples? Real keys would be better, but that said, I do like the whimsical content of those I decoded;-) - As it happens I disagree with Alissa's discuss. This seems clear enough to me, same as any sneakernet protocol.
(Suresh Krishnan; former steering group member) No Objection
(Terry Manderson; former steering group member) No Objection