draft-ietf-ippm-ioam-direct-export - AD Evaluation

[shwethab]

Martin Duke [email protected]
Apr 8, 2022, 11:25 PM
to draft-ietf-ippm-ioam-direct-export.all

This document is in good shape and I have some minor comments before sending this to Last Call.

First: the number of authors exceeds the IESG policy. Please identify one or more "editors" in the document header who have taken responsibility for shepherding this document through the process, and list the remaining authors (with contact information, etc) in the back.

(3.1.2) I skimmed through ioam-data again but I'm still not sure. How is it possible to ignore this option if there's no length encoding? Are we assuming that the encapsulation provides this? Maybe this is written somewhere, or if not it ought to be.

(3.2 Flow ID) It might be useful to offer something between central assignment of all flow IDs and random assignment, which creates birthday problems, etc. Perhaps (non-normatively) the central assigner could assign each encapsulating node a codepoint in the first eight bits, and then each encapsulator would have a 24-bit space to use without collision?

Relatedly, should you discuss privacy concerns related to Flow ID and/or sequence number? I'm not a practitioner, but I can imagine a deployment where the encapsulating node is also a tunnel ingress that conceals the inner IP header. If the inner header provides the flow key, there's clearly a privacy problem.

Nits:
(3.1) s/exporting and/or collection/exporting and/or collecting

(3.2 IOAM-Trace-Type) "...Checksum Complement data field should be assigned to zero..." SHOULD?

Thanks
Martin

[shwethab]

Flow ID - allocation out of scope of the draft. But the flow ID should be allocated such that it is free of birthday problem possibly by...

[shwethab]

Security and privacy consideration to be updated to call out flow id to be allocated not to compromise privacy.