a) Simply remove that section from the draft. As far as I remember most people suggested this on the mailing list. It would have the implications such as leaving it completely up to the implementations.
b) Not to have HA as DR. As you mentioned in an earlier mail, going for a second solution is also feasible IMHO.
----- Original Message ----
From: Pascal Thubert (pthubert) <pthubert at cisco.com>
To: Julien Laganier <julien.IETF at laposte.net>; Vijay Devarapalli <vijay at wichorus.com>
Cc: mext at ietf.org
Sent: Wednesday, June
25, 2008 8:17:54 AM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?
Hi Julien:
I have seen some discussions and I do not think that there is consensus
on the specific matter of removing the DHAAD based discovery from this
draft. If I did, I would have retracted the text already. What I've seen
is people interested in deprecating DHAAD which is a different thing.
I think there is confusion between a vision of a better future and the
practical work of adding a simple extension to an existing protocol.
Right now the MIP protocol suite still uses dhaad. A NEMO MR will set
the R bit to filter out HAs that do not support NEMO on top of MIP. It
just makes sense for the same MR to set the next bit to filter out HAs
that do not support PD on top of NEMO. Simple update, no new message or
FSM state.
I did not find a convincing alternate either. Making an additional DNS
request adds complexity whereas the idea scanning and binding to all HAs
in the DHAAD list till the PD
request works makes very little sense to
me. Finally, making the bootstrap mechanism a prereq to PD is an
undesirable dependency and as a vendor I would not want such an artifact
to impact my product planning.
In a same spirit, I disagree with obsoleting DHAAD in NEMO if we keep it
in MIP. Yet I'm not saying that Vijay is wrong. He might be very right
to push DHAAD out through the window. My point is that we must be
consistent with ourselves. Should we deprecate DHAAD, I think we should
define a new discovery that does it all and obsolete the whole suite of
protocols so that the new flow is not heavier than the current flow.
If you can dedicate a slot in Dublin for PD discussion then we can
expose both viewpoints and see what the group favors. That should be
enough to break the knot.
Pascal
>-----Original Message-----
>From: julien laganier [mailto:
julien.laganier at gmail.com] On Behalf Of
Julien Laganier
>Sent: mardi 24 juin 2008 12:19
>To: Vijay Devarapalli
>Cc: Pascal Thubert (pthubert); marcelo bagnulo braun;
mext at ietf.org>Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?
>
>Vijay and Pascal,
>
><Chair Hat ON>
>
>Vijay Devarapalli wrote:
>> Hi Pascal,
>>
>>> -----Original Message-----
>>> From: Pascal Thubert (pthubert) [mailto:
pthubert at cisco.com]
>>> Sent: Monday, June 23, 2008 5:52 AM
>>> To: Vijay Devarapalli; Behcet Sarikaya; Julien Laganier
>>> Cc:
mext at ietf.org>>> Subject: RE: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?
>>>
>>> Hi Vijay,
>>>
>>> I've not seen a consensus call on this and I'm sorry if I
>>> missed it. If there was none than let us have one with all
>>> the arguments from all parties on the table.
>>
>> There was no consensus call on this. But there were quite a few
>> emails sent on this topic. My conclusion from that discussion
>> was that most people agreed with removing extensions to DHAAD
>> from the prefix delegation document. I don't believe it is
>> Necessary, but we could have an explicit consensus call on this.
>> Julien, Marcelo?
>
>We do not necessary need a consensus call for every decision -- the
>consensus can appear by itself as the result of the
discussion,
>consensus call is only needed in case no clear consensus appears after
>the discussion has ran for some time.
>
>So the question is, do you think all the arguments have been expressed
>already and we're now rehashing the same ones? In case the answer is
>yes, I'm happy to proceed with issuing a consensus call on the DHAAD
for
>NEMO-PD issue.
>
>--julien
_______________________________________________
MEXT mailing list
MEXT at ietf.orghttps://www.ietf.org/mailman/listinfo/mext
