RE: [Seamoby] CT Requirements Comments from IESG

James:

  Sorry, but a small clarification: I did not say that dynamic context 
was rejected, I said that I recalled that there was, at one time, a
requirement
that attempted to directly address dynamic context and the need to update it

and that requirement was eventually removed. I think the reason was the
difficulty
in defining "dynamic" versus "static" context, as Charlie outlines in his
response.

  There is, however, a requirement, 5.5, that speaks to context updates in
general:

5.5 Context Update and Synchronization

5.5.1 The context transfer protocol MUST be capable of updating 
      context information when it changes.

5.5.2 A context update MUST preserve the integrity, and thus the
      meaning, of the context at each receiving AR.

   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. Any change of context at the
   supporting AR must be replicated at those ARs that have already
   received context for that MN.

I am now wondering why this requirement did not answer the IESGs concerns?
Possibly because it does not explicitly mention "dynamic context" or
"dynamic
updates"? 

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 9, 2002 13:22
> To: seamoby@ietf.org
> Subject: [Seamoby] CT Requirements Comments from IESG
> 
> 
> I have finally managed to get a couple of technical comments 
> out of the IESG on the CT requirements. More are coming but I think it
> might be worthwhile to start discussing these.
> 
> 1) The requirements say nothing about the maintenance of 
> dynamic context. Something must be said, is this out of scope 
> or what? Gary
> tells me that supporting dynamic context was rejected by the 
> working group, but it seems like we cannot punt on at least saying
> something about this issue.
> 
> 2) The requirements say nothing about context which must be 
> modified on the new router in order to be useful. An example is ROHC
> context when the mobile obtains a new care of address. How 
> would the CT protocol handle this?
> 
> I've asked Gary to lead a discussion on these two issues, 
> please send comments to the list.
> 
>             jak
> 
> 
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
> 