Re: 6MAN WG Adoption Call: draft-nordmark-6man-rs-refresh-01

Erik Nordmark <nordmark@acm.org> Tue, 21 April 2015 18:21 UTC

Return-Path: <nordmark@acm.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666BD1A0084 for <ipv6@ietfa.amsl.com>; Tue, 21 Apr 2015 11:21:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.635
X-Spam-Level:
X-Spam-Status: No, score=-1.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no
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 rjrGf9gkU4k8 for <ipv6@ietfa.amsl.com>; Tue, 21 Apr 2015 11:21:21 -0700 (PDT)
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B59B1A8838 for <ipv6@ietf.org>; Tue, 21 Apr 2015 11:21:21 -0700 (PDT)
Received: from [172.22.227.238] ([162.210.130.3]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t3LILH0R004261 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Apr 2015 11:21:17 -0700
Message-ID: <5536951D.60102@acm.org>
Date: Tue, 21 Apr 2015 11:21:17 -0700
From: Erik Nordmark <nordmark@acm.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: 神明達哉 <jinmei@wide.ad.jp>, Bob Hinden <bob.hinden@gmail.com>
Subject: Re: 6MAN WG Adoption Call: draft-nordmark-6man-rs-refresh-01
References: <16407124-2B19-4B8F-AEAC-F04D3C7E5C3A@gmail.com> <1FCBCC7C-A334-47AD-A22F-7685D1045A65@gmail.com> <CAJE_bqdh8aUzmF7UkBgicMNAM_YHBLQ5DYyuimbu9EY=d6T0Sg@mail.gmail.com>
In-Reply-To: <CAJE_bqdh8aUzmF7UkBgicMNAM_YHBLQ5DYyuimbu9EY=d6T0Sg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Sonic-CAuth: UmFuZG9tSVaWPCJtPtcuklmSnf9fFRtZJXqm2WmsaEokdldBQ29x0yeW2baPS0DlfpvP1tDWGO+j9p8W9fVP5V0RDASLMyqN
X-Sonic-ID: C;oibSM1Po5BGq34Y+Bvepxg== M;fAXnM1Po5BGq34Y+Bvepxg==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/S-BWnRSPadvwOS8RMmZuOMP8Cao>
Cc: IPv6 List <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Apr 2015 18:21:22 -0000

Jinmei,

Thanks for your comments.
Responses below.

On 4/10/15 9:57 AM, 神明達哉 wrote:
>
>
> On the draft itself, I have a few minor comments:
>
> - Section 5:
>     Refresh Time:  16-bit unsigned integer.  Units is seconds.  The all-
>                    ones value (65535) means infinite.
>
> What should the host do if this is 0?  Should it just keep sending
> RSes? (I'm joking).
Good catch. I'm inclined to just make zero be reserved, and state that 
hosts should ignore an RTO if the Refresh Time is zero - i.e. treat the 
RA as if the RTO was not present.
Is that sufficient?

We could pick some arbitrary number (10 seconds?) and say that it is a 
lower bound, but I don't know how to pick such a number.

>
> - Section 7: remove 'section'.
>     [...]  Note that section
>     Section 9 says that routers SHOULD report such inconsistencies to
>     system management.
Fixed.

>
> - Section 8.2: s/be be/may be/ (?)
>
>     [...]  That be be performed at deployment time (e.g., only
>     hosts which are known to support RTO are configured with the layer 2
>     security keys), or the routers detect any RSs which do not include
I think "could be" is better since it avoids potential confusion with 
uppercase MAY.
>
> - Section 8.3: remove '.' before 'Note':
>
>     .  Note that such new information is not likely to reach sleeping
>     hosts until those hosts refresh by sending a RS.
Fixed.

Thanks,
    Erik

>
> --
> JINMEI, Tatuya
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>