Subject: [MEXT] consensus call on dhaad

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 07 Nov 2008 09:47:28 +0100

Hi,

There has been a very long debate on whether we should keep or remove 
dhaad from rfc3775bis.
We would like to ask people to express whether they want to keep dhaad 
or remove it from rfc3775bis at this point.
Please send your opinion before the 14 of november.

(we are going to consider for this poll only the opinions sent as reply 
to this email, so even if you think your opinion is well known, reply to 
this email stating it again, so it can be considered as part of this poll)

Regards, marcelo

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Nov 2008 11:40:15 +0100

marcelo bagnulo braun wrote:
>  dhaad from rfc3775bis. We would like to ask people to express
> whether they want to keep dhaad or remove it from rfc3775bis at this
> point. Please send your opinion before the 14 of november.

DHAAD has been implemented and tested for interoperability, and is used
by NEMOv6 rfc3963 as well - keep it in rfc3775bis.

Alex

> 
> (we are going to consider for this poll only the opinions sent as
> reply to this email, so even if you think your opinion is well known,
> reply to this email stating it again, so it can be considered as part
> of this poll)
> 
> Regards, marcelo
> 
> _______________________________________________ MEXT mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/mext
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 07 Nov 2008 14:58:10 -0600

Hi Marcelo,

With the boostrapping specifications for MIP6 (RFC5026,
draft-ietf-mip6-bootstrapping-integrated-dhc-06.txt and,
draft-ietf-mip6-hiopt) and the capability to obtain HNP and HoA via IKEv2
(RFC4877), I think there are enough mechanisms to discover an HA, HoA and
Home prefix. So there is no need for DHAAD.

MIP6 is overloaded with unnecessary features such as DHAAD and hence getting
rid of it from 3775bis would be a simplification of the base protocol.

Hence I would be in favor of dropping DHAAD from 3775bis.

-Basavaraj

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 7 Nov 2008 13:00:16 -0800

I support Raj's point of view.

Gerardo

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Basavaraj Patil
> Sent: Friday, November 07, 2008 12:58 PM
> To: Marcelo Bagnulo; mext
> Cc: Julien Laganier
> Subject: Re: [MEXT] consensus call on dhaad
> 
> 
> Hi Marcelo,
>

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 07 Nov 2008 16:22:26 -0500

Hi Marcelo,
   While I have no strong position on the issue, if I was forced to 
pick, I would pick removing DHAAD and not burden all our future specs 
and implementations with this seldom used feature.

Thanks
Suresh

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 7 Nov 2008 14:35:05 -0800 (PST)

I also agree.

Regards,

Behcet

________________________________
From: Suresh Krishnan <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Cc: Julien Laganier <[email-masked]>; mext <[email-masked]>
Sent: Friday, November 7, 2008 3:22:26 PM
Subject: Re: [MEXT] consensus call on dhaad

Hi Marcelo,
  While I have no strong position on the issue, if I was forced to pick, I would pick removing DHAAD and not burden all our future specs and implementations with this seldom used feature.

Thanks
Suresh

marcelo bagnulo braun wrote:
> Hi,
> 
> There has been a very long debate on whether we should keep or remove dhaad from rfc3775bis.
> We would like to ask people to express whether they want to keep dhaad or remove it from rfc3775bis at this point.
> (we are going to consider for this poll only the opinions sent as reply to this email, so even if you think your opinion is well known, reply to this email stating it again, so it can be considered as part of this poll)
> 
> Regards, marcelo
>

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 7 Nov 2008 15:03:21 -0800 (PST)

Hi Marcelo,

Not sure, why we are running a consensus call on this issue. We already
discussed this in March IETF and clearly the general input from the
group was to retain DHAAD support in Mobile IPv6 specification. That
is a feature that exists in MIP6 implementations today, in released
products. Its used in NEMO spec and all Mobile Routers support this.
So, we (Cisco) have two released products that support this feature.

We cannot take out features in this random fashion and after a quick
2 week consensus call. This is a big decision as there is impact on
released products. Also, the input from our Area Director in
meeting during March IETF was to retain this in the spec.

Bottom line, I strongly disagree taking DHAAD out.

Regards
Sri

On Fri, 7 Nov 2008, Alexandru Petrescu wrote:

