Enhanced Duplicate Address Detection
RFC 7527
Yes
No Objection
Note: This ballot was opened for revision 13 and is now closed.
(Brian Haberman; former steering group member) Yes
(Jari Arkko; former steering group member) Yes
(Ted Lemon; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
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
(Barry Leiba; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
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
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
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
(Pete Resnick; former steering group member) No Objection
A very quick read of the document indicates no App related issues or concerns.
(Richard Barnes; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
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?