[6lo] Éric Vyncke's No Objection on draft-ietf-6lo-fragment-recovery-13: (with COMMENT)
Éric Vyncke via Datatracker <noreply@ietf.org> Wed, 19 February 2020 13:07 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: 6lo@ietf.org
Delivered-To: 6lo@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E40120019; Wed, 19 Feb 2020 05:07:03 -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-6lo-fragment-recovery@ietf.org, Carles Gomez <carlesgo@entel.upc.edu>, 6lo-chairs@ietf.org, carlesgo@entel.upc.edu, 6lo@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.118.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <158211762351.23776.5618697293473954460.idtracker@ietfa.amsl.com>
Date: Wed, 19 Feb 2020 05:07:03 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/2hOGVMaWc8iBckSVA0SJy2PEavo>
Subject: [6lo] Éric Vyncke's No Objection on draft-ietf-6lo-fragment-recovery-13: (with COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Feb 2020 13:07:04 -0000
Éric Vyncke has entered the following ballot position for draft-ietf-6lo-fragment-recovery-13: 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-6lo-fragment-recovery/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Pascal, thank you for the work put into this document. The idea is simple and smart, I like the fact that all fragments follow the same path, so they should be delivered in the right order. Nevertheless, please find below some non-blocking COMMENTs (and I would appreciate a response from the authors) and NITS. I hope that this helps to improve the document, Regards, -éric == COMMENTS == A generic question is whether RFC 7112 "Implications of Oversized IPv6 Header Chains" is applicable ? -- Section 4.2 and Section 7.1 -- Should default values for the inter-frame gap be given ? -- Section 5.1 -- With 8 bits in the Datagram_Tag, this means that a node can only transmit/forward 256 packets over a link. While this seems suffisant, did the author make some investigation on this limit? The text should also state what to do when the 8 bits are not enough. -- Section 5.2 -- I suggest to mention that the use of the Datagram_Tag field will be described in section 6. -- Section 6 -- I find it weird to read in the same paragraph "The RFRAG Acknowledgment can optionally carry an ECN" and later "MUST echo that information by setting the 'E'". I am not a native English speaker but may I suggest to replace the first part with "The RFRAG Acknowledgment has a ECN" -- Section 6.1.2 -- "An implementation may receive overlapping fragments as the result of retries after an MTU change." Is this a security risk (RFC 8200 forbids overlapping fragments but this is a different layers) ? I also suggest to make it a normative "MAY" or "MUST accept". -- Section 7.2 -- Should the network observation installs global states or per destination states ? E.g., typical IP implementations maintain a per destination Path MTU cache. == NITS == -- Section 7 -- Is it "Kbps" or "kbps" ?
- [6lo] Éric Vyncke's No Objection on draft-ietf-6l… Éric Vyncke via Datatracker
- Re: [6lo] Éric Vyncke's No Objection on draft-iet… Pascal Thubert (pthubert)
- Re: [6lo] Éric Vyncke's No Objection on draft-iet… Eric Vyncke (evyncke)