Subject: [Gen-art] Assignments for Jan 19th, 2006

From: "Mary Barnes" <[email-masked]>
Date: Thu, 12 Jan 2006 20:50:58 -0600

Here's the assignments for Jan 19th, 2006 based on the agenda as of this
evening:
http://www.alvestrand.no/ietf/gen/art/reviewers-060119.html

with the corresponding spreadsheets available at:
http://www.alvestrand.no/ietf/gen/art/gen-art.html
http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html

Let me know any if you see any errors or omissions.  

Mary.

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 15 Jan 2006 10:10:38 -0500

This document is not quite ready for publication as an informational RFC.

My concern is the status of the document.  It is normal for Cipher Suites 
(algorithm definitions) to be informational RFCs.  I have no argument with 
that.
However, this document is not an algorithm definition.
Rather, it is the definition of a set of TLS extensions and the format of 
the information in those TLS extensions.
As such, it is a definition for bits on a wire, not for a computational 
algorithm.
(I was curious to see how the algorithm would be described, having only 
seen exponential algorithms described in RFCs before.   The algorithm is 
not described in this document.)

Note: I will take as given that the descriptions of enums and structures 
here is sufficient that in conjunction with the base TLS documents and the 
extension description document an implementor can determine how to form the 
proper messages.    The description consisting  of the words "structure of 
the message" followed by the definition of an enum (to be used somewhere?) 
followed sometimes by a struct defintion (presumably to be included in a 
message somewhere, with some context identifier, if the values of the enum 
are used somewhere?) is not clear to one who is not immersed in TLS 
extension work.  (Presumably, this definition structure is used because 
giving the rest of the information would be both long and duplicative.)
I also presume that the definition of the lagnuage used for the structure 
definition, and the mapping of that definition to bits on the wire, is 
included in the TLS extensions document?

nit: idnits notes that the Copyright statement is not verbatim as specified.

Yours,
Joel M. Halpern

----
SEC ECC Cipher Suites for TLS (Informational) - 3 of 4
     <http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-12.txt>draft-ietf-tls-ecc-12.txt
     Note: Proto shepherd is Eric Rescorla <[email-masked]>.

Token:  <mailto:[email-masked]>Russ Housley
Reviewer: Joel Halpern

---

From: Russ Housley <[email-masked]>
Date: Sun, 15 Jan 2006 18:12:25 -0500

Brian:

I support progress as Informational RFC.  This is the approach that 
has been used in other Security Area WGs when the IPR status of the 
algorithm is unclear or unfavorable.

RFC 3278 is an example.  This document also deals with ECC, and it 
was produced by the S/MIME WG.

RFC 3058 is another example.  This document also deals with IDEA, 
which is clearly covered by a patent.

The idea is to document use of these algorithms in the context of a 
particular protocol to permit interoperability between any parties 
that choose to implement them.  However, the IETF is not advocating 
their implementation by keeping them off of the standards track.

Russ

At 10:10 AM 1/15/2006, Joel M. Halpern wrote:
>My concern is the status of the document.  It is normal for Cipher 
>Suites (algorithm definitions) to be informational RFCs.  I have no 
>argument with that.
>Rather, it is the definition of a set of TLS extensions and the 
>format of the information in those TLS extensions.
>As such, it is a definition for bits on a wire, not for a 
>computational algorithm.
>(I was curious to see how the algorithm would be described, having 
>only seen exponential algorithms described in RFCs before.   The 
>algorithm is not described in this document.)
>
>Note: I will take as given that the descriptions of enums and 
>structures here is sufficient that in conjunction with the base TLS 
>documents and the extension description document an implementor can 
>determine how to form the proper messages.    The description 
>consisting  of the words "structure of the message" followed by the 
>definition of an enum (to be used somewhere?) followed sometimes by 
>a struct defintion (presumably to be included in a message 
>somewhere, with some context identifier, if the values of the enum 
>extension work.  (Presumably, this definition structure is used 
>because giving the rest of the information would be both long and duplicative.)
>I also presume that the definition of the lagnuage used for the 
>structure definition, and the mapping of that definition to bits on 
>the wire, is included in the TLS extensions document?
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 16 Jan 2006 17:40:36 -0500

Well, those are clearly relevant prior uses.

It seems to me that this sort of publication in practice does not help the 
implementors understand the problem or the lack of recommendation.

But its up to you two, not mee.

Yours,
Joel

At 06:12 PM 1/15/2006, Russ Housley wrote:
>Brian:
>
>I support progress as Informational RFC.  This is the approach that has 
>been used in other Security Area WGs when the IPR status of the algorithm 
>is unclear or unfavorable.
>
>RFC 3278 is an example.  This document also deals with ECC, and it was 
>produced by the S/MIME WG.
>
>RFC 3058 is another example.  This document also deals with IDEA, which is 
>clearly covered by a patent.
>
>particular protocol to permit interoperability between any parties that 
>choose to implement them.  However, the IETF is not advocating their 
>implementation by keeping them off of the standards track.
>
>Russ
>
>
>>(algorithm definitions) to be informational RFCs.  I have no argument 
>>with that.
>>here is sufficient that in conjunction with the base TLS documents and 
>>the extension description document an implementor can determine how to 
>>form the proper messages.    The description consisting  of the words 
>>"structure of the message" followed by the definition of an enum (to be 
>>used somewhere?) followed sometimes by a struct defintion (presumably to 
>>be included in a message somewhere, with some context identifier, if the 
>>values of the enum are used somewhere?) is not clear to one who is not 
>>immersed in TLS extension work.  (Presumably, this definition structure 
>>is used because giving the rest of the information would be both long and 
>>duplicative.)

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Jan 2006 13:26:41 +0100

I don't see an IPR disclosure against this draft (not even a 3rd party
one). I take it that the concern is related to the disclosure at
http://www.ietf.org/ietf/IPR/CERTICOM-IPSEC-ECC ?

As Russ said, there are precedents for this way to deal with
IPR - in fact if we have failed to get an IPR disclosure offering
at least RAND conditions we don't actually have any other solution
except not publishing at all.

     Brian

Russ Housley wrote:
> been used in other Security Area WGs when the IPR status of the 
> RFC 3058 is another example.  This document also deals with IDEA, which 
> is clearly covered by a patent.
> 
>> Rather, it is the definition of a set of TLS extensions and the format 
>> of the information in those TLS extensions.
>> definition of an enum (to be used somewhere?) followed sometimes by a 
>> struct defintion (presumably to be included in a message somewhere, 
>> with some context identifier, if the values of the enum are used 
>> somewhere?) is not clear to one who is not immersed in TLS extension 
>> work.  (Presumably, this definition structure is used because giving 
>> the rest of the information would be both long and duplicative.)