Éric Vyncke's No Objection on draft-ietf-6man-icmp-limits-07: (with COMMENT)
Éric Vyncke via Datatracker <noreply@ietf.org> Fri, 06 March 2020 11:57 UTC
Return-Path: <noreply@ietf.org>
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 21BD63A0DE1; Fri, 6 Mar 2020 03:57:26 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6man-icmp-limits@ietf.org, 6man-chairs@ietf.org, ipv6@ietf.org, Bob Hinden <bob.hinden@gmail.com>, bob.hinden@gmail.com
Subject: Éric Vyncke's No Objection on draft-ietf-6man-icmp-limits-07: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.119.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <158349584610.2156.6067317475048579614@ietfa.amsl.com>
Date: Fri, 06 Mar 2020 03:57:26 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/tfro3fdoSAhzy802zRTMANTueRE>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 06 Mar 2020 11:57:27 -0000
Éric Vyncke has entered the following ballot position for draft-ietf-6man-icmp-limits-07: 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-icmp-limits/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Tom, Thank you for the work put into this document. It is short and easy to read while addressing a real problem in real deployments. ******************** * I was about to add a DISCUSS for not using the right BCP14 RFC 8174 template but please FIX this * (as this is the first review, I would suggest to issue today a revised I-D with just this fix * before other IESG reviews). * * I was also about to ballot a DISCUSS on the comment in section 2.4... ******************* Please find below some non-blocking COMMENTs and NITs. An answer will be appreciated. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 1.2 -- Just wondering why the "aggregate header limits" has a section on its own. Feel free to keep it like it is but this looks weird. -- Section 2 -- Strongly suggest to use TBA1, TBA2, ... in order to avoid mistakes done by the IANA. -- Section 2.2 -- Why not using a new code for 'unrecognized header' by intermediate node ? I really wonder why: it can only be confusing to existing implementation. Please also ensure what is meant by 'destination' here... I would prefer to avoid discussions when a routing-header is used (too many discussions around this in 6MAN already) -- Section 2.4 -- How can the original source distinguish among the two potential causes ? Why not using two code points? Or am I missing something obvious? I was really about to issue a blocking DISCUSS on this one. -- Section 3 -- Some justifications on why using a different ICMPv6 format would really help the reader. -- Section 4.1 -- The wording "1) Real error (existing codes)" looks weird because the code points in this documents will also be existing. Why not using "1) RFC 4443 error codes" ? -- Section 5.2 -- Is applicable to RFC 4443 in general, so, I wonder why it is in this document. == NITS == -- Section 1.1 -- If I was picky, then I would argue that "Extension Headers are placed between the IPv6 header and the Upper-Layer Header in a packet" is not always true: if Next-Header is 59 (No Next Header per RFC 8200 section 4.7) ;-) -- Section 2.1 + 3.1-- s/IPv6 Fields:/IPv6 Header Fields:/
- Éric Vyncke's No Objection on draft-ietf-6man-icm… Éric Vyncke via Datatracker
- Re: Éric Vyncke's No Objection on draft-ietf-6man… Tom Herbert
- Re: Éric Vyncke's No Objection on draft-ietf-6man… Eric Vyncke (evyncke)
- Re: Éric Vyncke's No Objection on draft-ietf-6man… Tom Herbert
- Re: Éric Vyncke's No Objection on draft-ietf-6man… Eric Vyncke (evyncke)