Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 18 Jun 2008 08:33:37 -0700 (PDT)

Yes. The reason is simple, look at this draft:
http://tools.ietf.org/id/draft-dupont-mext-dhaadharmful-00.txt

Regards,

Behcet

----- Original Message ----
From: Julien Laganier <[email-masked]>
To: [email-masked]; Behcet Sarikaya <[email-masked]>
Sent: Wednesday, June 18, 2008 10:29:27 AM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

On Wednesday 18 June 2008, Behcet Sarikaya wrote:
> Well, I was just wondering if its coauthors agree with this text ?

Well, then I'm still wondering what you're wondering about... Are you 
asking whether or not coauthors of the draft agree with the draft?! 

--julien

> ----- Original Message ----
> From: Julien Laganier <[email-masked]>
> To: Behcet Sarikaya <[email-masked]>
> Cc: [email-masked]
> Sent: Wednesday, June 18, 2008 4:00:49 AM
> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?
>
> Behcet,
>
> I'm wondering what you're wondering about -- the message I sent
> (excerpt below) is quite explicit, isn't it?
>
> > We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as
> > a WG draft corresponding to the Nemo Prefix Delegation work item.
> >
> > Authors, please resubmit the draft as WG draft under the name:
> >
> >     draft-ietf-mext-nemo-pd-00.txt
>
> --julien
>
> On Tuesday 17 June 2008, Behcet Sarikaya wrote:
> > Hi Julien,
> >   It seems like draft-ietf-mext-nemo-pd-00.txt does not carry any
> > changes based on the long and heated debates we had on
> > draft-droms-mext-nemo-pd-00.txt. It is a keep-alive version. Is
> > this what you expected from the authors?
> >
> > Regards,
> >
> > Behcet
> >
> >
> > ----- Original Message ----
> > From: Julien Laganier <[email-masked]>
> > To: [email-masked]
> > Cc: [email-masked]
> > Sent: Friday, June 13, 2008 10:42:14 AM
> > Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?
> >
> > Folks,
> >
> > We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as
> > a WG draft corresponding to the Nemo Prefix Delegation work item.
> >
> > Authors, please resubmit the draft as WG draft under the name:
> >
> >     draft-ietf-mext-nemo-pd-00.txt
> >
> > Note: you can use the online I-D submission tool to make it faster:
> > <https://datatracker.ietf.org/idst/upload.cgi>
> >
> > Thanks.
> >
> > --julien & marcelo, MEXT chairs.
> >
> > On Friday 30 May 2008, marcelo bagnulo braun wrote:
> > > Hi,
> > >
> > > We would like to ask the WG what is their opinion about accepting
> > > draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo
> > > PD deliverable included in our charter.
> > >
> > > Please provide comments so we cna make some progress on this long
> > > overdue deliverable
> > >
> > > thanks, Julien and marcelo
> > >
> > > -------- Mensaje original --------
> > > Asunto:     I-D Action:draft-droms-mext-nemo-pd-00.txt
> > > Fecha:     Fri, 30 May 2008 05:45:01 -0700 (PDT)
> > > De:    [email-masked]
> > > Responder a:    [email-masked]
> > > Para:    [email-masked]
> > >
> > >
> > >
> > > A New Internet-Draft is available from the on-line
> > > Internet-Drafts directories.
> > >
> > >     Title           : DHCPv6 Prefix Delegation for NEMO
> > >     Author(s)       : R. Droms, et al.
> > >     Filename        : draft-droms-mext-nemo-pd-00.txt
> > >     Pages           : 12
> > >     Date            : 2008-05-30
> > >
> > > One aspect of network mobility support is the assignment of a
> > > prefix or prefixes to a Mobile Router (MR) for use on the links
> > > in the Mobile Network.  DHCPv6 prefix delegation can be used for
> > > this configuration task.
> > >
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.t
> > >xt
> > >
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > >
> > > Below is the data which will enable a MIME compliant mail reader
> > > implementation to automatically retrieve the ASCII version of the
> > > Internet-Draft.
> >
> > _______________________________________________
> > MEXT mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mext

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

---

From: Julien Laganier <[email-masked]>
Date: Wed, 18 Jun 2008 18:20:28 +0200

Behcet, 

if that is your question, guess you should ask the authors, not me.

--julien

On Wednesday 18 June 2008, Behcet Sarikaya wrote:
> > > We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt
> > > as a WG draft corresponding to the Nemo Prefix Delegation work
> > > item.
> > >
> > > We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt
> > > as a WG draft corresponding to the Nemo Prefix Delegation work
> > > item.
> > >
> > > Note: you can use the online I-D submission tool to make it
> > > faster: <https://datatracker.ietf.org/idst/upload.cgi>
> > >
> > > Thanks.
> > >
> > > > We would like to ask the WG what is their opinion about
> > > > accepting draft-droms-mext-nemo-pd-00.txt as the WG document
> > > > for the Nemo PD deliverable included in our charter.
> > > >
> > > > Please provide comments so we cna make some progress on this
> > > > long overdue deliverable
> > > >
> > > > in the Mobile Network.  DHCPv6 prefix delegation can be used
> > > > for this configuration task.
> > > >
> > > > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00
> > > >.t xt
> > > >
> > > > Below is the data which will enable a MIME compliant mail
> > > > reader implementation to automatically retrieve the ASCII
> > > > version of the Internet-Draft.
> > >

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 20 Jun 2008 09:28:25 +0200

Hi Behcet

The PD draft is consistent with its parent RFCs 3775 and 3963. If the
group agrees in some future that DHAAD should be deprecated, then we'll
need to revise all 3 documents. What's important IMHO is to keep them
consistent.

