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-cades-06 Reviewer: Pasi Eronen Review Date: 2007-10-30 IETF LC End Date: 2007-11-01 IESG Telechat date: 2007-11-15 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: 1) I'm a bit puzzled by the relationship between this document and ETSI TS 101 733 V1.7.3. If ETSI is responsible for the technical maintenance of this specification, why is this being published in IETF? That is, why it's a good idea to spend IETF resources (time of various volunteers, money paid for e.g. secretariat and RFC editor services) on this? (I've understood that ETSI specs are available at zero cost nowadays -- please correct me if I'm wrong.) (Or perhaps the relationship is more complex, and technical maintenance is done simultaneously at both organizations?) At any rate, the document abstract and/or introduction should briefly explain the relationship with ETSI, including who is responsible for maintaining the spec, and the reasons for publishing it in two document series. For the purpose of this review, I'm assuming that the technical contents are maintained by ETSI, and thus I'm limiting my review to the re-publishing aspects. 2) If the intent is to re-publish the ETSI TS as is, the document probably should have an RFC Editor note, asking the RFC Editor not to perform the usual editing on the text. 3) For most part, the document is a verbatim copy of the ETSI TS, with only slight editorial variations (e.g. using "section 4.1" instead of "clause 4.1"; small variations on where paragraph breaks are inserted, etc.). However, in some places there is additional and/or modified text that is not present in the ETSI TS (one place I noticed is in Section 5.8.1, sentence "If hashValue is zero..."). The document would probably benefit from having a list of these non-trivial additions/modifications. 4) The document slightly changes the section ordering/numbering compared to the ETSI TS. I'd suggest keeping them exactly the same to save work and hassle (or, at the very least, explicitly giving the mapping between ETSI section numbers and section numbers used here). 5) The ETSI TS uses upper-case MUST/MAY/etc. keywords (although without citing e.g. RFC 2119, so their precise definition is a bit unclear). It seems they have been converted to lowercase here -- is this intentional? Best regards, Pasi _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
