Hi Steve, I appreciate the very rapid revisions.
I am perfectly happy with all of the proposed revisions below. I think the amended document is ready to progress. Cheers Terry On 28/02/2013, at 4:26 PM, Stephen Kent wrote: > Terry, > > Thanks for the feedback. Below are responses to your comments. > > On 2/27/13 11:48 PM, Terry Manderson wrote: >> Apologies for taking so long to review this document. >> >> This is a well constructed template and I have only 6 concerns to be >> addressed. >> >> 1) My first observation is that the CPS takes an organisational view (and >> that is expected) of the RPKI CA's in action, and while it certainly >> provides allowances for multiple CA's within an organisation (s 1.3.1) >> There are situations that the 'organisation' will have different >> personalities. To which I would like "organisation" to also explicitly >> include wording that includes 'business unit.' >> > How about the following revision to the preface: > > This document contains a template to be used for creating a > Certification Practice Statement (CPS) for an Organization that is > part of the Resource Public Key Infrastructure (RPKI). (Throughout this > document > the term “Organization” is used broadly, e.g., the entity in question > might > be a business unit of a larger organization.) >> 2) In section 1.3.5, "Specify the entity that operatesŠ" Entity should >> most definitely be plural. Yes, I accept that is a little(?) picky. >> > <Specify one or more entities that operate a repository holding > certificates, > CRLs, and other RPKI-signed objects issued by this Organization, and > provide a URL for the repository.> >> 3) Nit: Section 1.6 Page 11. There appears to be an extra "<tab>-" in the >> definition if ISP, NIR, and RPKI-signed object. >> > fixed. >> 4) Section 2.1 "via RSYNC". Can that be adjusted to "standardised >> mechanisms supported by RPKI"? or something similar? >> > The <Name of Organization> RPKI CA will publish certificates, CRLs, > and RPKI-signed objects via a repository that is accessible via > <insert SIDR-designted protocol name here> at <insert URL here>. This > repository will > conform to the structure described in [RFC6481]. >> 5) In section 4.1.1, can "Any subscriber who holds..", be amended to "Any >> vetted and approved subscriber who holds.." >> > Any subscriber in good standing who holds INRs distributed by this > Organization may submit a certificate application to this CA. > >> 6) Can you explain why compromise and disaster recovery (s5.7) was omitted >> from the template? >> >> > 5.7. Compromise and disaster recovery > > <Describe your plans for dealing with CA key compromise and how you > plan to continue/restore operation of your RPKI CA in the event of a > disaster.> > > > Steve > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
