[MBONED] Adam Roach's No Objection on draft-ietf-mboned-mtrace-v2-22: (with COMMENT)

[Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-mboned-mtrace-v2-22: 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-mboned-mtrace-v2/



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

Thanks to everyone who put in the work to improve the overall mtrace mechanism.
I have a handful of substantive questions and comments, most of which I believe
require clarifying text in the document.

---------------------------------------------------------------------------

§3:

>  All Mtrace2 messages are UDP packets.  For IPv4, Mtrace2 Query and
>  Request messages MUST NOT be fragmented.

Since Query messages can transit intermediate routers on the way to the LHR,
this requirement seems to imply that Mtrace2 clients MUST set the IP
do-not-fragment (DF) bit in Query messages. That should probably be called out
explicitly here.

To be clear, the above text seems to intentionally allow fragmentation of Reply
messages. Was that on purpose?

Finally, the corresponding IPv6 text puts a parallel restriction of 1280 bytes
on "the Mtrace2 messages", which would imply all message types, not ust Query
and Request.  Again: is that the intention?

---------------------------------------------------------------------------

§3.1:

All of the TLVs defined in this document appear to take pains to end on
four-byte boundaries (e.g., inserting "must be zero" bytes as necessary). This
document establishes an IANA registry for TLVs, presumably so new ones can be
defined elsewhere. When new TLVs are defined, is is a requirement that their
lengths are a multiple of four? If so, please indicate as much here, as it
allows implementations to make certain simplifying assumptions.

If this isn't the case, it should also be indicated here so that implementations
don't make such assumptions based on the six TLVs defined in this document.

---------------------------------------------------------------------------

§3.2.4:

>     This field contains a forwarding information/error code.  Values
>     with the high order bit set (0x80-0xff) are intended for use as
>     error or exception codes.

...

>    0x06   WRONG_LAST_HOP  This router is not the proper LHR.

Given that the "WRONG_LAST_HOP" forwarding code appears to be a fatal
condition based on client misconfiguration (per the description in §4.1.1),
I'm a bit confused about what is meant by "error or exception codes." Assuming
the assignment of 0x06 (rather than, say, 0x86) was intentional, I believe the
description of when the high order bit is set needs additional text to explain
more precisely what criteria is used to make such a determination.

---------------------------------------------------------------------------

§3.2.6:

>      The Augmented Response Type is defined as follows:
>
>         Code    Type
>         ====    ===============================================
>         0x01    # of the returned Standard Response Blocks

As this is a 16-byte field, it would be less confusing if this were:

>         Code      Type
>         ======    ===============================================
>         0x0001    # of the returned Standard Response Blocks


---------------------------------------------------------------------------

§8:

I am surprised not to see an IANA registry created for the 16-bit "Augmented
Response Type" field defined in §3.2.6. How are these values intended to be
managed?