Subject: [MBONED] Spencer Dawkins' No Objection on draft-ietf-mboned-mtrace-v2-22: (with COMMENT)

From: Spencer Dawkins <[email-masked]>
Date: Wed, 24 Jan 2018 08:44:37 -0800

Spencer Dawkins 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:
----------------------------------------------------------------------

I support Mirja's Discuss ballot point on IANA.

In addition, I have a few comments.

I'm looking in the Introduction for an unambiguous statement as to whether this
mechanism can be initiated by a source, and I'm not seeing one. Just based on
the Introduction, I'm guessing not, but the Introduction starts by mentioning
that it's difficult to trace from the source, so I'm confused.

In section 3, I'm seeing

   If an
   implementation receives an unknown TLV type for the first TLV in a
   message (i.e., the header TLV), it SHOULD ignore and silently discard
   the entire packet.  If an implementation receives an unknown TLV type
   for a subsequent TLV within a message, it SHOULD ignore and silently
   discard the entire packet.

and trying to understand why these two cases are listed separately. I'm also
trying to understand why they're SHOULDs, but please help me understand the
differences you have in mind.

I share the question about mixing IPv4 and IPv6.

Is the last sentence in

   Upstream Router Address: 32 bits
      This field specifies the address of the upstream router from which
      this router expects packets from this source.  This may be a
      multicast group (e.g., ALL-[protocol]-ROUTERS group) if the
      upstream router is not known because of the workings of the
      multicast routing protocol.  However, it should be 0 if the
      incoming interface address is unknown or unnumbered.

normative?