Subject: RE: [Seamoby] Section 5.2 in CT Requirements

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

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.
 
Madjid 
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Friday, August 09, 2002 3:51 PM
To: 'James Kempf'; Nakhjiri Madjid-MNAKHJI1; [email-masked]; [email-masked]
Subject: RE: [Seamoby] Section 5.2 in CT Requirements

James: 

Please correct me if I am wrong, but 802.11 APs are layer 2 devices. 
The protocols used for IAPP may be L3 protocols, but the context is 
relevant to L2 only. Therefore, IAPP is an L2 context transfer solution, 
not an L3 ct solution. 

Layering is a model, not an implementation, so it is dangerous to get too 
hung up on the distinctions. L3 CT should be able to transfer L2 context, 
as long as the performance of the L3 CT solution meets the requirements of 
the L2 context. Said another way: we do not want L2 requirements for 
synchronization, latency, bandwidth, reliability, etc. driving the Seamoby 
L3 CT design. 

Transferring Radius context is possible with an L3 CT due to the nature of 
the Radius context. 

Gary 

> -----Original Message----- 
> From: James Kempf [ mailto:[email-masked] <mailto:[email-masked]> ] 
> Sent: August 9, 2002 16:37 
> To: Nakhjiri Madjid-MNAKHJI1; Kenward, Gary [WDLN2:AN10:EXCH]; 
> [email-masked]; [email-masked] 
> Subject: Re: [Seamoby] Section 5.2 in CT Requirements 
> 
> 
> Madjid/Gary, 
> 
> IAPP does not run at Layer 2, it is an IP protocol. Runs over 
> UDP. It currently 
> only support RADIUS contexts. 
> 
> 
> 
> 
> ----- Original Message ----- 
> From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]> 
> To: "'Gary Kenward'" <[email-masked]>; "'James Kempf'" 
> <[email-masked]>; <[email-masked]>; 
> <[email-masked]> 
> Sent: Thursday, August 08, 2002 2:00 PM 
> Subject: RE: [Seamoby] Section 5.2 in CT Requirements 
> 
> 
> > I keep hearing IAPP  as a contender for CT. 
> > IAPP only carries one context and that is Radius and that is because 
> authentications 
> > taking place in a WLAN depends on RADIUS and its servers. 
> IAPP does not offer 
> a generic 
> > context transfer solution and it is not at layer 3 and it 
> is L2 and L2 
> technology specific. 
> > 
> > Madjid 
> > -----Original Message----- 
> > From: Gary Kenward [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > Sent: Tuesday, August 06, 2002 12:26 PM 
> > To: 'James Kempf'; [email-masked]; [email-masked] 
> > Subject: RE: [Seamoby] Section 5.2 in CT Requirements 
> > 
> > 
> > 
> > James: 
> > 
> >   All well and good, but the requirement basically states that CT 
> > should run over a transport protocol, reliable or unreliable, IETF 
> > or non-IETF...hmmm, not really a requirement, except that it implies 
> > that CT does not include transport capabilities. 
> > 
> >   BTW: as far as I know, IAPP is a layer 2 protocol. CT is concerned 
> > with L3, with transfer of L2 as an option. Since we are 
> already talking 
> > about separate transport protocols for different features, 
> I do not see 
> > the rationalization for using CT to carry, or to replace, IAPP. 
> > 
> > Gary 
> > 
> > > -----Original Message----- 
> > > From: James Kempf [ mailto:[email-masked] <mailto:[email-masked]>  
> < mailto:[email-masked] <mailto:[email-masked]> > ] 
> > > Sent: July 22, 2002 12:31 
> > > To: [email-masked]; [email-masked] 
> > > Subject: Re: [Seamoby] Section 5.2 in CT Requirements 
> > > 
> > > 
> > > John, 
> > > 
> > > > I disagree with your requirement, because I don't see a lot 
> > > of meaning 
> > > > and/or use in it. 
> > > > 
> > > > I think that different context may have different need. 
> > > Timelyness & 
> > > > reliability are 2 different and opposing needs.  This 
> is directly 
> > > > relatable to the earlier discussion on dynamicisity of context. 
> > > > A situation could occur where a context goes stale during 
> > > re-transmission 
> > > > when running over a reliable protocol.  Some other context, 
> > > such as security 
> > > > may not time out, unless the end-user completely times 
> out of the 
> > > user-session. 
> > > > 
> > > > Besides going stale, it is entirely possible that some 
> context may 
> > > > be superceded.  As this issue is fairly complex and 
> > > intertwined with the 
> > > > context being transfered, I suggest we don't have a 
> > > reliability requirement, 
> > > > but rather we try to do an analysis of the reliability 
> > > needs and then 
> > > > take this into the solution. 
> > > > 
> > > > Additionally, I don't think that we want to get into 
> defining new 
> > > > transport protocols or behaviors. 
> > > > 
> > > 
> > > 
> > > That is exactly why I proposed this requirement. The intent 
> > > of this requirement, 
> > > together with the newly proposed Section 5.8, is that it 
> > > would be up to the 
> > > particular feature context profile to specify the transport. 
> > > 
> > > Here's an example of why I think the requirement is needed. 
> > > 802.11 specifies 
> > > its own context transfer protocol, namely IAPP. If we specify 
> > > that, for example, 
> > > SCTP is required for transport, vendors on 802.11 would have 
> > > to implement two 
> > > context transfer protocols, IAPP and the Seamoby SCTP-based 
> > > protocol. IMHO, it 
> > > makes sense to only have one context transfer protocol and 
> > > leverage a particular 
> > > transport for the feature contexts that need it. 
> > > 
> > > Does this make sense? 
> > > 
> > >             jak 
> > > 
> > > 
> > > 
> > > 
> > > _______________________________________________ 
> > > Seamoby mailing list 
> > > [email-masked] 
> > > https://www1.ietf.org/mailman/listinfo/seamoby <https://www1.ietf.org/mailman/listinfo/seamoby>  
> < https://www1.ietf.org/mailman/listinfo/seamoby <https://www1.ietf.org/mailman/listinfo/seamoby> > 
> > > 
> > 
> > 
> 
>

---

From: "James Kempf" <[email-masked]>
Date: Fri, 9 Aug 2002 14:42:31 -0700

> 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

---

From: "James Kempf" <[email-masked]>
Date: Fri, 9 Aug 2002 14:42:31 -0700

jak