The Resource Public Key Infrastructure (RPKI) to Router Protocol
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
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?