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

[Hitoshi Asaeda <[e-mail]>]

Hi Stig,

Thank you very much for your careful review.
We’ll carefully check all your comments and give you back.

Regards,
--
Hitoshi Asaeda




> 2016/09/16 6:41, Stig Venaas <[e-mail]> wrote:
> 
> 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
> 
> _______________________________________________
> MBONED mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mboned