Re: [Gen-art] review of draft-laurie-pki-sunlight-07.txt
In your previous mail you wrote: Minor issues: = BTW I received a side comment stating the document is too long and should be split into 3 parts (maths, mechanisms, application). Of course you may answer it is too late... - section 2 is not enough accurate, for instance: * the critical [k1:k2] notation is introduced after its first use, IMHO it is the primary one, i.e., [n] is a short hand for [0:n] Notation is rather tricky here, but I don't think that saying D[n] is shorthand for D[0:n] adds clarity. This is because D[k:n] becomes D[n-k] on recursion. Saying D[k:n] is the same as D[0:n-k] is just confusing (and, indeed, wrong). = I don't say D[k:n] is the same as D[0:n-k], just that D[0:n-k] is the same than D[n-k]. But this is a matter of taste and I have no good proposal to make this section very clear... * the largest power of two must be strictly smaller, not just smaller. There is no difference between strictly smaller and smaller (in contrast to decreasing and strictly decreasing). = it is a language problem: I leave it to native English speaker. - 1 page 4: it is a general mechanism but what are its constraints at the exception of the intended usage. For instance is the mechanism applicable to any end entity public key certificate? or larger?? I don't know what this comment refers to. = you have a mechanism which can be applied to more than public TLS server certificates. IMHO it should be fine to put a few words about the technical (vs usage) scope of the mechanism. Note the term general before mechanism and the very limited scope are both at the end of the first paragraph of section 1. - 1 page 5: misbehaviours - misbehaviors (and 3.3 page 16, and others too) I am not American. = nor I am: I just applied an american English spell checker and reported what it considered as spelling errors. Note that RFCs are supposed to be written in american English (even it is not a strict rule at all), and what I did is a good practice when they are many authors from different countries (i.e., in the general case). - 2.1.1 page 7 and 2.1.2 page 8: the wording the length (k2 - k1) list is IMHO a bit uncommon even I can understand it. It's maths. = I am clearly under the Bourbaki's influence (i.e., maths should be written in the best possible wording :-). - 2.1.4 page 10: using a key of at least 2048 bits. - using a public key of at least 2048 bits. (or a modulus as it is for RSA ?) The public and private keys are the same length in RSA (and the length is the length of the modulus). = as keys in RSA are not integers but tuples of integers they have no length by themselves. Now I agree the common meaning is what you say so I remove my comment (i.e., to be more accurate will be pedantic without a clear benefit). - 3 pages 13, 14, etc: what is the language used for ASN.1? It is not ASN.1 itself, nor C? The format of certificates is defined elsewhere. The name ASN.1Cert (which is what I assume you refer to) is taken from RFC 5246. = oops, I missed the 1.2 where this was stated. - 3.1 page 13: parenthesis around 65535 are not necessary (i.e, they are insipid and stupid :-) I love you, too. = I thought you know the LISP programming language acronym... (I was a LISP programmer so I know all jokes about LISP :-) In fact, they are required, see section 4.5 of RFC 5246. = I see. But in this case there are spurious 255 (not (255) as the default is one byte?). RFC 5246 uses (255) so I suggest to change all 255 at the end of enums into (255) *if* you have the opportunity to do this. BTW if the document creates new OID perhaps they should be put in an annex? I am not aware of a requirement to do so. = nor I am (this is why I put a question mark) PS: I noted there are still some LC comments in the ML. I am not aware of any I have missed. = it was just a reminder to the LC comment statement at the beginning of the standard gen-art template, and an indication to other gen-art ML readers. Thanks francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] review of draft-laurie-pki-sunlight-07.txt
On 1 March 2013 12:11, Francis Dupont francis.dup...@fdupont.fr wrote: In your previous mail you wrote: Minor issues: = BTW I received a side comment stating the document is too long and should be split into 3 parts (maths, mechanisms, application). Of course you may answer it is too late... I do. Way too late. :-) Also, I'd observe that increasing the number of documents will not decrease the amount of reading. - section 2 is not enough accurate, for instance: * the critical [k1:k2] notation is introduced after its first use, IMHO it is the primary one, i.e., [n] is a short hand for [0:n] Notation is rather tricky here, but I don't think that saying D[n] is shorthand for D[0:n] adds clarity. This is because D[k:n] becomes D[n-k] on recursion. Saying D[k:n] is the same as D[0:n-k] is just confusing (and, indeed, wrong). = I don't say D[k:n] is the same as D[0:n-k], just that D[0:n-k] is the same than D[n-k]. But this is a matter of taste and I have no good proposal to make this section very clear... * the largest power of two must be strictly smaller, not just smaller. There is no difference between strictly smaller and smaller (in contrast to decreasing and strictly decreasing). = it is a language problem: I leave it to native English speaker. This was explained to me offlist. Certainly there is no problem in English, but I understand other languages don't work as well. So, I added mathematical notation for clarity. - 1 page 4: it is a general mechanism but what are its constraints at the exception of the intended usage. For instance is the mechanism applicable to any end entity public key certificate? or larger?? I don't know what this comment refers to. = you have a mechanism which can be applied to more than public TLS server certificates. IMHO it should be fine to put a few words about the technical (vs usage) scope of the mechanism. Note the term general before mechanism and the very limited scope are both at the end of the first paragraph of section 1. - 1 page 5: misbehaviours - misbehaviors (and 3.3 page 16, and others too) I am not American. = nor I am: I just applied an american English spell checker and reported what it considered as spelling errors. Note that RFCs are supposed to be written in american English (even it is not a strict rule at all), and what I did is a good practice when they are many authors from different countries (i.e., in the general case). The style guide (http://www.rfc-editor.org/rfc-style-guide/rfc-style) says English. - 2.1.1 page 7 and 2.1.2 page 8: the wording the length (k2 - k1) list is IMHO a bit uncommon even I can understand it. It's maths. = I am clearly under the Bourbaki's influence (i.e., maths should be written in the best possible wording :-). I changed it anyway :-) - 2.1.4 page 10: using a key of at least 2048 bits. - using a public key of at least 2048 bits. (or a modulus as it is for RSA ?) The public and private keys are the same length in RSA (and the length is the length of the modulus). = as keys in RSA are not integers but tuples of integers they have no length by themselves. Now I agree the common meaning is what you say so I remove my comment (i.e., to be more accurate will be pedantic without a clear benefit). - 3 pages 13, 14, etc: what is the language used for ASN.1? It is not ASN.1 itself, nor C? The format of certificates is defined elsewhere. The name ASN.1Cert (which is what I assume you refer to) is taken from RFC 5246. = oops, I missed the 1.2 where this was stated. - 3.1 page 13: parenthesis around 65535 are not necessary (i.e, they are insipid and stupid :-) I love you, too. = I thought you know the LISP programming language acronym... (I was a LISP programmer so I know all jokes about LISP :-) Heh. I always thought it was irritating, not insipid. In fact, they are required, see section 4.5 of RFC 5246. = I see. But in this case there are spurious 255 (not (255) as the default is one byte?). RFC 5246 uses (255) so I suggest to change all 255 at the end of enums into (255) *if* you have the opportunity to do this. You are right, I will change them. BTW if the document creates new OID perhaps they should be put in an annex? I am not aware of a requirement to do so. = nor I am (this is why I put a question mark) PS: I noted there are still some LC comments in the ML. I am not aware of any I have missed. = it was just a reminder to the LC comment statement at the beginning of the standard gen-art template, and an indication to other gen-art ML readers. I see. Thanks! ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] review of draft-laurie-pki-sunlight-07.txt
On 18 February 2013 14:53, Francis Dupont francis.dup...@fdupont.fr wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-laurie-pki-sunlight-07.txt Reviewer: Francis Dupont Review Date: 20130208 IETF LC End Date: 20130226 IESG Telechat date: unknown Summary: Almost Ready Major issues: None Minor issues: - section 2 is not enough accurate, for instance: * the critical [k1:k2] notation is introduced after its first use, IMHO it is the primary one, i.e., [n] is a short hand for [0:n] Notation is rather tricky here, but I don't think that saying D[n] is shorthand for D[0:n] adds clarity. This is because D[k:n] becomes D[n-k] on recursion. Saying D[k:n] is the same as D[0:n-k] is just confusing (and, indeed, wrong). * the largest power of two must be strictly smaller, not just smaller. There is no difference between strictly smaller and smaller (in contrast to decreasing and strictly decreasing). Without this critical detail recursion rules don't work for n = 2^m Unfortunately there is no wikipedia or equivalent web page where to refer to so the document is the place where all gory details have to be... - the Maximum Merge Delay (MMD) is an important parameter but I can't find where is the way users get its value, nor any recommendation for it. We anticipate that this will be published in some kind of human readable policy. Nits/editorial comments: - 1 page 4: CA is not a well known abbrev so please introduce it (cf http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt) Fixed. - 1 page 4: it is a general mechanism but what are its constraints at the exception of the intended usage. For instance is the mechanism applicable to any end entity public key certificate? or larger?? I don't know what this comment refers to. - 1 page 5: misbehaviours - misbehaviors (and 3.3 page 16, and others too) I am not American. - 1 page 5: e.g. - e.g., Fixed. - 2.1.1 page 6: i.e. - i.e., Fixed. - 2.1.1 page 7 and 2.1.2 page 8: the wording the length (k2 - k1) list is IMHO a bit uncommon even I can understand it. It's maths. - 2.1.4 page 10: using a key of at least 2048 bits. - using a public key of at least 2048 bits. (or a modulus as it is for RSA?) The public and private keys are the same length in RSA (and the length is the length of the modulus). - 3 pages 13, 14, etc: what is the language used for ASN.1? It is not ASN.1 itself, nor C? The format of certificates is defined elsewhere. The name ASN.1Cert (which is what I assume you refer to) is taken from RFC 5246. - 3.1 page 12: accomodate - accommodate Fixed. - 3.1 page 13: parenthesis around 65535 are not necessary (i.e, they are insipid and stupid :-) I love you, too. In fact, they are required, see section 4.5 of RFC 5246. - 3.1 page 13: submmited - submitted Fixed. - 3.2 page 14: opaque TBSCertificate1..2^16-1 add final ';' Fixed. - 4.6 page 22: honour - honor No. - 4.6 page 22: convering - covering? Fixed. BTW if the document creates new OID perhaps they should be put in an annex? I am not aware of a requirement to do so. Thanks for your comments! Regards francis.dup...@fdupont.fr PS: I noted there are still some LC comments in the ML. I am not aware of any I have missed. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
