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
