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

From: George Tsirtsis <[email-masked]>
Date: Wed, 27 Mar 2002 11:21:10 -0500

So, is there anyone that seriously thinks that "blasting GAAR IDs and all of
their capabilities to MN" is a good idea? If not (which I hope so) then the
requirements document should not imply otherwise.

George

-----Original Message-----
From: Hemant Chaskar [mailto:[email-masked]]
Sent: Wednesday, March 27, 2002 4:08 PM
To: [email-masked]
Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement
(was: Examples of CAR discovery)

Hi Hernik:

I did read your comment and responded as follows in my earlier email. 
Cut'n'Paste:

-------------------------------
If we honestly think that the requirement does not oblige AR to blast all 
GAAR IDs and all of their capabilities to MN, why not say so clearly. Why do

we need to hide this fact? We can come up with something else, if you do not

like on-demand extension. I think without such extension the solution 
satisfying this requirement may have serious shortcomings that I described 
in my other email to James.
--------------------------------

BR,
Hemant

>From: "Henrik Levkowetz" <[email-masked]>
>To: "Hemant Chaskar" <[email-masked]>
>Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement     
>(was: Examples of CAR discovery)
>Date: Wed, 27 Mar 2002 02:09:44 +0100
>
>Hemant,
>
>	You apparently did not read my recent posting. Cut'n'Paste:
>
>	No, the requirement is just fine. It 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 think that's the essence of it. Do you oppose this? Why? Do you
>want to make things more complicated than they have to be?
>
>	Henrik
>
>Hemant wrote:
> >
> > Hi James:
> >
> > There are serious shortcomings of the solution satisfying this 
>requirement.
> > They are described below. How can we finalise this requirement unless it

>is
> > agreed that these pitfalls do not exist?
> >
> > For this, it might be good idea to visualise how the solution satisfying
> > this requirement looks like and violates basic tenets of engineering 
>design,
> > namely efficiency. The solution satisfying this requirement is obliged 
>to
> > blast GAAR IDs and their capabilities on MN when AR sees MN. This might 
>be a
> > big chunk of data (= number of GAARs times capability set of each). This
> > flood will occur either on active traffic connection which I call case 
>(i)
> > (relevant for single interface MN and two-interface MN where second
> > interface is sleeping) or on second interface which I call case (ii)
> > (relevant for two interface MN with both interfaces awake). There are
> > following effects of this flood:
> >
> > 1. Disruption in traffic: For case (i), it causes disruption in traffic 
>over
> > active traffic channel.
> >
> > 2. Power wastage: For both cases (i) and (ii), receiving this flood 
>causes
> > power wastage. This is because, after receiving these capabilities MN 
>either
> > rejects the new AR (which is worst), and even if it selcects one why 
>does it
> > need to receive capabilities of GAARs that do not matter for it.
> >
> > 3. Bandwidth wastage: An AR needs to send this flood to every MN that it
> > sees. Which means the same information (which could be big enough) is
> > transmitted on downlink so many times. This takes up considerable 
>fraction
> > of downlink capacity.
> >
> > 4. Limit on capability definition: This requirement restricts the 
>definition
> > of capabilities to a very small size, otherwise all ARs will only be
> > transmitting GAAR capabilities to different MNs all the time. This means
> > capability set cannot be comprehensive and extensible.
> >
> > So, IMHO rather than counting who agrees to one statement requirement 
>that
> > you proposed and who have not, we should first analyse above harmful 
>effects
> > before deciding either way.
> >
> > Br,
> > Hemant
> >
> >
> > >From: "James Kempf" <[email-masked]>
> > >To: "Govind Krishnamurthi" <[email-masked]>, <[email-masked]>
> > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement 
>(was:
> > >Examples of CAR discovery)
> > >Date: Tue, 26 Mar 2002 15:40:36 -0800
> > >
> > >,
> > > > 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.
> > >
> > >
> > > > Which first implies that the network is taking care of CAR 
>discovery.
> > > > This seems contradictory to your earlier mails saying that there is
> > > > no basis for network based CAR discovery. So are you now agreeing
> > > > that network based CAR discovery has its place?
> > > >
> > >
> > >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.
> > >
> > >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.
> > >
> > >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?
> > >
> > >             jak
> > >
> > >
> > >_______________________________________________
> > >Seamoby mailing list
> > >[email-masked]
> > >https://www1.ietf.org/mailman/listinfo/seamoby
> >
> >
> > _________________________________________________________________
> > MSN Photos is the easiest way to share and print your photos:
> > http://photos.msn.com/support/worldwide.aspx
> >
> >
> > _______________________________________________
> > Seamoby mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/seamoby

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

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

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

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 27 Mar 2002 16:27:38

