Warren Kumari's No Objection on draft-ietf-6man-rfc6434-bis-08: (with COMMENT)

Warren Kumari <warren@kumari.net> Wed, 04 July 2018 18:15 UTC

Return-Path: <warren@kumari.net>
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 EBB24130E07; Wed, 4 Jul 2018 11:15:51 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari <warren@kumari.net>
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: Warren Kumari's No Objection on draft-ietf-6man-rfc6434-bis-08: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.81.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153072815195.27351.5059287323725577376.idtracker@ietfa.amsl.com>
Date: Wed, 04 Jul 2018 11:15:51 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/wMAzkMKR278NdRht6hBf9u7oQvY>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.26
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: Wed, 04 Jul 2018 18:16:02 -0000

Warren Kumari has entered the following ballot position for
draft-ietf-6man-rfc6434-bis-08: 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:
----------------------------------------------------------------------

Thank you for this - it is a large amount of work!

I had a question, and a few nits.

Question:
"In core networks dominated by routers, Redirects are typically disabled.  The
sending of Redirects SHOULD be disabled by default on backbone routers.  They
MAY be enabled by default on routers intended to support hosts on edge
networks." The SHOULD here concerns me, but only because a "backbone router"
isn't really defined. I know one when I see one, but if I'm an implementer I
don't really know if the box is a backbone router or not (todays backbone gear
becomes tomorrow's edge gear, and next week's boat anchor). I have no
suggestions for how to address this (and feel free to ignore it!)

Nits (I'm sure the RFC Ed would have caught them, but doesn't hurt to make
their lives easier) Section 5.3.  Protecting a node from excessive EH options
"If a packet is received and the number of destination or hop-by-hop optines
exceeds the limit, then the packet should be silently discarded." options

Section  5.4.  Neighbor Discovery for IPv6 - RFC 4861
"  [RFC7559] discusses packet loss resliency for Router Solicitations,"
resiliency

Section 5.7.1.  Path MTU Discovery - RFC 8201
" For example, this will result in connections that
   complete the TCP three- way handshake"
three-way.