Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of

From: "Govind Krishnamurthi" <[email-masked]>
Date: Tue, 26 Mar 2002 19:53:33 -0500

>,
> > So now you agree that the AR can hand over the list of GAARs and
> > their capabilities to the MN (maybe only pass on those which satisfy
> > the MN requirements, which is what CAR discovery was originally
>about).
> >
>
>No, that it sends all, along with the capabilities. Let me repeat the
>requirement I would like to see (and Henrik apparently agrees) so we are
>clear on this:
>
>     The CAR discovery protocol MUST provide the MN with GAAR
>     information, along with capabilities.
>

[Govind] First what you are calling as CAR discovery is not CAR discovery.
What you are saying is GAAR + associated capabilities discovery
not CAR discovery therefore part of CAR discovery. CAR discovery matches the 
requirements of the MN with the capabilities of the GAARs.

Having said that, if the purpose of the sending this information to
the MN is to run the TAR selection algorithm there, then it would be
prudent to filter out some of the GAARs (which don't satisfy the MN's 
requirements) and send only the remaining to the MN. That would reduce
the bandwidth as well as power.

Having said that, I disagree with this requirement which first forces a
particular TAR selection aspect onto CAR discovery which I feel is totally 
not required. A better requirement is CAR discovery output MUST
be made available to the TAR selection algorithm whereever it resides.

>Please see the requirement above. No contradiction. The protocol allows
>the MN to discover  the GAAR and capabilities, the MN decides which one
>it wants.
>Nothing about the AR in control of anything. The MN may use a variant >of
>IPv6 neighbor discovery, the AR may be involved somehow, but that's a
>protocol design, not a requirement, choice. The requirement is clearly
>that the MN does the discovery.

[Govind] I don't agree to the fact that MN must alone do the discovery.

>We now have two working group members who want this reqirement worded
>just this way. Nothing about "as the MN expresses its preferences" or
>"by the CAR discovery module" or anything else. And I believe Hesham has
>also expressed a preference for this requirement.

[Govind] Well I'm against it and I know others who have objected to this
too.

>
>Anybody else out there have an opinion on this? Should we include this
>requirement instead of requirement 3.4, which has the AR in control?
[Govind] I agree that the requirement 3.4 may look biased toward a AR
solution and we can re-word it. But to swing the pendulum to the other
extreme which prohibits anything other than a MN based discovery is
not correct.

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 11:33:42 -0500

James,

>Govind,
>
>Of course it is CAR discovery. The MN takes the GAARs and figures out
>which are CARs. Then it performs TAR.

[Govind]All the GAARs and their capabilities is NOT CARs. I totally 
disagree.
Second, it is your opinion that this is the way to do it.
Not mine.
>
>What you seem to want is for the AR to do the CAR selection. As I've
>pointed out numerous times, the AR can't possibly know a priori what the
>MN's current interface configuration is at any day and time.

[Govind] I have pointed out several times too  about why it does not matter, 
as in the TAR selection
process the reachability information from the MN will be there to take care 
of what you point out as the only difficulty.

Right now I am saying
that the AR should be allowed to do CAR discovery. I don't know what you 
mean by CAR selection. You seem to indicate that AR CANNOT DO IT. Which
is clearly a technically unsubstantiated opinion till now, IMHO.

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 11:33:42 -0500

James,

Right now I am saying

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 13:03:48 -0500

James,

>Here's the requirement:
>
>     The other fundamental function of CAR discovery protocols is that of
>     identifying the capabilities of GAARs. The protocol MUST provide
>     functionality to allow ARs to discover their GAAR's capabilities.
>These
>     capabilities MUST be communicated in a secure fashion.
>
>There is not one single mention of the MN in this requirement.
>
>How can you interpret that this requirement does NOT put the AR in
>control? This is exactly the message Steve Deering was trying to get
>across in the Minne-apple.

[Govind] There is a bias and I agree that the bias should be removed.

But
what you are suggesting is to swing the pendulum to the opposite end
putting an MN bias. We should work toward an un-biased set of requirements, 
IMHO, and thats what I will endeavor to do based on the discussions in the 
mailing list.

Regards,
Govind.

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

---

From: [email-masked]
Date: Wed, 27 Mar 2002 14:01:30 -0500

Henrik,

> IMHO, and thats what I will endeavor to do based on the discussions in the 

Yes, yes! 

	That is what we are suggesting! That there *needs* to be a bias
towards the MN, that whatever we design which does not give this to the
MN will not provide the User with what he wants and needs, and ultimately won't
be deployed and used.

[DOT] Does this necessarily mean that the MN has to do the job entirely? Giving
the control of the handover decision to the MN and providing information to do
so through assistance of the network, is a different thing.

	I thought Steve was so clear in Minneapolis, and the case so clear as
