Re: Spencer Dawkins' Discuss on draft-ietf-6man-resilient-rs-05: (with DISCUSS and COMMENT)

Suresh Krishnan <suresh.krishnan@ericsson.com> Wed, 08 April 2015 04:15 UTC

Return-Path: <suresh.krishnan@ericsson.com>
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 C00021B2D63; Tue, 7 Apr 2015 21:15:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 iyj3DpzCue5U; Tue, 7 Apr 2015 21:15:54 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8A9C1B2D62; Tue, 7 Apr 2015 21:15:53 -0700 (PDT)
X-AuditID: c6180641-f790b6d000004359-7b-552448d49782
Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id A5.30.17241.5D844255; Tue, 7 Apr 2015 23:15:01 +0200 (CEST)
Received: from [153.88.4.126] (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.75) with Microsoft SMTP Server (TLS) id 14.3.210.2; Wed, 8 Apr 2015 00:15:51 -0400
Message-ID: <5524AB6F.90602@ericsson.com>
Date: Wed, 08 Apr 2015 00:15:43 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Brian Haberman <brian@innovationslab.net>, Spencer Dawkins <spencerdawkins.ietf@gmail.com>, The IESG <iesg@ietf.org>
Subject: Re: Spencer Dawkins' Discuss on draft-ietf-6man-resilient-rs-05: (with DISCUSS and COMMENT)
References: <20150407030724.32439.29818.idtracker@ietfa.amsl.com> <5523DC07.3040008@innovationslab.net>
In-Reply-To: <5523DC07.3040008@innovationslab.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [147.117.188.8]
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyuXSPt+5VD5VQg95GUYvdU6axWczs+cdo MePPRGaLl2ffM1ms2LWe1WLZlD3MDmweU35vZPXYOesuu8eSJT+ZPGYe/8ISwBLFZZOSmpNZ llqkb5fAldHw9A9TwRexioZbSxkbGM8KdTFyckgImEi8/3KHBcIWk7hwbz1bFyMXh5DAUUaJ +RMvMUM4mxklmg89BaviFdCU2LJ7HyuIzSKgIvG36TE7iM0GNGnDzs9MILaoQJjEtN/PWSHq BSVOznwC1isiUCXxbNkOsDizgLXE/km9QDYHh7BAmsTxgwIgYSGBdImHuzaAlXAKGEksa93B AlLCLGAv8WBrGUSnvMT2t3OYIco1Jbau+c4Kcb+ixIvjP5kmMArNQrJ4FkL3LCTdCxiZVzFy lBanluWmGxluYgQG+TEJNscdjAs+WR5iFOBgVOLhXXBSKVSINbGsuDL3EKM0B4uSOG/ZlYMh QDcmlqRmp6YWpBbFF5XmpBYfYmTi4JRqYMw5c11U6ee3NVMKn9xguP7JS77GK/bfs8K2azw9 XxTtLF0/xcRO/3rDLFRAR/d0kohcT8CUdeWNLIckkgv6HtdyPmUtOLn91vekoMy3AXuqZqp4 5To/vRT/YcWkUoN2V+aDG30rkuoC991v4os2eRv0OPiOnpRy2aQ/h93O9bAyXThtkqLho8RS nJFoqMVcVJwIAP263EdTAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/EDvhQAOXT2ntmu4Cnsiifo9AEUs>
Cc: ot@cisco.com, ipv6@ietf.org, 6man-chairs@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: Wed, 08 Apr 2015 04:15:55 -0000

Hi Brian,

On 04/07/2015 09:30 AM, Brian Haberman wrote:
> Hi all,
>
> On 4/6/15 11:07 PM, Spencer Dawkins wrote:
>> Spencer Dawkins has entered the following ballot position for
>> draft-ietf-6man-resilient-rs-05: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> http://datatracker.ietf.org/doc/draft-ietf-6man-resilient-rs/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> I'm piling on Barry's Comment as a Discuss, which should be easy to
>> discuss, but ... in this text:
>>
>> 3.  Configuring the use of retransmissions
>>
>>     Implementations of this specification MAY provide a configuration
>>     option to enable or disable the use of such potentially infinite
>>     retransmissions.  If the implementation provides such a configuration
>>     option, it MUST be able to enable/disable retransmissions on a per-
>>     interface basis.
>>
>> You can tell me that it's a LAN, so the transport ADs can go back to
>> sleep, but I was surprised that this configuration option was a MAY.
>>
>> I was also surprised that there was no guidance about the default setting
>> (on or off), but let's start with the MAY.
>>
>> IP does get tunneled to new and exciting places ... and infinite
>> retransmissions are infinite ...
>
> I went back and re-read Barry's Comment and the resulting response and
> felt unsatisfied.
>
> Barry & Spencer, let me know if I am misinterpreting your concerns...
>
> It appears odd to give such concrete guidance as "enable/disable
> retransmissions on a per-interface basis" for a function that is
> completely optional.  After some thought, I am trying to figure out why
> it would be optional since typical NA/NS/RA/RS functionality is
> per-interface anyway.
>
> Given what is being described, I would think we would want to encourage
> implementers to provide a configuration option rather than make it
> optional.  The text could be re-written (without 2119 keywords) as such:
>
> NEW:
> Implementations of this specification are encouraged to provide a
> configuration option to enable or disable potentially infinite RS
> retransmissions. Providing an option to enable/disable retransmissions
> on a per-interface basis allows network operators to configure RS
> behavior most applicable to each connected link.

This text looks good. If this will help clarify things, I will make the 
change.

Thanks
Suresh