Subject: [seamoby] Who defines protocol specific context and how is transported?

From: George Tsirtsis <[email-masked]>
Date: Tue, 14 Aug 2001 10:23:34 -0400

Here is one more issue that we consider important and thus post
separately...

The requirements draft says:
"5.1.2 The context transfer protocol design MUST define a standard 
      representation for conveying context information that will be 
      interpreted uniformly and perspicuously by different 
      implementations."

Who defines the protocol specific info but also the way it is forwarded
between ARs? Protocol specific groups MUST be involved in this process.
SEAMOBY MUST NOT make the mistake to try to define feature specific context
descriptions without the concent and active participation of the appropriate
WGs. The initial CT protocol proposals MAY use examples of framing feature
context but then the appropriate WG  MUST not only be consulted but design
the protocol specific transfer whenever possible.

One way would be to define CT as a protocol that carries opague objects with
various modes e.g:reliable/unrelaible or before/during/after handoff.
Seamoby should then go to each WG affected (e.g.: RSVP, RHOC, AAA etc) and
define the actual context, timing and reliability requirements. This is the
only way for the experts in its area to:

1. Provide feedback to the basic CT mechanism/protocol from their
prespective
2. Evaluate the relative merits of CT vs re-establishment of state at newAR
(it is not always obvious that CT is going to be beneficial)
3. Define the timing and reliability requirements of protocol specific state

Regards
George (and Scott, Vince, Alan, Matt and Michaela)