Hi, There are a few issues that need to be corrected and clarified before submitting this document to the IESG. There may be more, but I did not have the time to perform a full MIB Doctor review, this is what I found at a first pass reading of the document.
- Runing smilint indicates a number of problems - most derive from the fact that indices of many table are of the SYNTAX of Integer32 with no range restriction - LispAddressType TC is defined as a four-tuple with several variants - how can it have 0 as its lower size? - Having a REFERENCE clause that says "[LISP]" is not useful. People may use the MIB module but not the RFC, and even if they know what the reference is just one high level reference is useless. To be useful to implementers REFERENCE clauses of specific objects must point to the exact paragraphs that define the origin of the MIB definition in the LIPS RFC - Some of the Integer objects have obviously a range, but this is not specified - for example lispMapCacheLocatorRlocPriority or lispMapCacheLocatorRlocWeight - The indexation of lispIidToVrfTable seems broken - if the value of VPNIdOrZero is zero because a VPN ID could not be determined, how are to rows in such situation distinguished? - There is no discontinuity indicator for the (many) counter objects in the MIB module. See section 4.6.1.2 in RFC 4181 for some advice on this issue - IANA Considerations - IANA must allocate a branch under mib-2 for this MIB module (marked xxx in the MIB module) Regards, Dan > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Sander Steffann > Sent: Wednesday, August 29, 2012 12:36 PM > To: Terry Manderson > Cc: LISP mailing list list > Subject: Re: [lisp] WGLC for draft-ietf-lisp-mib-05 > > Hi, > > > I have not seen any review nor comments made of this document in this > > WGLC by anyone in the WG. > > > > I am extending this last call by a further 14 days. > > > > The extended LC will end on Tuesday the 11th of September. Please WG, > > cast your eyes over this document, it cannot progress without adequate > review! > > I don't see anything wrong with the document. It would have been nice if > notifications had been defined, for example for (certain) changes to > lispEidRegistrationTable, lispMappingDatabaseTable and > lispMappingDatabaseLocatorTable. But everything that is defined in the > document looks good! > > Thanks, > Sander > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