Hi George:

I think this blind blasting is a bad idea, and hence, requirement should not 
imply it. The current requirement (as seen from the plain statement text) 
may imply this. Hence, it needs some extension. That is what I am saying.

Hemant

>From: George Tsirtsis <[email-masked]>
>To: 'Hemant Chaskar' <[email-masked]>, [email-masked]
>Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa 
>s: Examples of CAR discovery)
>Date: Wed, 27 Mar 2002 11:21:10 -0500
>

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

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 27 Mar 2002 16:27:38

Hi George:

Hemant

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 17:32:30 +0100

What is iths blöasting that people keep
bringing up? an extra option in an RA is blasting ????
What is the alternative: The magic AR that knows 
everything ??????????????

Seriously, let's keep it simple or this whole 
protocol will start collapsing the moment
anyone starts deploying it. Of course if deployment
is not a concern then I'll just og back to sleep!

Hesham

  > From: George Tsirtsis [mailto:[email-masked]]
  > Sent: Wednesday, March 27, 2002 5:21 PM
  > To: 'Hemant Chaskar'; [email-masked]
  > (wa s: Examples of CAR discovery)
  > 
  >

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 17:32:30 +0100

Hesham

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 27 Mar 2002 16:37:45

Hi Hesham:

No RA is not what blasting is about. What this requirement is saying is to 
send to MN a volume of data = Number of GAARs times capability set of each. 
Number of GAARs itself could be large and capability set could be very large 
too. It might contain policies, supported IP protocols, any application 
specific functionality support and this set could be extensible.

Sending this volume of data to MN without any regard to whether it wants it 
or not is what I call blasting.

Hemant

>From: "Hesham Soliman (ERA)" <[email-masked]>
>To: "'George Tsirtsis'" <[email-masked]>,   "'Hemant Chaskar'"  
><[email-masked]>, [email-masked]
>Date: Wed, 27 Mar 2002 17:32:30 +0100
>

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

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 27 Mar 2002 16:37:45

Hi Hesham:

Hemant

---

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

Hesham,

[DOT] Maybe, you should just read the requirement text and the
mails that have been brought up in this context. We are not
talking about an option in RAs, we are talking about the information
that is stated in the requirement to be transfered. This is more
than having an option. Maybe, you don't care about transferring 
unnecessary information to the MN, maybe others do. The discussion
did not imply that the 'magic AR knows everything'. 

Dirk

---

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

Hesham,

Dirk

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 17:38:07 +0100

,
  > requirement I would like to see (and Henrik apparently 
  > agrees) so we are
  > clear on this:
  > 

=> Agreed.

  > 
  > 
  > > Which first implies that the network is taking care of 
  > CAR discovery.
  > Nothing about the AR in control of anything. The MN may use 
  > a variant of
  > "by the CAR discovery module" or anything else. And I 
  > believe Hesham has

=> Agreed 200%. I know more people too that want this :)

  > requirement instead of requirement 3.4, which has the AR in control?

=> Yep!

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 17:38:07 +0100

,

=> Agreed.

=> Yep!

Hesham

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 27 Mar 2002 11:40:54 -0500

Hesham relax :-)

The "extra option" on the RA may or may not be a problem. We will only know
if this is a problem AFTER we know what "capabilities" mean i.e.: how much
data can be in there for the list of GAARs. That does make me nervous,
doesn't you?

