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

From: "Denis Pinkas" <[email-masked]>
Date: Wed, 31 Oct 2007 15:17:35 +0100

><snip>

>> The main advantage is to get the RFC referenced on the 
>> S-MIME WG main page.

>If this is really the main advantage, talking with [email-masked]
>would be easier than publishing an RFC.

I have difficulties to understand what you mean here.
Currently all the documents that are referenced are only RFCs.

><snip>

>> >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.

I did not explained myself sufficiently. I was not meaning the whole document, 
but only the following text :

from the abstract:

  The contents of this Informational RFC amounts to a 
   transposition of the ETSI TS 101 733 V.1.7.3 (CMS Advanced 
   Electronic Signatures - CAdES) [TS101733] and is technically 
   equivalent to it.

and the following text from the Intellectual property section:

   ETSI takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed 
   to pertain to the implementation or use of the technology described 
   in this document or the extent to which any license under such 
   rights might or might not be available; nor does it represent that 
   it has made any independent effort to identify any such rights. 

   Information on the ETSI Intellectual Property Rights Policy may be 
   obtained from <http://www.etsi.org/legal/home.htm>. The document is 
   an extract from Annex 6 of the ETSI Rules of Procedure that are 
   available at : <http://portal.etsi.org/directives/home.asp>.

   The ETSI IPR database http://webapp.etsi.org/IPR/home.asp contains 
   IPRs, particularly patents and patent applications, which have been 
   notified to ETSI as being essential, or potentially essential, to 
   ETSI standards. Unless otherwise specified, all IPRs contained 
   herein have been notified to ETSI, with an undertaking from the 
   owner to grant licenses according to the terms and conditions of 
   Article 6.1 of Annex 6 of the ETSI Rules of the ETSI IPR Policy.

   The ETSI IPR database provides data that is based on the information 
   received. ETSI has not checked the validity of the information, nor 
   the relevance of the identified patents/patent applications to the 
   ETSI Standards and cannot confirm, or deny, that the patents/patent 
   applications are, in fact, essential, or potentially essential. No 
   investigation, or IPR searches, have been carried out by ETSI and 
   therefore no guarantee can be given concerning the existence of 
   other IPRs which are, or may become, essential.

   Potential Licensees should use the information in this database at 
   their discretion and should contact the patent holder.

>Err... if it's not possible even to add a sentence saying
>"This document is maintained by ETSI", why is this document 
>going through IETF last call? If the IETF community is asked
>to comment the document, certainly changes should be possible.

The ETSI TS is maintained by ETSI. We have no commitment to publish 
an RFC every time a new version from the TS is published.

In fact we waited several versions before issuing a new RFC.

To be positive, I would rather think that an additional sentence 
might be needed to say something like:

"Further updates to the ETSI TS will be available at :
http://www.etsi.org/services_products/freestandard/home.htm"

Not all of the comments will be accepted, since this document is on 
the Informational track rather than on Standard track. Errors ands lacks 
of explanations are certainly taken into consideration.

><snip>

>> >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.

>The RFC editor recommends a particular section ordering, but for 
>most sections, does not absolute require it. If there's a good 
>reason (and in this case, there is), I think there's some room 
>for keeping the section order identical to the ETSI TS.

For the main body of the document, the text is perfectly aligned, 
I mean sections 3 to 8. Readers will not be lost between one text or the other.

For sections 1 to 2, each document respects its own structure.
Sections 9 and beyond only exist for the RFC document.

The ETSI TS structure:

Introduction
1	Scope
2	References

up to section 8.

The RFC structure:

1.  Introduction
2.  Scope

(...)

9.  Security considerations
9.1  Protection of private key
9.2  Choice of algorithms
10.  IANA Considerations
11.  References
11.1  Normative references
11.2  Informative references

Regards,

Denis

>Best regards,
>Pasi

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: <[email-masked]>
Date: Wed, 31 Oct 2007 16:52:09 +0200

> http://www.etsi.org/services_products/freestandard/home.htm"

Something along those lines might be a good idea. Perhaps
"The technical contents of this specification are maintained
by ETSI; further updates to the ETSI TSI will be available at.."

<snip>
> 11.2  Informative references

There's still unnecessary reordering in Section 9 and the Annexes.

I'd suggest moving "Security Considerations" (current Section 9) to
Annex E (where it originally was), "Guidance on Naming" (current Annex
E) back to Annex J, and "Changes from the previous version" (current
Annex J) back to Annex K.

After this change, the only differences left would be Sections 1, 2, 
and 11 (where it might be OK). Section 10 (the empty IANA considerations

section) will be removed by the RFC editor.

Best regards,
Pasi