Subject: [Emu] Channel Binding Consensus Call

From: Joe Salowey <[email-masked]>
Date: Mon, 18 Apr 2011 11:11:59 -0700

This is a consensus call to validate the direction the draft-ietf-emu-chbind-07 and confirm the consensus around the encoding of the channel binding TLV.  Please respond to the following questions by May 2, 2011.  

1.  Do you agree with the direction taken in draft-ietf-emu-chbind-07.  More specifically the usage of a channel binding specific TLV, the support of multiple name spaces, and that the server indicates to the client what attributes were validated.  

2.  Two encoding method where described in IETF-80 in the following presentation http://tools.ietf.org/agenda/80/slides/emu-1.pdf.  Do you prefer encoding option 1, where attributes are encoded individually or option 2 where attributes in the same namespace are grouped together.  

Cheers,

Joe

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Mon, 18 Apr 2011 14:57:47 -0400

1. agree

2. option 1 because it appears cleaner but no strong preference

Katrin 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Joe
> Salowey
> Sent: Monday, April 18, 2011 1:12 PM
> To: [email-masked]
> Subject: [Emu] Channel Binding Consensus Call
> 
> This is a consensus call to validate the direction the draft-ietf-emu-
> chbind-07 and confirm the consensus around the encoding of the channel
> binding TLV.  Please respond to the following questions by May 2,
2011.
> 
> 1.  Do you agree with the direction taken in draft-ietf-emu-chbind-07.
> More specifically the usage of a channel binding specific TLV, the
support
> of multiple name spaces, and that the server indicates to the client
what
> attributes were validated.
> 
> 2.  Two encoding method where described in IETF-80 in the following
> presentation http://tools.ietf.org/agenda/80/slides/emu-1.pdf.  Do you
> prefer encoding option 1, where attributes are encoded individually or
> option 2 where attributes in the same namespace are grouped together.
> 
> Cheers,
> 
> Joe
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Klaas Wierenga <[email-masked]>
Date: Tue, 26 Apr 2011 18:01:34 +0200

On 4/18/11 8:11 PM, Joe Salowey wrote:

Hi,

1. yes

2. option 1

I have no strong preference for either, but option 1 seems cleaner to me
(no further parsing neccesary, and I think the waste of bytes is not
that big that we need to be too worried about that).

For the record, I have indicated the same in the WG meeting.

Klaas

> This is a consensus call to validate the direction the
> draft-ietf-emu-chbind-07 and confirm the consensus around the
> encoding of the channel binding TLV.  Please respond to the following
> questions by May 2, 2011.
> 
> 1.  Do you agree with the direction taken in
> draft-ietf-emu-chbind-07.  More specifically the usage of a channel
> binding specific TLV, the support of multiple name spaces, and that
> the server indicates to the client what attributes were validated.
> 
> presentation http://tools.ietf.org/agenda/80/slides/emu-1.pdf.  Do
> you prefer encoding option 1, where attributes are encoded
> individually or option 2 where attributes in the same namespace are
> grouped together.
> 
> Cheers,
> 
> Joe _______________________________________________ Emu mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/emu

---

From: Joe Salowey <[email-masked]>
Date: Tue, 26 Apr 2011 09:46:43 -0700

This consensus call closes next week.  This is an important working group work item. If you have an opinion about this issue please send it to the list so we can keep the work moving forward. 

Thanks,

Joe

---

From: Stefan Winter <[email-masked]>
Date: Wed, 27 Apr 2011 13:13:07 +0200

1. Agree

2. Option 1

Attribute parsing should be easier with this option 1 - Length can
always serve as a pointer to the next attribute, with explicit namespace
ID. With option 2, attribute delimiters are only within NS-Specific, and
Length points to the Namespace, if any. That makes two code paths, one
for parsing NSID delimiters, and one for parsing attributes.

However, the chances that I'll ever actually implement this are
incredibly slim, so my opinion shouldn't be considered with much weight.

Greetings,

Stefan

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: Nancy Cam-Winget <[email-masked]>
Date: Wed, 27 Apr 2011 09:08:55 -0700

1. Yes

2. Option 1 

Thanks, Nancy.

On 4/26/11 9:46 AM, "Joseph Salowey" <[email-masked]> wrote:

