Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)
draft-ietf-sidr-cp-17

I have No Objection to the publication of this document, but there are
a couple of nits I hope the authors will attend to before publication.

---

Missing close parenthesis in the document title.

---

In the Introduction...

   Note: This document is based on the template specified in the
   Internet Engineering Task Force (IETF) standards document RFC 3647
   [RFC3647].  In the interest of keeping the document as short as
   reasonable, a number of sections contained in the template are
   omitted from this policy because they did not apply to this PKI.
   However, we have retained the section numbering scheme employed in
   the RFC to facilitate comparison with the outline in Section 6 of
   the RFC. Each of these omitted sections should be read as "No
   stipulation" in CP/CPS parlance.

In the interestes of disambiguity (for example, once this document
has been published as an RFC) could you please
s/the RFC/RFC 3647/
both times it shows.

---

1.5.4. CP approval procedures

   The IESG MUST approve a replacement BCP that either updates or
   obsoletes this BCP, following the procedures of the IETF Standards
   Process as defined in RFC 2026 [RFC2026].

This is a little amusing. But I think you actually mean...


   Any BCP that either updates or obsoletes this BCP, MUST be approved
   by the IESG following the procedures of the IETF Standards Process as
   defined in RFC 2026 [RFC2026].

---

3.1.2. Need for names to be meaningful

   The Subject name in each certificate SHOULD NOT be "meaningful",
   i.e., the name is NOT intended to convey the identity of the Subject
   to relying parties.

While I understnd the desire for stress, I think s/NOT/not/

---

3.1.3. Anonymity or pseudonymity of subscribers

   Although Subject (and Issuer) names need not be meaningful, and may
   appear "random," anonymity is not a function of this PKI, and thus
   no explicit support for this feature is provided.

Unless there is some special meaning of "pseudonimity" in the security
community, I would suggest dropping it from the section title. The 
section text does not discuss the use of pseudonyms, and (to me) the
use of a pseudonym is destinct from annonymity.

---

3.1.5

s/Subject names/subject names/ at least twice

4.10. Certificate status services

   This PKI does not make provision for use of OCSP or SCVP, because it

Informative references are needed here.

   is anticipated that the primary RPs (ISPs) will acquire and validate
   certificates for all participating resource holders.

Some comments from Ari Keränen:

4.6.7. Notification of certificate issuance by the CA to other entities

   No additional stipulations beyond those of section 4.3.3.

There's no section "4.3.3" in this document; I'd assume you mean "4.4.3" (same problem in sections 4.7.7 and 4.8.7).


13. References

Missing RFC5736 reference (mentioned in Section 1.1.)

Please expand "SIA" on first use and provide a reference if necessary.

In section 4.2.1, I suggest changing "SHOULD never" to "SHOULD NOT".

A few nits:

Abstract: s/Internet resource/Internet Number Resource/

Introduction: s/Internet number resource/Internet Number Resource/

In section 2.4, should this text use RFC 2119 terms:

   This data is supposed to be accessible to the public.

Why are sections 5.1.*, 5.2.* listed as sections with no text?

  Please consider the minor issues raised in the Gen-ART Review by
  Francis Dupont on 24-Feb-2011.