[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: alternatives for carrying eap lower layer information

To: "Nelson, David" <dnelson@enterasys.com>
Subject: Re: alternatives for carrying eap lower layer information
From: Jari Arkko <jari.arkko@piuha.net>
Date: Mon, 08 Nov 2004 15:34:10 +0200
Cc: radiusext@ops.ietf.org, "David Mariblanca (EE/EEM)" <david.mariblanca@ericsson.com>
In-reply-to: <A675D99D53706742B50619249A8EBF04FE2A7D@MAANDMBX2.ets.enterasys.com>
Organization: None
References: <A675D99D53706742B50619249A8EBF04FE2A7D@MAANDMBX2.ets.enterasys.com>
Reply-to: jari.arkko@piuha.net
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316

Nelson, David wrote:

Is the potential for confusion because one might have *both* an incoming tunnel service (potentially terminating at the NAS) and an outgoing tunnel service for the same connection?


Yes, that was my question. I can certainly see this happening,
but I'm uncertain if RFC 2868 is able to cope with it.

--Jari

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

References:
- RE: alternatives for carrying eap lower layer information
  - From: "Nelson, David" <dnelson@enterasys.com>

Prev by Date: RE: alternatives for carrying eap lower layer information
Next by Date: RE: alternatives for carrying eap lower layer information
Previous by thread: RE: alternatives for carrying eap lower layer information
Next by thread: RE: alternatives for carrying eap lower layer information
Index(es):
- Date
- Thread