> This consensus call closes next week.  This is an important working group work
> item. If you have an opinion about this issue please send it to the list so we
> can keep the work moving forward.
> 
> Thanks,
> 
> Joe
>> draft-ietf-emu-chbind-07 and confirm the consensus around the encoding of the
>> channel binding TLV.  Please respond to the following questions by May 2,
>> 2011.  
>> 
>> 1.  Do you agree with the direction taken in draft-ietf-emu-chbind-07.  More
>> specifically the usage of a channel binding specific TLV, the support of
>> multiple name spaces, and that the server indicates to the client what
>> presentation http://tools.ietf.org/agenda/80/slides/emu-1.pdf.  Do you prefer
>> encoding option 1, where attributes are encoded individually or option 2
>> where attributes in the same namespace are grouped together.
>> 
>> Cheers,
>> 
>> Joe

---

From: Alan DeKok <[email-masked]>
Date: Wed, 27 Apr 2011 18:38:13 +0200

(speaking as individual contributor)

#1 - Yes, I agree.

#2 - encoding method #2

---

From: Stephen McCann <[email-masked]>
Date: Wed, 27 Apr 2011 18:50:22 +0100

Dear all,

1) Agree
2) Option 1

Kind regards

Stephen McCann
Research in Motion
Southampton, UK

---

From: Glen Zorn <[email-masked]>
Date: Thu, 28 Apr 2011 09:15:27 +0700

>> 1.  Do you agree with the direction taken in draft-ietf-emu-chbind-07.  More specifically the usage of a channel binding specific TLV, the support of multiple name spaces, and that the server indi…

Since one-word, unjustified answers seem to be the way to go, I guess
I'll save time by following suit: No.

>> 2.  Two encoding method where described in IETF-80 in the following presentation http://tools.ietf.org/agenda/80/slides/emu-1.pdf.  Do you prefer encoding option 1, where attributes are encoded in…

Neither.

...

---

From: Alan DeKok <[email-masked]>
Date: Thu, 28 Apr 2011 10:01:48 +0200

>> 1.  Do you agree with the direction taken in draft-ietf-emu-chbind-07.  More specifically the usage of a channel binding specific TLV, the support of multiple name spaces, and that the server indi…

  Yes.

>> 2.  Two encoding method where described in IETF-80 in the following presentation http://tools.ietf.org/agenda/80/slides/emu-1.pdf.  Do you prefer encoding option 1, where attributes are encoded in…

  (2).

  Speaking as an individual contributor.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 28 Apr 2011 10:04:30 +0200

> for parsing NSID delimiters, and one for parsing attributes.

  My $0.02 is that it's easier to do:

    Parse NS stuff
	NS1 - parse protocol-specific 1
	NS2 - parse protocol-specific 2

  The alternative is:

    Parse NS stuff
	NS1 - parse NS1-specific variant of protocol 1
	NS2 - parse NS2-specific variant of protocol 2

  I don't want to write yet another "almost RADIUS" or "almost Diameter"
encoder/decoder.  I'd like to re-use the existing code where possible.

  But the current consensus of the WG seems to be against this opinion.
 Oh well.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 28 Apr 2011 12:45:00 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan> Stefan Winter wrote:
    >> Attribute parsing should be easier with this option 1 - Length
    >> can always serve as a pointer to the next attribute, with
    >> explicit namespace ID. With option 2, attribute delimiters are
    >> only within NS-Specific, and Length points to the Namespace, if
    >> any. That makes two code paths, one for parsing NSID delimiters,
    >> and one for parsing attributes.

    Alan>   My $0.02 is that it's easier to do:

    Alan>     Parse NS stuff NS1 - parse protocol-specific 1 NS2 - parse
    Alan> protocol-specific 2

I think this is true on the server.
However, I'd really appreciate your thoughts on what will happen inside
the EAP peer itself?
My assumption is that outside of the guts of a TTLS implementation, EAP
peers today don't have knowledge either of RADIUS or DIAMETER. So, a
format that minimizes how much they need to understand either of these
protocols would be valuable.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 28 Apr 2011 18:57:28 +0200

Yes.

> However, I'd really appreciate your thoughts on what will happen inside

  Ideally, code re-use.

> peers today don't have knowledge either of RADIUS or DIAMETER.

  Largely, yes.

> So, a

  Valuable, yes.  High value, perhaps not.

  There is plenty of BSD-licensed code available for packing and
unpacking RADIUS attributes.  There should be little cost to re-using
that, and a larger cost in writing a new attribute packer.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 28 Apr 2011 13:51:36 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan>   There is plenty of BSD-licensed code available for packing
    Alan> and unpacking RADIUS attributes.  There should be little cost
    Alan> to re-using that, and a larger cost in writing a new attribute
    Alan> packer.

Assuming RADIUS is basically the only namespace we end up needing this
probably is true.