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

( 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

( Margaret Wasserman ) No Objection

( Alex Zinin ) No Objection