Skip to main content

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

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)
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)

                            
Stephen Farrell Former IESG member
Yes
Yes (2013-12-05 for -04)
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)

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -04)

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -04)

                            
Benoît Claise Former IESG member
No Objection
No Objection (for -04)

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -04)

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -04)

                            
Jari Arkko Former IESG member
No Objection
No Objection (2013-12-04 for -04)
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)

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -04)

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -04)

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (2013-11-30 for -04)
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)