The problem of course starts from the fact that one AR is supposed to
provide this list of GAARs + capabilities to the MN (which could be a lot of
info). In a MN centric approach the MN knows which the GAARs are and gets
their capabilities directly from them...much better IMO.

George
-----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Wednesday, March 27, 2002 4:33 PM
To: 'George Tsirtsis'; 'Hemant Chaskar'; [email-masked]
Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement

Hesham

  > agrees) so we 
  > believe Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 17:43:38 +0100

> that is stated in the requirement to be transfered. 

=> I think I know what you're talking about. Or I'm trying
at least. I'm giving you an example of a way to carry the 
information to the MN. Perhaps this is too radical?? 
Is carrying this information to the MN too radical ?
If so, I need to hear a technical reason. All I've
seen is mere speculation. 
I discussed this already with Govind in MPLS and 
after the meeting I thought it was agreed on.

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 17:43:38 +0100

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 17:45:52 +0100

Hi Hemant, 

  > specific functionality support and this set could be extensible.

=> This is all based on an assumption: The scope 
of the GAAR discovery will scale to a very large number of GAARs. 
I don't think this is realistic, and after Steve's presentation
I thought the entire WG agreed with this. 
Why are we trying to reverse this concensus?

  > or not is what I call blasting.

=> See above. 

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 17:45:52 +0100

Hi Hemant, 

=> See above. 

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 17:48:14 +0100

> data can be in there for the list of GAARs. That does make 

=> I agree, but only if you assume that GAAR
discovery will cover a very large number of 
GAARs. This is where I think that the assumptions are
flawed. If we limit the AR-based discovery to one 
operator's network and one access tech, then we are
most likely to end up with one or two GAARs.
Right ?

  > their capabilities directly from them...much better IMO.

=> Can't agree more.

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 17:48:14 +0100

=> Can't agree more.

Hesham

---

From: [email-masked]
Date: Wed, 27 Mar 2002 11:48:51 -0500

Hesham,

[DOT] It is not HOW it is transferred, it is WHAT and HOW MUCH.
Since we don't yet how much it is we're talking about here
(independent of how you actually transport it), concerns have
been expressed to provide this unknown amount of data to the MN,
even if it is not necessary. I do think that this is a technical
reason.

Dirk

---

From: [email-masked]
Date: Wed, 27 Mar 2002 11:48:51 -0500

Hesham,

Dirk

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 27 Mar 2002 11:57:39 -0500

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Wednesday, March 27, 2002 4:48 PM
To: 'George Tsirtsis'; Hesham Soliman (ERA); 'Hemant Chaskar';
[email-masked]

GT> In cellular deployment each AR will have up to 6 GAARs assuming ARs on
each BS/AP. What you say above is that the protocol we are talking about is
clever enough to know between which 2 or 3 ARs the MN is currently located.
In the "anticipated" mode CAR discovery takes place prior to handoff so I am
not sure your assumption will always hold. Or maybe I have misunderstood
something?

=> Can't agree more.

GT> I suspected as much...I think that was the general feeling during the WG
meeting and after Steve's presentation.

Thanks
George

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 18:02:24 +0100

> each BS/AP. 

=> Err, in _your_ cellular deployment ;) 
I wouldn't make this general statement about 
cellular networks. In fact it's the exact opposite
with cdma2000 or 3GPP.

What you say above is that the protocol we are 
  > talking about is

=> I think I wasn't too clear. In the anticipated
mode, the assumption I make is that the triggers
are at the AR, so the AR will do the discovery
and forward the info to the MN. Just like 
the Prrtradv is FMIPv6. 
This is the problem with calling it anticipated, 
it gives the impression that anticipated must 
be network controlled. which is not the case 
of course.

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 18:02:24 +0100

Hesham

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 27 Mar 2002 12:11:44 -0500

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Wednesday, March 27, 2002 5:02 PM
To: 'George Tsirtsis'; Hesham Soliman (ERA); [email-masked]
Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement

