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
- Spencer Dawkins' Discuss on draft-ietf-6man-resil… Spencer Dawkins
- Re: Spencer Dawkins' Discuss on draft-ietf-6man-r… Brian Haberman
- Re: Spencer Dawkins' Discuss on draft-ietf-6man-r… Spencer Dawkins at IETF
- Re: Spencer Dawkins' Discuss on draft-ietf-6man-r… Suresh Krishnan
- Re: Spencer Dawkins' Discuss on draft-ietf-6man-r… Suresh Krishnan
- Re: Spencer Dawkins' Discuss on draft-ietf-6man-r… Spencer Dawkins at IETF