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

From: [email-masked]
Date: Mon, 22 Jul 2002 06:42:37 +0300

Hi James

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.

John

===
5.2 Transport Requirements 

 This section contains requirements on the context transfer transport. 

5.1 Independence of Underlying Transport 

  The context transfer solution MUST be independent of  the underlying 
  transport. It SHOULD be possible to transfer context directly on top of 
  reliable transports, such as TCP or SCTP, unreliable transports, such as UDP, 
  or as an  option or extention on another protocol, such as handover signaling. 

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

---

From: "James Kempf" <[email-masked]>
Date: Mon, 22 Jul 2002 09:31:29 -0700

John,

> 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

---

From: "James Kempf" <[email-masked]>
Date: Mon, 22 Jul 2002 09:31:29 -0700

John,

Does this make sense?

            jak