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>, 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
- [Gen-art] A *new* batch of IETF LC reviews - 2012… A. Jean Mahoney
- [Gen-art] review: draft-ietf-manet-nhdp-mib-12 Joel M. Halpern
- Re: [Gen-art] [manet] review: draft-ietf-manet-nh… Ulrich Herberg
- Re: [Gen-art] [manet] review: draft-ietf-manet-nh… Joel M. Halpern
- Re: [Gen-art] Fwd: [manet] review: draft-ietf-man… Robert G Cole
- [Gen-art] review: draft-ietf-manet-nhdp-mib-13 Joel M. Halpern