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

Ulrich Herberg <ulrich@herberg.name> Fri, 27 April 2012 16:56 UTC

Return-Path: <ulrich@herberg.name>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994E021F86D6 for <gen-art@ietfa.amsl.com>; Fri, 27 Apr 2012 09:56:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.912
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RP+eTkvf0B3l for <gen-art@ietfa.amsl.com>; Fri, 27 Apr 2012 09:56:50 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 79C4421F8671 for <gen-art@ietf.org>; Fri, 27 Apr 2012 09:56:50 -0700 (PDT)
Received: by pbbrp16 with SMTP id rp16so1222770pbb.31 for <gen-art@ietf.org>; Fri, 27 Apr 2012 09:56:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; 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; d=google.com; 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 10.68.220.2 with SMTP id ps2mr25095647pbc.109.1335545810242; Fri, 27 Apr 2012 09:56:50 -0700 (PDT)
Received: by 10.142.89.17 with HTTP; Fri, 27 Apr 2012 09:56:49 -0700 (PDT)
In-Reply-To: <4F7F12CA.9010009@joelhalpern.com>
References: <4F7E279C.3030707@nostrum.com> <4F7F12CA.9010009@joelhalpern.com>
Date: Fri, 27 Apr 2012 09:56:49 -0700
Message-ID: <CAK=bVC9EfdXVPj3b+mhjzsDyiYjOEwQEH+jQ49KcFbO4PkV=YA@mail.gmail.com>
From: Ulrich Herberg <ulrich@herberg.name>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
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
Cc: gen-art@ietf.org, manet@ietf.org, sratliff@cisco.com
Subject: Re: [Gen-art] [manet] review: draft-ietf-manet-nhdp-mib-12
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=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 <jmh@joelhalpern.com>
Date: Fri, Apr 6, 2012 at 8:59 AM
Subject: [manet] [Gen-art] review: draft-ietf-manet-nhdp-mib-12
To: gen-art@ietf.org
Cc: manet@ietf.org, "A. Jean Mahoney" <mahoney@nostrum.com>om>,
sratliff@cisco.com


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