I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.


0. From the security perspective, the requirements in this document
appear to be sufficient, though not very detailed. As it's a requirments
doc, this is ok. Obviously, I assume following specifications will be
more detailed in how the described security requirments are satisfied.

1. DISCUSS:
Question: as the document describes requirements and is in wide areas
unprecise in how they shall be implemented I wonder why it aims to be
“Standards Track” and not “Informational”?

2. COMMENT:
Question: section Terminology: “Fault: A fault is the inability of a
function to perform a required action. This does not include an
inability due to preventive maintenance, lack of external resources, or
planned actions (from [21], 3.26).”
Why does a lack of external resources not constitute a fault? (the other
two reasons I can understand but this one not?


3. COMMENT:
section 5.2:
“The MPLS-TP NE MUST perform persistency checks on fault causes before
it declares a fault cause a failure.”
I am not sure whether a “SHOULD” would be more appropriate here:
First, depending on the type of fault a NE my consider a failure after
the first fault cause and
Second, two paragraphs below, you speak of configurable time “A
data-plane forwarding path failure MUST be declared if the fault cause
persists continuously for a configurable time (Time-D). The failure MUST
be cleared if the fault cause is absent continuously for a configurable
time (Time-C).” if it is configurable, it may also be configured to
infinite small, which kind of contradicts with the “MUST” for
persistency check?

4. COMMENT:
Section 5.3.2: Question:
should this “An MPLS-TP NE MUST support suppression of alarms based on
configuration.” be changed to “An MPLS-TP NE MUST support suppression of
alarms based on configuration and for a limited time.”
Or do you may not want to allow infinite and unlimited suppression of
alarms?


6.
s/An MPLS-TP NE MUST support secure management protocols and SHOULD do
so in a manner the reduce potential impact of a DoS attack./An MPLS-TP
NE MUST support secure management protocols and SHOULD do so in a manner
that reduces potential impact of a DoS attack.

Kind regards, Tobias


Tobias Gondrom
email: tobias.gondrom at gondrom.org