> _______________________________________________ _______________________

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 07 Nov 2008 15:27:50 -0800

Hello folks,

For the purposes of this discussion, I will remain neutral
on the technical merits of DHAAD.  However, I think it
would be pretty unwelcome for the IETF to standardize
protocol features, and then to remove them without
strong cause.

If I summarize the reasons to remove so far, we have:
a) alternative mechanisms exist
b) "no strong position on the issue, but simpler without"

as opposed to the reasons to retain:
- "used in NEMOv6 rfc3963"
- "released products that support this feature"
- previous consensus to retain

I don't think that all votes should be counted
equally in this debate.  But there is one other
alternative to be mentioned.  DHAAD "could"
be separated out into another document.  I don't
know why two documents would be better than
one, but anyway it might satisfy more people.
Vendors could claim compliance to _more_
standards.  Simplifications could be had.  I could
have _more_ work to do.  _More_ alternatives
could be available (oops, those last two are negatives).

Just a thought.

Regards,
Charlie P.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 7 Nov 2008 17:37:58 -0600

I agree with Charlie.

Although, I understand the pain that many people have with maintaining
DHAAD, but on the other hand, I do not think it is wise to remove it and
ignore those who trusted this standard body documents and already
implemented this feature in their product.

Regards,
Ahmad

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Charles E. Perkins
> Sent: Friday, November 07, 2008 5:28 PM
> To: mext
> For the purposes of this discussion, I will remain neutral on 
> the technical merits of DHAAD.  However, I think it would be 
> pretty unwelcome for the IETF to standardize protocol 
> features, and then to remove them without strong cause.
> 
> I don't think that all votes should be counted equally in 
> this debate.  But there is one other alternative to be 
> mentioned.  DHAAD "could"
> be separated out into another document.  I don't know why two 
> documents would be better than one, but anyway it might 
> satisfy more people.
> Vendors could claim compliance to _more_ standards.  
> Simplifications could be had.  I could have _more_ work to 
> do.  _More_ alternatives could be available (oops, those last 
> two are negatives).
> 
> Just a thought.
> 
> Regards,
> Charlie P.
> 
> 
> 
> 
> Sri Gundavelli wrote:
> > Hi Marcelo,
> >
> > Not sure, why we are running a consensus call on this issue. We 
> > already discussed this in March IETF and clearly the general input 
> > from the group was to retain DHAAD support in Mobile IPv6 
> > specification. That is a feature that exists in MIP6 
> implementations 
> > today, in released products. Its used in NEMO spec and all 
> Mobile Routers support this.
> > released products. Also, the input from our Area Director 
> in meeting 
> > during March IETF was to retain this in the spec.
> >
> >>>  There has been a very long debate on whether we should keep or 
> >>> remove  dhaad from rfc3775bis. We would like to ask people to 
> >>> express  whether they want to keep dhaad or remove it from 
> >>> rfc3775bis at this  point. Please send your opinion 
> before the 14 of november.
> >>
> >> DHAAD has been implemented and tested for interoperability, and is 
> >> used by NEMOv6 rfc3963 as well - keep it in rfc3775bis.
> >>
> >> Alex
> >>
> >>>
> >>> reply to this email, so even if you think your opinion is well 
> >>> known,  reply to this email stating it again, so it can be 
> >>> considered as part  of this poll)
> >>>
> >>>  Regards, marcelo
> >>>
> _____________________________________________________________________
> >> _ This email has been scanned by the MessageLabs Email Security 
> >> System.
> >> _______________________

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 08 Nov 2008 11:43:44 +1100

Hi Marcelo, Julien

I'm fairly neutral on this issue but he are some thoughts.

I don't think it's terribly useful now that we defined ways for dynamic home
address config. DHAAD almost always assumes manual config. Or, said
differently, it assumes that the MN knows its home address but doesn't know
its HA. I'm not sure that's realistic outside manual config cases. Manual
config obviously has its problems and its benefits are not clear to me. One
can always allocate a static HoA dynamically, so no need for manual config
at all. 

I don't think it's harmful really, I just think it's not all that useful.

It sounded good at the time but I won't be losing sleep if we remove it from
the spec. I don't actively call for it to be removed because I'm just a bit
conservative when it comes to removing stuff that isn't broken, but I don't
think it's all that useful now.

