Subject: RE: [Nea] Problem statement - comments/questions

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 6 Apr 2006 13:32:15 -0400

When we come down to what mechanism should transport our messages -
we'll decide whether it is EAP and what to do if it isn't. For now we
can safely assume that there is or will be a method that will do the job
(EAP is an existing example of such).

As for "non-NEA based hosts" - it does sound weird at the NEA list. If
you mean "non-EAP hosts" - the answer is "we'll see" - way too early to
consider it now.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, April 06, 2006 1:19 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Nea] Problem statement - comments/questions

> I understand that this means "support endpoints with or withoug NEA
> clients". What should be done with these clientless endpoints should
> be up to the policies at the site.
>
> And I'm a bit confused about the mention of "non-browser based
> systems". I always supposed that it was obvious that NEA should not
> make any assumptions outside the fact that the endpoints have some
> kind of connectivity and may have a NEA client installed.
>
>I was at IETF 65 and there I thought that everyone was thinking along
>this line.

I think this question may have been brought up by Amardeep Sibia and
Tatiana in the BOF.  What should be done with clients that do not speak
EAP?

The NEA group could define an additional IF-PT method.  An example could
be
TLS. In that case a person could develop a Java applet that can do
IF-PA,
IF-PB and communicate that information over SSL (IF-PT) to the NEA
Server.
This would be an attractive option for the non NEA agent based hosts.

Kevin

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

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