Madjid:

  Fine, replace "before" with "proactive". I still use the term "proactive"
because I never associated it with the triggers (and neither did the original
wording in the draft).

  To sum up, the whole purpose of CT is to attempt to prepare the destination
AR *before* a handover occurs and the destination AR has to forward it's first
packet to/from the roaming MN. Performing CT *during* or *after* a handover has
been initiated, particularly after the MN's packets have begun arriving at the
destination AR is a necessary capability, but the potential performance
improvements are not as great.

Gary

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri <at> motorola.com]
> Sent: July 22, 2002 11:37
> To: 'James Kempf'; Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri
> Madjid-MNAKHJI1; seamoby <at> ietf.org
> Subject: RE: Section 5.5 Modifications
>
>
> Well, I am maybe not as good of a boy scout as some others
> but, I remember 3 weeks of debate, followed by a period
> of  2 months of silence and then a 90 minute discussion in London
> (not to mention the 3$K trip expense :) )
> that lead to us not making reactive
> or proactive CT as a basis for the CT usefulness debate.
> Lets not open that barrel of snakes (certainly bigger than
> worms) again.
>
> If you want to mention proactive a byproduct, or use case,
> that is fine.
> But I think we should be careful about making a byproduct a
> primary goal.
>
>
> Regards,
>
> Madjid
>
>
> -----Original Message-----
> From: James Kempf [mailto:kempf <at> docomolabs-usa.com]
> Sent: Friday, July 19, 2002 7:47 PM
> To: Gary Kenward; 'Nakhjiri Madjid-MNAKHJI1'; seamoby <at> ietf.org
> Subject: Section 5.5 Modifications
>
>
> Hi Gary,
>
> >   I get the impression that either everyone has forgotten
> about proactive
> > CT, or does
> > not care. Which is too bad, for the boy scouts are right on
> when they say
> > "be prepared".
> >
>
> Thanx for reminding me, being an old Boy Scout myself I should have
> remembered.
>
>
> How about if we modify the text I sent out as below? In
> addition, I think we
> need an additional section, which I will post on a separate
> thread, that
> describes the steps needed to standardize a feature context.
> This text will
> include a requirement for update on feature contexts that are
> not tightly
> synchronized with external events.
>
>                 jak
>
> ------------------------------------------------------------
>
> 5.5 Context Update and Synchronization
>
> 5.5.1 The base context transfer protocol SHOULD NOT provide
> direct support
> for
> synchronization with outside events, since synchronization is not a
> requirement
> for all or even most feature contexts.
>
> 5.5.2 The base context transfer protocol MUST allow individual feature
> context
> specifications to define their own synchronization with
> external events.
>
> 5.5.3 The base context transfer protocol SHOULD NOT provide
> support for
> updating
> context after it is transfered, since individual feature contexts will
> differ in
> their
> need for update.
>
> 5.5.4 The base context transfer protocol MUST allow individual feature
> context
> specifications to define their own update procedures if required.
>
>         Most feature contexts will not require
> synchronization, however
> there
>         are a few that may. Header compression, for example,
> may require
> that
>         the header compressor on the old access router cease and the
> compressor
>         on the new router start in synchrony with hand over
> of routing to
> the
>         new router; otherwise, the compressor on the new
> router will not be
>        properly synchronized. Since most contexts don't need
> synchronization
>        support, the general CT solution need not support it,
> but it should
> not
>        provide a hinderance to those feature contexts that do.
>
>        Feature contexts will differ in whether or not they
> require update.
>        A feature context such as QoS parameters for the service level
> agreement
>        with a user may not involve dynamically changing
> information, but it
> may
>        change during or after context transfer. Such feature
> contexts may
> benefit
>        from allowing the context to change after the transfer
> is completed.
> Other
>        feature contexts, such as header compression, may be tightly
> synchronized
>        with external events and changes on the old router need to be
> discarded
>        since the new router's state may already have been modified.
>
>
>

James:

> -----Original Message-----
> From: James Kempf [mailto:kempf <at> docomolabs-usa.com]
> Sent: July 19, 2002 21:26
> To: seamoby <at> ietf.org
> Subject: [Seamoby] New Section 5.8 - Requirements on Feature Context
> Specifications
>
>
> I'd like to propose the following new section for the CT
> requirments listing
> requirements on feature context specifications. Note that
> this section does not
> place requirements on the feature context protocols
> themselves, but only on
> their specifications.
>
>             jak
>
> ------------------------------------------
>
> 5.8 Feature Context Specifications
>
> The context transfer protocol provides a basic framework in
> which feature
> contexts of varying types can be transfered. Recognizing that
> the particular
> feature contexts may have very different needs with regard to update,
> synchronization, and transport, this section contains
> requirements on the
> feature context specifications. Note that these requirements
> do not constrain
> the actual feature context protocols themselves, but only
> their specification.
>
> 5.8.1 A feature context specification MUST contain an IANA
> assigned type code
> for the particular feature context. If an experimental
> feature context protocol
> is being developed, a type code from the context transfer protocol's
> experimental range SHOULD be used. The type code is used in
> the context transfer
> container to identify the feature context.
>
> 5.8.2 A feature context specification MUST define the byte
> layout of the
> individual elements of the feature context, and how those map
> into the context
> transfer protocol's container. The byte layout SHOULD obey
> standard IETF
> conventions with regard to mapping of data into on the wire format.

What is "wire format"?