Hesham

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 08 Nov 2008 12:35:10 +0900

Hi Marcelo and Julien,

I am very neutral on this.

However, I have one question.
If we remove DHAAD completely from the spec, shall we also remove the 
- managing HA List (used for DHAAD)
- exchanging RA with HA information list for the HA list

These two functionalities are coupled with DHAAD.

regards,
ryuji

At Fri, 07 Nov 2008 09:47:28 +0100,

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 7 Nov 2008 19:47:49 -0800 (PST)

Right. There is no purpose of HA list any more.
It will have impact on the following:

RFC-3963
RFC-4295 (MIB objects)
Home Agent List maintanance by HA
Home Agent Informaiton option
DHAAD Discovery related text
...

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 7 Nov 2008 20:20:54 -0800 (PST)

On Sat, 8 Nov 2008, Hesham Soliman wrote:

> address config.

Its bit debatable if DNS based discovery mechanism is better than the
current DHAAD appraoch. There are pros and cons in both the approaches
and one can argue either way.

There are certain useful aspects such as the ability for the Home Agent to 
adjust its preference on the fly and based on the binding count, gives
some simple load balancing capability. Runtime discovery vs depending on
a static DNS configuration with potentially stale data. There are no
predictable service labels in DNS SRV records that can be used by clients
to locate nearest Home Agents. All of these cannot be ignored.

Bottom line, the feature is modelled into the design and has dependency
on other specs and other features, so it has to survive.

Regards
Sri

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 08 Nov 2008 08:52:03 +0100

Hi Sri,

I will only be addressing the procedural issues you bring in this email 
and will not comment on the dhaad issue per se.

Sri Gundavelli escribió:
> Hi Marcelo,
>
> Not sure, why we are running a consensus call on this issue.
cause we need to define what to do with it

> We already
> discussed this in March IETF 
right and we have disucssed before that as well

> and clearly the general input from the
> group was to retain DHAAD support in Mobile IPv6 specification. 

this is not my reading of the consensus
In my opinion there was no consensus and we are trying to reach one

> That
> products. Its used in NEMO spec and all Mobile Routers support this
>
So, having this feature out of the rfc3775 bis does not means your 
products are no longer compliant to with the rfc, right? I mean doing 
more than what is n the rfc doesn't imply that you don't comply with it.

> We cannot take out features in this random fashion

please provide a DETAILED explanation to me about what is random about this

We have been disucssing this issue for a long time now
People have expressed their arguments in the ml and in the meetings
It is my opinion that now everyobody understand the arguments of the 
others and have their own opinion
So, it seems the right moment to have a consensus poll and try to make a 
decision
We need to wrap up with rfc3775 bis
there are some issues where the consensus has been reached, but this is 
not one of them
Since we would like to  close these issue by next ietf, we need to do 
this now
> and after a quick
> 2 week consensus call.
2 weeks seems a reasonable time to do a consensus call, how long do you 
think we need for a consensus poll?

> This is a big decision as there is impact on
> released products.
Right, that is why we are taking all the stpes needed to take a good 
decision, Long disucssion period, disucssion in the meetings and then a 
formal consensus poll with a cosndierable time so that everybody 
expresses their final opinion
Do you think there something in the process that can be improved

> Also, the input from our Area Director in
FWIW this process and in particular this consensus poll was agreed with 
the AD. If you have any comments in this respect please feel free to con 
contact him

> Bottom line, I strongly disagree taking DHAAD out.
goo, that is what i was asking, thanks for the input

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 08 Nov 2008 09:27:16 +0100

Hi Charlie,

some comments about this

> protocol features, and then to remove them without
I agree with this indeed
So, as i mentioned in the previous email, we need a strong consensus to 
remove this

> - previous consensus to retain
not commenting on the technical issues, but just the last one
Actually, so far, i think the consensus can have been read in different 
ways, throughout the discussion.
I mean, to me sometimes it felt people wanted to remove this and some 
other times it felt they didn't
That is why, i think that having this final poll would help us to close 
this issue.
So, i don't take into account the last argument, since i think it can be 
interpreted either way depeding in the point in time you read the consensus.

> could be available (oops, those last two are negatives).
this last option could be a possible way forward.
good input
Now, i think we should finish this consensus poll and see where we are 
standing (don't think chaning the consensus poll at this point is a good 
idea) and if there is no clear outcome, we can try this option
Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 08 Nov 2008 09:28:52 +0100

