Subject: [Seamoby] CT Requirements Comments from IESG

From: "James Kempf" <[email-masked]>
Date: Tue, 9 Jul 2002 10:22:10 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 09 Jul 2002 10:46:31 -0700

Hello,

James Kempf wrote:

> 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.

What does "static" context mean?  Is it something that doesn't change?
I would expect that the kinds of context that are worth transferring
would very often contain dynamic information.  Even QoS, which may be
set up with static parameters per flow (or per mobile, even), would
likely have dynamic measurements that needed to be transferred (for
traffic shaping or metering).  Security associations (which could be
transferred (and should be)) also have dynamic ancillary data (like
lifetime or current volume of data).

> 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?

This is a property of the context, not a property of the
context transfer protocol.

In fact, whether or not the context is dynamic is also not a
property of the context transfer protocol.  It's up to the new
access router to figure out how to "install" the context, whether
or not it's dynamic, or dependent upon link parameters at the
new access router.  For instance, transferring QoS between
dissimilar access routers would require different procedures to
manage the QoS transfer effectively.  The security associations
should be modified in some predictable way in order to be
installed at the new access router.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 09 Jul 2002 10:46:31 -0700

Hello,

Regards,
Charlie P.

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 09 Jul 2002 13:00:57 -0700

hi Jim,

> context when the mobile obtains a new care of address. How would the CT protocol handle this?

the context transfer protocol should not worry about this at all.
it is specific to each feature. for ROHC, the IP addresses have
to be changed. for IPsec Security Associations, the SPIs maybe
need to be changed in addition to the IP addresses.

regards
Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 09 Jul 2002 13:00:57 -0700

hi Jim,

regards
Vijay