Skip to main content

The Resource Public Key Infrastructure (RPKI) to Router Protocol
draft-ietf-sidr-rpki-rtr-26

Yes

(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Stewart Bryant)

No Objection

(David Harrington)
(Gonzalo Camarillo)
(Robert Sparks)
(Wesley Eddy)

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

Jari Arkko Former IESG member
Yes
Yes (2012-02-01) Unknown
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.)
Peter Saint-Andre Former IESG member
(was Discuss) Yes
Yes (2012-01-30) Unknown
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)
Ron Bonica Former IESG member
Yes
Yes () Unknown

                            
Russ Housley Former IESG member
Yes
Yes () Unknown

                            
Sean Turner Former IESG member
Yes
Yes () Unknown

                            
Stewart Bryant Former IESG member
(was Discuss, Yes) Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2012-01-31) Unknown
I am also concerned about the internationalisability of error strings, but otherwise have no objection to the publication of this document.
Dan Romascanu Former IESG member
No Objection
No Objection (2012-01-30) Unknown
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? 
David Harrington Former IESG member
No Objection
No Objection () Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection () Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2012-01-28) Unknown
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.
Ralph Droms Former IESG member
No Objection
No Objection (2012-01-29) Unknown
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.
Robert Sparks Former IESG member
No Objection
No Objection () Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2012-01-29) Unknown

- "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.
Wesley Eddy Former IESG member
No Objection
No Objection () Unknown