Subject: [seamoby] some issues on the ct draft

From: "Shahrier, Sharif M." <[email-masked]>
Date: Thu, 22 Feb 2001 11:28:46 -0500

Henrik,

I have read through the draft "draft-ietf-seamoby-ct-problem-alpha06" (I was
not sure if that was the one submitted for last call, in any case it should
be close to it). I would like to make some contributions to it as follows.

1. In 3.2.1 and 3.2.2 security and header compression was mentioned as 2
examples of context. I would like to add 2 more, namely, QoS, and IP address
of (source/target). These are required by our mobility management protocol
draft which I will be submitting tomorrow.
Of  course, people can add other parameters as well. I will send you text to
add as 3.2.3 and 3.2.4.

2. I would like to bring up the PDP-context as deployed in GPRS networks.
Since, this network is commercially used today and forms over 80 percent of
the world's mobile packet network, I don't think we should ignore it. Thus,
I will send you some text on the activation and transfer of PDP-context as
an example of what's deployed today.

3. On p. 12, 3.2.5 buffers are discussed. I would like to expand this and
add buffering methods for some different types of handover. I will you send
a short segment to add to that section.

4. Section 4.1.2 discuss mobile updating contexts, while 4.1.3 discusses
access routers 
exchanging contexts. I would like to add a subsection that discuss a hybrid
combination of the two methods. We are studying such a method ourselves for
future work.

5. 4.1.4: Central repository, I would like to add a con: not fault-tolerant.
This is a big issue for centralized systems.

Thank you, and I look forward to receiving some feedback.

Sharif Shahrier

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Thu, 22 Feb 2001 19:12:11 +0100

Sharif,

> Of  course, people can add other parameters as well. I will send you text to

QoS is one of the examples mentioned in 3.2.x, in the Diffserv/Intserv section
3.2.3.   The needs of QoS mechanisms very much also underlay the definition
of context in terms of microflows and their features, where a microflow definition
includes not only (source/target IP address, but more, see section 3.1.1 of the
draft.  I think the design team needs to see your text before carrying on.

> an example of what's deployed today.

(Answered separately)

> a short segment to add to that section.

I believe we already removed some text talking about different buffering methods.

> combination of the two methods. We are studying such a method ourselves for

We have already omitted inclusion of one hybrid combination.  Again, we could
describe hundreds of variations, but to which point?

> This is a big issue for centralized systems.

I think this is a very valid point, which should be included in an eventual revision.