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: [email protected] [mailto:[email protected]] Sent: Sunday, May 06, 2012 02:29 PM To: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> 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 <[email protected]> > Date: Fri, Apr 6, 2012 at 8:59 AM > Subject: [manet] [Gen-art] review: draft-ietf-manet-nhdp-mib-12 > To: [email protected] > Cc: [email protected], "A. Jean Mahoney" <[email protected]>, > [email protected] > > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/manet > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
