Barry Leiba's No Objection on draft-ietf-6man-resilient-rs-05: (with COMMENT)

"Barry Leiba" <barryleiba@computer.org> Fri, 13 March 2015 15:24 UTC

Return-Path: <barryleiba@computer.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 D029E1A7030; Fri, 13 Mar 2015 08:24:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 r7USECXgXk3o; Fri, 13 Mar 2015 08:24:37 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A661A1AB5; Fri, 13 Mar 2015 08:24:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Barry Leiba <barryleiba@computer.org>
To: The IESG <iesg@ietf.org>
Subject: Barry Leiba's No Objection on draft-ietf-6man-resilient-rs-05: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 5.12.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150313152437.30738.60495.idtracker@ietfa.amsl.com>
Date: Fri, 13 Mar 2015 08:24:37 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/4S6Lo8lmgw8K3cxiE6kQme8ZyvE>
Cc: ot@cisco.com, draft-ietf-6man-resilient-rs.all@ietf.org, ipv6@ietf.org, 6man-chairs@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 13 Mar 2015 15:24:39 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-6man-resilient-rs-05: No Objection

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/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-- Section 1 --

   In certain scenarios, these router solicitations
   transmitted by the host might be lost. e.g. The host is connected to
   a bridged residential gateway over Ethernet or WiFi.  LAN
   connectivity is achieved at interface initialization, but the
   upstream WAN connectivity is not active yet.

Purely minor editorial: I got a little tangled in that, and suggest tying
it together better this way:

NEW
   In certain scenarios, these router solicitations
   transmitted by the host might be lost. For example, if the
   host is connected to a bridged residential gateway over
   Ethernet or WiFi, LAN connectivity is achieved at interface
   initialization but the upstream WAN connectivity is not
   yet active.
END

-- Section 3 --

   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.

I find this a slightly odd usage of MAY and MUST: you're making the
configuration option entirely optional, but then you're saying that if I
have that configuration option, it MUST work a certain way.  Is it really
better not to be able to disable the infinite retransmissions at all,
than to make it all or nothing?  What is harmed by having a configuration
option that affects all interfaces at the same time... that is worse than
not having that configuration option at all?

In the end, do as you think best; I just wanted to bring up the comment.