Subject: Re: Adoption call of draft-halpern-6man-nd-pre-resolve-addr for 6MAN

From: Ole Troan <[email-masked]>
Date: Fri, 3 Oct 2014 09:24:13 +0200

This end the adoption call for draft-halpern-6man-nd-pre-resolve-addr.
The chairs conclusion is that there is consensus in the working group to adopt this document.

Authors, please resubmit this draft as draft-ietf-6man-nd-pre-resolve-addr

Best regards,
Ole

> On 24 Sep 2014, at 9:24 , Ole Troan <[email-masked]> wrote:
> 
> All,
> 
> The authors have requested an adoption call for this document as an informational document.
> 
> Please provide a view with reasons as to whether the WG should adopt this or not.
> 
> This message starts a one week 6MAN Working Group call on adopting:
> 
> 	Title           : Triggering ND Address Resolution on Receiving DAD-NS
> 	Author(s)    : I. Chen, J. Halpern
> 	Filename    : draft-halpern-6man-nd-pre-resolve-addr-00
> 	Pages        : 7
> 	Date          : 2014-01-10
> 
> http://tools.ietf.org/html/draft-halpern-6man-nd-pre-resolve-addr-00
> 
> The call ends on October 1st, 2014.
> 
> Regards,
> 
> Bob Hinden & Ole Trøan
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 03 Oct 2014 16:07:10 -0700

Ole,

I missed the reference to the IPR disclosure since it wasn't in the 
actual WG last call but in a follow-up email.

I find this technique of limited utility. For instance, it does not 
describe how the entry can actually remain in the neighbor cache for 
weeks or months (the host will do DAD once, and the DOS attack can 
happen a long time after that). As indicated in RFC 6583 events like 
Spanning Tree Protocol (STP) Topology Change Notification (TCN) might 
invalidate the neighbor cache on an interface. Or a flood which results 
in NUD packets not being processed in a timely manner will result in 
loosing the NCE.

Given that *plus* the claimed IPR, I don't see why the WG needs to spend 
time on this.
It might be useful to document this behavior that Ericsson as 
implemented in an independent submission informational document.

    Erik

On 9/24/14 11:20 PM, Ole Troan wrote:
> for some additional information, here is the initial discussion of the draft back in January:
> https://mailarchive.ietf.org/arch/search/?q=draft-halpern-6man-nd-pre-resolve-addr&gbt=1
>
> and here is the IPR disclosure:
> https://datatracker.ietf.org/ipr/2300/
>
> Ole
>

---

From: Erik Kline <[email-masked]>
Date: Mon, 6 Oct 2014 16:30:46 +0900

> It might be useful to document this behavior that Ericsson as implemented
> in an independent submission informational document.
>

Agreed.

---

From: Brian Haberman <[email-masked]>
Date: Mon, 06 Oct 2014 16:16:30 -0400

>> in an independent submission informational document.

As a data point, the IESG has been encouraging the use of the ISE for
documents that describe what companies have implemented.  And since this
document is listed Informational, that approach makes more sense to me.

Regards,
Brian

---

From: Bob Hinden <[email-masked]>
Date: Tue, 7 Oct 2014 10:53:36 -0700

Brian,

> document is listed Informational, that approach makes more sense to me.

This is a fair point.  Contrary to our earlier conclusion on adopting this document, we now think going the Independent Submission route is appropriate.  If it was intended for all nodes and making changes to Neighbor Discovery, then it should be adopted in 6MAN.  As it not intended to be implemented by all nodes and it is Informational, we think the ISE route is appropriate for this document.

We also think that this was intended to be implemented in all nodes, then it would probably need additional work and some of this overlaps with the Efficient ND work going on in the w.g.

Is the w.g., and especially those who were in favour of adopting this draft, OK with this approach?

Bob