[ippm] Robert Wilton's No Objection on draft-ietf-ippm-ioam-direct-export-10: (with COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-ippm-ioam-direct-export-10: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Discuss cleared.

Previous, non-blocking comments:

1.
   This draft has evolved from combining some of the concepts of PBT-I
   from [I-D.song-ippm-postcard-based-telemetry] with immediate
   exporting from [I-D.ietf-ippm-ioam-flags].

I'm not sure that this paragraph is really helpful now, and could probably be
deleted - you could use the datatracker to indicate the document history and
which previous drafts this document replaces.

2.
   N >> M

I'm assuming that by ">>", this means much greater than?  It would be better
use words here, or at least define what this means (e.g., as opposed to a
bit-shift).

3.
   An IOAM node
   MAY maintain a counter or a set of counters that count the events in
   which the IOAM node receives a packet with the DEX Option-Type and
   does not collect and/or export data due to the rate limits.

Given that this is a MAY, I wasn't sure that this really specifies anything, I
guess that it is just offering a suggestion.

4.
   Exported packets SHOULD NOT be exported over a path or a tunnel that
   is subject to IOAM direct exporting.  Furthermore, IOAM encapsulating
   nodes that can identify a packet as an IOAM exported packet MUST NOT
   push a DEX Option-Type into such a packet.  This requirement is
   intended to prevent nested exporting and/or exporting loops.

It was unclear to me how that that SHOULD NOT can really be enforced, if the
exported packets are allowed to leave the limited domain.  Perhaps the "SHOULD
NOT" should be limited to the domain where IOAM is operating?

5.
   transit or decapsulating IOAM node that receives an unknown IOAM-
   Option-Type ignores it (as defined in [RFC9197]), and specifically
   nodes that do not support the DEX Option-Type ignore it.  Note that
   as per [RFC9197] a decapsulating node removes the IOAM encapsulation
   and all its IOAM-Option-Types, and specifically in the case where one
   of these options is a (possibly unknown) DEX Option-Type.  The
   ability to skip over a (possibly unknown) DEX Option-Type in the
   parsing or in the decapsulation procedure is dependent on the
   specific encapsulation, which is outside the scope of this document.
   For example, when IOAM is encapsulated in IPv6

I found the sentence from "Note that ..." to be somewhat unclear.

6. Option-Type Format

Would it be more helpful to explicitly specify what the length is.  I.e., X
bytes + 4 * number of set bits in the Extension-Flags?

7. Extension-Flags

More a question for my own knowledge:  I presume that the length calculation
(i.e., checking for the count of set bits) can be performed efficiently?  I.e.,
if calculating the length is important on any fast path.

8. subject to birthday problem conflicts, while centralized

Would it be helpful to spell out what is meant by "birthday problem conflicts",
or perhaps include an informative reference to the wiki page?

Nits:
N>100 => N > 100