The Resource Public Key Infrastructure (RPKI) to Router Protocol
RFC 6810

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

(Jari Arkko) Yes

Comment (2012-02-01 for -)
This is a well written and much needed document, thank you for writing it.

(The only worry that I had was that there was a long list of different security mechanisms, perhaps too many for interoperability.)

(Ron Bonica) Yes

(Stewart Bryant) (was Discuss, Yes) Yes

(Russ Housley) Yes

(Peter Saint-Andre) (was Discuss) Yes

Comment (2012-01-30)
I second Pete's query about ASCII-only error text.

The AppsDir review by Lisa Dusseault asks some questions that deserve a response:

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04230.html

Section 2 states:

   Serial Number:  A 32-bit monotonically increasing unsigned integer
      which wraps from 2^32-1 to 0.

Do you mean "strictly increasing" instead of "monotonically increasing"?

Section 10 states:

   This section contains a preliminary list of error codes.  The authors
   expect additions to this section during development of the initial
   implementations.

A forward reference to the IANA considerations would be friendly here.

IDnits reports:

  ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925)

(Sean Turner) Yes

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

Comment (2012-01-29 for -)
Minor editorial suggestion - section 5.10 seems out of order
and would have been more useful to me if it had appeared
before the definitions of the PDU fields in section 5.

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2012-01-31 for -)
I am also concerned about the internationalisability of error strings, but otherwise have no objection to the publication of this document.

(Stephen Farrell) No Objection

Comment (2012-01-29 for -)

- "Formally" and "simple but reliable" in the abstract and intro
seem to be marketing text.

- I (still) don't like where it says you SHOULD do ACLs or
something. (The text in the document uses "..." rather than "or
something" but that's the meaning.)  Just delete the elipsis or
actually give a non-ACL example of what one might sensibly do.

- I agree with the comments about the expansion of MITM but,
like everyone else probably, don't care that much.

(David Harrington) No Objection

(Pete Resnick) No Objection

Comment (2012-01-28 for -)
In 5.9:

   If error text is present, it SHOULD be a
   string in US-ASCII, for maximum portability; if non-US-ASCII
   characters are absolutely required, the error text MUST use UTF-8
   encoding.

I'm trying to suss out what "maximum portability" means. Is UTF-8 known to screw up some implementations (in which case the SHOULD is justified), or is it just that you're being super-conservative, or worse, that you're afraid some non-English might end up in the error log? :-) Unless there's a real worry for interoperability here, just define the thing as UTF-8 (which means that US-ASCII still looks like US-ASCII) and be done with it.

A reference to RFC 3629 might be extra friendly.

(Dan Romascanu) No Objection

Comment (2012-01-30 for -)
1. It would be useful for the readability of the document to have acronyms expanded at the first occurence (starting with RPKI)

2. In Section 5.9:  

> The diagnostic text is optional, if not present the Length of Error
   Text field SHOULD be zero. 

Why is this a SHOULD? 

3. Same: 

> If error text is present, it SHOULD be a
   string in US-ASCII, for maximum portability; if non-US-ASCII
   characters are absolutely required, the error text MUST use UTF-8
   encoding.

Pete already refered to this. RFC 2277 mandates implementing UTF-8, so what is the reason for recommending US-ASCII? 

(Robert Sparks) No Objection