[MBONED] Alia Atlas' No Objection on draft-ietf-mboned-mtrace-v2-22: (with COMMENT)

[Alia Atlas <[e-mail]>]

Alia Atlas 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:
----------------------------------------------------------------------

1) In Sec 3, the first paragraph says: "If an implementation receives an
unknown TLV type
   for a subsequent TLV within a message, it SHOULD ignore and silently
   discard the entire packet."  This appears to me to remove the possibility of
   incremental deployment of new features or TLVs.  A rationale for why
   future-proofing isn't needed would be helpful.  I do see the Augmented
   Response Block and Augmented Query Block have sub-types, which does help
   with extensibility.

2)End of Sec 3: "Additionally, Mtrace2 supports both IPv4 and IPv6, but not
mixed.
   For example, if an Mtrace2 Query or Request message arrives in as an
   IPv4 packet, all addresses specified in the Mtrace2 messages MUST be
   IPv4 as well.  Same rule applies to IPv6 Mtrace2 messages."
I do not understand the rationale for forbidding some addresses being IPv4 and
some IPv6. Presumably, some could even be unnumbered interfaces.  Many networks
are dual-stack or may have IPv4 in one part of the network and IPv6 in another
part.  What is the reason for ruling this out as a valid situation?  I do see
that the encodings are problematic if partly IPv4 and partly IPv6 - but I do
not see a reason that IPv4 addresses could not be sent as mapped into IPv6.

3) Sec 3.2.1: "If the actual number of hops is not
   known, an Mtrace2 client could send an initial Query message with a
   large # Hops (e.g., 0xffffffff), in order to try to trace the full
   path."
   Since the #Hops field is an octet long - the largest value should be 255;
   specifying for a uint32 instead of a uint8 is incorrect.

4) Sec 3.2.1: If all the addresses in the Query message must be either IPv4 or
all must be IPv6, the
    way of determining which it is from the length should be clearly specified.
     I.e. The length field MUST be either 8 plus 3*4 (IPv4 addresses) or 8 +
    3*16 (IPv6 addresses); if the length is 20, then IPv4 addresses MUST be
    assumed and if the length is 56, then IPv6 addresses MUST be assumed. One
    could - of course, simply force all IPv6 addresses since an IPv4 address
    can be represented as an IPv6 address.  That would allow any of these
    addresses to be either IPv4 or IPv6 while formatted as IPv6.

5) Sec 3.2.2: "The format of an Mtrace2 Request message is similar to an Mtrace2
   Query except the Type field is 0x02."   This should be clearer and more
   normative.  The Mtrace2 Request TLV is exactly the same as an Mtrace2 Query
   except for the identifying Type field of  0x02. The same applies to 3.2.3
   for Mtrace2 Reply.