Re: [MBONED] WGLC for draft-ietf-mboned-mtrace-v2

[Stig Venaas <[e-mail]>]

Hi

I think the draft is ready for publication with just minor changes.
Here are all my comments.

In the introduction it first talks about tracing down vs up the tree.
Then it says

   Mtrace2 is usually initiated from a Mtrace2
   client towards a specified source, or a Rendezvous Point (RP) if no
   source address is specified.

It's not clear here whether "usually" is regarding tracing to a source,
or if it talks about the complete sentence. Given the first paragraph,
"usually" could potentially mean something other than tracing from a
client. Also please write "or towards a Rendezvous..." or should it be
"or from a Rendezvous..."?

Also in the introduction it says:

   RP is a special router where the source
   and receiver meet in PIM-SM [5].

Perhaps it would be better to write "sources and receivers"?

We have this sentence:
   Moreover, Mtrace2 provides
   additional information such as the packet rates and losses, as well
   as other diagnosis information.

Would it be better to say "diagnostic information"? Or maybe information
for diagnosis?

There is this sentence:
   Source, Receiver and Mtrace2 client are typically a host on the
   Internet.

Should be "hosts on the Internet", or "Internet hosts".

>From earlier in the introduction it appears that a source address is
optional, that it can be an RP address instead? But then we have this
sentence:

When an Mtrace2 client initiates a multicast trace anywhere on the
Internet, it sends an Mtrace2 Query packet to the LHR or RP for a
multicast group and a source address.

So it seems one always need to specify a source address? Maybe you can
remove "anywhere on the Internet"? It seems unnecessary.

Multicast is most often used outside of what is typically called the
Internet, so I think it might be better to not use the term Internet
that much.

In 2.1 we have this text:

Outgoing interface
      The interface to which data from the source or RP is expected to
      transmit for the specified source and group.  It is also the
      interface on which the Mtrace2 Request will be received.

Maybe "expectte to be transmitted" is better? It should maybe not say
"the interface" as there can be many outgoing interface. Perhaps say
that "it is also an interface on which an Mtrace2 Request may be
received".

  Last-hop router (LHR)
      The router that is directly connected to the receivers.  It is
      also the router that receives the Mtrace2 Query from an Mtrace2
      client.

Maybe better to say "A router that is directly connected to a receiver"?

In second paragraph of section 3 it says:
   If the length of a TLV exceeds the
   length specified in the TLV, the TLV SHOULD be accepted; however, any
   additional data after the specified TLV length SHOULD be ignored.

Note that if this happens one may need to ignore all data after the
length. Not just what was supposed to be in that one TLV, as one does
not know where the data ends. Also, it may not be possible to detect
that the TLV is longer than the length. Once the length is reached,
one will simply have to assume that the next byte is the start of the
next "field" in the packet. Also if one were to find out, it is
possible that there is some corruption, or that the value is not what
it was intended to me. Please consider whether this sentence makes
sense. If it does, please add some more clarification.

In 3.1 it says:

   Length: 16 bits

      Length of Type, Length, and Value fields in octets.  Minimum
      length required is 6 octets.  The maximum TLV length is not
      defined; however the entire Mtrace2 packet length should not
      exceed the available MTU.

As I understand it, type and length fields are included. Which means
that a value must be at least 3 bytes? Is this correct? Even if it is
correct now, is it wise to require at least 6 octets here? Isn't it
possible that new TLVs might be defined in the future where this may
not be the case?

It looks like normative language may be missing some places. E.g SHOULD
NOT in the length description here? See also MBZ fields.

In 4.2.1 it says the term 224/24 is used. I think it is best to write
224.0.0.0/24.

In 4.2.2 it says:
   The first one
   encountered is the one that is reported, i.e. all "note Forwarding
   Code N" should be interpreted as "if Forwarding Code is not already
   set, set Forwarding Code to N".

Does this mean that the router must process the message following the
steps in this order? I think it might make sense for a router to for
instance report 5 ADMIN_PROHIB without first checking if it has a route
NO_ROUTE in 3.

In 4.3.2:
   An Mtrace2 Request should be sent with the address of the Incoming
   interface.  However, if the Incoming interface is unnumbered, the
   router can use one of its numbered interface address as the source
   address.

I think it should say "one of its numbered interface addresses".
Same in 4.4.2.

In 6 it says:
   This section describes the Mtrace2 behavior with the present of
   different multicast protocols.

Present should be presence.

iN 8.2 it says:

The IANA should allocate UDP destination port for Mtrace2 upon
publication of the first RFC.

Maybe better to refer to this document? What do you want this section to
say after publication? Perhaps it is better to write something like:

The Mtrace2 UDP destination port is [TBD].

It might be easier for IANA if you here list the name and exact content
of the registries. I see you are requiring Standards Action. Should e.g.
Experimental RFCs not be allowed?

Regards,
Stig