Hi Ahmad,

So, are you saying we should keep it?
Regards, marcelo

Ahmad Muhanna escribió:
>>>>>  (we are going to consider for this poll only the 
>>>>>           
>> opinions sent as  
>>     
>>>>>  _______________________________________________ MEXT 
>>>>>           
>> mailing list  
>>

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 08 Nov 2008 21:16:39 +1100

> and one can argue either way.

=> I wasn't comparing DNS-based approaches to DHAAD. That's comparing apples
and oranges because DHAAD assumes that the MN already knows its HoA.

Hesham

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Sun, 9 Nov 2008 12:30:32 -0500

Hi Ryuji,

The mobile node being able to construct the home agent list by listening
to the router advertisements on the home link can exist independently of
DHAAD. I don't see why they should get coupled with DHAAD. Even if DHAAD
gets removed, it might be useful to keep the HA list feature. It could
be used for HA reliability. Each home agent would know about the other
home agents on the home link without manual configuration.

Vijay

> Behalf Of Ryuji Wakikawa
> Sent: Friday, November 07, 2008 7:35 PM
> To: marcelo bagnulo braun
> Cc: Julien Laganier; mext

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 9 Nov 2008 09:43:55 -0800 (PST)

Hi Vijay,

How would you use the HA list within the scope of RFC-3775 or
RFC-3963 ?

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 9 Nov 2008 11:03:26 -0800 (PST)

Hi Marcelo,

Please see inline.

On Sat, 8 Nov 2008, marcelo bagnulo braun wrote:

> Hi Sri,
>
> I will only be addressing the procedural issues you bring in this email and 
> will not comment on the dhaad issue per se.
>
> Sri Gundavelli escribió:
>>  Hi Marcelo,
>>
> So, having this feature out of the rfc3775 bis does not means your products 
> are no longer compliant to with the rfc, right? I mean doing more than what 
> is n the rfc doesn't imply that you don't comply with it.
>

There is a cost of building a product to a standard, getting compliance
to that standard and for having that architecture modeled into a product.
We can absolutely remove any features and still be compliant, this
applies to all IETF specs. But, the impact is much more. Vendor-1 is
first in the market, implemens feature-A, Vendor-2 who has no product in
the market and no skin in the game till then, would love to take feature-A
out from the specs. So, we have to look at this type of changes in a
bit different perspective.

> please provide a DETAILED explanation to me about what is random about this

As I see it, features are to deleted from specs when a given approach or
a feature has major problems and after analysing the impact on the
all the specs and after determining the overall plan. In this specific
case, its not clear there is a better alternative to DHAAD that can be
used. That analysis has not been done and there is no spec that identifies
the impact on other specs. If we say DNS-based discovery scheme is
better, its debatable, as Hesham says, DHAAD-based discovery and DNS-based
discovery when compared are like comparing apples to oranges. In that
sense, I said, this is bit like in random.

> It is my opinion that now everyobody understand the arguments of the others 
> and have their own opinion
> there are some issues where the consensus has been reached, but this is not 
> one of them
> Since we would like to  close these issue by next ietf, we need to do this 
> now
>>  and after a quick
>>  2 week consensus call.
> 2 weeks seems a reasonable time to do a consensus call, how long do you think 
> we need for a consensus poll?
>

My problem with the two week notice. Generally from my experience, any
WG discussions are followed closely by 5 to 10 people. It does not
mean others have no interest. There are many MIP implementations from
open source to commercial, even in chipsets there are client
implementations, there has to be much more participation and input before
fundamental architectural changes are executed. But, I see that you
already said, the bar is high and good to know that.

> formal consensus poll with a cosndierable time so that everybody expresses 
> their final opinion

Thanks for asking this. I think, there has to be a plan. First its not
clear DHAAD based scheme is really bad as perceived by some. That
debate has to happen. Second, its not clear there is a better solution
within the parameters of the problem scope and one that is a comparable
approach. Third, if decided, we need plan to revise other specs, as this
change cannot be done in isolation.

> FWIW this process and in particular this consensus poll was agreed with the 
> AD. If you have any comments in this respect please feel free to con contact 
> him
>

No, thats fine. AD is listening.

Thanks
Sri

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 09 Nov 2008 20:41:13 +0100

Sri Gundavelli escribió:
>> I will only be addressing the procedural issues you bring in this 
>> email and will not comment on the dhaad issue per se.
>>
>> Sri Gundavelli escribió:
>>>  Hi Marcelo,
>>>
Right, i agree that removing features from an rfc is to be considered 
seriously, hence, we have a higher bar to do this.

> a feature has major problems
Well, that is indeed a good reason to do that,
But there may be other reasons, like for instance that the considered 
feature has been superseeded by alternative mechanisms, or becuse the 
particular feature is no longer relevant or for other multiple reasons. 
Moreover, in order tp progress from proposed standard to draft std, it 
is feasible to remove those features that no one has implemented. So, 
the siutation is definitly as simple as you seem to describe

Moreover, in general, i would say that as any technical decision in the 
ietf, a certain feature is removed, if the wg considers that need to be 
removed. (the process is the usual, we discuss and we reach some form of 
concensus).
> and after analysing the impact on the
> all the specs
well, that is a process
First we decide to remove the feature and then we update the rest of the 
specs so they reflect that. There is certianly no need to update all 
specs at once. See for instance the deprectation of the site local 
addresses. There are plenty of specs that still have the site local in 
tere. there is no problem. when the other specs are updated, they 
reflect this change. no big deal here.

> and after determining the overall plan. 
overall plan??

what do you mean?

Here we have a disucssion about this particular feature whether it is 
useful or not and whether we keep it or not.
Not sure what is the overall plan that you are referring to

> In this specific
that is part of the technical disucssion that the wg needs to agree on
If the WG thinks that this feature has been superseeded by alternative 
ones, then so be it. As i said this is up to the wg to decide

So, i come back to randomness that you mentioned before, there is 
absolutelly nothing random in this consesus call. It is not like i woke 
up today and randomly selected one feature of rfc3775 that i would make 
a consensu call on whehter it should stay or not.

The WG has been disucssing this issue for a LONG time now.
there has been plenty of time to disucss the reasons to keep it and to 
remove it. We have tried to reach a concensus through discussion in the 
ml and in the meetings. At some point we need to wrap up and move on. 
this is now.
So i hope you do agree that there is nothing random about making this 
consensus call
>> So, it seems the right moment to have a consensus poll and try to 
>> make a decision
>> there are some issues where the consensus has been reached, but this 
>> is not one of them
>> 2 weeks seems a reasonable time to do a consensus call, how long do 
>> you think we need for a consensus poll?
>>
>
> My problem with the two week notice.

what timeframe do you think it is reasonable????
I mean, two weeks for a consensu call seems the usual tiemframe. If 
people are not participating in te disucssion, then this is plenty of 
time to get up to date and express their opinion... what would you 
suggest, 2 months to make a consensus call?

> Generally from my experience, any
> WG discussions are followed closely by 5 to 10 people.
right, but i have sent an email with the subject "consensus call on 
dhaad" which should be clearly and easily to idenify to anyone who cares 
about the subject.

what would you suggest me to do in order to attract all the interested 
people that should be replying to the call?

Really, i am not really understanding your points about the process here

> It does not
>> decision, Long disucssion period, disucssion in the meetings and then 
>> a formal consensus poll with a cosndierable time so that everybody 
I think i have addressed all the issues above, but just in case:

- in terms of the technical merit or need for dhaad, it is up to the wg 
to decide (my task is to read the consensus)

- in terms of the procedure, we have been disucssing this issue for a 
long time now (probably over 9 months since the first proposal to remove 
dhaad was proposed)) I think that people have had enough time to ask the 
relevant questions and provide answers. At some point we need to move 
on. We cannot spent forever recurrently disucssing whether we keep dhaad 
or not.

