Resource Public Key Infrastructure (RPKI) Router Implementation Report
draft-ietf-sidr-rpki-rtr-impl-05
Yes
(Sean Turner)
(Stewart Bryant)
No Objection
(Adrian Farrel)
(Barry Leiba)
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Ted Lemon)
Note: This ballot was opened for revision 04 and is now closed.
Richard Barnes Former IESG member
Yes
Yes
(2013-12-04 for -04)
Unknown
Editorial nit: It seems clear that some of these implementations are client-only and some server-only (not clear if any are both, maybe rpki.net). It might be helpful to note somewhere which is which, and maybe group the table columns into clients and servers. It's disappointing that the transport report in Section 5 does not indicate that any secure transport is universally supported. Given that SSH seems to enjoy pretty wide support, might it be worth considering updating RFC 6810 to say that SSH MUST be implemented, at least by servers? Not a comment for this document, but for the WG more generally.
Sean Turner Former IESG member
Yes
Yes
(for -04)
Unknown
Stephen Farrell Former IESG member
Yes
Yes
(2013-12-05 for -04)
Unknown
Yep - pity about so many "NO" entries in the security/transport table. Be nice to see more YES entries there.
Stewart Bryant Former IESG member
Yes
Yes
(for -04)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -04)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -04)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -04)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -04)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -04)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2013-12-04 for -04)
Unknown
Suresh Krishnan's Gen-ART review raised some questions. Is there an answer? ---- Summary: This draft is ready for publication as an Informational RFC but I do have a few comments that the authors may wish to consider. Minor ===== * Section 4 -> The sequences specified in this section do not map directly onto the sequences mentioned in Section 6 of RFC6810. Not sure why there is a mismatch. -> It is unclear what the following footnote means since the row is concerning S2 and Section 6.2 of RFC6810 is the one that deals with a typical exchange. "1) NO, we always respond as described in 6.3 of [RFC6810]" * Section 5 RFC6810 does talk about IPsec as a transport at a SHOULD level, but it is not at all covered here in the support table.
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -04)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -04)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -04)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2013-11-30 for -04)
Unknown
Thank you for carrying out this work. I have one question (at comment level, I'm already No-Obj), and I'm not sure whether I lack imagination or math skills. In this text: 4. Protocol Sequence Does RPKI Router protocol implementation follow the four protocol sequences as outlined in Section 6 of [RFC6810]? S1: Start or Restart S2: Typical Exchange S3: Generation of Incremental Updates Sequence S4: Receipt of Incremental Updates Sequence S5: Generation of Cache has No data Sequence I'm counting five sequences here, but when I compare to the four sequences in Section 6 of [RFC6810], I see 6. Protocol Sequences The sequences of PDU transmissions fall into three conversations as follows: 6.1. Start or Restart 6.2. Typical Exchange 6.3. No Incremental Update Available 6.4. Cache Has No Data Available So, if I was trying to guess, I'd guess this (but I'm guessing): S1 = 6.1 S2 = 6.2 S3 = ? S4 = ? ? = 6.3 S5 = 6.4 Obviously, I'm only pattern matching, so if this is super clear to everyone else, please carry on ... but I'm confused.
Ted Lemon Former IESG member
No Objection
No Objection
(for -04)
Unknown