An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks
draft-ietf-mpls-tp-oam-analysis-09

-- Section 7 --
   In addition to implement security protocol, tools, and mechanisms,
   following strict operation security procedures is very important,
   especially MPSL-TP static provisioning processes involve operator
   direct interactions with NMS and devices, its critical to prevent
   human errors and malicious attacks.

This paragraph needs to be turned into more understandable English.  I'd offer, but I don't understand what it's trying to say well enough to do it (hence, this comment).  I suggest that it needs to be two or three sentences, rather than just one, and the grammar needs to be corrected so it's clear what it's saying.  [I note that the rest of the document is fine to read; it's only this section that has any notable problem.]

The next paragraph also has a couple of minor grammatical errors, but it's understandable:
OLD
   Since MPLS-TP OAM uses G-ACh, the security risks and mitigation
   described in [RFC 5085] apply here.  In short, the G-ACh could be
   intercepted, or false G-ACh packets could be inserted.  DoS attack
   could happen by flooding G-ACh messages to peer devices.  To mitigate
   this type of attacks, throttling mechanisms can be used.  For more
   details, please see [RFC 5085].
NEW
   Since MPLS-TP OAM uses G-ACh, the security risks and mitigation
   described in [RFC 5085] apply here.  In short, the G-ACh could be
   intercepted, or false G-ACh packets could be inserted.  DoS attacks
   can be mounted by flooding G-ACh messages to peer devices.  To
   mitigate this type of attack, throttling mechanisms can be used.
   For more details, please see [RFC 5085].

- Thanks for this document, and specifically for the tables in section 4, as it's difficult to find his way in a world full of MPLS OAM RFCs (requirements, framework, Fault specific, Packet Loss and Delay, you name it ). Along the same lines, I welcome http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-06, which has got a broader scope.

- 

   o  The OAM toolset developed for MPLS based transport networks needs
      to be fully inter-operable with existing MPLS OAM tools as
      documented in [RFC 5860].

Are you referring to http://tools.ietf.org/html/rfc5860#section-2.1.6

   When MPLS-TP is run with IP routing and forwarding capabilities, it
   MUST be possible to operate any of the existing IP/MPLS and PW OAM
   protocols (e.g., LSP-Ping [4], MPLS-BFD [13], VCCV [5], and VCCV-BFD
   [14]).

The document would benefit from clearly identifying what you mean.

This is even more confusing because you mention just below:
   The MPLS-TP OAM toolset is based on the following existing tools:

   o  LSP-Ping as defined in [RFC 4379].

   o  Bidirectional Forwarding Detection (BFD) as defined in [RFC 5880]
      and refined in [RFC 5884].

   o  ITU-T OAM for Ethernet toolset as defined in [Y.1731].  This has
      been used for functionality guidelines for the performance
      measurement tools that were not previously supported in MPLS.

   It should be noted that certain extensions and adjustments have been
   specified relative to the existing MPLS tools, in order to conform to
   the transport environment and the requirements of MPLS-TP.  However,
   compatibility with the existing tools has been maintained.

"compatibility with the existing tools has been maintained" I guess that you meant the list above: LSP-Ping, BFD, Y.1731. So what about the delta from my previous point: VCCV, and VCCV-BFD?

Section 8., paragraph 3:

>    Thanks to Rui Costa for his review and comments which helped improve
>    this doecument.

  s/doecument/document/

(Oops wrong button, I've no objection really:-)

- draft-ietf-mpls-tp-security-framework-02, May 2011 was
updated by a -03 in October 2011.

- weird references, the spaces muck up tools: 
[MPLS TP ITU Idents]
[MPLS-TP Security Frwk]

- s/MPSL-TP/MPLS-TP/ maybe?