Re: [manet] review: draft-ietf-manet-nhdp-mib-12

Dear Joel,

thank you very much for your review and apologies for our late reply. Find our answers below, and
please tell us if they address your comments.

 ---------- Forwarded message ----------
From: Joel M. Halpern <jmh@...>
Date: Fri, Apr 6, 2012 at 8:59 AM
Subject: [manet] [Gen-art] review: draft-ietf-manet-nhdp-mib-12
To: gen-art@...
Cc: manet@..., "A. Jean Mahoney" <mahoney@...>,
sratliff@...


> 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.


<nhdp-mib-authors>
That's good :-)
</nhdp-mib-authors>




> 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.


<nhdp-mib-authors>
How about adding the following sentence at the end of
the paragraph of 5.1.3.1:
"The suppression window for notifications is started when the 'nhdpIfStatus'
transitions
 from its default value of 'false' to 'true'."
</nhdp-mib-authors>



>    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.



<nhdp-mib-authors>
Yes, you are right. We we pull these from the draft and
save the text and possibly use elsewhere in the future.
</nhdp-mib-authors>



> 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.
>


<nhdp-mib-authors>
We can change 'HELLO_INTERVAL' in Section 5.1.3.1 to 'nhdpHelloInterval'.
</nhdp-mib-authors>



>    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.


<nhdp-mib-authors>
How about adding the following sentence to 5.1.3.2:
The following objects are used to define the thresholds and time
windows for specific Notifications defined in the NHDP-MIB module:
nhdpNbrStateChangeThreshold,
nhdpNbrStateChangeWindow, nhdp2HopNbrStateChangeThreshold,