Re: [secdir] Secdir review of draft-ietf-mpls-tp-nm-req-05.txt

[Eric Gray <[e-mail]>]

Tobias,

	Thanks for your review and comments.

	The decision to publish this document as a standards
track RFC was based on the previous restriction that ITU-T
cannot refer to an Informational RFC.  This restriction 
has only just been relaxed to allow references to an RFC
that results from the IETF consensus process, so it may no
longer be necessary to publish this draft as a standards 
track RFC. 

	That decision is out of my hands.

	Some definitions included are verbatim extractions
from ITU-T publications, taken to avoid the need for a
normative reference to those publications.  As such, they
are not actually subject to change and - if you disagree
with them - I would suggest taking it up with applicable
Questions in Study Group 15 at ITU-T.

	We tried to clarify the use of RFC 2119 language in 
this document and were somewhat limited in our ability to
do so by the requirements enforced by "idnits" that the
text must appear verbatim in the draft.  The intent in -
for example - making a statement that the NE MUST perform
persistency checks is to ensure protocol and management 
specifications ensure that doing so is possible based on
configuration.  The case where persitistency checking is
effectively disabled by configuration could be considered
the degenerate case where required persistency is zero.

	The intention with alarm suppression is that some
alarms are not desired in some configurations or under
some conditions. Escalation procedures MAY, in certain
situations, result in escalating an alarm condition to one
that is not suppressed.  Hence - to directly answer your
question - suppression is permanent for those specific
alarms for which it is configured, and as long as it is
not configured otherwise.

	The instance of "the" that you pointed out should
be changed to "that" as you suggest.

	Again, thanks for the review!

--
Eric

-----Original Message-----
From: Tobias Gondrom [mailto:[e-mail]] 
Sent: Monday, October 05, 2009 5:06 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; Eric Gray; Scott Mansfield; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Secdir review of draft-ietf-mpls-tp-nm-req-05.txt

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: [e-mail]