An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services
RFC 8183

Note: This ballot was opened for revision 06 and is now closed.

(Joel Jaeggli) Yes

Alvaro Retana Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

(Benoît Claise) No Objection

Comment (2017-01-19 for -06)
No email
send info
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.

Alissa Cooper (was Discuss) No Objection

Comment (2017-02-22 for -08)
No email
send info
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.

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2017-01-18 for -06)
No email
send info
- 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 No Objection

Mirja Kühlewind No Objection

Comment (2017-01-16 for -06)
No email
send info
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...?

(Terry Manderson) No Objection

Alexey Melnikov No Objection

Comment (2017-01-14 for -06)
No email
send info
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.

(Kathleen Moriarty) No Objection