Subject: 6MAN WGLC: draft-ietf-6man-enhanced-dad

From: Ole Troan <[email-masked]>
Date: Tue, 3 Jun 2014 17:09:05 +0200

All,

This message starts a two week 6MAN Working Group Last Call on draft-ietf-6man-enhanced-dad

	Title           : Enhanced Duplicate Address Detection
	Author(s)   : R. Asati, H. Singh, W. Beebee, E. Dart, W. George, C. Pignataro
	Filename   : draft-ietf-6man-enhanced-dad-05
	Pages        : 11
	Date           : 2014-05-02
    http://tools.ietf.org/html/draft-ietf-6man-enhanced-dad

as a Proposed Standards document. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors.  This last call will end on June 17, 2014.

We need volunteers to do a detailed review of the document. We would also encourage volunteers to act as document shepherds. Please contact the chairs directly.

Regards,

Bob Hinden & Ole Trøan

---

From: Ole Troan <[email-masked]>
Date: Wed, 18 Jun 2014 10:29:16 +0200

All,

This WGLC has not received a single comment. 
We will keep this last call open until we get some review of the document. We also need a volunteer to do a detailed review.

Best regards,
Ole

On 03 Jun 2014, at 17:09 , Ole Troan <[email-masked]> wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: 神明達哉 <[email-masked]>
Date: Wed, 18 Jun 2014 08:26:23 -0700

At Wed, 18 Jun 2014 10:29:16 +0200,

> We will keep this last call open until we get some review of the document. We also need a volunteer to do a detailed review.

I've read the draft on the LC, but didn't find anything obviously
wrong or any useful comments that could improve it.  I didn't
explicitly respond to the LC since I generally don't like to respond
with a one-liner like "no objection":-).  I also didn't volunteer for
a detailed review as I didn't seem to be able to provide any
non-trivial feedback.  But if there's no other (and better) volunteer
I'll give another, a bit closer read, and see if I can say something
more meaningful.

--
JINMEI, Tatuya

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 19 Jun 2014 14:27:14 +0000

So let's go for it...

Minor comment, why is Carlos not in the same block of Cisco authors?

I would prefer to have section 1 (terminology) after section 2
(introduction).

Section 1:
- first bullet s/Note even Optimistic/Note: even Optimistic/
- loopback does not always loop between the same physical interface...
Think about a layer-3 switch with two different layer-2 interface for the
same layer-3 interface, looping the layer-2 interfaces will also introduce
a loop
- NS(DAD) should we add the destination at layer-2 and layer-3 being a
mcast?

Section 2 should be a real introduction, i.e., more the 'problem
description' in a new section ;-)
- "The interface issues a NS for the IPv6 link-local address DAD" why
restricting to LLA only? GUA/ULA have the same problem
- the last paragraph would benefit if rewritten, not really easy to
understand and ASCII art would help, also state that the cable-modem are
in bridge mode
- s/one layer 3 interface/one layer-3 interface/
- s/100 thousand/hundred thousands/

Section 3.1
- this I-D would benefit of a better punctuation, such as s/simplest the
mitigation/simplest; the mitigation/
- not sure whether a core router 'SHOULD' support disabling DAD...
Consequences could be catastrophic for a core router

Section 3.2:
- s/layer 2 protocols/layer-2 protocols/ (to be applied multiple times)
- add using the source MAC address as differentiator example?

Section 4:
- should we add 'mitigation 'to the section title to be similar to section
3?
- s/sufficiently large for nonce collisions/sufficiently large for
avoiding nonce collisions/

Section 4.2:
- split the paragraph in two pieces: one for the sheer sending and one for
repeating the sending of the probes
- not sure why enhanced DAD should be optional... Why not making it
mandatory?

Section 4.3:
- s/compares the nonce, if any, is included in the message/compares the
nonce included in the message, if any,/
- not sure why the last sentence is there as it is relevant to section 4.2

Section 6:
- should we add that the nonce does not protect against the DoS caused by
a rogue node replying by fake NA to all DAD probes?

Hope this helps

-éric

On 3/06/14 17:09, "Ole Troan" <[email-masked]> wrote:

>as a Proposed Standards document. Substantive comments and statements of
>support for advancing this document should be directed to the mailing
>list. Editorial suggestions can be sent to the authors.  This last call
>will end on June 17, 2014.
>
>We need volunteers to do a detailed review of the document. We would also
>encourage volunteers to act as document shepherds. Please contact the
>chairs directly.
>
>Regards,
>
>Bob Hinden & Ole Trøan