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

Ulrich Herberg <> Fri, 27 April 2012 16:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 994E021F86D6 for <>; Fri, 27 Apr 2012 09:56:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.912
X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RP+eTkvf0B3l for <>; Fri, 27 Apr 2012 09:56:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 79C4421F8671 for <>; Fri, 27 Apr 2012 09:56:50 -0700 (PDT)
Received: by pbbrp16 with SMTP id rp16so1222770pbb.31 for <>; Fri, 27 Apr 2012 09:56:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NKqLJ892KVJ0dYOwA5GSlOq0Hrl50owbAnD+Fx6pH7A=; b=To5RWmqW7CqpqO5mGcSp+lsuxBtqZmyoyDwPhSGDiWOf/8gigX/jNkp6gJsXDHfGpJ GSYC6pSeoUQMB8hV+Ydc9KqUeJljL4kiLvnn+5KPIORnBP0yBnCuwy4vuaMRSQNPoHzb AyHk1zqemd9VKx/Hff+vMBI5Oiff+7/DNAJZM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=NKqLJ892KVJ0dYOwA5GSlOq0Hrl50owbAnD+Fx6pH7A=; b=mHb/sseNRL5kyeNWMS0P6RMpbDiXMgK+ahjuQs2pNoj1/aLlEmlJ1MdtFsP/BZ4/Aq iOVN2uis+eXX+tdlJPonVhl64Il8g1OqfSFBYAhc7dNdoULywA/coYevefN6wYnuJnky nlXXEA4xERZVaed/vUo9Q3KL8BjRN2HnEYmyMw4+aEGYIz7p1pQFN1uj9E2wYzgKQpcS +nqO5l0kk1nIxxk7NSJJn2GSTYFYSQtb8ZNsuFas3x2OWPcqX7HVoMXsu3FGqHmzDh0K 7rFTwhs6r6iHUboi/wViDAvwlMb6CkFCBl0GHShPf4onxklATMGz6CCbwZxK7DJyHzAA jUFA==
MIME-Version: 1.0
Received: by with SMTP id ps2mr25095647pbc.109.1335545810242; Fri, 27 Apr 2012 09:56:50 -0700 (PDT)
Received: by with HTTP; Fri, 27 Apr 2012 09:56:49 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Fri, 27 Apr 2012 09:56:49 -0700
Message-ID: <>
From: Ulrich Herberg <>
To: "Joel M. Halpern" <>
Content-Type: multipart/alternative; boundary="047d7b2ee19999ce0404beabfd77"
X-Gm-Message-State: ALoCoQmKE9r6H6cnAj1UekaLPuJVGSwlleakkXpbCXx2h+QX6gqE+qicgtYKvnCwxL/JuhAi0Ib0
X-Mailman-Approved-At: Fri, 27 Apr 2012 10:26:53 -0700
Subject: Re: [Gen-art] [manet] review: draft-ietf-manet-nhdp-mib-12
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 27 Apr 2012 16:56:51 -0000

 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 <>
Date: Fri, Apr 6, 2012 at 8:59 AM
Subject: [manet] [Gen-art] review: draft-ietf-manet-nhdp-mib-12
Cc:, "A. Jean Mahoney" <>,

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <>.
> 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.

That's good :-)

> Major issues:
>    Section 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 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.

How about adding the following sentence at the end of
the paragraph of
"The suppression window for notifications is started when the 'nhdpIfStatus'
 from its default value of 'false' to 'true'."

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

Yes, you are right. We we pull these from the draft and
save the text and possibly use elsewhere in the future.

> 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

We can change 'HELLO_INTERVAL' in Section to 'nhdpHelloInterval'.

>    I believe section 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

How about adding the following sentence to
The following objects are used to define the thresholds and time
windows for specific Notifications defined in the NHDP-MIB module:
nhdpNbrStateChangeWindow, nhdp2HopNbrStateChangeThreshold,
nhdp2HopNbrStateChangeWindow,         nhdpIfRxBadPacketThreshold,

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

We agree that this is probably a good practice to follow and will work up
text to handle this.

>    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,
> 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?

That's true. We will go through all constraints from NHDP and
add them to the MIB.

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

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.

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

We actually don't know, and will ask the chairs about that.

Best regards
Ulrich and Bob