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

[Loa Andersson <[e-mail]>]

Tobias,

on the being Standards Track or not you are 50% right.

ITU/T has changed their rules, but the document we need in
the IETF (the IAB boilerplate doc) is not yet published,
so I don't want the proposed status changed for requirements.

Let us hope that we can do it for the Frameworks.

/Loa

Eric Gray wrote:
> 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]
> 
> 

-- 


Loa Andersson                         email: [e-mail]
Sr Strategy and Standards Manager            [e-mail]
Ericsson Inc                          phone: [phone]
                                              [phone]