draft-ietf-ippm-ioam-flags. AD Evaluation comments

[shwethab]

Martin Duke [email protected]
Sat, Apr 9, 1:02 AM
to draft-ietf-ippm-ioam-flags.all

Like ioam-direct-export, this is mostly ready. Thanks for a short, clearly written document.

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.

I only have one point of confusion, which might be an editorial issue or just my lack of depth on the subject:

IIUC the restrictions on flags mean that there will be only one trace option in the IOAM header. As there's only one trace option, I don't know why (4.2) says
"The IOAM transit node pushes the required data field
after creating the copy of the packet, in order to allow any
egress-dependent information to be set based on the egress of the
copy rather than the original packet."
Why "any egress-dependent information"? Don't we know exactly what egress-dependent information there is by virtue of the big restrictions?

Relatedly, in (4.3) it envisions "adding any requested data at each transit node". But isn't that precluded by the option restrictions?

This reads like a relic from before the flag restriction existed, but there is very likely a subtlety I am missing here.

Thanks
Martin

[shwethab]

"adding any requested data at each transit node". -> "adding requested data at each transit node".

[shwethab]

drop : "The IOAM transit node pushes the required data field
after creating the copy of the packet, in order to allow any
egress-dependent information to be set based on the egress of the
copy rather than the original packet."