Pascal

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Behcet Sarikaya
Sent: mercredi 18 juin 2008 17:34
To: Julien Laganier
Cc: [email-masked]
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

Regards,

Behcet

----- Original Message ----
From: Julien Laganier <[email-masked]>
To: [email-masked]; Behcet Sarikaya <[email-masked]>
Sent: Wednesday, June 18, 2008 10:29:27 AM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

--julien

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 20 Jun 2008 11:25:49 -0700

Hi Pascal,

I believe there was reasonable consensus on removing the DHAAD extensions in
the NEMO prefix delegation document, when were discussing adoption of the
draft as a WG document.

Many had argued said there is no need to extend DHAAD in the first place for
prefix delegation. Perhaps you missed those emails buried in the emails on
DHAAD deprecation. So your argument below that since it is there in 3776 and
3963, it should be in the prefix delegation document, does not make sense to
me.

Vijay

On 6/20/08 12:28 AM, "Pascal Thubert (pthubert)" <[email-masked]> wrote:

> Hi Behcet
>  
> The PD draft is consistent with its parent RFCs 3775 and 3963. If the group
> agrees in some future that DHAAD should be deprecated, then we¹ll need to
> revise all 3 documents. What¹s important IMHO is to keep them consistent.
>  
> 
> Pascal
> 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Behcet
> Sarikaya

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 23 Jun 2008 14:52:12 +0200

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.

My point is that this PD draft extends a family started with 3775 and 3963. This is why I think it makes sense to be consistent between the 3. People do not have to call their lawyer to figure how discovery is done depending on which MIP feature we are talking about.

What I do disagree with is your idea of trying all the HAs found in MIP/NEMO DHAAD till one HA is found that supports PD. I think that this is what does not make lots of sense...

Pascal

>-----Original Message-----
>From: Vijay Devarapalli [mailto:[email-masked]]
>Sent: vendredi 20 juin 2008 20:26
>To: Pascal Thubert (pthubert); Behcet Sarikaya; Julien Laganier
>Cc: [email-masked]

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 23 Jun 2008 13:35:09 -0400

Hi Pascal, 

> From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
> Sent: Monday, June 23, 2008 5:52 AM
> To: Vijay Devarapalli; Behcet Sarikaya; Julien Laganier
> Cc: [email-masked]
> 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?

> My point is that this PD draft extends a family started with 
> 3775 and 3963. This is why I think it makes sense to be 
> consistent between the 3. People do not have to call their 
> lawyer to figure how discovery is done depending on which MIP 
> feature we are talking about.

First of all, the HA discovery mechanisms that are likely to be 
used are either DNS-based or integrated scenario-based. While 
DHAAD is a useful tool for testing, I don't think it will get 
used or deployed. If you feel that we MUST define a mechanism 
to discover a DHCPv6-PD capable home agent, then we are better 
off extending the DNS-based or integrated scenario mechanisms. 
FWIW, I don't think this is necessary. We have mechanisms for 
the mobile router to try other home agents and/or to recover 
from the error. 

I also believe it was not necessary to extend DHAAD in RFC 3963. 
If and when we revise 3963, I would support removing the DHAAD 
extensions. 

Vijay

> What I do disagree with is your idea of trying all the HAs 
> found in MIP/NEMO DHAAD till one HA is found that supports 
> PD. I think that this is what does not make lots of sense...
> 
> Pascal
> 
> accepting

---

From: Julien Laganier <[email-masked]>
Date: Tue, 24 Jun 2008 12:19:13 +0200

Vijay and Pascal,

<Chair Hat ON>

> Necessary, but we could have an explicit consensus call on this.

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Jun 2008 14:07:47 +0200

Hi Vijay,

Vijay Devarapalli wrote:
[...]
> First of all, the HA discovery mechanisms that are likely to be used
> are either DNS-based or integrated scenario-based.

Where was a DNS-based HA discovery mechanism experimented, prototyped,
shown?

> While DHAAD is a useful tool for testing, I don't think it will get 
> used or deployed.

I have seen DHAAD used for testing in my lab, with two different 
implementations.

Or should I assume that you make deployment statements relying _only_ on 
SDO requirements?

Alex

______________________________________________________________________
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: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 24 Jun 2008 13:55:07 -0400

> the discussion has ran for some time.

Exactly. Pascal, please review the earlier thread. If you still think we
need an explicit consensus call, let the chairs know.

Vijay

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 25 Jun 2008 15:17:54 +0200

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

>From: julien laganier [mailto:[email-masked]] On Behalf Of
Julien Laganier
>Sent: mardi 24 juin 2008 12:19
>To: Vijay Devarapalli
>Cc: Pascal Thubert (pthubert); marcelo bagnulo braun; [email-masked]

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 25 Jun 2008 08:47:14 -0700 (PDT)

I agree. We are not taking DHAAD out from 3775bis for various reasons and
if the support exists there, let there be no restrictions in other
extensions. The word here is consistency. DHAAD as a discovery mechanism
has some value and all the existing implementations support it and I
prefer to keep this and let the extensions leverage this feature.

Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 25 Jun 2008 13:18:39 -0400

Pascal,

I want to focus on extending DHAAD for prefix delegation. We are *not*
talking about DHAAD deprecation in this thread. We already had the
discussion a while ago and decided that DHAAD would stay in 3775bis. In
fact I had supported keeping DHAAD in 3775bis at that point.

What I don't like is extending DHAAD every time we had a minor extension
to the MIPv6 home agent. It is not necessary. We have mechanisms for the
mobile node to recover when ever the home agent does not support a
particular feature.

Lets focus on that.

Vijay

> Sent: Wednesday, June 25, 2008 6:18 AM
> To: Julien Laganier; Vijay Devarapalli
> Cc: marcelo bagnulo braun; [email-masked]