Subject: RE: [seamoby] Questions on CAR Discovery Problem Statement?

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 31 Oct 2001 15:03:02 -0600

Hi,

Not sure if I have missed the deadline or not.
Can't say I have a problem with this work item, just
 a few comments about the draft:

1- I am glad to see that Capability discovery is mentioned here.
Recognizing the relationship between capability and CAR discovery is 
important.

2- I agree that the work of algorithm development for TAR selection
is out of scope, since the algorithm will depend on the selection 
criteria such as network policy and MN/ network preference.
However, I don't think the selection of CAR is entirely out of scope,
given the algorithm, there still need to be a protocol in place, which
I think this work item is trying to define.

3-Why the terminolgy of "anticipated v.s. dynamic" is used for 
"network assisted" v.s. "MN centric" CAR discovery.
The distinction being made in the draft is based on the unit that
is doing the work, and some temporal aspects but not all such
as static v.s. dynamic capabilities.
Let me explain:

In 4.2 you do talk about capabilities such QoS, security... as inputs to
selection algorithm. Some of these inputs are more static, such
as QoS profiles, PHBs, security policies and so on, 
while some of the inputs are more dynamic such as current state of the
congestion, bandwidth allocation in the network, and maybe even some 
fading on signal strength.

The more dynamic aspects would still need to be used as input.
So when you say dynamic CAR selection, I can't help it. I think 
about the dynamic capability discovery.

Just my 2 cents (2/3 cents per comment :) )
Keep up the good work,
Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Friday, October 12, 2001 2:14 PM
To: [email-masked]
Cc: [email-masked]
Subject: [seamoby] Questions on CAR Discovery Problem Statement?

Folks,

The CAR discovery problem statement is currently in last call. At IETF
51 in London, I vaguely recall after Govind's presentation hearing that some WG 
members were uncertain why CAR discovery was necessary. The current problem
statement attempts to address this question more directly than
the original did. I hope those of you who had this question will
read the problem statement and submit any further questions to the list.
In addition, if anybody has any further issues with the problem
statement, now is your chance to raise them. Thanx.

		jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 31 Oct 2001 13:28:10 -0800

Madjid,

>  a few comments about the draft:

Well, you did miss the deadline, we were about to submit the
revised draft to the IESG. But let's talk about your comments...

> Recognizing the relationship between capability and CAR discovery is

OK.

> I think this work item is trying to define.

Is there anything that needs to be changed in the draft?

As you say, the algorithm to select the TAR is a matter of implementation
and configuration. With regard to selection of CARs, there may be
a need for some alorithm, particularly with regard to evaluating
geographical
adjacency information or radio signal strength. But I think that is a
separate
issue and not something that needs to be defined in the protocol for
exchanging capability and other information. I don't know if the WG wants
to get into that or not.

> "network assisted" v.s. "MN centric" CAR discovery.

Well, we couldn't think of any other names. Anticipated implies
that the information is on the router prior to the MN requiring a handover,
it may or may not be updated dynamically. Dynamic was meant to
imply that it may be exchanged during an actual handover.

> as static v.s. dynamic capabilities.

Sure. There are static aspects of the dynamic case and
dynamic aspects of anticipated. The MN could be gathering
information all the time, then apply it just at handover. The
issue is when the protocol would be used. If the protocol
is being used at handover time, we have been calling it
dynamic. If it is used prior to handover and doesn't
involve the MN, then we've been calling it anticpated.

> about the dynamic capability discovery.

If you have any suggestions for better names, please let us know.

            jak