Enhanced Duplicate Address Detection
draft-ietf-6man-enhanced-dad-15

I have No Objection to the publication of this document, but I should
have liked more clarify on how the three updated RFCs are updated.
Section 4.3 makes this very clear for 4861, but the updates to 4862
and 4429 are less clear.

How about a new section 1.3 called "Updates to existing RFCs" that can
summarise for all three RFCs and give a forward pointer to 4.3?

You should precise when using the RFC 2119 keywords
OLD:
   A Service Provider router, such as an access concentrator, or network
   core router, SHOULD support this mitigation strategy.

NEW:
   A Service Provider router, such as an access concentrator, or network
   core router, SHOULD support the DAD desactivation per interface 

Same remark for "this solution" in
   This solution SHOULD be enabled by default, and MUST be a
   configurable option if the layer-2 technology provides means for
   detecting loopback messages on an interface circuit.

Please expand it.

Comment from Tim Chown's opsdir review:

Hi,

I have reviewed this document as part of the Operational directorate's 
ongoing effort to review all IETF documents being processed by the IESG.  These 
comments were written with the intent of improving the operational aspects of the 
IETF drafts. Comments that are not addressed in last call may be included in AD reviews 
during the IESG review.  Document editors and WG chairs should treat these comments 
just like any other last call comments. 

I believe this draft is on the IESG telechat agenda for tomorrow. There have been 
a minor update from -13 to -14 in the last couple of days to clarify the RFCs that 
the draft updates, which now seems resolved between the advice from the two 
ADs in question.

My view is that the document is Ready.

Very minor nits:

The last sentence of section 1 is a little clumsy, and perhaps unnecessary:
"The Changes to RFC 4861 section includes an update to RFC 4861."

The first paragraph in the Problem Statement could be broken into two or three.

Tim

Thanks for your work on this draft.  The SecDir reviewer had a few comments that you should respond on and in terms of security, the statement in section 5 on trust should be clarified.

https://www.ietf.org/mail-archive/web/secdir/current/msg05436.html

Section 5:
   Any other network that follows the same trust model MAY use the
   automated actions proposed in this section.
The problem is that as nearly as I can tell, there is only one such action in the section, the one in the immediately preceding sentence.

A very quick read of the document indicates no App related issues or concerns.

I'm a bit confused here - you use a field from SEND, and
then say that that could be borked, so the mitigation is
that one might use SEND to protect that. Why not just use
SEND - can you explain?