Subject: IAPP v.s. CT was:RE: [Seamoby] Section 5.2 in CT Requirements

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 9 Aug 2002 16:55:14 -0500

No that is not what I am saying, you can use IAPP for transfering RADIUS
context,
as IAPP is designed for, but beyond RADIUS you are on your own. 
IAPP does not have support for generic context. In the appendix for the
April 2002 doc,
the limitations of IAPP as a context trasnfer protocol are explained. 

Basically IAPP relies on the using the same message exchange that led to the
context in the
first place as a context transfer mechanism, this is fundamentally different
from our CT
where you just take the chuck and transfer it.
IAPP's approach would be very useful, when you have context that is upgrade
by deltas based on intermediate messages (like header compression), or it is
not very economic, if you need to do many messages to arrive at the final
state in the state machine....

CT is more generic than IAPP. But that means we should work faster on CT's
standardization and not make it too complex, otherwise, every access
technology will come up with its own methods.

Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Friday, August 09, 2002 4:43 PM
To: Nakhjiri Madjid-MNAKHJI1; 'Gary Kenward'; [email-masked];
[email-masked]
Subject: Re: [Seamoby] Section 5.2 in CT Requirements

> Agreed to some extent. To be precise: context has to be present at layer 2
devices.
>
> by Layer 2 I meant, IAPP is an AP-AP protocol not that IAPP itself is
below IP
on the stack.
> CT on the other hand as of today is AR-AR.
>

So suppose I'm developing a 802.11 AP that also contains AR functionality.
Are
you saying that I have to use two context transfers, one with IAPP and one
with
an IP CT protocol, in order to be able to get Radius context between the
devices?

            jak

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