GT> Personally i do not own or have any cellular deployment so it is
certainly not mine :-) But seriously, how does it work in cdma? what I said
probably applies to tdma systems I guess?

GT> What you are saying is that CAR discovery can be network controlled but
the actual handoff may be MN controlled? In which case this is a bit weird
in that the network knows exactly what the MN is going to do next but lets
the MN do it...hmm anyway, I do not have a problem with that although I do
not like it either.

George

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 27 Mar 2002 12:11:44 -0500

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Wednesday, March 27, 2002 5:02 PM
To: 'George Tsirtsis'; Hesham Soliman (ERA); [email-masked]
Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement

George

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 18:38:43 +0100

> probably applies to tdma systems I guess?

=> Well, the only difference is that the AR coverage
area includes several APs, so it's very unlikely
that you would end up with 6 GAARs in the same
technology. 

  > the actual handoff may be MN controlled? 

=> No quite. I meant that ARs can do the discovery
of GAARs that _they_know, then pass the info
to the MN who might know some more, then the MN
can decide. So the way I see it, the ARs 
are not controlling anything, they simply pass
information. 

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 18:38:43 +0100

Hesham

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 27 Mar 2002 17:47:52

Hi Hesham:

I do not know what consensus you are talking about. There was one question 
asked which was not clearly stated, and for that too, I saw only three hands 
go up.

The requirement was posted after MPLS and there has not been any consensus 
on it yet.

What we have agreed in MPLS was "MN's requirements MUST be considered in CAR 
discovery, handoffs etc.". We all are in good agreement on that.

I don't think however that this means that it precludes executing processor 
level algorithms anywhere else than MN's processor, as long as those 
algorithms consider all MN's requirement. This is implementation-specific 
aspect.

More comments below.

Hemant

>To: "'Hemant Chaskar'" <[email-masked]>,   "Hesham Soliman (ERA)"  
><[email-masked]>,   [email-masked], 
>[email-masked]
>Date: Wed, 27 Mar 2002 17:45:52 +0100
>
>Hi Hemant,
>

[HC] What matters here is the product of number of GAARs and size of their 
capabilities". Even if you do not have large number of GAARs, capabilities 
of each one of them can be huge and extensible.

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 27 Mar 2002 12:48:16 -0500

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Wednesday, March 27, 2002 5:39 PM
To: 'George Tsirtsis'; Hesham Soliman (ERA); [email-masked]
Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement

GT> I see, I guess because of soft handoff in cdma. But then, in
environments that can actually utilize an AR per BS/AP it is possible to
have multiple GAARs even if you restrict this to a single technology. So the
concern that some people have about GAAR+capabilities list is not totally
unfounded, wouldn't you say?.

GT> OK, thanks.
George

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 27 Mar 2002 12:48:16 -0500

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Wednesday, March 27, 2002 5:39 PM
To: 'George Tsirtsis'; Hesham Soliman (ERA); [email-masked]
Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement

GT> OK, thanks.
George

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 18:54:42 +0100

> unfounded, wouldn't you say?.

=> Right, but if we restrict it to a single
technology within one operator's network, 
then it should be fairly simple for the AR to send
only one or two GAAR info. 
I still think that in this scenario it would be 
difficult to get 6 different GAARs that the MN
can choose from, given that the MN is moving
a certain direction. 

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 18:52:34 +0100

> asked which was not clearly stated, and for that too, I saw 

=> We must have been in different meetings :)
I vividly remember James asking people whether
the model Steve presented made more sense than
the current assumptions, and almost all hands
went up. In fact Michael even said that he and
Dana Blair presented the same model a year ago and
there was no interest in the WG and he wondered
why the sudden change ?

So I don't know what you're referring to really.
Perhaps we should wait for the minutes.

