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
Reviewed by Mary Barnes, Gen-ART Her review: Summary: --------- 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 tools). Nits: ----- - 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") from: 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 activity." 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
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.