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 <[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> 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 mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
