Subject: [Emu] WG consensus on charter update

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 24 Jan 2008 09:44:58 -0800

So far I have only seen responses from Dan Harkins on the proposed
charter update 
( http://www1.ietf.org/mail-archive/web/emu/current/msg00712.html )

Please respond on the list if you have reviewed the charter and have
comments or if you approve of the current text.  Also make sure to
review the milestones.  

Thanks,

Joe

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: "Stephen Hanna" <[email-masked]>
Date: Fri, 25 Jan 2008 18:15:36 -0500

I apologize for not responding earlier. I have reviewed the
proposed charter revision and milestones. I think they are
good and should be approved.

Thanks,

Steve

-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
Sent: Thursday, January 24, 2008 12:45 PM
To: [email-masked]
Subject: [Emu] WG consensus on charter update

Thanks,

Joe

---

From: "Nancy Winget (ncamwing)" <[email-masked]>
Date: Mon, 28 Jan 2008 10:02:54 -0800

Hi Joe,

The emu charter looks fine to me, the only item I would put in question
right now is whether we can actually have a clean first draft of the
requirements by the March meeting?

	Nancy.

-----Original Message-----
From: Joseph Salowey (jsalowey) 
Sent: Thursday, January 24, 2008 9:45 AM
To: [email-masked]
Subject: [Emu] WG consensus on charter update

So far I have only seen responses from Dan Harkins on the proposed
charter update (
http://www1.ietf.org/mail-archive/web/emu/current/msg00712.html )

Thanks,

Joe

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 28 Jan 2008 13:39:58 -0800

I know it's after the deadline, but I think we should clarify some of 
the text to avoid debates on interpretation later.  (Note: this is going 
to sound like nit picking :) ).

For instance, on,
"Enable a TLS-based EAP method to support channel bindings. So as to
enable RFC 2716bis to focus solely on clarifications to the existing
protocol, this effort will be handled in a separate document.  This item
will not generate a new method, rather it will enhance EAP-TLS or the
TLS based tunnel method.  "

Which is "the TLS based tunnel method" that is going to be enhanced?

We need to specify what we mean by channel bindings.  Is there an agreed 
upon definition that we can refer to?

regards,
Lakshminath

---

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Mon, 28 Jan 2008 16:50:01 -0500

Joe:

I am ok with the updated charter, with the following minor comments:

1. Should we add crypto-agility to the requirements of tunnel method?
And maybe strong shared secret method as well?
2. Move this paragraph right after the tunnel method paragraph, as it
reference the tunnel method above. This way if causes less confusion
with the TLS based channel binding method.
"A mechanism meeting RFC 3748 and RFC 4017 requirements that makes use
of existing password databases such as AAA databases.  This item will be
based on the above tunnel method."
3. TLS based channel binding paragraph: 
"Enable a TLS-based EAP method to support channel bindings. So as to
enable RFC 2716bis to focus solely on clarifications to the existing
protocol, this effort will be handled in a separate document.  This item
will not generate a new method, rather it will enhance EAP-TLS or the
TLS based tunnel method."

What does "will not generate a new method" mean? If we enhance EAP-TLS,
we are likely need to create a new method ID (the current one doesn't
have a version field). Even if we do, likely we will create backward
compatibility issue. Sound like the tunnel method is better, so we
creating minimum new EAP methods. If we choose the TLS based tunnel
method, the requirements already cover the channel binding. Why don't we
just make the decision now and say it is part of the tunnel method, or
at least make the minimum operation mode of the tunnel method is just
TLS with channel binding?  

> So far I have only seen responses from Dan Harkins on the 
> proposed charter update ( 
> Please respond on the list if you have reviewed the charter 
> and have comments or if you approve of the current text.  
> Also make sure to review the milestones.  
> 
> Thanks,
> 
> Joe
> 
>

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 29 Jan 2008 09:47:35 -0800

> From: Lakshminath Dondeti [mailto:[email-masked]] 
> Sent: Monday, January 28, 2008 1:40 PM
> To: Joseph Salowey (jsalowey)
> Cc: [email-masked]
> Subject: Re: [Emu] WG consensus on charter update
> 
> I know it's after the deadline, but I think we should clarify 
> some of the text to avoid debates on interpretation later.  
> (Note: this is going to sound like nit picking :) ).
> 
> For instance, on,
> "Enable a TLS-based EAP method to support channel bindings. 
> So as to enable RFC 2716bis to focus solely on clarifications 
> to the existing protocol, this effort will be handled in a 
> separate document.  This item will not generate a new method, 
> rather it will enhance EAP-TLS or the TLS based tunnel method.  "
> 

[Joe] This "the TLS based tunnel method" is the method the working group
will be working.  Would it help if I said "the above TLS based tunnel
method"

> We need to specify what we mean by channel bindings.  Is 
> there an agreed upon definition that we can refer to?
> 
[Joe] I think we are working towards this, I will check with the Ads to
see where this is at. I don't think we should hold up the charter
definition for this. 

> and have

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 29 Jan 2008 10:03:54 -0800

> From: Hao Zhou (hzhou) 
> Sent: Monday, January 28, 2008 1:50 PM
> To: Joseph Salowey (jsalowey); [email-masked]
> Subject: RE: [Emu] WG consensus on charter update
> 
> Joe:
> 

[Joe] I think crypto agility is a well accepted requirement, but I can
explicitly add it. 

> 2. Move this paragraph right after the tunnel method 
> paragraph, as it reference the tunnel method above. This way 
> if causes less confusion with the TLS based channel binding method.
> "A mechanism meeting RFC 3748 and RFC 4017 requirements that 
> makes use of existing password databases such as AAA 
> databases.  This item will be based on the above tunnel method."

[Joe] Since we have two work items that reference tunnel method, how
about changing "above tunnel method" to "tunnel method work item"?

> rather it will enhance EAP-TLS or the TLS based tunnel method."
> 
> What does "will not generate a new method" mean? If we 
> enhance EAP-TLS, we are likely need to create a new method ID 
> (the current one doesn't have a version field). Even if we 
> do, likely we will create backward compatibility issue. Sound 
> like the tunnel method is better, so we creating minimum new 
> EAP methods. 
> If we choose the TLS based tunnel method, the 
> requirements already cover the channel binding. Why don't we 
> just make the decision now and say it is part of the tunnel 
> method, or at least make the minimum operation mode of the 
> tunnel method is just TLS with channel binding?  
> 
[Joe] Jari requested that we do not close the door and create a solution
that works only with a tunnel method in the charter.  If the solution
requires large modifications to EAP-TLS then it probably won't be
attractive to the group.  I think it is reasonable to keep this open in
the charter. 

> > comments or if you approve of the current text.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 30 Jan 2008 21:16:04 -0800

Joseph Salowey (jsalowey) <mailto:[email-masked]> scribbled on

> http://www1.ietf.org/mail-archive/web/emu/current/msg00712.html )  

I'm a little confused: I interpreted the above-referenced message as a
call for consensus.  Was that correct?  If so, it seems like the
deadline came & went w/only the responses you mentioned from Dan.
Therefore, the (visible) consensus of the group (excluding yourself, as
Chair) expressed during the period of time allotted for comments was
that the password-based method (w/no tunnel involved) should _not_ be
removed from the charter, right?  If the people supporting the removal
couldn't be bothered to send comments for 2 weeks, I'm not sure that
their opinion should count afterwards: either there was a deadline or
there wasn't (surely we don't just continue to ask the question until we
get the answer we want).  OTOH, if the message was _not_ a consensus
call then it's not clear to me what the purpose was...