An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services
draft-ietf-sidr-rpki-oob-setup-09

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