[ippm] Éric Vyncke's No Objection on draft-ietf-ippm-ioam-data-12: (with COMMENT)
Éric Vyncke via Datatracker <email@example.com> Thu, 25 March 2021 08:34 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 746433A15EE; Thu, 25 Mar 2021 01:34:46 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= <firstname.lastname@example.org>
To: "The IESG" <email@example.com>
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Al Morton <email@example.com>, firstname.lastname@example.org
Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= <email@example.com>
Date: Thu, 25 Mar 2021 01:34:46 -0700
Subject: [ippm] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-ippm-ioam-data-12=3A_=28with_COMMENT=29?=
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Thu, 25 Mar 2021 08:34:47 -0000
Éric Vyncke has entered the following ballot position for draft-ietf-ippm-ioam-data-12: 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-ippm-ioam-data/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document and thank you for acknowledging my comments and advices (as they were minor, I am not recusing myself). Sometimes the text is difficult to read as paragraphs and sentences are long and somehow repetitive. Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits. Like Alvaro, I was hesitating to ballot a DISCUSS on one point about section 4 (insertion/deletion of data on the flight). I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Abstract -- "a path between two points in the network" does this mean that this document cannot be used with a multicast destination address ? -- Section 2 -- Is the list about 'contributors' (as in the section title) or 'co-authors' (as in the text) ? -- Section 3 -- Please use the BCP14 boilerplate Please note that Geneve is now RFC 8926. -- Section 4 -- Should the 'deployment domain' include a reference to RFC 8799 ? I was about to ballot a DISCUSS on this one: While the actual encapsulation is out of scope, the definition of "IOAM control points" alludes to nodes at the edge and in the core being able to add/remove data fields. This behavior will obviously have some impacts on the PMTU discovery and possibly on the handling of ICMP. Did the authors think of writing a generic section in this document on how this can be done in a correct way? What is "live user traffic" ? I guess that this is not about end-user real-time video ;-) but a better wording would be welcome. I am afraid that "ships in the night" does not apply here as all ships are usually on the same layer ;-) (planes do flight at different flight levels) But, this is not that important. No need to reply. -- Section 5.1 -- Is it expected to have additional IOAM data types than the 4 in this document? Text should clarify this. -- Section 5.2 -- "A transit node MUST NOT add new IOAM-Option-Types" seems to contradict the "IOAM control points" definition of section 4. -- Section 5.3 -- If 0x0000 is already reserved, then I would suggest to make it part of the IANA range (i.e., making IANA range 0x0000 t 0x7FFF). -- Section 184.108.40.206 -- Should there be a precise definition (or reference) of "time in nanoseconds the packet spent in the transit node"? E.g., between first bit received and last bit sent ? -- Section 220.127.116.11 -- Is there a reason why the queue depth is expressed in buffers and not in packets? (Both metrics have useful values imho) -- Section 5.5 -- In "Random: Unique identifier for the packet" how are collisions resolved? Do they matter at all ? How can a transit/decaps node can handle the PoT (and also the E2E of section 5.6) as the length is not specified in the header ? == NITS == Usually "e.g." is enclosed between commas. The sentence "The definition of how IOAM-Data-Fields are encapsulated into other protocols is outside the scope of this document." or a minor variation of it occurs multiple times in the document. Please consider avoiding those repetitions.
- [ippm] Éric Vyncke's No Objection on draft-ietf-i… Éric Vyncke via Datatracker