Mtrace Version 2: Traceroute Facility for IP Multicast
draft-ietf-mboned-mtrace-v2-26

[Ballot 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?

[Ballot 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?

[Ballot discuss]
Thanks for this well written document! However, I think there are a few things that need clarification. I also agree with Ekr's discuss and the tsv-art review (Thanks Brian!) and would like to see stronger access control (as least MUST filter instead of SHOULD).

Further, the IANA section is not fully specified. Sec 8.2 doesn't define a registration policy. Sec 8.1. says
"Any additions to
  this registry are required to fully describe the conditions under
  which the new Forwarding Code is used."
which sounds like RFC8126 "Specification Required" which would however include expert review. Is an expert review require/desired here?

Also, I think the entry in the port registry should be updated to point to this RFC and reassign the port to the IESG as maintainer of this RFC.

Further, based on the feedback provided by the tsv-art review (Thanks Brian again!): How does a receiver distinguish between mtrace version 1 and mtrace2?

And also on use of UPD ports: Section 3 says:
"The source port is uniquely selected by the local host operating
  system.  The destination port is the IANA reserved Mtrace2 port
  number (see Section 8)."
This sounds like the IANA assigned port is used as destination for all mtrace messages including a reply. If that would be the case, you don't have to carry the mtrace client's port #. Can you please clarify?

Section 5.2 needs a bit of clarification. This says:
"If no Reply is received at a
  certain hop, the hop count can continue past the non-responding hop,
  in the hopes that further hops may respond.  These attempts should
  continue until the [Mtrace Reply Timeout] timeout has occurred."
This seems to be contradicting. If no Reply is received that means the Mtrace Reply Timeout has occurred, so how and when should you try further attempts. Also I think it would be good to clarify that only one Request MUST be sent at once. I assume that is how Mtrace Reply Timeout is used to rate limit requests (while traditional traceroute often sends multiple packets with different TTLs at once). Right?

[Ballot comment]
A few minor comments:

1) Regarding the protocol design: Given all messages types are actually fixed length (of course depending on what the underlying IP version is), you would actually not need a length field, but I guess it doesn't hurt. However, if you have it, shouldn't a receiver actually check if the length field is correct (based on the underlying IP version)?

2) sec 3.2.4 says:
"Note that Mtrace2 does not require all the routers on the path to
      have synchronized clocks in order to measure one-way latency."
What do you mean by one-way latency? You can measure the time between sending a request and receiving a reply on an mtrace client but I guess you'd be rather interested in the one-way delay between the LHR and FHR (which does require synchronized close at least between the LHR and FHR), no?

[Ballot comment]
-3.1. Length: "Length SHOULD NOT exceed the available MTU"
How does that interact with the previous "MUST NOT be fragmented" requirement?

-2: There are lower case versions of the 2119 keywords. Unless those were meant to be capitalized, please consider using the boilerplate from 8174.

