Skip to main content

Enhanced Duplicate Address Detection
RFC 7527

Yes

(Brian Haberman)
(Jari Arkko)
(Ted Lemon)

No Objection

(Alia Atlas)
(Barry Leiba)
(Martin Stiemerling)
(Richard Barnes)
(Spencer Dawkins)

Note: This ballot was opened for revision 13 and is now closed.

(Brian Haberman; former steering group member) Yes

Yes (for -13)

                            

(Jari Arkko; former steering group member) Yes

Yes (for -14)

                            

(Ted Lemon; former steering group member) Yes

Yes (for -14)

                            

(Adrian Farrel; former steering group member) No Objection

No Objection (2015-03-03 for -13)
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?

(Alia Atlas; former steering group member) No Objection

No Objection (for -14)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (for -14)

                            

(Benoît Claise; former steering group member) No Objection

No Objection (2015-03-05 for -14)
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.

(Joel Jaeggli; former steering group member) No Objection

No Objection (2015-03-04 for -14)
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

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2015-03-04 for -14)
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.

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -13)

                            

(Pete Resnick; former steering group member) No Objection

No Objection (2015-03-04 for -14)
A very quick read of the document indicates no App related issues or concerns.

(Richard Barnes; former steering group member) No Objection

No Objection (for -14)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -14)

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (2015-03-05 for -14)

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?