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

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

(Bert Wijnen) Yes

(Harald Alvestrand) No Objection

Comment (2004-10-28)
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?)

(Steven Bellovin) No Objection

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Scott Hollenbeck) No Objection

(Russ Housley) No Objection

(David Kessens) No Objection

(Allison Mankin) No Objection

Comment (2004-10-28)
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.

(Thomas Narten) No Objection

(Jon Peterson) No Objection

(Alex Zinin) No Objection