RE: [Seamoby] CT Requirements Comments from IESG

James, all, 

I think we are walking on a fine line between requirements and solutions.

1-
It was decided long time ago that collection and drainage of context
is not the job of context transfer protocol. whichever protocol entity
injecting its states into the CT protocol is responsible for the freshness
of context. We debated a lifetime field for each context, in case the
context
is dynamic, how you handle these sort of issues is completely in solution
space.
For requirement phase, again I say the freshness of context is the job of
the protocol
unit. Now you can argue that we don't have any reliability mechanisms (such
as
error protection and retransmissions) so after a couple of retries the
context
gets old, but again in the absence of reliability mechanisms only a life
time
mechanisms is the most the CT protocol can do.

2- Usefulness at the new AR is not CT's headache. Rohc is just one thing,
different QoS policies, DSCP<->PHB/ service mapping are another, different
security mechanisms are another. Negotiation is another.
CT is not supposed to deal with adaptation, negotiation, remapping....
CT only transfers what it thinks is the same at both side.
As far as Rohc goes, well change of IP address might change
a lot of things, not just headers (QoS profile is one example, SPI
is another, as Vijay mentioned). I don't think this is CT's problem.
This is the problem of the protocol that uses CT for things that
are not the same at both sides of handover.

Regards,
Madjid

-----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: Tuesday, July 09, 2002 12:22 PM
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

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