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

From: "Gary Kenward" <[email-masked]>
Date: Tue, 6 Aug 2002 13:26:00 -0400

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]]
> 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
>

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 6 Aug 2002 13:26:00 -0400

James:

Gary

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 8 Aug 2002 16:00:48 -0500

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]]
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: 

Gary 

> From: James Kempf [ mailto:[email-masked] <mailto:[email-masked]> ] 
> https://www1.ietf.org/mailman/listinfo/seamoby <https://www1.ietf.org/mailman/listinfo/seamoby>  
>

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 9 Aug 2002 16:50:42 -0400

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

> Sent: August 9, 2002 16:37
> To: Nakhjiri Madjid-MNAKHJI1; Kenward, Gary [WDLN2:AN10:EXCH];
> [email-masked]; [email-masked]
> 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
> > 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
> <https://www1.ietf.org/mailman/listinfo/seamoby>
> > >
> >
> >
> 
>

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 9 Aug 2002 16:50:42 -0400

James:

Gary

---

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: 

Gary 

> > From: Gary Kenward [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > > From: James Kempf [ mailto:[email-masked] <mailto:[email-masked]>  
> < mailto:[email-masked] <mailto:[email-masked]> > ] 
> < https://www1.ietf.org/mailman/listinfo/seamoby <https://www1.ietf.org/mailman/listinfo/seamoby> > 
> > > 
> > 
> > 
> 
>

---

From: "Gary Kenward" <[email-masked]>
Date: Mon, 12 Aug 2002 11:27:38 -0400

James:

  Well, the short answer is no, as the requirements still say
that CT can convey L2 context, as long as it does not require
CT to do anything special.

  Curiously, the concern, at least on my part, was with the idea
that IAPP would be considered part of the suite of feature context
transport protocols used for a context transfer. 

  Your comment below expressing a concern about "two context
transfers", would seem to contradict the requirement text
you proposed that implied that each feature context would
specify its own transport protocol. 

  I am looking for CT to be light weight, relatively fast and 
relatively reliable, including the transport. By relatively fast
I mean that it must enhance mobility, otherwise it's not worth
doing. By relatively reliable, I mean it had better work most
of the time, but I really do not need five nine's of reliability
- that handovers fail occasionally is a reality with wireless.
I cannot be more specific without talking numbers.

  And so, from your comments below, I take it that you also would
prefer one CT exchange, implying one transport protocol? If so,
would you be willing to modify your proposed text at least to 
indicate that this is the preferred objective for CT?

Cheers,
Gary

> Sent: August 9, 2002 17:43
> > 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.
> 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
> 
>

---

From: "Gary Kenward" <[email-masked]>
Date: Mon, 12 Aug 2002 12:56:44 -0400

As I said in a previous email, RADIUS is not an L2 protocol.
But AP's are L2 devices, and RADIUS is being used to set up
an L2 environment, hence the context is L2. 

Let's drop this thread. 

Gary

> Sent: August 12, 2002 12:15
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1;
> Gary,
> Can you explain to me why you believe that RADIUS is an L2 protocol?
> 
>             jak
> 
> 
> 
>

---

From: "Gary Kenward" <[email-masked]>
Date: Mon, 12 Aug 2002 12:56:44 -0400

Let's drop this thread. 

Gary