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

From: [email-masked]
Date: Wed, 27 Mar 2002 11:45:02 -0500

Henrik,

	We seem not to be communicating here. You snipped out the part of
my posting where I point out that this requirement does *not* imply that
the MN needs to bee flooded, and then you point out that to avoid flooding
might be worthwile.

	The point I was trying to make here was:
					This requirement does not require *all* GAAR
information, it does not require *on-demand operation*, it expresses exactly
what we are in a position to say about the matter now:

		The CAR discovery protocol MUST provide the MN with GAAR
		information, along with capabilities.

	I am starting to wonder why people protest and debate this requirement
so much, even when it seems to allow for all variations that people have
advocated, exactly as it stands?

	Henrik

[DOT] apart from the greetings I left the mail now unchanged. What I don't understand is,
if we are so much in line that it is not required to send ALL GAAR information, why is it
so controversial to state this explicitly? Apparently, the current text is controversial among
a set of people to the extent that it might be interpreted that you have to send ALL GAARs+capa
to the MN. Because of this controversial interpretation, the requirement should be changed in a way 
that it is not anymore. So if we agreed that not ALL GAAR information needs to be transferred, we would
make a step forward. But I still see a disagreement even in this discussion. But if we agreed, 
we should put that in a wording that reflects it properly and makes the requirement non-controversial 
in its understanding to someone who wants to design the protocol.

Dirk

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

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Wed, 27 Mar 2002 17:54:11 +0100

Dirk,

	Thank you.

	The point is rather that the revised form of this requirement
imposed another restriction, namely that a filtering mechanism would
have to be part of the solution. 

	I would like to avoid that requirement for now.

	The solution when somebody misapprehends a well formulated 
requirement is NOT to change the requirement into something that 
has unwanted side effects, but rather to clear up the misapprehension 
itself, I think.

	Regards,
		Henrik

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Wed, 27 Mar 2002 17:54:11 +0100

Dirk,

	Thank you.

	Regards,
		Henrik