Subject: [Gen-art] Gen-ART review of draft-ietf-smime-cades-06

From: <[email-masked]>
Date: Tue, 30 Oct 2007 09:38:16 +0200

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-masked]
https://www1.ietf.org/mailman/listinfo/gen-art