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

Robert G Cole <rgcole01@comcast.net> Sun, 06 May 2012 14:41 UTC

Return-Path: <rgcole01@comcast.net>
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 898A621F8491 for <gen-art@ietfa.amsl.com>; Sun, 6 May 2012 07:41:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Yqf0wzBz8OGp for <gen-art@ietfa.amsl.com>; Sun, 6 May 2012 07:41:14 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6489721F846F for <gen-art@ietf.org>; Sun, 6 May 2012 07:41:14 -0700 (PDT)
Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta10.westchester.pa.mail.comcast.net with comcast id 6ePk1j0010EZKEL5AehEYa; Sun, 06 May 2012 14:41:14 +0000
Received: from [10.0.1.195] ([68.55.94.27]) by omta01.westchester.pa.mail.comcast.net with comcast id 6ehE1j0080bRkG43MehExu; Sun, 06 May 2012 14:41:14 +0000
From: Robert G Cole <rgcole01@comcast.net>
To: jmh@joelhalpern.com
In-Reply-To: <CAK=bVC-oB-7uwGw4TWJYO0YD4xbV-RjGSq90G2EU=agbMBLQXg@mail.gmail.com>
References: <4F7E279C.3030707@nostrum.com> <4F7F12CA.9010009@joelhalpern.com> <CAK=bVC-oB-7uwGw4TWJYO0YD4xbV-RjGSq90G2EU=agbMBLQXg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Sun, 06 May 2012 10:41:11 -0400
Message-ID: <1336315271.2040.6.camel@chapman>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Sun, 06 May 2012 08:33:00 -0700
Cc: robert.g.cole@us.army.mil, gen-art@ietf.org, manet@ietf.org, Ulrich Herberg <ulrich@herberg.name>, sratliff@cisco.com
Subject: Re: [Gen-art] Fwd: [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: Sun, 06 May 2012 14:41:16 -0000

Joel,

Ulrich and I have updated the NHDP-MIB module to address your questions
and suggestions.  We hope these changes are satisfactory?

Thanks,

Bob and Ulrich

----- Original Message -----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Sunday, May 06, 2012 02:29 PM
To: manet-chairs@tools.ietf.org <manet-chairs@tools.ietf.org>rg>;
draft-ietf-manet-nhdp-mib@tools.ietf.org <draft-ietf-manet-nhdp-mib@tools.ietf.org>rg>; adrian@olddog.co.uk <adrian@olddog.co.uk>
Subject: New Version Notification - draft-ietf-manet-nhdp-mib-13.txt

New version (-13) has been submitted for
draft-ietf-manet-nhdp-mib-13.txt:
http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-mib-13.txt

Sub state has been changed to AD Followup from Revised ID Needed


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/

Diff from previous version:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-manet-nhdp-mib-13

IETF Secretariat.


On Mon, 2012-04-23 at 11:14 -0700, Ulrich Herberg wrote:



> Dear Joel,
> 
> thank you very much for your review. 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>
> [To Bob: I am not so sure if the below is correct. Can you check?]
> Yes, we agree. How about adding the following sentence at the end of
> the paragraph of 5.1.3.1:
> "The suppression window for notifications is started by Interface Up."
> </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>
> [To Bob: It is true that we actually don't use the derived objects. I
> am not quite sure what to do about it. Shall we remove the derived
> objects?
> </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>
> [To Bob: Do we have such object? I am not sure... does OSPF-MIB have
> one?]
> </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: 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>
> [To Bob: I am not sure if we need this. I suggest to refer to the MIB
> Doctor review; if they request it, it should be easy to copy the text]
> </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>
> [To Bob: That's true. I can 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>
> [To Bob: I can look at the descriptions and copy some more text from
> NHDP. However, I 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>
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
> 
> 
>