RE: [Seamoby] Proposal on Sync/NoSync Requirement

Gary,

thanks for the suggestions, please see my comments below.

Madjid

Proposed: 
5.5 Context Update and Synchronization 
5.5.1 The context transfer protocol MUST be capable of supporting the 
      updates to context information when it changes.  

 Madjid>> Ok, this takes care of the dynamic context, however,we 
need to be clarify that we are not requiring the oldAR sends updates
to context features it has already transmitted while it is transmitting
context for other features, otherwise CT might never end.
Since, some folks have brought that up, I want to make sure that we
 are not reading that in the requirement. Updates initiated by oldAR
should only be based on outside triggers such as new flow, flow terminations
or messages from central entities...

5.5.2 Context updates SHOULD complete before the context is needed at 
      the receiving AR. 

Madjid>> How do we know when the context is needed at the receiving AR? 
I find this more like a design guidance than a requirement. The following
text
can with some exceptions added to the explanation of 5.5.2.

   The context at the AR actually supporting an MN's traffic will 
   change with time. For example, the MN may initiate new microflow(s), 
   or discontinue existing microflows. 
Madjid>> the above is good.

Any change of context at the 
   supporting AR must be replicated at those ARs that have already 
   received context for that MN.
Madjid>> MUSt is too strong. 5.5.1 is SHOULD, so should this one be
(sorry for too many shoulds :)) There are ways to avoid having to do
this through CT. 

   However, context changes are often driven by events external to the 
   sending AR, and will thus be asynchronous to any on-going context 
   updates. Given that context transfers will take a finite amount of 
   time to complete, it is possible that a change in context cannot be 
   conveyed in time to the destination AR to avoid any impact on a possible 
   handover. The objective of the context transfer design must be to make 
   the likelihood of this delay, and its magnitude, as low as possible. 

Madjid>> The above is good.

This is not perfect: the desire to avoid a requirement for an extreme degree

of synchronization is only implied by the soft "SHOULD" in 5.5.2. 
Regards, 
Gary 

> -----Original Message----- 
> From: James Kempf [mailto:kempf@docomolabs-usa.com] 
> Sent: July 14, 2002 18:52 
> To: john.loughney@nokia.com; seamoby@ietf.org 
> Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement 
> 
> 
> That sounds better. 
> 
>             jak 
> 
> ----- Original Message ----- 
> From: <john.loughney@nokia.com> 
> To: <kempf@docomolabs-usa.com>; <seamoby@ietf.org> 
> Sent: Sunday, July 14, 2002 3:01 PM 
> Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement 
> 
> 
> > Hi James, 
> > 
> > > "Out of scope" is typically WG charter language. I know the 
> > > SHOULD/SHOULD NOT sounds a bit funny, but I think we need to 
> > > express this in a way that is more requirements language. 
> > 
> > Then how about changing: 
> > 
> >       ... the CT solution need 
> >       not support it, but it should not provide a 
> hinderance to those feature contexts 
> >       that do. 
> > 
> > to: 
> >       ... the CT solution is not requireed to directly 
> support synchronization, but 
> >       may support simple methods for the synchronization 
> context for feature contexts 
> >       that do. 
> > 
> > John 
> > 
> 
> 
> _______________________________________________ 
> Seamoby mailing list 
> Seamoby@ietf.org 
> https://www1.ietf.org/mailman/listinfo/seamoby 
> 

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby