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.