- in terms of the other specs, once we make a decision on dhaad, if we 
decide to remvoe it, we can deal with the rest of the specs when they 
are updated. this is the usal procedure, i don't see any problem with that

Regards, marcelo

>> FWIW this process and in particular this consensus poll was agreed 
>> with the AD. If you have any comments in this respect please feel 
>> free to con contact him
>>
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sun, 9 Nov 2008 18:47:08 -0600

Hi Marcelo,
Sorry for not replying back on time; been on a very long flight:(

As I said I had two concerns:
1. keeping DHAAD in RFC3775bis has a painful consequence, IMO.
2. I believe that people who implemented this feature did so based on the trust they had in MEXT or MIP6 wg and IETF in general. To me it is quite very important NOT to break this trust and those who implemented this feature deserve careful consideration before making such a decision.

So apparently, I chose the safest approach by leaning towards keeping DHAAD rather than taking it out. In other words, enduring the painful consequences rather than loosing the confidence of those who trusted the wg standard.

However, I have been thinking of the topic inline with other IETF experiences as follows:

1. A very relevant example is IKE. IKEv2 deprecate IKEv1 and actually IKEv2 is NOT backward compatible with IKEv1. However, some SDOs still like IKEv2 and actually allow both in their network.
2. Your explanation that a device which support DHAAD will still be compliant with RFC3775bis (assuming removal of DHAAD from RFC3775bis). As you said having more features than what in RFC3775bis is not a violation.

After carefully taking the above two examples in consideration, I am more comfortable to support the option of REMOVING DHAAD from RFC3775bis than keeping it.

Sorry for the long answer but I felt it is quite important to explain the background.

Regards,
Ahmad

> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Saturday, November 08, 2008 5:29 PM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Charles E. Perkins; mext
> > DHAAD, but on the other hand, I do not think it is wise to 
> remove it 
> > and ignore those who trusted this standard body documents 
> and already 
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> >> Of Charles E. Perkins
> >> For the purposes of this discussion, I will remain neutral on the 
> >> technical merits of DHAAD.  However, I think it would be pretty 
> >> unwelcome for the IETF to standardize protocol features, 
> and then to 
> >> remove them without strong cause.
> >>
> >> I don't think that all votes should be counted equally in this 
> >> debate.  But there is one other alternative to be 
> mentioned.  DHAAD 
> >> "could"
> satisfy more 
> >> people.
> >> Simplifications could be had.  I could have _more_ work to do.  
> >> _More_ alternatives could be available (oops, those last two are 
> >> negatives).
> >>
> >> Just a thought.
> >>
> >> Regards,
> >> Charlie P.
> >>
> >>
> >>
> >>
> >> Sri Gundavelli wrote:
> >>     
> >>> Hi Marcelo,
> >>>

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 9 Nov 2008 18:18:43 -0800 (PST)

Hi Marcelo,

> seriously, hence, we have a higher bar to do this.

Ok.

> If the WG thinks that this feature has been superseeded by alternative ones, 
> then so be it. As i said this is up to the wg to decide
>
> So, i come back to randomness that you mentioned before, there is absolutelly 
> nothing random in this consesus call. It is not like i woke up today and 
> randomly selected one feature of rfc3775 that i would make a consensu call on 
> whehter it should stay or not.
>
> there has been plenty of time to disucss the reasons to keep it and to remove 
> it. We have tried to reach a concensus through discussion in the ml and in 
> the meetings. At some point we need to wrap up and move on. this is now.

Ok. Fair enough. I take that word back.

Regards
Sri

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 10 Nov 2008 17:45:36 +0900

Hi Vijay,

RFC3775 said so. Fo example in section "10.5.1.  Receiving Router  
Advertisement Messages"

    "For each link on which a router provides service as a home agent,  
the
    router maintains a Home Agents List recording information about all
    other home agents on that link.  This list is used in the dynamic
    home agent address discovery mechanism, described in Section 10.5."

HA reliability is not provided by RFC3775.

regards,
ryuji

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Mon, 10 Nov 2008 16:10:34 +0100

Hi,

For security reasons (cf. DHAAD Harmful draft), I am in favor to
remove DHAAD mechanism from rfc3775bis.

Best regards.

JMC.

2008/11/7 marcelo bagnulo braun <[email-masked]>:
> (we are going to consider for this poll only the opinions sent as reply to
> this email, so even if you think your opinion is well known, reply to this
> email stating it again, so it can be considered as part of this poll)
>
> Regards, marcelo
>

---

From: Brian Haley <[email-masked]>
Date: Mon, 10 Nov 2008 10:51:44 -0500

> by NEMOv6 rfc3963 as well - keep it in rfc3775bis.

+1 for keeping DHAAD.

-Brian

---

From: "Hui Deng" <[email-masked]>
Date: Tue, 11 Nov 2008 00:18:28 +0800

some vendor use it and feel useful, so let's keep it.

-Hui

2008/11/7 marcelo bagnulo braun <[email-masked]>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 10 Nov 2008 14:03:22 -0800

Hi Ryuji, Sri,

Ryuji Wakikawa wrote:
>    "For each link on which a router provides service as a home agent, the

> How would you use the HA list within the scope of RFC-3775 or

Please let me re-phrase what I wrote in my earlier email. The ability to 
construct of a list of home agents serving a home link dynamically is a 
useful feature to have. IMO, it does not have to tied to DHAAD. I 
suggest keeping it in 3775bis even if we decide to remove DHAAD.

I would also be fine with removing the home agents list function from 
3775bis and adding it to the HA reliability document.

Vijay

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 11 Nov 2008 07:17:26 -0800 (PST)

Hi Marcelo, can you please clarify that DHAAD is a feature unique in MIPv6 and there is no corresponding feature in MIPv4? For example DHAAD uses anycast addresses which do not exist in IPv4.

Regards,

Behcet

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 12 Nov 2008 12:30:23 +0100

From MIPv6's perspective I'm neutral on removing DHAAD.

 From NEMO's perspective, DHAAD should be kept.

This makes me come to Charlie's wondering about separating specs. 
Instead of separating DHAAD (this is a good suggestion, indeed), I've 
always wonder if we shouldn't have a spec for HA, on for NEMO-MR, and 
one for MIP6-MH (and may be yet another one for packet format). This 
would a significant work, but in the end it may prove useful to 
implementers and archictural work but other bodies using IETF specs.

Thierry

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 18 Nov 2008 12:38:45 +0100

Hi Charlie:

I find your arguments perfectly reasonable. 

There's another dimension that I'd wish more emphasized here: the
interest of the users. 

At the last Mext meeting, Frederic Detienne gave us a very interesting
analogy (paraphrasing, Fred, please correct me if I'm wrong):

What we found deploying DMVPN (that has both a DNS-type and a DHAAD-type
functionality) is that the users pretty much split in half, each side
favoring one approach and not ready to migrate to the other.

MIP6 and NEMO have similar properties with DMVPN. The analogy would
indicate us that once mobility technologies reach acceptance and larger
deployments, users will also equally like both approaches. Removing
DHAAD is just taking a deployment option away from them.

Pascal

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
Charles E. Perkins
>Sent: samedi 8 novembre 2008 00:28
>To: mext
already
>>>>  There has been a very long debate on whether we should keep or
remove
>>> DHAAD has been implemented and tested for interoperability, and is
used
>>>>  reply to this email, so even if you think your opinion is well
known,
_______________________

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 18 Nov 2008 09:25:41 -0600

Hi Thierry,

> From NEMO's perspective, DHAAD should be kept.

Can you explain why?

When MR boots up, it follows one of the bootstrapping mechanism and  
starts DHCP-PD after the binding registration.
DHAAD is not used in the sequence of the MR's bootstrap.

regards,
ryuji

> Instead of separating DHAAD (this is a good suggestion, indeed),  
> I've always wonder if we shouldn't have a spec for HA, on for NEMO- 
> MR, and one for MIP6-MH (and may be yet another one for packet  
> format). This would a significant work, but in the end it may prove  
> useful to implementers and archictural work but other bodies using  
> IETF specs.
>
> Thierry
>
>
>
>>>> For more information please visit http://www.messagelabs.com/ 
>>>> email _______________________________________________  
>>>> _______________________
> <thierry_ernst.vcf>_______________________________________________
> MEXT mailing list
> [email-masked]

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 18 Nov 2008 11:09:20 -0600

Hi Pascal,

> There's another dimension that I'd wish more emphasized here: the

And can you elaborate why there is specific interest in using DHAAD vs any
of the other bootstrapping mechanisms?

> DHAAD is just taking a deployment option away from them.

I think this is highly speculative. DHAAD as currently specified has little
use in any real deployment given some of the issues that have been
discussed. The only claim that I have heard so far is from Sri saying that
there is an existing implementation of this feature today. However the
question still would be if it is actually used. Having it in an
implemenation is one thing vs whether it serves any useful purpose.

-Raj