An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services
draft-ietf-sidr-rpki-oob-setup-09
Yes
(Alvaro Retana)
(Joel Jaeggli)
No Objection
(Alia Atlas)
(Ben Campbell)
(Deborah Brungard)
(Jari Arkko)
(Kathleen Moriarty)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)
Note: This ballot was opened for revision 06 and is now closed.
Alvaro Retana Former IESG member
Yes
Yes
(for -06)
Unknown
Joel Jaeggli Former IESG member
Yes
Yes
(for -06)
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(2017-01-14 for -06)
Unknown
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 IESG member
No Objection
No Objection
(for -06)
Unknown
Alissa Cooper Former IESG member
(was Discuss)
No Objection
No Objection
(2017-02-22 for -08)
Unknown
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 IESG member
No Objection
No Objection
(for -06)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(2017-01-19 for -06)
Unknown
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 IESG member
No Objection
No Objection
(for -06)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -06)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -06)
Unknown
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2017-01-16 for -06)
Unknown
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 IESG member
No Objection
No Objection
(for -06)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2017-01-18 for -06)
Unknown
- 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 IESG member
No Objection
No Objection
(for -06)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -06)
Unknown