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 TBSCertificate<1..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. _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
