Last Call Review of draft-ietf-mpls-rfc6374-udp-return-path-04
review-ietf-mpls-rfc6374-udp-return-path-04-opsdir-lc-vyncke-2016-01-04-00

I have reviewed draft-ietf-mpls-rfc6374-udp-return-path as part of the
Operational directorate's ongoing effort to review all IETF documents being
processed by the IESG.  These comments were written with the intent of
improving the operational aspects of the
 IETF drafts. Comments that are not addressed in last call may be included in
 AD reviews during the IESG review.  Document editors and WG chairs should
 treat these comments just like any other last call comments.

This is a standard track document of the MPLS WG and it the procedure to be
used by the Packet Loss and Delay Measurement. A query can be sent over MPLS
for measurement with a URO (UDP return object) forcing the reply to be sent
over UDP (possibly outside of
 the MPLS domain). The URO can contain IPv4 or IPv4 addresses (good).

This short I-D is quite clear and easy to understand, security & manageability
sections are correct. I found nothing in this framework document which could
cause operational issues EXCEPT:

as I am unsure of the usual PLDM procedures, what is the expected behavior when
a PLDM message (incl a URO) is received by a PLDM node which does not support
this object type? If it is well defined in PLDM, then there is no problem
 of course.

Can a reply be fragmented? Should the reply contains the DF bit for IPv4?
Probably worth mentioning what to do over fragmentation.

What is the expected behavior when the URO contains an IPv6 address and the
PLDM responder only has IPv4 address(es)?

Small nits:

in introduction, I guess you meant "

internally be forwarded" rather than "

internally
 forwarded"

Section 4.3, when selecting the source address, you may want to refer to RFC
6724

Hope this helps and (if it means something for you) Merry Christmas

-éric