On 3/4/13 6:16 PM, David Mandelberg wrote:
Overall this looks good. I found one minor issue and a bunch of nits,
and I have some questions:
= minor =
4.6.7. Notification of Certificate Issuance by the CA to Other Entities:
There is no section 4.4.3.
fixed.
= questions =
1.5.1. Organization administering the document: Should the address
and/or website of the organization also be included? That could help
disambiguate when there are multiple organizations with the same or
similar names.
reworded to include these additional pieces of info.
4.1.2. Enrollment Process and Responsibilities: I found the second
sentence unclear. Are you trying to tell registries and ISPs that
certificates should be issued as part of their normal business
practices? Are you trying to say that *if* certificates are issued as
part of normal business practices *then* "a separate application to
request a certificate may not be necessary"?
the text is saying that an org allocating INRs is already establishing a
relationship with the subject, and thus need not repeat that process when
it issues an RPKI cert.
4.6.1. Circumstance for Certificate Renewal: The phrase "unless the
private key has been reported as compromised" doesn't specify how a
compromised key can be reported. Should there be a reference to section
4.9.3?
added forward pointer.
4.7.1. Circumstance for Certificate Re-key: What Certificate Policy is
"Section 5.6 of the Certificate Policy" referring to? Section 5.6 of
RFC6484 doesn't mention validity intervals.
The CP used to refer to this validity interval issue, but
it later changed, as did the admonition. We'll delete the paragraph.
5.4.1. Types of Events Recorded: Why aren't "Key generation", "Software
and/or configuration updates to the CA", and "Clock adjustments" listed?
5.6. Key Changeover: Does mention of validity intervals belong in this
section?
= nits =
Multiple places: Should "the RPKI CP" be changed to "[RFC6484]"?
sure.
Preface: item 5 lists "Acknowledgments" three times (twice as
"Acknowledgments", once as "12").
fixed.
1. Introduction: "(INRs, see definition in Section 1.7)" references a
non-existent section 1.7.
changed to 1.6
1.1. Overview: Change "as described in 2.4" to "as described in Section
2.4".
fixed.
1.4.1. Appropriate Certificate Uses: Change "2.4" to "Section 2.4".
fixed
2.2. Publication of Certification Information: Should the hyphen in
"RPKI-signed objects" be changed to a space?
yes, fixed.
2.3. Time or Frequency of Publication: Change "nextScheduledUpdate" to
"nextUpdate".
fixed.
3.1.2. Need for Names to be Meaningful: The first two sentences seem
redundant with section 3.1.5.
removed redundant sentences.
3.2.6. Criteria for Interoperation: Change "e g." to "e.g.".
fixed.
4.1.1. Who Can Submit a Certificate Application: Should "this
Organization" be changed to "<Name of Organization>"?
reworded.
4.2.2. Approval or Rejection of Certificate Applications: Change "3.2.1"
to "Section 3.2.1".
fixed
4.4.2. Publication of the Certificate by the CA: Insert space in
"notified>.<Describe".
fixed.
4.6.4. Notification of New Certificate Issuance to Subscriber: Change
"4.3.2" to "Section 4.3.2".
fixed.
4.7.2. Who May Request Certification of a New Public Key: Change "or" in
"holder or a certificate" to "of".
fixed.
4.9.7. CRL Issuance Frequency: Change "nextScheduledUpdate" to
"nextUpdate".
fixed.
5.7. Compromise and disaster recovery [OMITTED] and 5.8. CA or RA
Termination: These section numbers don't match up with rfc 6484.
Whoops. the CP lost an [OMITTED] subsection # here. "CA or RA
Termination" is supposed to be 5.8, not 5.7.
so the CPS is correct, re alignment with RFC 3647. Guess we'll have to
issue an editorial errata for the CP.
Steve
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