Hesham

  > >   > >   > Subject: RE: [Seamoby] Concensus call on new 
  > CAR Discovery
  > >   > >   > Requirement
  > >   > >   > their capabilities to MN" is a good idea? If 
  > not (which I
  > >   > >   > hope so) then the
  > >   > >   > Subject: RE: [Seamoby] Concensus call on new 
  > CAR Discovery
  > >   > >   > Requirement
  > >   > >   > If we honestly think that the requirement does 
  > not oblige
  > >   > >   > AR to blast all
  > >   > >   > GAAR IDs and all of their capabilities to MN, 
  > why not say
  > >   > >   > so clearly. Why do
  > >   > >   >
  > >   > >   > satisfying this requirement may have serious 
  > shortcomings
  > >   > >   > that I described
  > >   > >   > >Subject: RE: [Seamoby] Concensus call on new 
  > CAR Discovery
  > >   > >   > Requirement
  > >   > >   > >information, it does not require *on-demand 
  > operation*, it
  > >   > >   > expresses
  > >   > >   > >exactly
  > >   > >   > >	I think that's the essence of it. Do 
  > you oppose this?
  > >   > >   > Why? Do you
  > >   > >   > > > this requirement looks like and violates 
  > basic tenets
  > >   > >   > of engineering
  > >   > >   > >design,
  > >   > >   > > > big chunk of data (= number of GAARs times 
  > capability
  > >   > >   > set of each). This
  > >   > >   > > > (relevant for single interface MN and 
  > two-interface MN
  > >   > >   > where second
  > >   > >   > > > interface is sleeping) or on second 
  > interface which I
  > >   > >   > call case (ii)
  > >   > >   > > > power wastage. This is because, after 
  > receiving these
  > >   > >   > capabilities MN
  > >   > >   > >either
  > >   > >   > > > 3. Bandwidth wastage: An AR needs to send 
  > this flood to
  > >   > >   > every MN that it
  > >   > >   > > > sees. Which means the same information 
  > (which could be
  > >   > >   > big enough) is
  > >   > >   > > > of capabilities to a very small size, 
  > otherwise all ARs
  > >   > >   > will only be
  > >   > >   > > > transmitting GAAR capabilities to different 
  > MNs all the
  > >   > >   > time. This means
  > >   > >   > > > you proposed and who have not, we should 
  > first analyse
  > >   > >   > above harmful
  > >   > >   > >effects
  > >   > >   > > > >Subject: [Seamoby] Concensus call on new 
  > CAR Discovery
  > >   > >   > Requirement
  > >   > >   > >(was:
  > >   > >   > > > > > So now you agree that the AR can hand 
  > over the list
  > >   > >   > of GAARs and
  > >   > >   > > > >the MN to discover  the GAAR and 
  > capabilities, the MN
  > >   > >   > decides which one
  > >   > >   > > > >it wants.
  > >   > >   > > > >just this way. Nothing about "as the MN 
  > expresses its
  > >   > >   > preferences" or
  > >   > >   > > > >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?
  > >   > >   > > > >
  > >   > >   > > > >             jak
  > >   > >   > > > >
  > >   > >   > > > >

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 18:52:34 +0100

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 18:54:42 +0100

Hesham

---

From: [email-masked]
Date: Wed, 27 Mar 2002 14:05:58 -0500

James, 

Right, this is what we have been arguing about with Dirk, Hemant, and
Govind. The MN should get the GAARs and decide. The requirement I posted
does not say that the AR sends those to the MN, it says that the
protocol should provide them to the MN. Exactly how is the task of the
protocol design. Dirk, Hemant, and Govind have been making the
assumption that they have to come from one specific AR, this might not
be the case, but, it depends on the design.

[DOT] Even if it comes from different ARs, the information might be unwanted.
The interpretation that I assumed that one AR will send this information,
kind of confuses me.

However, I am sympathetic to the efficiency argument and have no
objection to a network efficiency requirement. I posted one in a
response to Hemant's message.

[DOT] As I said in a previous email, what is the efficiency requirement
worth if another requirement demands for sending all this information??
It is maybe useful for choosing a representation format for the transferred
information that is as efficient as possible.

Regards,

Dirk