well, that I did not expect this resistance.

[DOT] This is open to interpretation since everybody got his/her own impression.
I did also take away from this presentation that it indeed makes sense to use information
and functionality from the network to do the CAR discovery. I did not understand Steve's
talk in a way that EVERYTHING has to be MN-based.

[DOT] Another point is that we should not take Steve's talk and its interpretation by
WG members as the final mandate for the definition of requirements. His presentation
certainly stimulated the discussion, and that is good since we made progress in 
addressing certain things. But just pointing to interpretations of this talk to justify
requirements and their sense is not enough for me. We still have to have a discussion
and a WG consensus about this work.

Regards,

Dirk

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 14:36:31 -0500

James,
I agree that an incompletely stated requirement is meaningless.

But I just don't seem to understand why you claim that an AR based scheme 
which can take the MN's requirement totally into consideration cannot do the 
job which you illustrate? Note that I have never
said what you propose is not feasible but the feasibility of what I propose 
is also true. Can't we have a happy medium? :)

Thanks,
-Govind.

>Govind,
>
>We have to think about what the requirement is intending to accomplish.
>If we don't mention that, then the requirement becomes meaningless. The
>intent is to get the MN the information it needs to select the next AR.
>Thus, I believe we must mention the MN.
>
>             jak
>
>----- Original Message -----
>From: "Govind Krishnamurthi" <[email-masked]>
>To: <[email-masked]>
>Sent: Wednesday, March 27, 2002 10:03 AM
>Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement
>(was: Examples of
>
>
> > James,
> >
> > >Here's the requirement:
> > >

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

---

From: [email-masked]
Date: Wed, 27 Mar 2002 14:39:34 -0500

Govind,

[DOT] But isn't that the disagreement, namely the amount of information
the MN needs to select? Assuming that MN could, by any means, connect/handover
to x ARs, does it really mean that the MN has to get the entire information 
of all these x ARs? What if only y ARs satify the MN's requirements? It still
sufficient (and even MN-controlled) to choose out of these y since the other
ones are worthless.

Dirk

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 15:48:48 -0500

Govind,
I don't completely understand your mail. Let me make clear my
concern.
What are you referring to as a solution?

The objective of CAR discovery is to match the GAARs capabilities to the 
MN's requirements to come up with a set of CARs. That is a requirement.

I would say pushing GAARs and their capabilities to the MN is a solution as 
it describes a way to do it.

Regards,
Govind.

>
>Govind,
>
>Because this is a solution, not a requirement.
>
>The requirement is that the MN get the information it needs. How that is
>implemented is up to the protocol.
>
>             jak
>

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 15:48:48 -0500

Govind,

Regards,
Govind.

---

From: [email-masked]
Date: Wed, 27 Mar 2002 15:57:14 -0500

James,

This is solution space. Without examining this in detail, we can't say.
The intent of the requirements is to constrain the solution through high
level goals, not specify them in detail. The information could be
handled by a 16 bit bit vector, or it could require an ASN.1 LDAP query,
we cannot say at this point.

That's why I and others think that we need to clearly state that the MN
gets the information it needs.

[DOT] The reason of contention is simply that I want to avoid a requirement
that reads like providing unnecessary information to the MN. We're totally
in agreement that the MN should get the information to make the decision. 
See my proposed wording in my other mail to address this. I just want to avoid
that someone is coming back later saying "hey, your solution is not giving me
ALL GAAR info that you have, hence it is not compliant to the requirements".

Dirk

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 27, 2002 11:39 AM
Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement
(was: Examples of

---

From: [email-masked]
Date: Wed, 27 Mar 2002 15:57:14 -0500

James,

Dirk

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 27, 2002 11:39 AM
Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement
(was: Examples of

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 27 Mar 2002 20:54:08

Hi James:

To get around the possible interpretation of forced physical delivery part 
of it, how do you like:

"The GAARs and their capabilities MUST be made available to the entity 
performs comparison of MN's requirements and capabilities of GAARs.

When this comparison is done in MN, the GAARs and their capabilities MUST be 
made available to MN.

MN MUST be given full control of deciding about the entity that performs 
this comparison."

If you do not like it, ignore it. Thanks.

Hemant

>From: "James Kempf" <[email-masked]>
>To: <[email-masked]>, <[email-masked]>, <[email-masked]>
>Date: Wed, 27 Mar 2002 12:38:21 -0800
>
>Dirk,
>

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 27 Mar 2002 20:54:08

Hi James:

Hemant

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 28 Mar 2002 17:55:07 -0600

[eunsoo] If the presentation is so influential on our issues, could anyone
make it available for the people who did not attend the Minneapolis meeting?

Madjid>> That plus the meeting minutes, thank you,

Madjid

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 28 Mar 2002 17:55:07 -0600

Madjid