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

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

Pending actual text availability, the approaches described seem to 
recognize the issues and plan to address them appropriately.
I look forward to seeing the result when it is ready,
Thank you,
Joel

On 4/27/2012 12:56 PM, Ulrich Herberg wrote:
> 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 <[e-mail] <mailto:[e-mail]>>
> Date: Fri, Apr 6, 2012 at 8:59 AM
> Subject: [manet] [Gen-art] review: draft-ietf-manet-nhdp-mib-12
> To: [e-mail] <mailto:[e-mail]>
> Cc: [e-mail] <mailto:[e-mail]>, "A. Jean Mahoney"
> <[e-mail] <mailto:[e-mail]>>,
> [e-mail] <mailto:[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.
>
>
> <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 <http://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 <http://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,
> nhdp2HopNbrStateChangeWindow,         nhdpIfRxBadPacketThreshold,
> nhdpIfRxBadPacketWindow.
> </nhdp-mib-authors>
>
>
>  >    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.
>
>
> <nhdp-mib-authors>
> We agree that this is probably a good practice to follow and will work
> up text to handle this.
> </nhdp-mib-authors>
>
>
>  >    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?
>
>
> <nhdp-mib-authors>
> That's true. We will go through all constraints from NHDP and
> add them to the MIB.
> </nhdp-mib-authors>
>
>
>
>  >    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.)
>
>
>
> <nhdp-mib-authors>
> We will can look at the descriptions and copy some more text from
> NHDP. However, we would like to avoid copying all NHDP into the MIB.
> </nhdp-mib-authors>
>
>
>  > 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?
>
>
> <nhdp-mib-authors>
> We actually don't know, and will ask the chairs about that.
> </nhdp-mib-authors>
>
>
> Best regards
> Ulrich and Bob