>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).
Thank you for reviewing the document. >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? ETSI is indeed responsible. An earlier version of this TS has been published as an RFC. ETSI has requested many years ago to also publish this document as an RFC so that it could get a wider audience. It is an extension of CMS (Cryptographic Message Syntax) and thus fits very well in the S-MIME WG. We got major improvements, thanks to the carefull review from Russ Housley, during the WG last call period. This was an additional advantage to submit this new version to the 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.) It is correct that the ETSI TS is available at zero cost, if you provide your e-mail address and accept to follow the rules fro ETSI about copyright. The main advantage is to get the RFC referenced on the S-MIME WG main page. >(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. The current text has been reviewed by the lawyers from ETSI and an agreement was not that easy. :-( Any change would need to be resubmmited to the ETSI laywers. >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. This was the original intention. However, the comments we got from Russ were very valuable. Next week, there is a meeting from TC ESI from ETSI. BTW, the meeting will be hosted by my company in Paris. I will raise the issue to republish the ETSI TS, so that it becomes really technically identical to the RFC which is now "better" than the original document. This will be a change that we can do during the 24 hours period for last editing. >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.). Correct, the languages are different between the two organizations. >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. Alignment, seems better. If not, your suggestion is certainly valid and would need to be followed. >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). This is unfortunately not possible because the RFC mandates some clauses in a certain order, while the ETSI TS does something different. >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? Yes. The ETSI TS was not using correctly the upper-case MUST/MAY/... The RFC does not claim to use them. It would have been better to use the upper-case MUST/MAY/ in the ETSI TS in a consistent way, but this has not been done. Regards, Denis >Best regards, >Pasi _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
