My confusion - sorry for the dup posting.

On 10/03/2010, at 7:13 AM, Sandra Murphy wrote:

> If the "have been informed" was my message today, I was talking about the 
> message you posted Nov 30, the one I attached to my message, in which you 
> said that the authors should address the comments received, pointed to the 
> issue tracker, etc, for the sidr-cp-07 version.
> 
> --Sandy
> 
> On Wed, 10 Mar 2010, Geoff Huston wrote:
> 
>> [I have been informed that my note I posted yesterday in response to the 
>> Last Call did not get circulated on the SIDR mailing list - I'll try once 
>> more - Geoff]
>> 
>> 
>> I do not believe that this document is ready for submission to the IESG. 
>> Some issues still remain with this document, as listed below.
>> 
>> Geoff
>> 
>> On 06/03/2010, at 9:05 AM, Sandra Murphy wrote:
>> 
>>> The authors of Certificate Policy (CP) for the Resource PKI (RPKI) have 
>>> submitted a new version in accordance with comments received in the last 
>>> call (http://tools.ietf.org/html/draft-ietf-sidr-cp-08).
>>> 
>>> I am opening a last call on this document for one week, ending Friday, 
>>> March 12.
>>> 
>>> Note that comments on this revision are restricted to whether the issues 
>>> have been adequately addressed.
>>> 
>> 
>> 1. Introduction, para 1 - is the use of the verb "will" normative (i.e. 
>> MUST), or intentional "SHOULD" or optional" "MAY". I'd like to see the 
>> second sentence changed to say "MAY" or if that is not acceptable, to say 
>> "may"
>> 
>> 2. Introduction, para 1 - third sentence - is this "will" more accurately a 
>> "can"
>> 
>> 3. Introduction, para1, third sentence - "uniqueness" is not an outcome of 
>> verification of a certificate. It would be more accurate to drop 
>> "uniqueness" from this assertion.
>> 
>> 4. section 1.2, para 1. The same assertion is made that associated 
>> certification with uniqueness. The constraint on an address issuer that 
>> creates a unique distribution of resources is not an intrinsic attribute of 
>> certification of the issuance.
>> 
>> 5. section 1.4.1 - the document appears to preclude the actions of LIRs / 
>> ISPS in distributing AS numbers. I do not believe that this is appropriate, 
>> nor accurate, in today's environment
>> 
>> 6. section 2.2 - is a CA responsible for publishing ALL certifications it 
>> issues, or can it be selective in publication? The section is unclear on this
>> 
>> 7. section 2.2 - a similar question is raised regarding CRLs and RPKI-signed 
>> objects. Is the CA requires to publish ALL such issued objects?
>> 
>> 8 section 2.3 - the document does not specify a CA's actions regarding the 
>> publication of expired and revoked certifications, nor indicate of the CA's 
>> CPS should include such information.
>> 
>> 9. section 2.4 - is the "shall" here a "SHALL" in a normative sense or a 
>> "MAY"?
>> 
>> 10. section 3.2.1 - is this "will require" a MUST require or a SHOULD 
>> require?
>> 
>> 11. section 3.2.2 - is this "will" a MUST, SHOULD or a MAY?
>> 
>> 12. section 3.2.3 - is this "will" a MUST, SHOULD or a MAY?
>> 
>> 13. section 3.2.5 - is this "will" a MUST, SHOULD or a MAY? - This occurs in 
>> subsequent sections that describe actions of the CA, and the use of 
>> normative language in describing these CA actions is recommended. These 
>> instances are not further flagged here,.
>> 
>> 14. sections 3.2 and 3.2 - I am not sure that these need to be separate - 
>> for example is issuance after revocation any different from initial issuance 
>> - i.e. the same criteria of 3.2.1, 3.2.2, 3.2.3 and 3.2.5 apply, so why is 
>> 3.3.2 called out - what new information is being provided here that is not 
>> already provided in the previous section?
>> 
>> 15. section 3.4 - why does this section of the text NOT refer to the actions 
>> of a CA as described in sections 3.2.1, 3.2.2, 3.2.3 and 3.2.5? It appears 
>> that revocation is described in more informal terms and issuance, yet the 
>> constraints on the CA to ensure that authenticity of the request are 
>> intended to be the same.
>> 
>> 16. section 4.1.1 - normative language required - the "should" referred to 
>> here is unclear. Subsequent sections also use "should" where normative 
>> language would be clearer.
>> 
>> 17. section 4.5.2 - this section refers to "all the CAs in the chain that 
>> issued the certificates relevant to the certificate in question" without 
>> further clarification or explanation. In the light of related work on local 
>> TA generation I am left with the question of what exactly is being referred 
>> to here in this "chain"./ I would prefer this term to be defined.
>> 
>> 18. section 4.8 - why is the treatment of augmentation of a subject's INRs 
>> treated differently to  reduction in a subject's INRs? While section 4.8 
>> deals with the steps involved in issuing a new certification in the case 
>> where a subject's INR's are augmented, there is no corresponding description 
>> of the process in reduction, other that the single sentence in section 4.8.1 
>> that does not refer to any other part of the CPS.
>> 
>> 19 section 4.10 - is it truye to say that "This PKI does not make use of 
>> OCSP or SCVP" or is it more appropriate to state that "RPs SHOULD NOT rely 
>> on the use of OCSP or SCVP"?
>> 
>> 20 - section 5.8 "The termination of a CA shall therefore be subject to the 
>> agreement between the issuer and the subscriber and will be described in the 
>> CPS for the issuer." I am finding it difficult to reconcile this need for 
>> "an agreement" in the light of the observation that where a CA no longer has 
>> any INR resources then it cannot function as a CA in the RPKI, whether or 
>> not an agreement is reached, Why then is an agreement stipulated here?
>> 
>> Style comment:
>> 
>> Is the use of double ' chars instead of a " or ' char deliberate? For 
>> example, I would've expected to see " marks in section 1.3 when describing 
>> the name of the document, and thereafter when denoting the use of particular 
>> terms.
>> 
>> 
>> 

_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to