An Infrastructure to Support Secure Internet Routing
RFC 6480

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

(Adrian Farrel) Yes

Comment (2011-03-17 for -)
No email
send info
I am balloting "Yes" for this document, but there are a few minor nits
that I hope the authors will attend to before publication.

---

The Introduction uses "CRL" without explanation. This does show up in
the Terminology section that follows immediately, but it would be nice
to clarify in the Introduction.

---

CRLDP shows up in Figure 3 and nowhere else in the document.
Please add a note to the text.

---

Figure 1 seems to be mysteriously missing.

---

Section 4.3 has a slight disconnect between the specification of access
protocols and the deployment of access protocols. Thus, when you say...

   each function must be implemented by at least one access protocol.

...I think you mean...

   each function must be implemented by at least one access protocol
   deployed by a repository operator.

Similarly, when you say things like...

  Download: Access protocols MUST support the bulk download of  

...it is ambiguous whether you mean "all access protocols" or "at least
one access protocol in the suite of access protocols" or "at least one
access protocol deployed by the repository operator"

---

Section 4.3

   To ensure all relying parties are able to acquire all RPKI signed 
   objects, all publication points MUST be accessible via RSYNC (see 
   [RFC 5781] and [RSYNC]), although other download protocols also be 
   supported.

s/also/may also/

---

Section 5

Since according to this text a manifest is a signed object, and since
the manifest is presumable issued by the authority, I would assume that
a manifest includes itself in its listing. But perhaps you should 
clarify this one way or the other.

Alexey Melnikov (was Discuss) Yes

(Tim Polk) Yes

(Robert Sparks) Yes

(Sean Turner) Yes

(Jari Arkko) No Objection

Comment (2011-03-17 for -)
No email
send info
From Ari Keränen's review:

9. IANA Considerations

   This document requests that the IANA issue RPKI Certificates for the
   resources for which it is authoritative, i.e., reserved IPv4
   addresses, IPv6 Unique Local Addresses (ULAs), and address space not
   yet allocated by IANA to the RIRs. 

It would be good to have explicit references to the documents where each of these "resources" are defined.

draft-ietf-sidr-iana-objects-01 lists also AS numbers as such a resource; should that be listed here too?

(Ron Bonica) No Objection

(Stewart Bryant) (was Discuss, Yes) No Objection

(Russ Housley) No Objection

Comment (2011-03-15 for -)
No email
send info
  Please consider the comments from the Gen-ART Review by
  David Black on 24-Feb-2011.

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection