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

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-6man-resilient-rs-04-rtgdir-early-ginsberg-2015-02-19

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