Resource Public Key Infrastructure (RPKI) Router Implementation Report
RFC 7128

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

(Richard Barnes; former steering group member) Yes

Yes (2013-12-04 for -04)
No email
send info
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 steering group member) Yes

Yes ( for -04)
No email
send info

(Stephen Farrell; former steering group member) Yes

Yes (2013-12-05 for -04)
No email
send info
Yep - pity about so many "NO" entries in the 
security/transport table. Be nice to see more
YES entries there.

(Stewart Bryant; former steering group member) Yes

Yes ( for -04)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Benoît Claise; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Brian Haberman; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection (2013-12-04 for -04)
No email
send info
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 steering group member) No Objection

No Objection ( for -04)
No email
send info

(Martin Stiemerling; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Pete Resnick; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Spencer Dawkins; former steering group member) No Objection

No Objection (2013-11-30 for -04)
No email
send info
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 steering group member) No Objection

No Objection ( for -04)
No email
send info