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
