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.

(Adrian Farrel; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Stewart Bryant; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(David Harrington; former steering group member) (was Discuss) No Objection

No Objection (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.

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Pete Resnick; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Peter Saint-Andre; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ralph Droms; former steering group member) No Objection

No Objection (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"



(Robert Sparks; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection (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.)

(Wesley Eddy; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info