Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels
RFC 6424

Note: This ballot was opened for revision 11 and is now closed.

(Stewart Bryant) Yes

(Adrian Farrel) Yes

(Ron Bonica) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

Comment (2011-08-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Very minor editorial suggestions:

Section 1:

   This documents describes methods for performing LSP-Ping (specified
   in [RFC4379] traceroute over MPLS tunnels.

change to "This document [...]"; is there a right paren missing?

In the next sentence "in case where" sounds wrong; perhaps use
"in the case where" for both parts of the sentence?

Section 3.3.1:

   MAY be include [...]

change to "MAY be included"



(Wesley Eddy) No Objection

(Stephen Farrell) No Objection

Comment (2011-08-11 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I see that this defines a "NIL FEC" that can be used to hide
information, which is just fine. That made me wonder though
if this is only needed here or maybe also elsewhere (e.g. 
in draft-ietf-mpls-p2mp-lsp-ping)? Or, perhaps other MPLS
ping functions need some equivalent? (Just checking.)

(David Harrington) (was Discuss) No Objection

Comment (2011-08-09)
No email
send info
in 3.2.1, s/the node needs to return a different Return Code/Return SubCode for each downstream. / the node needs to return a Return Code/Return SubCode for each downstream./ (I suspect that each return code may not need to be different)
in 3.4, "The Downstream Mapping TLV has been deprecated." should this be "This document deprecates the Downstream Mapping TLV"? If another document specified the deprecation, please provide a reference.

(Russ Housley) No Objection

(Pete Resnick) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

(Sean Turner) (was Discuss) No Objection