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

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 27 April 2012 18:03 UTC

Return-Path: <jmh@joelhalpern.com>
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 9314521F86F5; Fri, 27 Apr 2012 11:03:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.372
X-Spam-Level:
X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, NORMAL_HTTP_TO_IP=0.001, USER_IN_WHITELIST=-100]
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 TjBFTpNEdj4B; Fri, 27 Apr 2012 11:03:25 -0700 (PDT)
Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id E2BFA21F86E8; Fri, 27 Apr 2012 11:03:25 -0700 (PDT)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id CEB795580DD; Fri, 27 Apr 2012 11:03:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 9CC521BCE071; Fri, 27 Apr 2012 11:03:25 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from [10.10.10.100] (pool-71-161-51-182.clppva.btas.verizon.net [71.161.51.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 378DF1BCE06F; Fri, 27 Apr 2012 11:03:24 -0700 (PDT)
Message-ID: <4F9ADF8B.804@joelhalpern.com>
Date: Fri, 27 Apr 2012 14:03:55 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0
MIME-Version: 1.0
To: Ulrich Herberg <ulrich@herberg.name>
References: <4F7E279C.3030707@nostrum.com> <4F7F12CA.9010009@joelhalpern.com> <CAK=bVC9EfdXVPj3b+mhjzsDyiYjOEwQEH+jQ49KcFbO4PkV=YA@mail.gmail.com>
In-Reply-To: <CAK=bVC9EfdXVPj3b+mhjzsDyiYjOEwQEH+jQ49KcFbO4PkV=YA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 18:03:26 -0000

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 <jmh@joelhalpern.com <mailto: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 <mailto:gen-art@ietf.org>
> Cc: manet@ietf.org <mailto:manet@ietf.org>, "A. Jean Mahoney"
> <mahoney@nostrum.com <mailto:mahoney@nostrum.com>>,
> sratliff@cisco.com <mailto: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 <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