Comments in-line. Also note that I've made the reference to RFC 3236 normative instead of informative. Although RFC 3236 is an informative RFC, it is required to implement the contents of this document, in which case RFC 3967 seems to require it to be a normative reference.
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 18, 2007 8:38 AM > To: [email protected] > Cc: Guido Appenzeller; Luther Martin; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: reiew of draft-ietf-smime-ibearch-05.txt > > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-smime-ibearch-05.txt > Reviewer: Francis Dupont > Review Date: 2007-10-18 > IETF LC End Date: 2007-10-25 > IESG Telechat date: unknown > > Summary: Not Ready > > Comments: the Not Ready comes mainly from the missing ASN.1 summary. > Other things: > - Abstract page 1: "generate their public key" the wording is not > good, I prefer the introduction one Changed to reflect this comment. > - ToC page 2: the 2.x.y titles overflow Changed to reflect this comment. > - 2.1 page 4 and some others: i.e. -> i.e., and e.g. -> e.g., Changed to reflect this comment. > - 2.2 page 4: the wording of: > The recipient's IBE public parameters allow the > creation of unique public and private keys. > is bad: one can understand these parameters are needed to create each > time a new private key. The text after is clearer so it is just a > wording > issue. Changed to reflect this comment. > - 2.2 page 5: send someone -> send to someone and send them -> send to > them Changed to reflect this comment. > - 2.2.1 page 6: the use of PKGs that require -> requires? > (it is just a question, i.e., a matter of taste) I believe that the current wording is grammatically correct. > - 2.2.2 page 6: key key -> key Changed to reflect this comment. > - 2.3 page 7: about HTTPS: after TLS 1.1 is always required and HTTP is > sometimes cited. As it is better/clearer IMHO that should be used at > this place too. Changed to reflect this comment. > - 3.1 page 10 (and at some other places): there is no reason to require > DER encoding when BER is enough. The IETF way should be to send DER > and to accept any kind of BER. DER is needed in the use of IBE because keys are calculated from the various values being used. Use of DER instead of BER avoids many implementation difficulties in this area. > - 3.2 page 10: the "set of" is very confusing. The term structure > has no meaning in ASN.1 and IMHO is far better. Changed to reflect this comment. > - 3.2 page 10: domain names are not coded in UTF8. In fact they are > on one hand free, i.e., octet strings, and on the other hand very > restricted... PKIX (RFC 3280) uses IA5String for dNSName but I > don't know if there is a real policy about this issue. The use of IA5String reflects the consensus of the S/MIME working group. > - 3.2 page 11: (notAfter) times -> time Changed to reflect this comment. > - 3.2 page 11: another misleading "set of" Changed to reflect this comment. > - 3.2 page 12: congratulations, you avoid an "ANY DEFINED BY" (brr...!) > - 4.3 page 14: but not XER (X.693). BTW this can make the document a > bit hard to implement (I know a very small number of XER > implementations) > and it raises again the question of the basic vs canonical encoding > (cf. the section 9 of the ITU-T recommendation). Why mix DER and XER? Changed to reflect this comment. > - 4.6 page 16: Extensions is not defined Changed to reflect this comment. > - 4.6 page 17: "the ASN.1 module below" is nowhere so: > * the preceeding comment > * I don't know if an ASN.1 module is required in this situation but > it is so useful I'll do as it is. Added. > - Authors' Addresses page 24: please add USA? Added. > > Regards > > [EMAIL PROTECTED] _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
