[MIB-DOCTORS] FW: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED)
"Cole, Robert G CIV USARMY CERDEC (US)" <robert.g.cole.civ@mail.mil> Wed, 13 June 2012 18:35 UTC
Return-Path: <robert.g.cole.civ@mail.mil>
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2AC11E8087 for <mib-doctors@ietfa.amsl.com>; Wed, 13 Jun 2012 11:35:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.767
X-Spam-Level:
X-Spam-Status: No, score=0.767 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6]
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 alQeLDwpkRaR for <mib-doctors@ietfa.amsl.com>; Wed, 13 Jun 2012 11:35:22 -0700 (PDT)
Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.6]) by ietfa.amsl.com (Postfix) with ESMTP id 934BE11E8083 for <mib-doctors@ietf.org>; Wed, 13 Jun 2012 11:35:19 -0700 (PDT)
Received: from UCOLHP3H.easf.csd.disa.mil (131.64.100.149) by UCOLHP4Z.easf.csd.disa.mil (131.64.100.6) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 13 Jun 2012 18:35:08 +0000
Received: from UCOLHP4J.easf.csd.disa.mil ([169.254.8.107]) by UCOLHP3H.easf.csd.disa.mil ([131.64.100.149]) with mapi id 14.02.0283.003; Wed, 13 Jun 2012 18:35:07 +0000
From: "Cole, Robert G CIV USARMY CERDEC (US)" <robert.g.cole.civ@mail.mil>
To: "'MIB Doctors (E-mail)'" <mib-doctors@ietf.org>, Thomas Nadeau <tnadeau@juniper.net>
Thread-Topic: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED)
Thread-Index: Ac1EcXKJSTnPFQ2MTQ6r8Xl0rB1SRAATYRUAATFut1AAA48u0A==
Date: Wed, 13 Jun 2012 18:35:05 +0000
Message-ID: <B9468E58D6A0A84AAD66FE4E694BEABB49D1C3A1@ucolhp4j.easf.csd.disa.mil>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [131.64.77.7]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0F4A_01CD4971.B7AB95A0"
MIME-Version: 1.0
Cc: Ulrich Herberg <ulrich@herberg.name>
Subject: [MIB-DOCTORS] FW: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED)
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: MIB Doctors list <mib-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mib-doctors>
List-Post: <mailto:mib-doctors@ietf.org>
List-Help: <mailto:mib-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jun 2012 18:35:23 -0000
Classification: UNCLASSIFIED Caveats: NONE Tom, MIB-Doctor's. We are looking for some guidance on one of the comments on the NHDP-MIB below, specifically issue #6. Please see below. Thanks, Bob -----Original Message----- From: Cole, Robert G CIV USARMY CERDEC (US) Sent: Wednesday, June 13, 2012 12:53 PM To: 'Benoit Claise'; adrian@olddog.co.uk Cc: 'The IESG'; manet-chairs@tools.ietf.org; draft-ietf-manet-nhdp-mib@tools.ietf.org; 'Ulrich Herberg' Subject: RE: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED) Classification: UNCLASSIFIED Caveats: NONE Benoit, I am struggling with your comments on the nhdpInterfaceTable (item #6 below). I give two alternatives (please read way below). a) I understand that this could be constructed as an AUGMENTS to the IF-MIB ifTable. E.g., (although the use of the nhdpIfRowStatus here does not seem right) " nhdpInterfaceEntry OBJECT-TYPE SYNTAX NhdpInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "nhdpInterfaceEntry describes one NHDP local interface configuration. It is constructed as an AUGMENTS to the Standard MIB II Interface Table (RFC2863)." AUGMENTS { ifIndex } ::= { nhdpInterfaceTable 1 } NhdpInterfaceEntry ::= SEQUENCE { nhdpIfStatus TruthValue, nhdpHelloInterval Unsigned32, nhdpHelloMinInterval Unsigned32, nhdpRefreshInterval Unsigned32, nhdpLHoldTime Unsigned32, nhdpHHoldTime Unsigned32, nhdpHystAcceptQuality Float32TC, nhdpHystRejectQuality Float32TC, nhdpInitialQuality Float32TC, nhdpInitialPending TruthValue, nhdpHpMaxJitter Unsigned32, nhdpHtMaxJitter Unsigned32, nhdpIfRowStatus RowStatus } " b) Instead we chose to extend the ifTable through a common indexing. A precedence does exists to our approach, e.g., "ipv4InterfaceEntry OBJECT-TYPE SYNTAX Ipv4InterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing IPv4-specific information for a specific interface." INDEX { ipv4InterfaceIfIndex } ::= { ipv4InterfaceTable 1 }nhdpIfRowStatus Ipv4InterfaceEntry ::= SEQUENCE { ipv4InterfaceIfIndex InterfaceIndex, ipv4InterfaceReasmMaxSize Integer32, ipv4InterfaceEnableStatus INTEGER, ipv4InterfaceRetransmitTime Unsigned32 } ipv4InterfaceIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value that uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex." ::= { ipv4InterfaceEntry 1 } " What is your recommendation? Thanks, Bob Cole -----Original Message----- From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Thursday, June 07, 2012 11:05 AM To: adrian@olddog.co.uk Cc: 'The IESG'; manet-chairs@tools.ietf.org; draft-ietf-manet-nhdp-mib@tools.ietf.org Subject: Re: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) Hi Adrian, Hi Benoit, I'm going to be a bit sniffy here :-) - There is a clear DISCUSS coming from the MIB-doctor review. Please address it. Sorry, what is your Discuss? My Discuss is simply: improve the MIB module according to the MIB doctor Looking at the long list of open issues, copied for the IESG convenience below, I wrote "clear DISCUSS" General Comments ---------------- 1. I did not re-compile the MIB as I am assuming Bert's comments from compilation were sufficient. These comments are IN ADDITION to Bert's so please make fixes required from his comments too. 2. Please go through the objects in the module and look for uses of DISPLAY-STRING and UNITS where possible. There are numerous cases where it should have been used but wasn't. I did not point out every one, just the first one. 3. In general, you have not explicitly described what happens to rows in the tables where read-create objects exist. You must describe these behaviors. I have noted the first instance of this, but please check all tables. 4. The use of DisplayString in the MIB is quite prevalent. RFC4181 is very clear in stating that: Note 2. DisplayString does not support internationalized text. It MUST NOT be used for objects that are required to hold internationalized text (which is always the case if the object is intended for use by humans [RFC2277]). Designers SHOULD consider using SnmpAdminString, Utf8String, or LongUtf8String for such objects. 5. You need a DEFVAL for *every* read-create object. I have noted the first case, but there are LOTS of these in the module that need to be fixed. 6. There is some confusion about your ifTable interaction. You seem to want an EXTENDS relationship, but your modeling is one of AUGMENTS. That is, the index text describes two types of interfaces (without a proper ifType BTW), where you allow for the modeling of non-manet interfaces. What I think you want to do is have this relationship: ifEntry NhdpInterfaceEntry 1, ifType=mols 2, ifType=mpls 3, ifType=manet ---------> 3 4, ifType = manet ---------> 4 5, ifType = mpls That is, you do not have entries in the NhdpInterfaceEntry table for ifIndex-es 1, 2 and 5. 7. I think it is customary to include the full reference description in the REFERENCE clause. For example: "RFC 2863 - The Interfaces Group MIB, McCloghrie, K., and F. Kastenholtz, June 2000" There are a number of these in the document, but I have only noted the first one. Please go through the document and make these corrections, and please do it consistently. 8. When you use InetAddress, you are constraining it to 4 or 16. This is unusual. It is typical to just use the TC as-is. 9. I have found a number of tables that match this guidance. The easiest thing to do is create a StorageType object in each table and define its semantics. I have only noted one case of this, but there are a number of them. There either MUST be one columnar object with a SYNTAX value of StorageType [RFC2579] and a MAX-ACCESS value of read-create, or else the row object (table entry) DESCRIPTION clause MUST specify what happens to dynamically-created rows after an agent restart. 10. In the notifications section, there is ambiguous terminology like "significant number"; you need to define what you expect this means. In fact, there is a lot of examples for defining explicit MIB variables like nhdpNbrStateChangeThreshold that explicitly define this. This will help aid interoperability. All of the notifications suffer from this deficiency. 11. The notifications emitted here seem to be potentially of a high volume given that manet applications can include massive numbers of "mobile" devices. You really should include some limiting/throttling parameters as explicit MIB configuration values. I know that you have defined this in some of the description clauses, but this is not easily interoperable, especially if implementations really need to use smaller values. Also, the way things are written, it is possible for implementations to experience DoS attack on the device because it is forced to emit so many notifications that it overwhelms the CPU. The "bad packets" notification is a great example. 12. The nhdpIfState notification is potentially dangerous given how the IfTable relationship is currently defined above to be essentially a 1:1 match with the IfEntry. Imagine having to issue notifications constantly for IF state changes for every interface in the normal IF-MIB and then here? Also, what value does this notification add above/beyond the normal IfUp/Down notification if you define an ifType=manet as I suggested above? 13. The nhdpPacketSrcAddr notification has no limits or throttling. What if %100 of the packets sent to the device match this criteria? Do you issue a notification for every one? Could you please capture your Discuss in the data tracker so that it can be resolved in discussion with you. Ok. - While reading through the document, I've been really waiting for an applicability statement section. So, I think you are asking "Why would any application that is not using telnet and a CLI or directly attached to the node want to know any details about the topology learnt by the node?" Not really, basically, I'm asking a very simple question: how do you plan on managing an ad-hoc network? I might ask you what is the point of the IF-MIB? Why would any management application ever want to learn about the behavior of a network node using a standardised protocol? I don't understand this. A sentence [RFC6130] such as "if router A is able to exchange packets with router B, and router B is able to exchange packets with router C, this does not guarantee that router A and router C can exchange packets directly" got me thinking about the management and operational aspects. How do you plan on using this MIB module, taking into account that you're dealing with an ad-hoc network? I am not sure whether you asking - How will a TCP-based application work in a MANET? Yes. or - What information might you learn from a MANET node that implements NHDP? NHDP discovers neighbors. Neighbor relationships are not necessarily symmetric. They are hard to predict because they depend on physical placement of the nodes (and other conditions that affect wireless transmissions). Reading the information gathered using NHDP allows an external application to generate map of the topology. Reading statistics about the performance of the protocol allows an application to assess whether there is a misbehaving implementation and also whether the reported topology is likely to be accurate. This all seems rather "obvious". I guess a statement like this could be added to the document. I hope that this would mean that *every* MIB module that goes for publication from now on will be required to add similar explanation of why a MIB module is relevant. Note that the write-up mentions: "This document shepherd is not aware of existing implementations of this MIB although several implementers have indicated interest in the work." So the potential implementers should have some views on the following questions. I'm really after 3 different parts in the applicability statement (or call it use cases if you want to): configuration management, monitoring, and notification. And I have questions such as: * one static NMS or each MANET router configures/monitors his (newly attached) neighbor(s)? I think the question you are asking is about write-access. I think it is obvious from the module that the node can update the information that is reported by an application reading the module. So the question is why is so much write-access needed to so many objects in the module? That is something the authors/WG need to answer. Coming back to my basic question: how do you plan on managing an ad-hoc network? Do you want to have one static NMS monitoring the entire network, or do you want to have every router only monitoring his neighbors (*). * where are the notifications sent to? Hmmm? Why is this question any different for this module compared with any other module? Who consumes Notifications from other modules? In the case of (*) * Do you expect all MANET routers to always have connectivity to a static NMS? Why ever not? It is a routed IP network. If there is a management station present, it can connect. If the network becomes partitioned, well, this is the same problem as in any other network. You know, I started to find a couple of my points addressed in http://www.herberg.name/downloads/pubs/CNSM_10.pdf <blockedhttp://www.herberg.name/downloads/pubs/CNSM_10.pdf> Interestingly, in that paper (and you will recognize the author), there is the notion of proxy with the REPORT-MIB Sorry proxy or "Do you expect all MANET routers to always have connectivity to a static NMS?" * etc... Can't address that one :-) Obviously, monitoring, for example, is important in ad-hoc networks, but please let us know how you envision doing this. For example, right now, I see the term "appropriate SNMP management stations", and I have no clue what's "appropriate" in the management of an ad-hoc network. Frankly, I don't think we have a good answer to what "appropriate" means in any network. Again, I am not sure why a MANET is any different. But I agree that "appropriate" is a bad word and I should have let it through my review. Perhaps this is a Comment? Whether this is Comment or a Discuss is not relevant. Let's not try to see every single line in this DISCUSS as a small thing to fix... it seems to me that there is an elephant in the room. At this point in time, I believe that a conf. with the authors would be more beneficial Regards, Benoit. I see some other MANET MIB modules... * draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects for the Optimized Link State Routing Protocol * draft-ietf-manet-report-mib-02 Definition of Managed Objects for Performance Reporting * draft-ietf-manet-smf-mib-04 Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set However, this document is the first MANET MIB module to reach the IESG, so those operational questions are important. Agreed. The authors of those other documents are waiting on the review of this document to help them with their work. The MIB Doctor review was much anticipated. I agree that the answers to the questions you have raised are equally applicable to the other documents. I think the lessons learned about write access will be quickly applied to the other document. But I have some trouble understanding the value of the other questions - I just can't understand why a MANET is so dramatically different in your eyes. If this is expressed in a different document, let me know, and I can review it. There is no other document on the applicability of managing MANET devices. Along the same lines, 1. see Al Morton's review, part of the OPS-DIR General question: Is a lossy, mobile ad-hoc network compatible with SNMPv3? In other words, will the link performance information needed for troubleshooting really be available when it is needed most, and critical nodes may be unreachable? Sorry, I have not seen Al's review. It looks like his question is "is it possible to run an IP-based application over a MANET?" Answer: yes. 2. Read Ron's Bonica's Abstain Read and discussed with Ron in person. Presuming you agree this part of your Discuss is not actionable (or maybe the action is to read Ron's comment :o) COMMENT: ---------------------------------------------------------------------- - Abstract This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. Should this be "MANET router"? "MANET router" is used in RFC6130 Alternatively, I see in this document: "NHDP router" "router in a Mobile Ad Hoc Network (MANET)" Same remark for the introduction, which uses the same text. This can be cleaned up. - First occurence of NHDP must be expanded. It already is. Classification: UNCLASSIFIED Caveats: NONE Classification: UNCLASSIFIED Caveats: NONE
- [MIB-DOCTORS] FW: Benoit Claise's Discuss on draf… Cole, Robert G CIV USARMY CERDEC (US)
- Re: [MIB-DOCTORS] Benoit Claise's Discuss on draf… Thomas Nadeau
- Re: [MIB-DOCTORS] Benoit Claise's Discuss on draf… Cole, Robert G CIV USARMY CERDEC (US)
- Re: [MIB-DOCTORS] Benoit Claise's Discuss on draf… Thomas Nadeau
- Re: [MIB-DOCTORS] Benoit Claise's Discuss on draf… Cole, Robert G CIV USARMY CERDEC (US)
- Re: [MIB-DOCTORS] Benoit Claise's Discuss on draf… Thomas Nadeau
- Re: [MIB-DOCTORS] Benoit Claise's Discuss on draf… Cole, Robert G CIV USARMY CERDEC (US)
- Re: [MIB-DOCTORS] Benoit Claise's Discuss on draf… Cole, Robert G CIV USARMY CERDEC (US)
- Re: [MIB-DOCTORS] Benoit Claise's Discuss on draf… Thomas Nadeau
- Re: [MIB-DOCTORS] Benoit Claise's Discuss on draf… Cole, Robert G CIV USARMY CERDEC (US)