Re: TSVDIR LC review: <draft-ietf-6man-resilient-rs-04.txt> (Packet loss resiliency for Router Solicitations) to Proposed Standard

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Tue, 17 February 2015 01:29 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1711A040C; Mon, 16 Feb 2015 17:29:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsdHEcsZgZWM; Mon, 16 Feb 2015 17:29:51 -0800 (PST)
Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C72371A01E7; Mon, 16 Feb 2015 17:29:50 -0800 (PST)
Received: by lbiz11 with SMTP id z11so1772585lbi.8; Mon, 16 Feb 2015 17:29:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ONZlAqXkz1gMPiCc7D9QPyKsl2s+b8tbg4Vxz+RafX8=; b=fy/dm0OjzPj6RpyjRiEILvJA6waXfdsgAwvk1k/6nZ0XiSljdx1OcTsmJJgciyyUOr 2ggEWTL7LhpBph+4noEr9AxWkBEbnrMzZt3DT3GmBxOspp7m82TZhthh7YOzhcvHSvpO wKAy81w5ySUD0W9b1zPC6JEB+GWKcu5LQg2/NmOcFeOG4+uyX/rr642Vvs1gew60WpyB s0ibvxhoIdDCUdASUsAQoBrYGV1/Nz0UoLI6vno5INhru7smL0Z6mfoO7t9cPqUEVETa JO22Nla8l/HbvdFyrT69bRpg1xvPpIDFzF0OaIflVvOMkBu9cL2ZjcS1l+fj/wVRWUOE QS7Q==
MIME-Version: 1.0
X-Received: by 10.152.18.133 with SMTP id w5mr25947523lad.51.1424136589338; Mon, 16 Feb 2015 17:29:49 -0800 (PST)
Received: by 10.152.22.100 with HTTP; Mon, 16 Feb 2015 17:29:49 -0800 (PST)
Received: by 10.152.22.100 with HTTP; Mon, 16 Feb 2015 17:29:49 -0800 (PST)
In-Reply-To: <CAP8yD=tNQS5eiRaL9L3DHpD4DEPJMM26i696JhZMnf0KJ=CtdQ@mail.gmail.com>
References: <CAP8yD=tNQS5eiRaL9L3DHpD4DEPJMM26i696JhZMnf0KJ=CtdQ@mail.gmail.com>
Date: Mon, 16 Feb 2015 19:29:49 -0600
Message-ID: <CAKKJt-d5qNNNoz4AW+Sbg4iqHS1r_zDm+o+e+m1wT4Jc2j1koQ@mail.gmail.com>
Subject: Re: TSVDIR LC review: <draft-ietf-6man-resilient-rs-04.txt> (Packet loss resiliency for Router Solicitations) to Proposed Standard
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
To: Allison Mankin <allison.mankin@gmail.com>
Content-Type: multipart/alternative; boundary="089e01493d4084ef16050f3ea3d9"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/NSh05beRxkSR6RZaw7gcUO-Z-8M>
Cc: ipv6@ietf.org, ietf@ietf.org, tsv-dir@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Feb 2015 01:29:53 -0000

Allison,

Thank you for the review!

Spencer

On Feb 16, 2015 4:39 PM, "Allison Mankin" <allison.mankin@gmail.com> wrote:
>
> I am the assigned TSV Directorate reviewer for this draft.
>
> Please resolve these comments along with any other Last Call comments you
may receive.
>
> Document:  draft-ietf-6man-resilient-rs-04.txt
> Reviewer: Allison Mankin
> Review Date: 2015-02-16
> IETF LC End Date: 2015-02-16
> IESG Telechat date: N/A.
>
> Summary: This draft is ready for publication as a standards track RFC.
>
> This draft deals with the problem that packet loss of Router
Solicitations (RS)  can lead to an extended period of being disconnected
from the Internet.  The circumstances are well described and the solution
specified is sound from a transport point of view, and also it has a track
record. The draft directs hosts to use the retransmission algorithm from
RFC 3315, the DHCPv6 specification, which includes backoffs and a
randomization factor.  The draft specifies using this algorithm with no
maximum retransmission count (MRC) or maximum retransmission duration (MRD)
and shows that if there is an extended cause for a router to not reply,
there will be roughly one RS per hour from each host.
>
> Major issues:
> None found
>
> Minor issues:
> The Maximum Retransmission Time (MRT) is set to a value of 3600 seconds
instead of a smaller value from RFC 3315.  The rationale is cited
normatively from an individual internet-draft from 2012 but the correct
reference (and the one that may be cited normatively) is RFC 7083.  I find
that the datatracker is missing a replaced-by that would have led from the
2012 individual i-d through the WG i-d to the RFC.
>
> On 2 February 2015 at 10:32, The IESG <iesg-secretary@ietf.org> wrote:
>>
>>
>> The IESG has received a request from the IPv6 Maintenance WG (6man) to
>> consider the following document:
>> - 'Packet loss resiliency for Router Solicitations'
>>   <draft-ietf-6man-resilient-rs-04.txt> as Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> ietf@ietf.org mailing lists by 2015-02-16. Exceptionally, comments may be
>> sent to iesg@ietf.org instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>    When an interface on a host is initialized, the host transmits Router
>>    Solicitations in order to minimize the amount of time it needs to
>>    wait until the next unsolicited multicast Router Advertisement is
>>    received.  In certain scenarios, these router solicitations
>>    transmitted by the host might be lost.  This document specifies a
>>    mechanism for hosts to cope with the loss of the initial Router
>>    Solicitations.  Furthermore, on some links, unsolicited multicast
>>    Router Advertisements are never sent and the mechanism in this
>>    document is intended to work even in such scenarios.
>>
>>
>>
>>
>> The file can be obtained via
>> http://datatracker.ietf.org/doc/draft-ietf-6man-resilient-rs/
>>
>> IESG discussion can be tracked via
>> http://datatracker.ietf.org/doc/draft-ietf-6man-resilient-rs/ballot/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>