Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks
RFC 4377

Note: This ballot was opened for revision 07 and is now closed.

(Alex Zinin) Yes

(Brian Carpenter) No Objection

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Sam Hartman) (was Discuss) No Objection

(Scott Hollenbeck) (was Discuss) No Objection

Comment (2005-11-23)
No email
send info
draft-ietf-mpls-oam-requirements-06: Acronyms in the title should probably be expanded.

(Russ Housley) No Objection

Comment (2005-12-15 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  draft-ietf-mpls-oam-frmwk-04, Section 7: s/IP based tools/IP-based tools/

(Mark Townsley) (was Discuss) No Objection

(Bert Wijnen) (was Discuss, No Record, Discuss, No Objection) No Objection

Comment (2005-12-01)
No email
send info
---------- MIB Doctor comments
Since new revisions are expected on both documents, let me just copy
some MIB doctor review comments, so that the authors can take this
into consideration for the new revisions.

--- from Mike Heard:

NITs in draft-ietf-mpls-oam-requirements-06.txt: abstract uses the imperative
"MAY" in a context where the ordinary verb "may" is required (the same error
occurs at other places in the document;  I don't think imperatives belong
here at all).  Some acronyms in the abstract also may need to be expanded
there (judgment call).  Also replace "this draft" by "this document".  In
Section 2 please exand "LSP" and "TE" and all other acronyms on or prior to
first use (reverse order of subsections if necessary).  Eliminate one of the
duplicate definitions of "Head-end Label Switch Router".  More substantive:
it is news to me that ICMP is part of the MPLS control plane (sec. 4.1) ...
I thought it was part of the data plane, as far as MPLS was concerned.  I
stop here on minor things that should have been corrected before the doc
went to the IESG (grumble).  Having said all that, I would be OK to have it
published once it got cleaned up (assuming that the responsible AD can vouch
that the MPLS network operator community is happy with its content.

Regarding draft-ietf-mpls-oam-frmwk-03.txt -- the title led me to expect some
real content regarding how OAM would be carried out on MPLS networks.  I didn't
see any.  I am not sure what purpose this document serves.  I do not understand
why it needs to be published.

---- from Dan Romascanu:
draft-ietf-mpls-oam-requirements-06.txt

4.9 Standard Management Interfaces

   The wide-spread deployment of MPLS requires common information 
   modeling of management and control of OAM functionality. This is 
   reflected in the the integration of standard MPLS-related MIBs 
   (e.g. [RFC3813][RFC3812][RFC3814]) for fault, statistics and 
   configuration management. These standard interfaces provide 
   operators with common programmatic interface access to
   operations and management functions and their status.


... Beyond the word repetition in the 3rd line ...

What is (are) the requirement(s)? This is in a requirements section. A
common information model? Which one, needs it be defined in the IETF,
some other place? SNMP support? Define another MIB module for MPLS OAM?
The listed MIB documents have no direct relation with MPLS OAM. 

I believe that this section needs clarification and re-wording


---- from Bert Wijnen:
I actually reviewed a pre-copy of revision 4 for the frmwrk doc:

- I do not see why there is thus MUST/SHOULD/etc in the Terminology
  section. Only MUST is used once in the Security Considerations,
  and even there, a lower case must makes much more sense
- typos:
  section 1:
    the required the applicability of data plane OAM functions. Included
  s/the// at least once?
  figure 1:
  s/dignose/diagnose/
  top of page 7:
    able to automatically remove the defective resources from and the
  s/and// ??
- Mmmm I wonder:
  sect 2:
    FCAPS        Fault management, Configuration management,
                 Administration management, Provisioning
                 management, and Security management
  I thought that the P stands for Performance and not Provisioning.
  Anyway, if "Provisioning" is intended, then you may want to be
  consistent throughout your dopcument.
  sect 7, end of 2nd para:
    and authorization for OAM technologies is something that MUST be
    considered when designing network mechanism which satisfy the
    requirements presented in this document.
  I though "this document" is a "Framework" and not a "Requirements"
  document??

(Ted Hardie) Abstain