Sign in
Version 5.13.0, 2015-03-25
Report a bug

Link Management Protocol (LMP) Management Information Base (MIB)

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

Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.

[Allison Mankin]

Comment (2004-10-28 for -)

Informative question:  does this use the common snmp approach to handling v4/v6
addresses in mibs? The 0/4/16 address length object stands out.

[Harald Alvestrand]

Comment (2004-10-28 for -)

Reviewed by Mary Barnes, Gen-ART

Her review:

Draft is ready to publish as Proposed Standard with the correction of
the following editorial nits ( based on the assumption that it's been
reviewed/approved by MIB doctors and run through the MIB compilation

- Needs updating to new template reflecting RFC 3668/3667.
- Blank lines between authors in the document heading is not at all necessary.
- Section 2: Introduction: The 2nd sentence is quite awkward and I
  would propose rewriting (at a minimum the word "which" should be
  changed to "whose")


      Along with Generalized MPLS (GMPLS) [RFC3471], the Link Management
    Protocol [LMP], which primary purpose is to manage traffic engineering
    (TE) links, is one of the key components of this stan dardization

  to something like:

       Generalized MPLS (GMPLS) [RFC3471] and the Link Management Protocol
    [LMP] are key components of this standardization activity. The primary
    purpose of LMP is to manage traffic engineering (TE) links."

- Section 14.1 Normative References: Remove reference to RFC 2026 per
 updates to template (curiously, RFC 3668 and 3667 are already listed
 as references - do they really need to be as I've not seen this done
 in other drafts?)