[ippm] Éric Vyncke's No Objection on draft-ietf-ippm-ioam-data-12: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

É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 5.4.2.5 --
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 5.4.2.7 --
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.