>
> 5.8.3 A feature context specification MUST define the
> transport to be used. If
> the feature context is transferred using an IETF transport
> layer protocol , then
> the feature context specification MUST include the full
> details of how the
> transport layer protocol is used. If the feature context is
> transferred as an
> option on another IETF protocol, then the feature context
> specification MUST
> define the mapping of the context transfer container into the
> other protocol's
> standard option format. If the feature context is transferred
> through a non-IETF
> protocol (such as IAPP [4]), then the feature context
> protocol specification
> MUST define how the standard context transfer container is
> mapped into the
> non-IETF transport.
>
> 5.8.4 A feature context specification MUST indicate whether
> update to context
> information is allowed if changes in the source occur after
> the context is
> transferred. If such changes are allowed, the feature context
> specification MUST
> define the change protocol message format using the standard
> context transfer
> container, and MUST include details of how the update is accomplished.

Does this mean that the fcs must describe how the ARs perform the update?
Doesn't this address router functionality?

>
> 5.8.5 A feature context specification MUST indicate whether
> the context transfer
> is tightly synchronized with external events, such as
> handover. The freature
> context specification MUST indicate what event or events
> trigger transfer.

For what purpose? The fcs should define the context information
that the destination is to expect. What would the destination
router do with this information?

It is apparent what the source router might do with this information,
but why does it need to be standardized? E.g. if a router manufacturer
wishes to update context every 10,000 clock ticks, what concern is
this to the IETF?

Gary

>
> 6.0 References
>
> [4]  "Recommended Practice for Multi-vendor Interaccess Point
> Interoperability
> via an Inter-access Point Protocol Across Distribution
> Systems Supporting IEEE
> 802.11 Operation," IEEE Std. 802.11f/D3,  January, 2002.

Looks good.
>
>
>
> _______________________________________________
> Seamoby mailing list
> Seamoby <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

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:kempf <at> docomolabs-usa.com]
> Sent: July 22, 2002 12:31
> To: john.loughney <at> nokia.com; seamoby <at> ietf.org
> 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
> Seamoby <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

Madjid:

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri <at> motorola.com]
> Sent: July 22, 2002 18:56
> To: 'James Kempf'; seamoby <at> ietf.org
> Subject: RE: [Seamoby] New Section 5.8 - Requirements on
> Feature Context
> S pecifications
>
>

*snip*

>
> If the feature context is transferred as an
> option on another IETF protocol, then the feature context
> specification MUST
> define the mapping of the context transfer container into the
> other protocol's
> standard option format. If the feature context is transferred

What did you mean by "standard option format"? CT, as we have
been discussing it, is a container protocol, defined around
context "chunks". Are you implying that it should also allow
for encoding of context into the option fields of other protocols???

Gary

*snip*

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:kempf <at> docomolabs-usa.com]
> Sent: July 22, 2002 12:31
> To: john.loughney <at> nokia.com; seamoby <at> ietf.org
> 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
> Seamoby <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

Madjid:

 I snip because the back and forth replies become long, and the email
rejects messages over 40K (which is not as big as it might seem).

 The text you quote does not address my concern. James used the particular
phrase "standard option format" in a paragraph discussing context transport,
not type codes. It is possible I misinterpreted his intent, but that is
why I asked the question.

 Even so, I would question the rationale of standardizing the mapping
of type codes into option format fields of specific transport protocols.
It implies that each transport protocol could have different mappings.
I see no advantage, and much risk in such an approach.

Gary

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri <at> motorola.com]
> Sent: August 8, 2002 16:57
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; 'James
> Kempf'; seamoby <at> ietf.org
> Subject: RE: [Seamoby] New Section 5.8 - Requirements on
> Feature Context
> S pecifications
>
>
> Gary,
>
> I am sorry, I think you took the "context" out of the
> discussion by snipping
> the rest of the comments :)
> The following text suggested by James captures the issue:
>
> Madjid
>
> > 5.8.1 A feature context specification MUST contain an IANA
> assigned type
> code
> > for the particular feature context. If an experimental
> feature context
> protocol
> > is being developed, a type code from the context transfer protocol's
> > experimental range SHOULD be used. The type code is used in
> the context
> transfer
> > container to identify the feature context.
>
>
>
> -----Original Message-----
> From: Gary Kenward [mailto:gkenward <at> nortelnetworks.com]
> Sent: Tuesday, August 06, 2002 12:32 PM
> To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; seamoby <at> ietf.org
> Subject: RE: [Seamoby] New Section 5.8 - Requirements on
> Feature Context S
> pecifications
>
>
> Madjid:
> > -----Original Message-----
> > From: Nakhjiri Madjid-MNAKHJI1
> [mailto:Madjid.Nakhjiri <at> motorola.com]
> > Sent: July 22, 2002 18:56
> > To: 'James Kempf'; seamoby <at> ietf.org
> > Subject: RE: [Seamoby] New Section 5.8 - Requirements on
> > Feature Context
> > S pecifications
> >
> >
> *snip*
> >
> > If the feature context is transferred as an
> > option on another IETF protocol, then the feature context
> > specification MUST
> > define the mapping of the context transfer container into the
> > other protocol's
> > standard option format. If the feature context is transferred
> What did you mean by "standard option format"? CT, as we have
> been discussing it, is a container protocol, defined around
> context "chunks". Are you implying that it should also allow
> for encoding of context into the option fields of other protocols???
> Gary
> *snip*
>