A Publication Protocol for the Resource Public Key Infrastructure (RPKI)
draft-ietf-sidr-publication-12
Yes
(Alvaro Retana)
(Joel Jaeggli)
No Objection
(Alia Atlas)
(Benoît Claise)
(Deborah Brungard)
(Jari Arkko)
(Spencer Dawkins)
(Suresh Krishnan)
Note: This ballot was opened for revision 10 and is now closed.
Alvaro Retana Former IESG member
Yes
Yes
(for -10)
Unknown
Joel Jaeggli Former IESG member
Yes
Yes
(for -10)
Unknown
Alexey Melnikov Former IESG member
(was Discuss)
No Objection
No Objection
(2017-02-26 for -11)
Unknown
Thank you for addressing my DISCUSS point. A couple of remaining issues: I still think lack of details about versionning and what requires (or not) to bump the version number is a mistake. RFC 2616 (HTTP) got obsoleted, please reference the latest version. In 2.5: is the list of error reasons extensible? If yes, should you have an IANA registry for them? In Section 5 you should reference this document (and not just section numbers), as IANA registrations cut & pasted to IANA website as separate files.
Alia Atlas Former IESG member
No Objection
No Objection
(for -10)
Unknown
Alissa Cooper Former IESG member
(was Discuss)
No Objection
No Objection
(2017-02-22 for -11)
Unknown
Thanks for addressing my DISCUSS.
Ben Campbell Former IESG member
No Objection
No Objection
(2017-01-18 for -10)
Unknown
Most of my comments have already been made by others. But with the questions about upgrade paths, I see there is in fact a "version" element defined. How is that expected to be used? I don't see a version related error code.
Benoît Claise Former IESG member
No Objection
No Objection
(for -10)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -10)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -10)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2017-01-18 for -10)
Unknown
Thanks for addressing the security directorate review. As for Alissa's comment on transport, more language added to the Security Considerations section would be helpful to explain why the CMS signature is sufficient. I am assuming that the only exposure would be to public information during transport that is protected from tampering, unless I missed something in reading the draft (I don't think you are transferring private keys and didn't see that in the text). Security controls being managed according to the CA policy mentioned earlier in the document is appropriate, having run CAs before - there are strict requirements already depending on the level you plan to run the CA.
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2017-01-16 for -10)
Unknown
My only question is why this is a sidr wg doc? This seems like a general mechanism that cannot only be used in the routing infrastructure. Has this doc been at least reviewed by other wgs?
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -10)
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2017-02-22 for -11)
Unknown
Thanks for addressing my discuss about alg agility.
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -10)
Unknown
Terry Manderson Former IESG member
(was Discuss)
No Objection
No Objection
(2017-03-26)
Unknown
Thank you for the discussion and resolution.