Benjamin Kaduk's No Objection on draft-ietf-6man-rfc6434-bis-09: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Mon, 16 July 2018 15:03 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7A313110E; Mon, 16 Jul 2018 08:03:04 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6man-rfc6434-bis@ietf.org, Robert Hinden <bob.hinden@gmail.com>, 6man-chairs@ietf.org, bob.hinden@gmail.com, ipv6@ietf.org
Subject: Benjamin Kaduk's No Objection on draft-ietf-6man-rfc6434-bis-09: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.82.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153175338430.21742.4791825773550865786.idtracker@ietfa.amsl.com>
Date: Mon, 16 Jul 2018 08:03:04 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/b4J6vrGNgY1OwPxwifx8RcvPjw8>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.27
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 16 Jul 2018 15:03:09 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-6man-rfc6434-bis-09: 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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6434-bis/



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

Thanks for the easy DISCUSS resolution :)
Original ballot comment preserved below.

Thanks for doing this work; it's quite helpful to have all this information
assembled in one place!

I have a few comments, broken out by section.

Section 1

]draft-thomson-postel-was-wrong and some discussion I've seen surrounding it
has made me wonder whether we are best served by continuing to "blindly cite"
Postel's Principle.  The principles it espouses do remain true in some aspects,
but there seems to be a tradeoff against other concerns as well.

Section 5.3

   A host MAY impose a limit on the maximum number of non-padding
   options allowed in a destination options and hop-by-hop extension
   headers. [...]

nit: is there a singular/plural mismatch here?

Section 13

Why is the phrase "SSL VPN" preferable to the phrase "TLS VPN"?
SSL is deprecated; the IETF protocol is TLS.

Section 15

   If an IPv6 node is concerned about the impact of IPv6 message power
   consumption, it SHOULD want to implement the recommendations in
   [RFC7772].

Do we really need to assign motive to IPv6 nodes?