Ballot for draft-ietf-sidr-rpki-oob-setup
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
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.
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.
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.
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...?
- 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.