[Ballot 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.

[Ballot comment]
Thanks for 9.2 and 9.3, it is very nice to see a control that can limit traceroute functionality by administrative domain to cut down on reconnaissance and other attack/pre-attack activities.  We normally just add warnings of that possibility in OAM drafts, so thank you!

[Ballot discuss]
The security considerations of this document are inadequate. My review
turns up at least the following potential issues which do
not seem to be addressed or even discussed:

- Amplification: this protocol does not appear to verify that the
  sender of the query actually owns the IP it claims. Because
  responses are much larger than queries, this allows for an amplification
  attack, especially if the client is able to send a query that elicits
  multiple replies. One defense here would be to fill the rest of the packet
  with zeroes, thus somewhat reducing the amplification factor. Access
  control would also help.

- Forgery of responses: because the query id is so short, an attacker
  can generally produce a message which has a nontrivial chance of
  corresponding to an extant query. This could be addressed by having
  a query ID that was large and random.

- Anyone on-path can forge responses.

In addition, Section 9.4 seems inadequate. Isn't it generally the case that
who is sending to who is sensitive? This seems like a fairly serious privacy
obstacle to using this protocol at all.

It seems like many of the issues I raise above would be fixed or at
least mitigated by having some sort of access control mechanism.  I
understand why it might be the case that it's not practical to have
full communication security between the links (though it would of
course be desirable), but it's not clear to me why arbitrary people
should be allowed to instantiate queries.

[Ballot comment]
S 1.
  When an Mtrace2 client initiates a multicast trace, it sends an
  Mtrace2 Query packet to the LHR or RP for a multicast group and,

This seems a bit confusing as there are multiple LHRs for the group.
Can you rephrase?


S 2.1.
  ALL-[protocol]-ROUTERS group
      It is a link-local multicast address for multicast routers to

This is grammatically funny. Perhaps remove "It is"


S 3.
  additional information associated with the message.  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.

ISTM that these cases are handled identically so is there a reason
not just to remove the first sentence and change the second one to
"for any TLV"/



S 3.2.1
  An Mtrace2 Query is usually originated by an Mtrace2 client which
  sends an Mtrace2 Query message to the LHR.  When tracing towards the
  source or the RP, the intermediate routers MUST NOT modify the Query
  message except the Type field.

I'm not sure I follow this. Don't routers either (a) not touch this at all
or (b) if they are the LHR, change Type from Query -> Request and then
add a response block? This text seems to not really capture either case.


S 3.2.4.
      Note that Mtrace2 does not require all the routers on the path to
      have synchronized clocks in order to measure one-way latency.

It's not clear to me how one does this. Can you expand?


S 3.2.6.

          0x01    # of the returned Standard Response Blocks

Nit: Do you want to say 0x0001

Also, an example of the case covered by this section would help, I think.



S 4.4.
It might be clearer to move this up a bit in the text as it sort of
summarizes some cases you already covered before. It would be easier
if it provided an overview instead.


S 5.9.

  In this case, the Mtrace2
  client may receive multiple Mtrace2 Replies from different routers
  along the path.  When this happens, the client MUST treat them as a
  single Mtrace2 Reply message.

Can you please describe how the client reassembles multiple messages
into one. I think I may know how to do this, but the document should
tell me.

S 8.
  The following new registries are to be created and maintained under
  the "RFC Required" registry policy as specified in [4].

Why did you choose RFC Required rather than Specification Required?
This just seems to unduly put load on the ISE.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper
type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard.


(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up. Recent examples can be
found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary:

This document describes the IP multicast traceroute facility, named
Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2
requires special implementations on the part of routers. This
specification describes the required functionality in multicast
routers, as well as how an Mtrace2 client invokes a query and
receives a reply.

Working Group Summary:

This document has received strong support from the working group and no
major controversies exist today with this document.

Document Quality:

The document was significantly reworked since a previous version was
submitted for publication. It generally well written and clear and has
received extensive review from multiple WG members from multiple
operators and vendors.

Personnel

Lenny Giuliano is the Document Shepherd, Warren Kumari is the
Responsible Area Director.

IANA Note

IANA Considerations

The following new registries are to be created and maintained under
the "RFC Required" registry policy as specified in [4].

"Mtrace2 Forwarding Codes" Registry

This is an integer in the range 0-255. Assignment of a Forwarding
Code requires specification of a value and a name for the Forwarding
Code. Initial values for the forwarding codes are given in the table
at the end of Section 3.2.4. Additional values (specific to IPv6)
may also be specified at the end of Section 3.2.5. Any additions to
this registry are required to fully describe the conditions under
which the new Forwarding Code is used.

"Mtrace2 TLV Types" registry

Assignment of a TLV Type requires specification of an integer value
"Code" in the range 0-255 and a name ("Type"). Initial values for
the TLV Types are given in the table at the beginning of Section 3.2.

UDP Destination Port

The Mtrace2 UDP destination port is [TBD].

[WK (1/2018) -  IANA has assigned UDP user port 33435 (mtrace) ]

(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.

Document was reviewed by the Shepherd, who feels it is ready for
publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

No concerns. Doc has been thoroughly reviewed and all issues seem to be
resolved.

(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

Not that I am aware of.

(6) Describe any specific concerns or issues that the Document Shepherd has
with this document that the Responsible Area Director and/or the IESG should be
aware of? For example, perhaps he or she is uncomfortable with certain parts of
the document, or has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated that it still
wishes to advance the document, detail those concerns here.

No concerns. Doc has been thoroughly reviewed and all issues seem to be
resolved.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

The authors have confirmed no IPR issue exists for this document.

(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

Not aware of any, nor any recollection of any WG discussion regarding IPR.

(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

There is strong WG consensus to publish the document. No objections have been
noted.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.

No applicable issues have been noted by ID nits.

(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

Not aware of any.

(13) Have all references within this document been identified as either
normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No. All normative references are published RFCs.

(15) Are there downward normative references references (see RFC 3967)? If
so, list these downward references to support the Area Director in the
Last Call procedure.

No.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed in
the Abstract and Introduction, explain why, and point to the part of the
document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.

No changes required.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries. Confirm that
any referenced IANA registries have been clearly identified. Confirm that newly
created IANA registries include a detailed specification of the initial
contents for the registry, that allocations procedures for future registrations
are defined, and a reasonable name for the new registry has been suggested (see
RFC 5226).

IANA considerations section looks appropriate to me.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

See IANA considerations above.

(19) Describe reviews and automated checks performed by the Document Shepherd
to validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

Not applicable.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-mboned-mtrace-v2-21. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has questions about the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are three actions which we must complete.

First, a new registry called the Mtrace2 Forwarding Codes registry will be created.

IANA QUESTION -> Where should this new registry be located? Does it belong at an existing URL? If not, 1) what is the title of the registry page, and 2) does it belong in an existing category at http://www.iana.org/protocols?

The registry is to be managed via the RFC Required policy defined by RFC 8126. The initial registrations in the new registry (each of which has this document as a reference) are as follows:

Value Name Description
----- -------------- ----------------------------------------------
0x00 NO_ERROR No error
0x01 WRONG_IF Mtrace2 Request arrived on an interface
to which this router would not forward for
the specified group towards the source or RP.
0x02 PRUNE_SENT This router has sent a prune upstream which
applies to the source and group in the
Mtrace2 Request.
0x03 PRUNE_RCVD This router has stopped forwarding for this
source and group in response to a request
from the downstream router.
0x04 SCOPED The group is subject to administrative
scoping at this router.
0x05 NO_ROUTE This router has no route for the source or
group and no way to determine a potential
route.
0x06 WRONG_LAST_HOP This router is not the proper LHR.
0x07 NOT_FORWARDING This router is not forwarding this source and
group out the outgoing interface for an
unspecified reason.
0x08 REACHED_RP Reached the Rendezvous Point.
0x09 RPF_IF Mtrace2 Request arrived on the expected
RPF interface for this source and group.
0x0A NO_MULTICAST Mtrace2 Request arrived on an interface
which is not enabled for multicast.
0x0B INFO_HIDDEN One or more hops have been hidden from this
trace.
0x0C REACHED_GW Mtrace2 Request arrived on a gateway (e.g.,
a NAT or firewall) that hides the
information between this router and the
Mtrace2 client.
0x0D UNKNOWN_QUERY A non-transitive Extended Query Type was
received by a router which does not support
the type.
0x0E-0x7F Unassigned
0x80 FATAL_ERROR A fatal error is one where the router may
know the upstream router but cannot forward
the message to it.
0x81 NO_SPACE There was not enough room to insert another
Standard Response Block in the packet.
0x82 Unassigned
0x83 ADMIN_PROHIB Mtrace2 is administratively prohibited.
0x84-0xFF Unassigned

Second, a new registry called Mtrace2 TLV Types will be created.

IANA QUESTION -> Where should this registry be located?

The registry is to be managed via the RFC Required policy defined by RFC 8126. The initial registrations in the new registry (each of which has this document as a reference) are as follows:

Code Type
== ================ ========
0x01 Mtrace2 Query [ RFC-to-be ]
0x02 Mtrace2 Request [ RFC-to-be ]
0x03 Mtrace2 Reply [ RFC-to-be ]
0x04 Mtrace2 Standard Response Block [ RFC-to-be ]
0x05 Mtrace2 Augmented Response Block [ RFC-to-be ]
0x06 Mtrace2 Extended Query Block [ RFC-to-be ]
0x07 - 0xFF Unassigned

IANA QUESTION -> Is the value 0x00 reserved or unassigned?

Third, IANA understands that the authors, in section 8.3 of the current draft, are requesting a UDP port to be assigned to Mtrace2.

IANA QUESTION -> The document doesn't provide the information required in order to fill in the fields in the registry (specifically, the service name and description fields). How should those fields be filled in? Please add this information to the IANA Considerations section.

The authors can also submit a template for early allocation, listing the Internet Draft
as a reference, according to RFC6335, Section 8.1.1:

IANA MAY accept early assignment
[RFC4020 ]
requests (known as "early allocation" therein) from IETF working groups that
reference a sufficiently stable Internet-Draft instead of a published
Standards-Track RFC.

The IANA Services Operator understands that these are the only actions required of us upon approval of this document.

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-11-23):

From: The IESG
To: IETF-Announce
CC: Leonard Giuliano , lenny@juniper.net, draft-ietf-mboned-mtrace-v2@ietf.org, mboned@ietf.org, mboned-chairs@ietf.org, warren@kumari.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Mtrace Version 2: Traceroute Facility for IP Multicast) to Proposed Standard


The IESG has received a request from the MBONE Deployment WG (mboned) to
consider the following document: - 'Mtrace Version 2: Traceroute Facility for
IP Multicast'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-11-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes the IP multicast traceroute facility, named
  Mtrace version 2 (Mtrace2).  Unlike unicast traceroute, Mtrace2
  requires special implementations on the part of routers.  This
  specification describes the required functionality in multicast
  routers, as well as how an Mtrace2 client invokes a query and
  receives a reply.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mboned-mtrace-v2/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mboned-mtrace-v2/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper
type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard.


(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up. Recent examples can be
found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary:

This document describes the IP multicast traceroute facility, named
Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2
requires special implementations on the part of routers. This
specification describes the required functionality in multicast
routers, as well as how an Mtrace2 client invokes a query and
receives a reply.

Working Group Summary:

This document has received strong support from the working group and no
major controversies exist today with this document.

Document Quality:

The document was significantly reworked since a previous version was
submitted for publication. It generally well written and clear and has
received extensive review from multiple WG members from multiple
operators and vendors.

Personnel

Lenny Giuliano is the Document Shepherd, Warren Kumari is the
Responsible Area Director.

IANA Note

IANA Considerations

The following new registries are to be created and maintained under
the "RFC Required" registry policy as specified in [4].

"Mtrace2 Forwarding Codes" Registry

This is an integer in the range 0-255. Assignment of a Forwarding
Code requires specification of a value and a name for the Forwarding
Code. Initial values for the forwarding codes are given in the table
at the end of Section 3.2.4. Additional values (specific to IPv6)
may also be specified at the end of Section 3.2.5. Any additions to
this registry are required to fully describe the conditions under
which the new Forwarding Code is used.

"Mtrace2 TLV Types" registry

Assignment of a TLV Type requires specification of an integer value
"Code" in the range 0-255 and a name ("Type"). Initial values for
the TLV Types are given in the table at the beginning of Section 3.2.

UDP Destination Port

The Mtrace2 UDP destination port is [TBD].


(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.

Document was reviewed by the Shepherd, who feels it is ready for
publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

No concerns. Doc has been thoroughly reviewed and all issues seem to be
resolved.

(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

Not that I am aware of.

(6) Describe any specific concerns or issues that the Document Shepherd has
with this document that the Responsible Area Director and/or the IESG should be
aware of? For example, perhaps he or she is uncomfortable with certain parts of
the document, or has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated that it still
wishes to advance the document, detail those concerns here.

No concerns. Doc has been thoroughly reviewed and all issues seem to be
resolved.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

The authors have confirmed no IPR issue exists for this document.

(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

Not aware of any, nor any recollection of any WG discussion regarding IPR.

(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

There is strong WG consensus to publish the document. No objections have been
noted.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.

No applicable issues have been noted by ID nits.

(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

Not aware of any.

(13) Have all references within this document been identified as either
normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No. All normative references are published RFCs.

(15) Are there downward normative references references (see RFC 3967)? If
so, list these downward references to support the Area Director in the
Last Call procedure.

No.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed in
the Abstract and Introduction, explain why, and point to the part of the
document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.

No changes required.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries. Confirm that
any referenced IANA registries have been clearly identified. Confirm that newly
created IANA registries include a detailed specification of the initial
contents for the registry, that allocations procedures for future registrations
are defined, and a reasonable name for the new registry has been suggested (see
RFC 5226).

IANA considerations section looks appropriate to me.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

See IANA considerations above.

(19) Describe reviews and automated checks performed by the Document Shepherd
to validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

Not applicable.

IANA has questions about the IANA actions related to this document.

IANA understands that there are two IANA actions that need to be
completed upon approval of this document.

First, the document appears to request IANA to create a registry of
forwarding codes for Mtrace Version 2. The document states that "new
Forwarding codes must only be created by an RFC that modifies this
document's Section 10, fully describing the conditions under which the
new forwarding code is used." However, Section 10 of the document
describes client behavior for mtrace and the forwarding codes appear to
be in Section 6.14 of the document.

IANA Question --> Are the forwarding codes in Section 6.14 the ones the
authors would like to have registered by IANA using the registration
rules that appear in the IANA Actions section of the document? If not,
what forwarding codes should be registered by IANA?

Second, IANA will allocate a UDP port from the User Registered Ports
Registry located at:

http://www.iana.org/assignments/port-numbers

for mtrace version 2.

IANA Question --> the title of section 13.2 of the document is "UDP
Destination Port and IPv6 Address" -- IANA wonders if an IPv6 address
was meant to be part of the request in this document.

IANA understands that these two actions are the only ones required upon
approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Mtrace Version 2: Traceroute Facility for IP Multicast) to Proposed Standard


The IESG has received a request from the MBONE Deployment WG (mboned) to
consider the following document:
- 'Mtrace Version 2: Traceroute Facility for IP Multicast'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-07-19. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


This document describes the IP multicast traceroute facility.  Unlike
unicast traceroute, multicast traceroute requires special
implementations on the part of routers.  This specification describes
the required functionality in multicast routers, as well as how
management applications can use the router functionality.



The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mboned-mtrace-v2/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mboned-mtrace-v2/


No IPR declarations have been submitted directly on this I-D.

Technical Summary

This document describes the IP multicast traceroute facility. Unlike
unicast traceroute, multicast traceroute requires special
implementations on the part of routers. This specification describes
the required functionality in multicast routers, as well as how
management applications can use the router functionality.

Working Group Summary

This draft has received solid support within the working group and no
major controversies were noted.

Document Quality

This draft has received significant input and comments during the
working group meetings and on the mailing list. During working
group last call, several issues were brought up by one reviewer,
but the author addressed all issues.

Personnel

Lenny Giuliano is the Document Shepherd, Ron Bonica is the
Responsible Area Director.

IANA Note

The following new assignments can only be made via a Standards Action
as specified in RFC 2434

Forwarding Codes

New Forwarding codes must only be created by an RFC that modifies
this document's Section 10, fully describing the conditions under
which the new forwarding code is used. The IANA may act as a central
repository so that there is a single place to look up forwarding
codes and the document in which they are defined.

UDP Destination Port and IPv6 Address

The IANA should allocate UDP destination port for multicast
traceroute version 2 upon publication of the first RFC.