[Gen-art] review: draft-ietf-manet-nhdp-mib-12

["Joel M. Halpern" <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-manet-nhdp-mib-12
     Definition of Managed Objects for the
         Neighborhood Discovery Protocol
Reviewer: Joel M. Halpern
Review Date: 6-April-2012
IETF LC End Date: 16-April-2012
IESG Telechat date: (if known)

Summary: This document is almost ready for publication as a Proposed 
Standard.

Major issues:
     Section 5.1.3.1 on Ignoring Initial Activity is trying to do a very 
reasonable thing, namely suppress notifications for activity which is 
expected.  The text references RFC 4750 as precedent.  RFC 4750 is clear 
that the suppress window is tied to specific events (interface up and 
election as a DR.)  Section 5.1.3.1 does not specify which condition(s) 
start(s) the suppress window.  If, as seems likely, it is Interface Up 
which starts the window, please state that explicitly in the text.

     In section 5.4, in addition to describing objects which are defined 
in the MIB, the text describes, under the heading "The following objects 
return statistics related to HELLO messages:", a number of what it 
refers to as "Derived Objects".  These do not appear to be actual 
elements of the MIB.  They appear rather to be descriptions of 
calculations which the manager can perform using the information from 
the MIB.  It is not at all clear why they are here.  If I am 
understanding their role properly, and if they belong in this document, 
they belong in some other section, as they are NOT objects which return 
statistics related to HELLO messages.  They appear not to be returned by 
the managed device at all.

Minor issues:
     I can not find the object that corresponds to the setting for 
Ignoring the Initial Activity.  I presume this is my error.  The 
document would be helped if the object were named in section 5.1.3.1.

     I believe section 5.1.3.2 on Throttling Traps is intended to refer 
to the StateChange Threshold and StateChangeWindow objects.  It would be 
very helpful if these were actually named in section 5.1.3.2.

     Most MIBs I review have a description of the tables they contain, 
how the tables relate to each other, and how they are indexed, in the 
front matter that is roughly equivalent to section 5.2, 5.3, and 5.4. 
As I am not a MIB Doctor, I do not know if that is formally required, 
but I find it very helpful, and am surprised not to see it here.

     In looking at the fields in the NhdpInterfaceEntry, some of the 
field definitions include some of the constraints from RFC 6130 section 
5 in their DESCRIPTION clauses.  Some do not.  (For exampple, 
REFRESH_INTERVAL >= HELLO_INTERVAL is captured in nhdbpRefreshInterval, 
but not in nhdpHelloInterval.  The requirement that nhdpHelloInterval be 
greater than 0 is not captured anywhere.  Neither is H_HOLD_TIME >= 
REFRESH_INTERVAL captured.)  Some elements have a statement that the 
object is persistent, while others do not, but these do not seem to 
correspond to a difference in RFC 6130.  It is possible that there is a 
good reason for this apparent variation.  Is there?

     Particularly for top-level objects such as nhdpNHoldTime and 
NhdpIHoldTime I would really like to see a better description than just 
this is <named> object from section 5 of RFC 6130.  Someone who is using 
the MIB, who is looking at the description clause for assistance, really 
needs something more than the name of the field in the MIB.  (I think 
better descriptions would be a good idea through much of the MIB.)

Nits/editorial comments:
     The tracker claims this is "In WG Last Call (manet), but also seems 
to indicate that it is in IETF Last Call.  Are the two happening at the 
same time?