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.
- Warren Kumari's No Objection on draft-ietf-6man-r… Warren Kumari
- Re: Warren Kumari's No Objection on draft-ietf-6m… Timothy Winters