Re: RtgDir review:draft-ietf-6man-resilient-rs-04

[Suresh Krishnan <[e-mail]>]

Hi Les,
   Thanks a lot for your review. Please find my responses inline.

On 02/16/2015 05:09 AM, Les Ginsberg (ginsberg) wrote:
> 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 throug
> discussion or by updating the draft.
>
> Document: draft-ietf-6man-resilient-rs-04
> <https://datatracker.ietf.org/doc/draft-ietf-6man-resilient-rs/>
>
> 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.

The exception text was added to allow such hosts to turn off soliciting 
on IPv4-only links. Once an RA is received from a router (even when the 
router is not willing to the default router), it signals to the host 
that the link is not an IPv4-only link. Hence the MUST for the host to 
continue sending the RSes. Does that make sense?

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

Will fix. Thanks.

Regards
Suresh