Early Review of draft-ietf-6man-resilient-rs-04
review-ietf-6man-resilient-rs-04-rtgdir-early-ginsberg-2015-02-19-00

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request.
 The purpose of the review is to provide assistance to the Routing ADs. For
 more information about the Routing Directorate, please see

http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating
 the draft.

Document:

draft-ietf-6man-resilient-rs-04

Reviewer: Les Ginsberg

Review Date: February 16, 2015

IETF LC End Date: February 16, 2015

Intended Status: Standard



Summary:  This document is basically ready for publication, but has one
substantive issue that would require some text changes prior to publication.



Major Issues: None



Minor Issues: I admit to not having followed the progress of this document
prior to my review - but I have read the email archives and do understand that
the scope of this document has been deliberately limited and there has been
significant
 "wordsmithing" of the document to reflect the limited scope. I am therefore a
 bit reluctant to suggest further changes - but I thought this might be worth
 discussing.



The mechanism defined in this document allows a host to send RSs beyond what is
defined in RFC 4861. Use of this mechanism is optional. The only MUST which
this document imposes is that if a host chooses to use the mechanism defined
 it MUST use the backoff algorithm defined in Section 2 of this document.
 However, Section 2 explicitly states that a host is free to cease sending RSs
 whenever



"it is willing to accept that no router exists"



I therefore find the following sentence in Section 2.1 inappropriate:



"If an RA is recieved from a router and it does not result in a default route
(i.e. Router Lifetime is zero) the host MUST continue retransmitting the RSs."



I think this sentence should be removed. I believe the intent of the sentence
is to indicate that the reception of an RA provides positive indication that
IPv6 is enabled on the interface and therefore it is useful to continue to
utilize
 the mechanism - but the introduction of a MUST here is in contradiction to the
 earlier quote from Section 2 (see above). It also raises the unanswered
 question as to how long a host MUST continue to send RSs once it has received
 an RA.



Nits:



Should you decide to keep the above sentence in Section 2.1 note that
"recieved" is misspelled. :-)



   Les