From bclaise@cisco.com Fri Jun 1 05:34:42 2012 Return-Path: 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 E60AA11E848D; Fri, 1 Jun 2012 05:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.509 X-Spam-Level: X-Spam-Status: No, score=-10.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 KK2dd3tjWlpT; Fri, 1 Jun 2012 05:34:41 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEDE11E8474; Fri, 1 Jun 2012 05:34:41 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q51CYeMu004787; Fri, 1 Jun 2012 14:34:40 +0200 (CEST) Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q51CYdZl027965; Fri, 1 Jun 2012 14:34:40 +0200 (CEST) Message-ID: <4FC8B6DF.4080407@cisco.com> Date: Fri, 01 Jun 2012 14:34:39 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: aaa-doctors@ietf.org, "MIB Doctors (E-mail)" , YANG Doctors , ops-dir@ietf.org, IETF DNS Directorate References: <20120531225226.25947.56446.idtracker@ietfa.amsl.com> In-Reply-To: <20120531225226.25947.56446.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120531225226.25947.56446.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [MIB-DOCTORS] Fwd: PRELIMINARY Agenda and Package for the June 7, 2012 IESG Teleconference X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 12:34:43 -0000 Dear all, Please find below the preliminary agenda of the June 7th IESG telechat. Please send your questions, comments and concerns before June 6th COB. Thanks and Regards, Ron and Benoit. -------- Original Message -------- 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-dccp-udpencap-10 Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP) (Proposed Standard) Note: Pasi Sarolahti (pasi.sarolahti@iki.fi) is the document shepherd. Token: Wesley Eddy o draft-ietf-dane-protocol-21 The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA (Proposed Standard) Note: Warren Kumari (warren@kumari.net) is acting as the Document Shepherd. Token: Stephen Farrell o draft-ietf-codec-opus-14 Definition of the Opus Audio Codec (Proposed Standard) Note: Jonathan Rosenberg (jdrosen@jdrosen.net) is the document shepherd. Token: Robert Sparks o draft-ietf-mpls-ldp-gtsm-07 The Generalized TTL Security Mechanism (GTSM) for Label Distribution Protocol (LDP) (Proposed Standard) Note: Loa Andersson is the document shepherd (loa@pi.nu). Token: Adrian Farrel o draft-ietf-trill-rbridge-bfd-05 TRILL: Bidirectional Forwarding Detection (BFD) Support (Proposed Standard) Note: Erik Nordmark (nordmark@acm.org) is the document shepherd. Token: Ralph Droms o draft-ietf-dnsext-dnssec-bis-updates-18 Clarifications and Implementation Notes for DNSSECbis (Proposed Standard) Note: Andrew Sullivan (ajs@anvilwalrusden.com) is the document shepherd. Token: Ralph Droms o draft-ietf-trill-rbridge-extension-04 TRILL: Header Extension (Proposed Standard) Note: Erik Nordmark (nordmark@acm.org) is the document shepherd. Token: Ralph Droms o draft-ietf-mile-iodef-xmlreg-01 Expert Review for IODEF Extensions in IANA XML Registry (Proposed Standard) Note: Kathleen Moriarty (Kathleen.Moriarty@emc.com) is the document shepherd. Token: Sean Turner 2.1.2 Returning Items o draft-ietf-manet-nhdp-mib-13 Definition of Managed Objects for the Neighborhood Discovery Protocol (Proposed Standard) Note: Stan Ratliff (sratliff@cisco.com) is the document shepherd. Token: Adrian Farrel Was deferred by Benoit Claise on 2012-05-21 o draft-ietf-appsawg-about-uri-scheme-05 The "about" URI Scheme (Proposed Standard) Note: Jiankang Yao (yaojk@cnnic.cn) is the Document Shepherd. Token: Barry Leiba 2.2 Individual Submissions 2.2.1 New Items NONE 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-tcpm-tcpmss-04 TCP Options and MSS (Informational) Note: The Document Shepherd is Michael Scharf (michael.scharf@alcatel-lucent.com). Token: Wesley Eddy o draft-ietf-mile-template-04 Guidelines for Defining Extensions to IODEF (Informational) Note: Kathleen Moriarty (Kathleen.Moriarty@emc.com) is the document shepherd. Token: Sean Turner 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items NONE 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items o draft-irtf-rrg-ilnp-arp-06 ARP Extension for ILNPv4 (Experimental) Note: Tony Li (tony.li@tony.li) is the document shepherd. Token: Ralph Droms 3.3.2 Returning Items o draft-irtf-rrg-ilnp-v4opts-05 IPv4 Options for ILNPv4 (Experimental) Note: Tony Li (tony.li@tony.li) is the document shepherd. Token: Ralph Droms Was deferred by Ralph Droms on 2012-05-24 o draft-irtf-rrg-ilnp-icmpv4-05 ICMP Locator Update message for ILNPv4 (Experimental) Note: Tony Li (tony.li@tony.li) is the document shepherd. Token: Ralph Droms Was deferred by Ralph Droms on 2012-05-24 3.3.3 For Action o draft-hotz-kx509-04 KX509 Kerberized Certificate Issuance Protocol (Informational) Token: Stephen Farrell 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o IMAP MOVE extension (imapmove) Token: Barry Leiba 4.1.2 Proposed for Approval o System for Cross-domain Identity Management (scim) Token: Barry Leiba 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review o TCP Maintenance and Minor Extensions (tcpm) Token: Wesley Eddy 4.2.2 Proposed for Approval o Behavior Engineering for Hindrance Avoidance (behave) Token: Wesley Eddy o Network File System Version 4 (nfsv4) Token: Martin Stiemerling o Multipath TCP (mptcp) Token: Wesley Eddy From simon.perreault@viagenie.ca Thu May 31 12:45:57 2012 Return-Path: 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 C00E111E80AD for ; Thu, 31 May 2012 12:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 smU-dIefwbHk for ; Thu, 31 May 2012 12:45:57 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 4779711E808C for ; Thu, 31 May 2012 12:45:57 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:d124:e508:53bd:2021]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 55EC540032; Thu, 31 May 2012 15:45:56 -0400 (EDT) Message-ID: <4FC7CA73.8010701@viagenie.ca> Date: Thu, 31 May 2012 15:45:55 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: mib-doctors@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 01 Jun 2012 08:14:10 -0700 Cc: Marc Blanchet , "Senthil Sivakumar \(ssenthil\)" , Tina Zouting Subject: [MIB-DOCTORS] Questions for the new NAT MIB X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 19:45:57 -0000 Doctors, Here are two questions related to draft-ietf-behave-nat-mib: 1. We are wondering how to support multiple NATs (possibly with overlapping address space) using a single SNMP agent. In our readings we stumbled upon SNMPv3 contexts. Dave Thaler also pointed us toward the Entity MIB. It's fairly complex stuff but we feel like the end result will be just a few lines of text in our draft. So far we were thinking of something along the lines of: SNMPv3 supports "Contexts" that can be used to implement MIB views on multiple NAT instances on the same system. See [RFC3411] or its successors for details. (Stolen from the OSPFv3 MIB [RFC5643].) Is this sufficient? Do we need to say anything about the Entity MIB? 2. We want NAT operators to be able to graph the rate of mapping creations and removals. We already provide absolute counters of mapping creations and removals. We're envisaging to simply rely on the polling station to compute its own derivative. It looks like it is common practice. Is it the right thing to do? Will accuracy be compromised or will inaccuracies just average out over time? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From j.schoenwaelder@jacobs-university.de Fri Jun 1 09:38:46 2012 Return-Path: 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 4B0B011E80C4 for ; Fri, 1 Jun 2012 09:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 gVuA0dVnaoeZ for ; Fri, 1 Jun 2012 09:38:37 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3B15311E8074 for ; Fri, 1 Jun 2012 09:38:37 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B32920BE0; Fri, 1 Jun 2012 18:38:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BfvfFWZdVdLg; Fri, 1 Jun 2012 18:38:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F85320BE3; Fri, 1 Jun 2012 18:38:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 239741F32C52; Fri, 1 Jun 2012 18:38:34 +0200 (CEST) Date: Fri, 1 Jun 2012 18:38:34 +0200 From: Juergen Schoenwaelder To: Simon Perreault Message-ID: <20120601163834.GB6271@elstar.local> Mail-Followup-To: Simon Perreault , mib-doctors@ietf.org, Marc Blanchet , "Senthil Sivakumar (ssenthil)" , Tina Zouting References: <4FC7CA73.8010701@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FC7CA73.8010701@viagenie.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mib-doctors@ietf.org, "Senthil Sivakumar \(ssenthil\)" , Tina Zouting , Marc Blanchet Subject: Re: [MIB-DOCTORS] Questions for the new NAT MIB X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 16:38:46 -0000 On Thu, May 31, 2012 at 03:45:55PM -0400, Simon Perreault wrote: > Doctors, > > Here are two questions related to draft-ietf-behave-nat-mib: > > > 1. We are wondering how to support multiple NATs (possibly with > overlapping address space) using a single SNMP agent. In our > readings we stumbled upon SNMPv3 contexts. Dave Thaler also pointed > us toward the Entity MIB. It's fairly complex stuff but we feel like > the end result will be just a few lines of text in our draft. So far > we were thinking of something along the lines of: > > SNMPv3 supports "Contexts" that can be used to implement MIB views on > multiple NAT instances on the same system. See [RFC3411] or its > successors for details. > > (Stolen from the OSPFv3 MIB [RFC5643].) > > Is this sufficient? Do we need to say anything about the Entity MIB? Not really sure what "multiple NATs" really means to you or me or anybody else. Concerning usage of context and the ENTITY-MIB, it would be good to specify what entLogicalType would contain for a NAT. Perhaps also something would need to be said for entAliasMappingIdentifier. > 2. We want NAT operators to be able to graph the rate of mapping > creations and removals. We already provide absolute counters of > mapping creations and removals. We're envisaging to simply rely on > the polling station to compute its own derivative. It looks like it > is common practice. Is it the right thing to do? Yes. > Will accuracy be compromised or will inaccuracies just average out > over time? I am not sure why there would be an accuracy problem. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Fri Jun 1 11:23:27 2012 Return-Path: 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 DC13711E80A2 for ; Fri, 1 Jun 2012 11:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.227 X-Spam-Level: X-Spam-Status: No, score=-102.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 F0TFbjJQbgoQ for ; Fri, 1 Jun 2012 11:23:27 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 428F611E80A0 for ; Fri, 1 Jun 2012 11:23:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=UZH+9nWq9BVNMDc0zhI01v/A+RKxGxeJhymp+9PuoSSj8V+7qFAdu0hzMyzDFFQ2; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:x-mimeole:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.51.237] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SaVYH-0000UT-L1; Fri, 01 Jun 2012 13:22:17 -0400 Message-ID: <004801cd401b$80465500$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "Simon Perreault" , References: <4FC7CA73.8010701@viagenie.ca> Date: Fri, 1 Jun 2012 10:25:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882951211ce6890f8873297804f4f202b1ad786f4544585de1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.51.237 Cc: Marc Blanchet , "Senthil Sivakumar \(ssenthil\)" , Tina Zouting Subject: Re: [MIB-DOCTORS] Questions for the new NAT MIB X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 18:23:28 -0000 Hi - > From: "Simon Perreault" > To: > Cc: "Marc Blanchet" ; "Senthil Sivakumar (ssenthil)" ; "Tina Zouting" > Sent: Thursday, May 31, 2012 12:45 PM > Subject: [MIB-DOCTORS] Questions for the new NAT MIB ... > 1. We are wondering how to support multiple NATs (possibly with > overlapping address space) using a single SNMP agent. In our readings we > stumbled upon SNMPv3 contexts. Dave Thaler also pointed us toward the > Entity MIB. It's fairly complex stuff but we feel like the end result > will be just a few lines of text in our draft. So far we were thinking > of something along the lines of: > > SNMPv3 supports "Contexts" that can be used to implement MIB views on > multiple NAT instances on the same system. See [RFC3411] or its > successors for details. > > (Stolen from the OSPFv3 MIB [RFC5643].) > > Is this sufficient? Do we need to say anything about the Entity MIB? Consider whether you'd have any reason to support use cases in which information belonging to two or more NAT instances would need to be carried in a single request, or which would also need to carry information belonging to any other component of the system (e.g. protocol status or counters). Contexts generally don't work well for those use cases, and you'd probably be better of with an index structure in which one of the indices (probably the first one) serves to distinguish the NAT instance. Randy From chelliot@gmail.com Fri Jun 1 15:26:34 2012 Return-Path: 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 2327711E8097 for ; Fri, 1 Jun 2012 15:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 DJS0zu4mi0lX for ; Fri, 1 Jun 2012 15:26:33 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C873711E8081 for ; Fri, 1 Jun 2012 15:26:32 -0700 (PDT) Received: by eekd4 with SMTP id d4so1125356eek.31 for ; Fri, 01 Jun 2012 15:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=icPs161JTWVzdrggjcJJ9plBp1TkhXajnU/rYuLxtOE=; b=y3VS+zXjhlRtl55dOSiRgOu0jgbaET9WXArH05Sokh8GUTxpmM7o4//9fMf9JFMbh3 tn3RI/l/w9ACpbxAkUFNh/2XmPj5Syxnzp6dHltN0zDCyA1erPSUOjJfvEaPOmDTPjzV 8rmLneKWPguQGERpYKJIhFQXcjpekl4auZIre74Fe3dj06nkyz71f4t2L+g5QUberGj0 +scygLXHKY4/yyzzLkedZm9U2dc9+y6NcAFSinFoGRhVK98+ODCsNMPm8GP1BdEhhDh2 r1f/UeRn9416R2Pze5kT/NrnfLlc9rn54m15piSTOvSsA31Rjc36le3dmz0WffbOU8Kb aTBA== Received: by 10.14.40.3 with SMTP id e3mr2245594eeb.27.1338589591739; Fri, 01 Jun 2012 15:26:31 -0700 (PDT) MIME-Version: 1.0 Sender: chelliot@gmail.com Received: by 10.14.126.5 with HTTP; Fri, 1 Jun 2012 15:26:11 -0700 (PDT) In-Reply-To: <20120601163834.GB6271@elstar.local> References: <4FC7CA73.8010701@viagenie.ca> <20120601163834.GB6271@elstar.local> From: Chris Elliott Date: Fri, 1 Jun 2012 18:26:11 -0400 X-Google-Sender-Auth: zgIrb-ujjfkJtV1njokZbIF_BSA Message-ID: To: Juergen Schoenwaelder , Simon Perreault , mib-doctors@ietf.org, Marc Blanchet , "Senthil Sivakumar (ssenthil)" , Tina Zouting Content-Type: multipart/alternative; boundary=bcaec52be4d31d9e0b04c170adf5 Subject: Re: [MIB-DOCTORS] Questions for the new NAT MIB X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: chelliot@pobox.com List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 22:26:34 -0000 --bcaec52be4d31d9e0b04c170adf5 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 1, 2012 at 12:38 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, May 31, 2012 at 03:45:55PM -0400, Simon Perreault wrote: > > Doctors, > > > > Here are two questions related to draft-ietf-behave-nat-mib: > > > > > > 1. We are wondering how to support multiple NATs (possibly with > > overlapping address space) using a single SNMP agent. In our > > readings we stumbled upon SNMPv3 contexts. Dave Thaler also pointed > > us toward the Entity MIB. It's fairly complex stuff but we feel like > > the end result will be just a few lines of text in our draft. So far > > we were thinking of something along the lines of: > > > > SNMPv3 supports "Contexts" that can be used to implement MIB views on > > multiple NAT instances on the same system. See [RFC3411] or its > > successors for details. > > > > (Stolen from the OSPFv3 MIB [RFC5643].) > > > > Is this sufficient? Do we need to say anything about the Entity MIB? > > Not really sure what "multiple NATs" really means to you or me or > anybody else. Concerning usage of context and the ENTITY-MIB, it would > be good to specify what entLogicalType would contain for a > NAT. Perhaps also something would need to be said for > entAliasMappingIdentifier. > > > 2. We want NAT operators to be able to graph the rate of mapping > > creations and removals. We already provide absolute counters of > > mapping creations and removals. We're envisaging to simply rely on > > the polling station to compute its own derivative. It looks like it > > is common practice. Is it the right thing to do? > > Yes. > > > Will accuracy be compromised or will inaccuracies just average out > > over time? > > I am not sure why there would be an accuracy problem. > Accuracy can be an issue for any number of reasons. The two most common reasons I've run into are polling more frequently than the server updates the counter (certain large switches from a certain large vendor updates their line card ifTable counters every 10 seconds, roughly) and variable delay in packet delivery. Not much to do on the first, but poll less frequently. On the second, if you request sysUpTime.0 in the same packet as the counter and use the time values returned to calculate the time delta then you can usually improve the accuracy of the rate calculation. Neither of these affects how the MIB should be written, however. Counters are the way to go for this type of data. Chris. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > -- Chris Elliott chelliot@pobox.com --bcaec52be4d31d9e0b04c170adf5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jun 1, 2012 at 12:38 PM, Juergen Schoenwaelder &l= t;j.schoenwaelder@jacobs-university.de> wrote:
On Thu, May 31, 2012 at 03= :45:55PM -0400, Simon Perreault wrote:
> Doctors,
>
> Here are two questions related to draft-ietf-behave-nat-mib:
>
>
> 1. We are wondering how to support multiple NATs (possibly with
> overlapping address space) using a single SNMP agent. In our
> readings we stumbled upon SNMPv3 contexts. Dave Thaler also pointed > us toward the Entity MIB. It's fairly complex stuff but we feel li= ke
> the end result will be just a few lines of text in our draft. So far > we were thinking of something along the lines of:
>
> =A0 =A0SNMPv3 supports "Contexts" that can be used to implem= ent MIB views on
> =A0 =A0multiple NAT instances on the same system. =A0See [RFC3411] or = its
> =A0 =A0successors for details.
>
> (Stolen from the OSPFv3 MIB [RFC5643].)
>
> Is this sufficient? Do we need to say anything about the Entity MIB?
Not really sure what "multiple NATs" really means to you or= me or
anybody else. Concerning usage of context and the ENTITY-MIB, it would
be good to specify what entLogicalType would contain for a
NAT. Perhaps also something would need to be said for
entAliasMappingIdentifier.

> 2. We want NAT operators to be able to graph the rate of mapping
> creations and removals. We already provide absolute counters of
> mapping creations and removals. We're envisaging to simply rely on=
> the polling station to compute its own derivative. It looks like it > is common practice. Is it the right thing to do?

Yes.

> Will accuracy be compromised or will inaccuracies just average out
> over time?

I am not sure why there would be an accuracy problem.

Accuracy can be an issue for any number of reasons. Th= e two most common reasons I've run into are polling more frequently tha= n the server updates the counter (certain large switches from a certain lar= ge vendor updates their line card ifTable counters every 10 seconds, roughl= y) and variable delay in packet delivery. Not much to do on the first, but = poll less frequently. On the second, if you request sysUpTime.0 in the same= packet as the counter and use the time values returned to calculate the ti= me delta then you can usually improve the accuracy of the rate calculation.=

Neither of these affects how the MIB should be written,= however. Counters are the way to go for this type of data.

<= /div>
Chris.
=A0

/js

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49= 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, Germany
Fax: =A0 += 49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/>
_____________________= __________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors



--
= Chris Elliott
chelliot@pobox.com

--bcaec52be4d31d9e0b04c170adf5-- From heard@pobox.com Sat Jun 2 10:06:10 2012 Return-Path: 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 27F2D21F85D3 for ; Sat, 2 Jun 2012 10:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] 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 EBaby+6nx1nC for ; Sat, 2 Jun 2012 10:06:09 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id D927021F85BE for ; Sat, 2 Jun 2012 10:06:07 -0700 (PDT) Received: (qmail 12543 invoked from network); 2 Jun 2012 10:06:05 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 2 Jun 2012 10:06:05 -0700 Date: Sat, 2 Jun 2012 10:06:05 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: "MIB Doctors (E-mail)" , Benoit Claise In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [MIB-DOCTORS] some advice to the new recruits X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 17:06:10 -0000 Greetings, Here are some comments from a long-retired MIB Doctor (who occasionally lurks but definitely should no longer be listed as a directorate member on the Mib Doctors web page). New recruits will definitely want to be familiar with RFC 4181 but need to be aware that much of the stuff dealing with the nut-and-bolts of how to construct a MIB **document** (as opposed to a MIB **module**) have been overtaken by events. That is most particularly the case for sections dealing with copyrights and IPR notices; and since RFC 4841 was just an update to the copyright notice, that document is likely completely useless now. Additionally, all the links in RFC 4181 that point to www.ops.ietf.org are now broken. I've been gone for long enough that I have no clue where the stuff that used to be there went to. The core of 4181 that I expect will remain useful is Section 4, SMIv2 Usage Guidelines (mudulo the broken links mentioned above). I emphatically agree that the mib-doctors mailing list archives are **not** a good resourse to help people learn how to write MIB modules. Those archives **might** be a resource for new recruits to see how we arrived at the decisions we made that are documented in Section 4 of RFC 4181 and, afterward, how we dealt with an obscure point not covered in the guidelines, but even for that the utility is likely to be rather limited. I did dive back into the archives on a few occasions, particularly when a controversy arose about something in 4181 that I thought had been settled and I wanted tp see if I could reconstruct the original reasoning. That exercise usually proved to be difficult even though I was one of the participants in the discussion. I expect that it would be even harder for someone who was not there. Also, be aware that prior to 2006-07-18 the list was hosted at psg.com, and those archives are stored here: http://www.psg.com/lists/mreview/ I emphatically agree with dbh's suggestion below to make all MIB reviews public and **easily accessible**. When I was in the business I almost always posted my reviews to the appropriate WG mailing list, which made them public, but I would be hard pressed to locate those reviews now (I can't even remember most of them). Finally, here one thing at the top of my list to say to new recruits: my experience was that the most painful reviews were those where there was lots of minor stuff wrong. Don't be afraid to politely but firmly return such documents/modules to the authors stating that you need for them to look at the guidelines and SMI documents and make an effort to fix up those minor things before they use up **your** limited time. Do this quickly before investing a lot of time in a thorough review. All too often I did not follow this advice and paid dearly in wasted time and frustration. Mike Heard On Fri, 25 May 2012, David Harrington wrote: > Hi, > > I don't agree this would be a good archive for people wanting to learn to > write a MIB. > > This email list is for MIB Doctors. > The discussion tends to be about reaching agreement amongst the MIB > Doctors on some esoteric point. > This is where MIB Doctors go when they need help finding/interpreting the > rules (such as the maximum value of a PEN). > This is where MIB Doctors go if they don't like a design choice in a MIB > module and want to know if other MIB Doctors agree, or to get alternate > design suggestions. > A person trying to learn to write a MIB will be totally lost and confused > by these discussions. > I think making the MIB reviews public could be a learning experience, but > readers would need to sift through a lot of irrelevant stuff to find > relevant nuggets. RFC4181 already gives them most of the nuggets we'll > find in a MIB Doctor review. > A MIB Doctor wiki might be a good way to capture additional nuggets from > new reviews. > Compare, for example, > http://trac.tools.ietf.org/area/app/trac/wiki/TypicalAppsAreaIssues, and > http://trac.tools.ietf.org/area/tsv/trac/wiki/tsvdir-common-issues. > > > > The mibs@ietf.org might be a better archive to check. > This is where people writing a MIB are encouraged to seek help, so the > focus is on advising MIB writers. > But it does tend to be about solving problems MIB writers run into, rather > than a from-scratch tutorial on how to write a MIB. > > > Offering a Sunday tutorial on MIB writing, and/or producing a > MIB-Doctor-written design guide would be far more helpful. > Templates for writing MIB documents are already available on the tools > page and from the RFC Editor. > We've had quite a few discussions of a design guide (for things like table > normalization, persistence, etc.) but haven't reached a point where > somebody was willing to volunteer to hold the pen. > A MIB design wiki might be a good way to start such a design guide, > without demanding dedicated authorship from a MIB Doctor. > > > There are multiple books available on MIBs; I find Dave Perkins' book > "Understanding SNMP MIBs" most useful as a MIB Doctor (available on > Amazon). > > From loa@pi.nu Sat Jun 2 19:16:27 2012 Return-Path: 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 032BC11E8073; Sat, 2 Jun 2012 19:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135, 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 JoAdWVC8Oj6O; Sat, 2 Jun 2012 19:16:26 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6DD21F845A; Sat, 2 Jun 2012 19:16:25 -0700 (PDT) Received: from [172.16.36.55] (unknown [122.146.68.192]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id B24E12A8002; Sun, 3 Jun 2012 04:16:17 +0200 (CEST) Message-ID: <4FCAC8F6.8060200@pi.nu> Date: Sun, 03 Jun 2012 04:16:22 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Thomas Nadeau , "aldrin.ietf@gmail.com" , "venkat.mahalingams@gmail.com" , Kannan KV Sampath , Sami Boutros , "ppan@infinera.com" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 02 Jun 2012 22:24:54 -0700 Cc: Swallow George , "mpls@ietf.org" , "MIB Doctors \(E-mail\)" , Ross Callon , Martin Vigoureux Subject: Re: [MIB-DOCTORS] Review for WG Adoption of draft-vkst-mpls-tp-oam-id-mib-02.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 02:16:27 -0000 Authors, The review by Joan was part of the MPLS RT review prior to polling the document to become a working group. Though updating the draft prior to the poll is strictly not necessary to start the poll. However I would strongly prefer to poll an updated document. Could you please update and republish. /Loa (as wg chair) On 2012-05-23 23:16, Thomas Nadeau wrote: > > Hi Joan! > > Thanks for the review. Comments inline start with TOM: > > On 5/23/12 11:30 AM, "Joan Cucchiara" wrote: > >> >> Hello Authors, >> >> Thank you for proposing this solution. >> Please see my notes below. >> >> Thank you, >> -Joan >> >> 1) Coherency of document: >> A) Is document useful and likely to be used/useful in operational >> networks? >> >> This document contains a MIB Module with 2 tables. The tables allow >> creation of >> TP IDs of MPLS LSPs and Pseudowires. Also a pointer to rows in >> other MIBs Modules., i.e. to an MPLS Tunnel in the MPLS-TE-STD-MIB >> (RFC3012) >> or >> pseudowire in the PWE-STD-MIB (RFC5601). Since many vendors and >> operators >> support the MPLS-TE-STD-MIB and PW-STD-MIB, then one could agree with the >> authors that the architecture of this MIB is a viable approach. >> >> In other words, the authors are leveraging off of existing MIB >> implementations. >> They are doing this in a way which adheres to the rules of SMIv2 and I do >> think that the MIB is likely to be used/useful in operational networks. >> >> >> B) Is document technically sound? >> >> From a MIB perspective, no: >> >> I) Many objects are of type "DisplayString" which is used >> in SMIv1 but not in SMIv2. >> >> As the MIB Common TC doc specifies: >> >> https://svn.tools.ietf.org/area/ops/trac/wiki/mib-common-tcs >> >> >> "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." >> >> II) The term "Trap" is used in both the document and the MIB. >> This needs to be replaced by the term "Notification". Traps a mechanism >> in SNMPv1. Please see RFC3584. > > TOM: Ooops! We will fix this. > >> 2) Is document ready for WG adoption? >> >> I would ask that changes to remove DisplayString and use a TC which >> supports internationalization be done, and the term Trap removed >> prior to WG adoption for reasons stated above. >> >> This request should only take a few minutes of editing, but will bring >> the >> document upto SMIv2. > > TOM: Agree. There is no big issue fixing this. We will need to re-spin the > draft in a WG-approved format anyways, so we can fix this during those > edits. > >> >> Additionally, a few comments (mostly as fyi): >> >> I) this MIB contains configuration (read-create) objects. >> >> II) the document proposes to root the MIB under mplsStdMIB which was >> the convention for the set of MPLS MIBs in 2004 but guidelines have >> changed since then. >> >> III) The use of the accessible-for-notify and imports of >> IFMIB tables do not seem necessary in the MIB's current state. >> As the MIB is updated, this should be removed or clarified. > > TOM: Cool. > > --Tom > >> >> > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From venkat.mahalingams@gmail.com Sat Jun 2 21:13:30 2012 Return-Path: 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 32A5911E808A; Sat, 2 Jun 2012 21:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.464 X-Spam-Level: X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_OTHER=0.135] 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 20EpJgNUx-OM; Sat, 2 Jun 2012 21:13:29 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC0DC11E8088; Sat, 2 Jun 2012 21:13:28 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2206176vbb.31 for ; Sat, 02 Jun 2012 21:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jCJy8LpujX1EiPdLvhqXFaFYWFMEtF2dpvipJ8zk4cE=; b=shHvkktzp5nOr28rByAX+xj4LNZIuAiuI14aR3i9ven/md7fe06Irscga87AEarLFM PZjCwjNZSF2gpKAYbn6tFC6Gem1GsQQ0rBaYpcm8gqArTD9mxyx/hlV+007/e/cKWtjQ lzQoL/lQpdKd368Y3nPLP7fAIQKg28fKuvv9130QqmcJWocTgJeMuRSb+Z+bZ6qCgmmy njid2RdSHSnmHfPdqxV0OzLP3f0HL+/I4IFkH5E6bC/V/2/7djOHMh1Me+p7AP3IcH7U Tzd0f18X1B13S5loRteC2dsAGmfDAkCEDGLxmwgNrHxUaHfFeTsfHrDDsGRh0VuR/crE 9Gpg== MIME-Version: 1.0 Received: by 10.52.94.147 with SMTP id dc19mr7180112vdb.74.1338696808373; Sat, 02 Jun 2012 21:13:28 -0700 (PDT) Received: by 10.220.193.6 with HTTP; Sat, 2 Jun 2012 21:13:28 -0700 (PDT) In-Reply-To: <4FCAC8F6.8060200@pi.nu> References: <4FCAC8F6.8060200@pi.nu> Date: Sat, 2 Jun 2012 21:13:28 -0700 Message-ID: From: Venkatesan Mahalingam To: Loa Andersson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 02 Jun 2012 22:24:52 -0700 Cc: Swallow George , "mpls@ietf.org" , "ppan@infinera.com" , Sami Boutros , "aldrin.ietf@gmail.com" , Kannan KV Sampath , "MIB Doctors \(E-mail\)" , Ross Callon , Martin Vigoureux Subject: Re: [MIB-DOCTORS] Review for WG Adoption of draft-vkst-mpls-tp-oam-id-mib-02.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 04:13:30 -0000 Loa, > Could you please update and republish. Sure. We will address Joan's comments and republish the draft soon. Thanks, Venkat. On Sat, Jun 2, 2012 at 7:16 PM, Loa Andersson wrote: > Authors, > > The review by Joan was part of the MPLS RT review prior to polling the > document to become a working group. > > Though updating the draft prior to the poll is strictly not necessary > to start the poll. However I would strongly prefer to poll an updated > document. > > Could you please update and republish. > > /Loa > (as wg chair) > > > On 2012-05-23 23:16, Thomas Nadeau wrote: >> >> >> =A0 =A0 =A0 =A0Hi Joan! >> >> =A0 =A0 =A0 =A0Thanks for the review. Comments inline start with TOM: >> >> On 5/23/12 11:30 AM, "Joan Cucchiara" =A0wrot= e: >> >>> >>> Hello Authors, >>> >>> Thank you for proposing this solution. >>> Please see my notes below. >>> >>> Thank you, >>> =A0-Joan >>> >>> 1) Coherency of document: >>> A) Is document useful and likely to be used/useful in operational >>> networks? >>> >>> This document contains a MIB Module with 2 tables. =A0The tables allow >>> creation of >>> TP IDs of MPLS LSPs and Pseudowires. =A0 Also a pointer to rows in >>> other MIBs Modules., i.e. to an MPLS Tunnel in the MPLS-TE-STD-MIB >>> (RFC3012) >>> or >>> pseudowire in the PWE-STD-MIB (RFC5601). =A0 Since many vendors and >>> operators >>> support the MPLS-TE-STD-MIB and PW-STD-MIB, then one could agree with t= he >>> authors that the architecture of this MIB is a viable approach. >>> >>> In other words, the authors are leveraging off of existing MIB >>> implementations. >>> They are doing this in a way which adheres to the rules of SMIv2 and I = do >>> think that the MIB is likely to be used/useful in operational networks. >>> >>> >>> B) Is document technically sound? >>> >>> From a MIB perspective, no: >>> >>> I) Many objects are of type "DisplayString" which is used >>> in SMIv1 but not in SMIv2. >>> >>> As the MIB Common TC doc specifies: >>> >>> https://svn.tools.ietf.org/area/ops/trac/wiki/mib-common-tcs >>> >>> >>> =A0 "Note 2. =A0DisplayString does not support internationalized text. >>> =A0 =A0 =A0 =A0 =A0 =A0It MUST NOT be used for objects that are require= d to >>> =A0 =A0 =A0 =A0 =A0 =A0hold internationalized text (which is always the= case >>> =A0 =A0 =A0 =A0 =A0 =A0if the object is intended for use by humans [RFC= 2277]). >>> =A0 =A0 =A0 =A0 =A0 =A0Designers SHOULD consider using SnmpAdminString, >>> =A0 =A0 =A0 =A0 =A0 =A0Utf8String, or LongUtf8String for such objects." >>> >>> II) The term "Trap" is used in both the document and the MIB. >>> This needs to be replaced by the term "Notification". =A0Traps a mechan= ism >>> in SNMPv1. =A0 Please see RFC3584. >> >> >> TOM: Ooops! We will fix this. >> >>> 2) Is document ready for WG adoption? >>> >>> I would ask that changes to remove DisplayString and use a TC which >>> supports internationalization be done, and the term Trap removed >>> prior to WG adoption for reasons stated above. >>> >>> This request should only take a few minutes of editing, but will bring >>> the >>> document upto SMIv2. >> >> >> TOM: Agree. There is no big issue fixing this. We will need to re-spin t= he >> draft in a WG-approved format anyways, so we can fix this during those >> edits. >> >>> >>> Additionally, a few comments (mostly as fyi): >>> >>> I) this MIB contains configuration (read-create) objects. >>> >>> II) the document proposes to root the MIB under mplsStdMIB which was >>> the convention for the set of MPLS MIBs in 2004 but guidelines have >>> changed since then. >>> >>> III) The use of the accessible-for-notify and imports of >>> IFMIB tables do not seem necessary in the MIB's current state. >>> As the MIB is updated, this should be removed or clarified. >> >> >> TOM: Cool. >> >> =A0 =A0 =A0 =A0--Tom >> >>> >>> >> > > -- > > > Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.= andersson@ericsson.com > Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu > Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +4= 6 10 717 52 13 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +46 767 72 92 13 From jcucchiara@mindspring.com Sun Jun 3 23:16:02 2012 Return-Path: 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 8670421F8821; Sun, 3 Jun 2012 23:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[AWL=0.911, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 KpmCtKj--SIQ; Sun, 3 Jun 2012 23:16:01 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 171D021F881C; Sun, 3 Jun 2012 23:16:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=FnmTmjIjiw1ar5ZjCtZuY4c3Afm+3Nk7wfyEwZY+eWrXqXVQc44G9gBUTju9G6qe; h=Received:Message-ID:From:To:Cc:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.138] (helo=JoanPC) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SbQa7-0007OX-Jv; Mon, 04 Jun 2012 02:15:59 -0400 Message-ID: <0eb801cd4219$c9fc8e80$6701a8c0@JoanPC> From: "Joan Cucchiara" To: , , "Kannan KV Sampath" , , "Thomas Nadeau" Date: Mon, 4 Jun 2012 02:17:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654ba516fb0838684aed774e1c454f248d80cdf93a589ab4c3c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Cc: Swallow George , "MIB Doctors \(E-mail\)" , Ross Callon , Loa Andersson Subject: [MIB-DOCTORS] MIB Dr. Review: draft-ietf-mpls-tp-te-mib-03.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 06:16:02 -0000 Hello, This document is clearly written and the examples are great! Thanks for that! Review is divided into sections. General Comments are followed by specific sections. The MIB Modules were compiled by smiLint and results are in each MIB Modules' section. There are some warnings, but think these should be fixed. My major concern is contained in the General Comments section below. Thanks, -Joan General Comments ----------------- Major concern: I would like to express that I can see why the MIB Modules are designed as they are. Namely, so mplsTunnelTable (in rfc3812) can be used for MPLS-TP Tunnels also. I do see there is likely to be value in doing that. However, my concern is that the semantic definition of two indices for mplsTunnelTable (mplsTunnelIngressLSRId, mplsTunnelEgressLSRId) are being semantically redefined in the MPLS-TE-EXT-STD-MIB, and this breaks the rules of the SMI and there is a chance that legacy implementations could be jeopardized. The index being proposed is: mplsNodeConfigLocalId mplsNodeConfigLocalId OBJECT-TYPE SYNTAX MplsLocalId MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object allows the administrator to assign a unique local identifier to map Global_Node_ID or ICC." ::= { mplsNodeConfigEntry 1 } Where the TC MplsLocalId is: MplsLocalId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This textual convention is used in accommodating the bigger size Global_Node_ID and/or ICC with lower size LSR identifier in order to index the mplsTunnelTable. The Local Identifier is configured between 1 and 16777215, as valid IP address range starts from 16777216(01.00.00.00). This range is chosen to identify the mplsTunnelTable's Ingress/Egress LSR-id is IP address or Local identifier, if the configured range is not IP address, administrator is expected to retrieve the complete information (Global_Node_ID or ICC) from mplsNodeConfigTable. This way, existing mplsTunnelTable is reused for bidirectional tunnel extensions for MPLS based transport networks. This Local Identifier allows the administrator to assign a unique identifier to map Global_Node_ID and/or ICC." SYNTAX Unsigned32(1..16777215) The MPLS-TE-STD-MIB (rfc3812) and the MPLS-TC-STD-MIB (rfc3811) have described the MplsExtendedTunnelId as: MplsTunnelEntry ::= SEQUENCE { ..... mplsTunnelIngressLSRId MplsExtendedTunnelId, mplsTunnelEgressLSRId MplsExtendedTunnelId, mplsTunnelIngressLSRId OBJECT-TYPE SYNTAX MplsExtendedTunnelId MAX-ACCESS not-accessible STATUS current DESCRIPTION "Identity of the ingress LSR associated with this tunnel instance. When the MPLS signalling protocol is rsvp(2) this value SHOULD be equal to the Tunnel Sender Address in the Sender Template object and MAY be equal to the Extended Tunnel Id field in the SESSION object. When the MPLS signalling protocol is crldp(3) this value SHOULD be equal to the Ingress LSR Router ID field in the LSPID TLV object." REFERENCE "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, Awduche et al, RFC 3209, December 2001 2. Constraint-Based LSP Setup using LDP, Jamoussi (Editor), RFC 3212, January 2002" ::= { mplsTunnelEntry 3 } mplsTunnelEgressLSRId OBJECT-TYPE SYNTAX MplsExtendedTunnelId MAX-ACCESS not-accessible STATUS current DESCRIPTION "Identity of the egress LSR associated with this tunnel instance." ::= { mplsTunnelEntry 4 } The TC from MPLS-TC-STD-MIB (rfc3811) is: MplsExtendedTunnelId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A unique identifier for an MPLS Tunnel. This may represent an IPv4 address of the ingress or egress LSR for the tunnel. This value is derived from the Extended Tunnel Id in RSVP or the Ingress Router ID for CR-LDP." REFERENCE "RSVP-TE: Extensions to RSVP for LSP Tunnels, [RFC3209]. Constraint-Based LSP Setup using LDP, [RFC3212]." SYNTAX Unsigned32(0..4294967295) So, while I agree that mplsTunnelIngressLSRID and mplsTunnelEgressLSRId and mplsNodeConfigLocalId are all 32-bit values, the following 2 TCs are not semantically the same: MplsExtendedTunnelId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A unique identifier for an MPLS Tunnel. This may represent an IPv4 address of the ingress or egress LSR for the tunnel. This value is derived from the Extended Tunnel Id in RSVP or the Ingress Router ID for CR-LDP." REFERENCE "RSVP-TE: Extensions to RSVP for LSP Tunnels, [RFC3209]. Constraint-Based LSP Setup using LDP, [RFC3212]." SYNTAX Unsigned32(0..4294967295) MplsLocalId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This textual convention is used in accommodating the bigger size Global_Node_ID and/or ICC with lower size LSR identifier in order to index the mplsTunnelTable. The Local Identifier is configured between 1 and 16777215, as valid IP address range starts from 16777216(01.00.00.00). This range is chosen to identify the mplsTunnelTable's Ingress/Egress LSR-id is IP address or Local identifier, if the configured range is not IP address, administrator is expected to retrieve the complete information (Global_Node_ID or ICC) from mplsNodeConfigTable. This way, existing mplsTunnelTable is reused for bidirectional tunnel extensions for MPLS based transport networks. This Local Identifier allows the administrator to assign a unique identifier to map Global_Node_ID and/or ICC." SYNTAX Unsigned32(1..16777215) Therefore, I believe this is a semantic redefinition and could potentially cause issues for some legacy implementations. *) There were some warning generated by smiLint that should probably be fixed (please see individual MIB Modules discussion below.) *) MIB should be capitalized consistently. Sometimes mib is used, so please use capitals. *) There are 4 MIB Modules in this document which pertain to MPLS-TP. The proposal is to root them under mplsStdMIB. This has not been the convention for sometime. However, if the authors feel strongly about using mplsStdMIB, then please let me know. *) The word "traps" appears as a MIB comment in the MIB Modules. Please either remove the comment or use the notifications where appropriate. Traps are a SNMPv1 mechanism. *) MIB Guidelines suggest naming conventions to be used within a MIB Module (for tables, rows and objects within a row), This was not followed in these MIB Modules. As an example: MPLS-TE-EXT-STD-MIB has the following table names: mplsNodeConfigTable mplsNodeIpMapTable mplsNodeIccMapTable mplsTunnelExtTable This is also the case in the other MIB Module(s). Please take a look at Appendix C of the MIB Guidelines (rfc4181). Section 4. Motivations ---------------------- Awkward. Section doesn't specify motivations, expect something like, This document provides a MIB Module which supports configuration of .... and monitoring of ....etc. Section 7. MIB Module Interdependencies How is this possible, since MPLS-TE-STD-MIB was defined so long ago? .. - MPLS-TE-STD-MIB [RFC3812] contains references to objects in MPLS-ID-STD-MIB. MPLS-TC-EXT-STD-MIB ========================== *) The name of this MIB Module is misleading. The TCs defined are specific to MPLS-TP so could this name be more specific, for example, MPLS-TP-TC-STD-MIB ? *) These TCs should have references. They are originally defined elsewhere, so why aren't their references? *) MplsNodeId DESCRIPTION ...LSR's /32 IPv4 loopback address What is meant by /32 ? MPLS-ID-STD-MIB ========================= SMILINT ------- mibs/MPLS-ID-STD-MIB:70: [5] {identifier-external-case-match} warning: identifier `mplsGlobalId' differs from `MPLS-TC-EXT-STD-MIB::MplsGlobalId' only in case mibs/MPLS-TC-EXT-STD-MIB:61: [6] {previous-definition} info: previous definition of `MplsGlobalId' mibs/MPLS-ID-STD-MIB:94: [5] {identifier-external-case-match} warning: identifier `mplsNodeId' differs from `MPLS-TC-EXT-STD-MIB::MplsNodeId' only in case mibs/MPLS-TC-EXT-STD-MIB:88: [6] {previous-definition} info: previous definition of `MplsNodeId' mibs/MPLS-ID-STD-MIB:4: [5] {import-unused} warning: identifier `NOTIFICATION-TYPE' imported from module `SNMPv2-SMI' is never used mibs/MPLS-ID-STD-MIB:6: [5] {import-unused} warning: identifier `NOTIFICATION-GROUP' imported from module `SNMPv2-CONF' is never used MPLS-LSR-EXT-MIB =================== *) The name of this MIB Module is too broad because MIB Module is specific to MPLS-TP, so something like MPLS-TP-LSR-EXT-MIB would be more appropriate IMHO. *) Is mplsXCExtTunnelPointer supposed to be read-only? The DESCRIPTION seems to indicate read-create? (leads to following question regarding compliance stmts....) *) The FullCompliance and ReadOnlyCompliance are confusing. Why does the mplsXCExtTunnelPointer object appear in both? MPLS-TE-EXT-MIB =================== SMILINT mibs/MPLS-TE-EXT-STD-MIB:22: [4] {module-identity-registration} warning: uncontrolled IETF module identity registration mibs/MPLS-TE-EXT-STD-MIB:4: [5] {import-unused} warning: identifier `Unsigned32' imported from module `SNMPv2-SMI' is never used mibs/MPLS-TE-EXT-STD-MIB:5: [5] {import-unused} warning: identifier `Gauge32' imported from module `SNMPv2-SMI' is never used mibs/MPLS-TE-EXT-STD-MIB:5: [5] {import-unused} warning: identifier `NOTIFICATION-TYPE' imported from module `SNMPv2-SMI' is never used mibs/MPLS-TE-EXT-STD-MIB:9: [5] {import-unused} warning: identifier `NOTIFICATION-GROUP' imported from module `SNMPv2-CONF' is never used *) Warnings of severity [5] should be fixed. *) The name of this MIB Module is too broad also. MIB is specific to MPLS-TP and the name of the MIB Module should reflect that. One example is, MPLS-TP-TE-EXT-MIB. From tnadeau@juniper.net Mon Jun 4 09:17:46 2012 Return-Path: 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 07EC321F87E0; Mon, 4 Jun 2012 09:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_OTHER=0.135] 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 wsbDpVIrX1n2; Mon, 4 Jun 2012 09:17:45 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 10D8521F878E; Mon, 4 Jun 2012 09:17:33 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKT8zfnNBw5jlwqocK3aIxUjVo2Jt+bn/F@postini.com; Mon, 04 Jun 2012 09:17:44 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 4 Jun 2012 09:16:45 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 4 Jun 2012 12:16:21 -0400 From: Thomas Nadeau To: Loa Andersson Date: Mon, 4 Jun 2012 12:16:21 -0400 Thread-Topic: Review for WG Adoption of draft-vkst-mpls-tp-oam-id-mib-02.txt Thread-Index: Ac1CbWEnaoiQRWEnQzOYxa2o9Epciw== Message-ID: <23EA0526-866E-4151-BBF6-6C26DE0A44AF@juniper.net> References: <4FCAC8F6.8060200@pi.nu> In-Reply-To: <4FCAC8F6.8060200@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Swallow George , "mpls@ietf.org" , "ppan@infinera.com" , Sami Boutros , "aldrin.ietf@gmail.com" , Ross Callon , Kannan KV Sampath , "MIB Doctors \(E-mail\)" , "venkat.mahalingams@gmail.com" , Martin Vigoureux Subject: Re: [MIB-DOCTORS] Review for WG Adoption of draft-vkst-mpls-tp-oam-id-mib-02.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 16:17:46 -0000 yes we will update. thanks again Joan for reviewing! Tom=20 On Jun 2, 2012, at 10:16 PM, "Loa Andersson" wrote: > Authors, >=20 > The review by Joan was part of the MPLS RT review prior to polling the > document to become a working group. >=20 > Though updating the draft prior to the poll is strictly not necessary > to start the poll. However I would strongly prefer to poll an updated > document. >=20 > Could you please update and republish. >=20 > /Loa > (as wg chair) >=20 > On 2012-05-23 23:16, Thomas Nadeau wrote: >>=20 >> Hi Joan! >>=20 >> Thanks for the review. Comments inline start with TOM: >>=20 >> On 5/23/12 11:30 AM, "Joan Cucchiara" wrote: >>=20 >>>=20 >>> Hello Authors, >>>=20 >>> Thank you for proposing this solution. >>> Please see my notes below. >>>=20 >>> Thank you, >>> -Joan >>>=20 >>> 1) Coherency of document: >>> A) Is document useful and likely to be used/useful in operational >>> networks? >>>=20 >>> This document contains a MIB Module with 2 tables. The tables allow >>> creation of >>> TP IDs of MPLS LSPs and Pseudowires. Also a pointer to rows in >>> other MIBs Modules., i.e. to an MPLS Tunnel in the MPLS-TE-STD-MIB >>> (RFC3012) >>> or >>> pseudowire in the PWE-STD-MIB (RFC5601). Since many vendors and >>> operators >>> support the MPLS-TE-STD-MIB and PW-STD-MIB, then one could agree with t= he >>> authors that the architecture of this MIB is a viable approach. >>>=20 >>> In other words, the authors are leveraging off of existing MIB >>> implementations. >>> They are doing this in a way which adheres to the rules of SMIv2 and I = do >>> think that the MIB is likely to be used/useful in operational networks. >>>=20 >>>=20 >>> B) Is document technically sound? >>>=20 >>> From a MIB perspective, no: >>>=20 >>> I) Many objects are of type "DisplayString" which is used >>> in SMIv1 but not in SMIv2. >>>=20 >>> As the MIB Common TC doc specifies: >>>=20 >>> https://svn.tools.ietf.org/area/ops/trac/wiki/mib-common-tcs >>>=20 >>>=20 >>> "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." >>>=20 >>> II) The term "Trap" is used in both the document and the MIB. >>> This needs to be replaced by the term "Notification". Traps a mechanis= m >>> in SNMPv1. Please see RFC3584. >>=20 >> TOM: Ooops! We will fix this. >>=20 >>> 2) Is document ready for WG adoption? >>>=20 >>> I would ask that changes to remove DisplayString and use a TC which >>> supports internationalization be done, and the term Trap removed >>> prior to WG adoption for reasons stated above. >>>=20 >>> This request should only take a few minutes of editing, but will bring >>> the >>> document upto SMIv2. >>=20 >> TOM: Agree. There is no big issue fixing this. We will need to re-spin t= he >> draft in a WG-approved format anyways, so we can fix this during those >> edits. >>=20 >>>=20 >>> Additionally, a few comments (mostly as fyi): >>>=20 >>> I) this MIB contains configuration (read-create) objects. >>>=20 >>> II) the document proposes to root the MIB under mplsStdMIB which was >>> the convention for the set of MPLS MIBs in 2004 but guidelines have >>> changed since then. >>>=20 >>> III) The use of the accessible-for-notify and imports of >>> IFMIB tables do not seem necessary in the MIB's current state. >>> As the MIB is updated, this should be removed or clarified. >>=20 >> TOM: Cool. >>=20 >> --Tom >>=20 >>>=20 >>>=20 >>=20 >=20 > --=20 >=20 >=20 > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 From tnadeau@juniper.net Wed Jun 6 18:23:41 2012 Return-Path: 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 0A08711E80BB for ; Wed, 6 Jun 2012 18:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.596 X-Spam-Level: X-Spam-Status: No, score=-4.596 tagged_above=-999 required=5 tests=[AWL=-1.963, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, J_CHICKENPOX_31=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] 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 0BOc-dRM7j8t for ; Wed, 6 Jun 2012 18:23:34 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id AB37B11E80B1 for ; Wed, 6 Jun 2012 18:23:33 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKT9ACin/Upvrwqj7cNLCn5KDXTIiONBce@postini.com; Wed, 06 Jun 2012 18:23:33 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 6 Jun 2012 18:22:34 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 6 Jun 2012 18:22:33 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 6 Jun 2012 21:22:31 -0400 From: Thomas Nadeau To: "adrian@olddog.co.uk" , 'Ulrich Herberg' , "'Bert Wijnen (IETF)'" , Benoit Claise Date: Wed, 6 Jun 2012 21:22:20 -0400 Thread-Topic: [MIB-DOCTORS] Heads-up MIB review impending Thread-Index: Ac1ETAJ0KN4dZzTuSIirteUFy8AXyg== Message-ID: In-Reply-To: <165b01cd385d$88067150$981353f0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet-chairs@tools.ietf.org" , "'MIB Doctors \(E-mail\)'" , "draft-ietf-manet-nhdp-mib@tools.ietf.org" Subject: Re: [MIB-DOCTORS] Heads-up MIB review impending X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 01:23:41 -0000 Hi all, Here are my MIB Doctor review comments on the draft-ietf-manet-nhdp-mib-13 = MIB. This document is clearly written and the examples are well done. My review is divided into two sections: General Comments, and specific comm= ents inline starting with TOM: General Comments ---------------- 1. I did not re-compile the MIB as I am assuming Bert's comments from com= pilation were sufficient. These comments are IN ADDITION to Bert's so plea= se 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 on= e. 3. In general, you have not explicitly described what happens to rows in th= e 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, th= e 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 y= ou want to do is have this relationship: ifEntry NhdpInterfaceEntry 1, ifType=3Dmols 2, ifType=3Dmpls 3, ifType=3Dmanet ---------> 3 4, ifType =3D manet ---------> 4 5, ifType =3D mpls That is, you do not have entries in the NhdpInterfaceEntry table for ifInde= x-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 firs= t one. Please go through the document and make these corrections, and pleas= e do it consistently. 8. When you use InetAddress, you are constraining it to 4 or 16. This is un= usual. It is typical to just use the TC as-is. 9. I have found a number of tables that match this guidance. The easiest t= hing to do is create a StorageType object in each table and define its sema= ntics. 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 "sign= ificant number"; you need to define what you expect this means. In fact, = there is a lot of examples for defining explicit MIB variables like nhdpNbr= StateChangeThreshold that explicitly define this. This will help aid intero= perability. 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" devic= es. You really should include some limiting/throttling parameters as explic= it MIB configuration values. I know that you have defined this in some of = the description clauses, but this is not easily interoperable, especially i= f 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 over= whelms the CPU. The "bad packets" notification is a great example. 12. The nhdpIfState notification is potentially dangerous given how the If= Table 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? Als= o, what value does this notification add above/beyond the normal IfUp/Down = notification if you define an ifType=3Dmanet 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? Internet Engineering Task Force U. Herberg Internet-Draft LIX, Ecole Polytechnique Intended status: Standards Track R. Cole Expires: December 3, 2012 US Army CERDEC I. Chakeres CenGen June 1, 2012 Definition of Managed Objects for the Neighborhood Discovery Protocol draft-ietf-manet-nhdp-mib-14 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. The MIB module defined in this memo, denoted NHDP-MIB, also reports state, performance information and notifications. This TOM: Change the above to: "reports state, performance information and notifications about NHDP. = This" additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 3, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Herberg, et al. Expires December 3, 2012 [Page 1] Internet-Draft The NHDP-MIB June 2012 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . . 3 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 4 5.1. Notifications . . . . . . . . . . . . . . . . . . . . . . 4 5.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 4 5.1.2. Notification Generation . . . . . . . . . . . . . . . 5 5.1.3. Limiting Frequency of Notifications . . . . . . . . . 5 5.2. The Configuration Group . . . . . . . . . . . . . . . . . 6 5.3. The State Group . . . . . . . . . . . . . . . . . . . . . 6 5.4. The Performance Group . . . . . . . . . . . . . . . . . . 7 5.5. Tables and Indexing . . . . . . . . . . . . . . . . . . . 7 6. Relationship to Other MIB Modules . . . . . . . . . . . . . . 9 6.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . . . 9 6.2. Relationship to Routing Protocol MIB Modules Relying on the NHDP-MIB Module . . . . . . . . . . . . . . . . . . 9 6.3. MIB Modules Required for IMPORTS . . . . . . . . . . . . . 10 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 59 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 61 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 11.1. Normative References . . . . . . . . . . . . . . . . . . . 61 11.2. Informative References . . . . . . . . . . . . . . . . . . 62 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Herberg, et al. Expires December 3, 2012 [Page 2] Internet-Draft The NHDP-MIB June 2012 1. Introduction 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 [RFC6130] process on a router. The MIB module defined in this memo, denoted NHDP-MIB, also reports state, performance information and notifications. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to Section 7 of [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB module are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in [RFC2578], [RFC2579] and [RFC2580]. 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 4. Overview [RFC6130] allows a router in a Mobile Ad Hoc Network (MANET) to discover and track topological information of routers up to two hops away by virtue of exchanging HELLO messages. This information is useful for routers running various routing and multicast flooding protocols developed within the IETF MANET Working Group. 4.1. Terms The following definitions apply throughout this document: o Notification Objects - triggers and associated notification messages allowing for asynchronous tracking of pre-defined events on the managed router. Herberg, et al. Expires December 3, 2012 [Page 3] Internet-Draft The NHDP-MIB June 2012 o Configuration Objects - switches, tables, objects which are initialized to default settings or set through the management interface defined by this MIB module. o State Objects - automatically generated values which define the current operating state of the NHDP protocol process in the router. o Performance Objects - automatically generated values which help an administrator or automated tool to assess the performance of the NHDP protocol process on the router and the overall discovery performance within the MANET. 5. Structure of the MIB Module This section presents the structure of the NHDP-MIB module. The MIB module is arranged into the following structure: o nhdpNotifications - objects defining NHDP-MIB notifications. o nhdpObjects - defining objects within this MIB module. The objects are arranged into the following groups: * Configuration Group - defining objects related to the configuration of the NHDP instance on the router. * State Group - defining objects which reflect the current state of the NHDP instance running on the router. * Performance Group - defining objects which are useful to a management station when characterizing the performance of NHDP on the router and in the MANET. o nhdpConformance - defining the minimal and maximal conformance requirements for implementations of this MIB module. 5.1. Notifications This section describes the use of notifications, and mechanisms to enhance the ability to manage NHDP networks. 5.1.1. Introduction Notifications can be emitted by an NHDP router as a reaction to a specific event. This allows a network manager to efficiently determine the source of problems or significant changes of configuration or topology, instead of polling a possibly large number of NHDP routers. Herberg, et al. Expires December 3, 2012 [Page 4] Internet-Draft The NHDP-MIB June 2012 5.1.2. Notification Generation When an exception event occurs, the application notifies the local agent, which sends a notification to the appropriate SNMP management stations. The message includes the notification type and may include a list of notification-specific variables. Section 7 contains the notification definitions, which includes the variable lists. At least one IP address of the NHDP router that originates the notification is included in the variable list so that the network manager may determine the source of the notification. 5.1.3. Limiting Frequency of Notifications To limit the frequency of notifications, the following additional mechanisms are suggested, similar to those in [RFC4750]: 5.1.3.1. Ignoring Initial Activity The majority of critical events occur when NHDP is first enabled on a router, at which time the symmetric neighbors and two-hop neighbors of the NHDP router are discovered. During this initial period, a potential flood of notifications is unnecessary since the events are expected. To avoid unnecessary notifications, a router SHOULD NOT originate expected notifications until a certain time interval has elapsed, which is to be predefined by the network manager. It is RECOMMENDED that this time interval is at least 3 x 'nhdpHelloInterval', so that symmetric neighbors are discovered. The suppression window for notifications is started when the 'nhdpIfStatus' transitions from its default value of 'false' to 'true' 5.1.3.2. Throttling Notifications The mechanism for throttling the notifications is the same as in [RFC4750] (i.e. the amount of transmitted notifications per time is bounded). Appropriate values for the window time and upper bound are to be selected by the network manager and depend on the deployment of the MANET. If NHDP is deployed on a lossy, wireless medium, sending too many notifications in a short time interval may lead to collisions and dropped packets. In particular, in dense deployments of NHDP routers (i.e. where each router has many neighbors), a change of the local topology may trigger many notifications at the same time. [RFC4750] recommends "7 notifications with a window time of 10 seconds" as upper bound. As NHDP is expected to be deployed in more TOM: Change to "as the upper bound." lossy channels than OSPF, it is RECOMMENDED to choose a lower threshold for the number of notifications per time than that. Herberg, et al. Expires December 3, 2012 [Page 5] Internet-Draft The NHDP-MIB June 2012 Specifically it is RECOMMENDED to choose a threshold value for the objects reflecting the change be set to a value of '10' and have set the DEFAULT values for these objects within the Notifications Group to this value. Further, a time window for the change objects is defined within this MIB module. It is RECOMMENDED that if the number of occurrences exceeds the change threshold within the previous change window, then the notification is to be sent. Furthermore, it is RECOMMENDED that the value for this window be set to at least 5 times the 'nhdpHelloInterval'. 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'. 5.1.3.3. One Notification per Event Similar to the mechanism in [RFC4750], only one notification is sent per event. 5.2. The Configuration Group The NHDP router is configured with a set of controls. The authoritative list of configuration controls within the NHDP-MIB module are found within the MIB module itself. Generally, an attempt was made in developing the NHDP-MIB module to support all configuration objects defined in [RFC6130]. For all of the configuration parameters, the same constraints and default values of these parameters as defined in [RFC6130] are followed. Refer to [RFC5148] for guidance on setting jitter related parameters, e.g., nhdpMaxJitter. 5.3. The State Group The State Group reports current state information of a router running [RFC6130]. The NHDP-MIB State Group tables were designed to contain the complete set of state information defined within the information bases specified in Section 6, Section 7 and Section 8 of [RFC6130]. Two constructs, i.e., TEXTUAL CONVENTIONs, are defined to support of the tables in the State Group. The NHDP protocol stores and indexes information through sets of (dynamically defined) addresses, i.e., address sets. Within SMIv2 it is not possible to index tables with variably defined address sets. Hence, these TEXTUAL CONVENTIONS are defined to provide a local mapping between NHDP managed address sets and SMIv2 table indexing. These constructs are the NeighborIfIndex and NeighborRouterIndex. These are locally (to the NHDP router) Herberg, et al. Expires December 3, 2012 [Page 6] Internet-Draft The NHDP-MIB June 2012 defined, unique identifiers of virtual neighbors and neighbor interfaces. Due to the nature of the NHDP protocol, the local router may have identified distinct address sets but is not able to associate these as a single interface. Hence, two or more NeighborIfIndexes pointing to multiple distinct address sets may in fact be related to a common neighbor interface. This ambiguity may also hold with respect to the assignment of the NeighborRouterIndex. The local MIB agent is responsible for managing, aggregating and retiring the defined indexes, and in updating MIB tables using these indexes as the local router learns more about its neighbors' topology. These constructs are used to define indexes to the appropriate State Group tables and to correlate table entries to address sets, virtual neighbor interfaces and virtual neighbors within the MANET. 5.4. The Performance Group The Performance Group reports values relevant to system performance. Unstable neighbors or 2-hop neighbors and frequent changes of sets can have a negative influence on the performance of NHDP. This MIB module defines several objects that can be polled in order to, e.g., calculate histories or monitor frequencies of changes. This may help the network administrator to determine unusual topology changes or other changes that affect stability and reliability of the MANET. One such framework is specified in [REPORT-MIB]. 5.5. Tables and Indexing The NHDP-MIB module contains a number of tables which record data related to: o the local NHDP router, o a local NHDP interface on the NHDP router, o other NHDP routers which are 1-hop removed from the local NHDP router, o interfaces on other NHDP routers which are 1-hop removed from the local NHDP router, and o other NHDP routers which are 2-hop removed from the local NHDP router. The NHDP-MIB module's tables are indexed via the following constructs: Herberg, et al. Expires December 3, 2012 [Page 7] Internet-Draft The NHDP-MIB June 2012 o nhdpIfIndex - which is the IfIndex of the local router on which NHDP is enabled. o nhdpDiscIfIndex - a locally managed index representing a known interface on an NHDP neighboring router. o nhdpDiscRouterIndex - a locally managed index representing an ID of a known neighboring NHDP router. These tables and their indexing are: o nhdpInterfaceTable - describes the configuration of the interfaces of this NHDP router. This table has 'INDEX { nhdpIfIndex }'. o nhdpLibLocalIfSetTable - records all network addresses which are defined as local interface network addresses on this NHDP router. This table has 'INDEX { nhdpLibLocalIfSetIndex }'. o nhdpLibRemovedIfAddrSetTable - records network addresses which were recently used as local interface network addresses on this NHDP router but have been removed. This table has 'INDEX { nhdpLibRemovedIfAddrSetIndex }'. o nhdpInterfaceStateTable - records state information related to specific interfaces of this NHDP router. This table has 'INDEX { nhdpIfIndex }'. o nhdpDiscIfSetTable - include the nhdpDiscRouterIndex of the discovered router, the nhdpDiscIfIndex of the discovered interface and the current set of addresses associated with this neighbor interface. This table has 'INDEX { nhdpDiscIfSetIndex }'. o nhdpIibLinkSetTable - foreach local interface, this table records all links belonging to other routers which are, or recently were, 1-hop neighbors to this NHDP router. This table has 'INDEX { nhdpIfIndex, nhdpDiscIfIndex }'. o nhdpIib2HopSetTable - foreach local interface, this table records network addresses (one at a time) of symmetric 2-hop neighbors, and the symmetric links to symmetric 1-hop neighbors of this NHDP router through which these symmetric 2-hop neighbors can be reached. This table has 'INDEX { nhdpIfIndex, nhdpDiscIfIndex, nhdpIib2HopSetIpAddressType, nhdpIib2HopSetIpAddress }'. o nhdpNibNeighborSetTable - records all network addresses of each 1-hop neighbor to this NHDP router. This table has 'INDEX { nhdpDiscRouterIndex }'. Herberg, et al. Expires December 3, 2012 [Page 8] Internet-Draft The NHDP-MIB June 2012 o nhdpNibLostNeighborSetTable - records network addresses of other NHDP routers which recently were symmetric 1-hop neighbors to this NHDP router, but which are now advertised as lost. This table has 'INDEX { nhdpDiscRouterIndex }'. o nhdpInterfacePerfTable - records performance objects that are measured foreach local NHDP interface on this NHDP router. This table has 'INDEX { nhdpIfIndex }'. o nhdpDiscIfSetPerfTable - records performance objects that are measured foreach discovered interface of a neighbor of this NHDP router. This table has 'INDEX { nhdpDiscIfIndex }'. o nhdpDiscNeighborSetPerfTable - records performance objects that are measured for discovered neighbors of this NHDP router. This table has 'INDEX { nhdpDiscRouterIndex }'. o nhdpIib2HopSetPerfTable - records performance objects that are measured for discovered 2-hop neighbors of this NHDP router. This table has 'INDEX { nhdpDiscRouterIndex }'. 6. Relationship to Other MIB Modules This section specifies the relationship of the MIB module contained in this document to other standards, particularly to standards containing other MIB modules. Definitions imported from other MIB modules and other MIB modules that SHOULD be implemented in conjunction with the MIB module contained within this document are identified in this section. 6.1. Relationship to the SNMPv2-MIB The 'system' group in the SNMPv2-MIB module [RFC3418] is defined as being mandatory for all systems, and the objects apply to the entity as a whole. The 'system' group provides identification of the management entity and certain other system-wide data. The NHDP-MIB module does not duplicate those objects. 6.2. Relationship to Routing Protocol MIB Modules Relying on the NHDP- MIB Module [RFC6130] allows routing protocols to rely on the neighborhood information that is discovered by means of HELLO message exchange. In order to allow for troubleshooting, fault isolation, and management of such routing protocols through a routing protocol MIB module, it may be desired to align the State Group tables of the NHDP-MIB module and the routing protocol MIB module. This is accomplished through the definition of two TEXTUAL-CONVENTIONS in the Herberg, et al. Expires December 3, 2012 [Page 9] Internet-Draft The NHDP-MIB June 2012 NHDP-MIB module: the NeighborIfIndex and the NeighborRouterIndex. These object types are used to develop indexes into common NHDP-MIB module and routing protocol State Group tables. These objects are locally significant but should be locally common to the NHDP-MIB module and the routing protocol MIB module implemented on a common networked router. This will allow for improved cross referencing of information across the two MIB modules. 6.3. MIB Modules Required for IMPORTS The following NHDP-MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], IF-MIB [RFC2863], INET-ADDRESS-MIB [RFC4001], and FLOAT-TC-MIB [RFC6340]. 7. Definitions This section contains the MIB module defined by the specification. NHDP-MIB DEFINITIONS ::=3D BEGIN -- This MIB module defines objects for the management of -- NHDP (RFC6130) - The Neighborhood Discovery Protocol, -- Clausen, T., Dearlove, C. and J. Dean, January 2011. IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Counter64, Integer32, Unsigned32, mib-2, TimeTicks FROM SNMPv2-SMI -- RFC2578 TEXTUAL-CONVENTION, TruthValue, TimeStamp, RowStatus, DisplayString FROM SNMPv2-TC -- RFC2579 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- STD58 InetAddressType, InetAddress, InetAddressPrefixLength FROM INET-ADDRESS-MIB -- RFC4001 InterfaceIndex FROM IF-MIB -- RFC2863 Float32TC FROM FLOAT-TC-MIB -- RFC6340 ; Herberg, et al. Expires December 3, 2012 [Page 10] Internet-Draft The NHDP-MIB June 2012 nhdpMIB MODULE-IDENTITY LAST-UPDATED "201206011000Z" -- June 1, 2012 ORGANIZATION "IETF MANET Working Group" CONTACT-INFO "WG E-Mail: manet@ietf.org WG Chairs: sratliff@cisco.com jmacker@nrl.navy.mil Editors: Ulrich Herberg Ecole Polytechnique LIX 91128 Palaiseau Cedex France ulrich@herberg.name http://www.herberg.name/ Robert G. Cole US Army CERDEC Space and Terrestrial Communications 6010 Frankford Street Bldg 6010, Room 453H Aberdeen Proving Ground, MD 21005 USA +1 443 395-8744 robert.g.cole@us.army.mil http://www.cs.jhu.edu/~rgcole/ Ian D Chakeres CenGen 9250 Bendix Road North Columbia, Maryland 21045 USA ian.chakeres@gmail.com http://www.ianchak.com/" DESCRIPTION "This NHDP-MIB module is applicable to routers implementing the Neighborhood Discovery Protocol defined in RFC6130. Copyright (C) The IETF Trust (2012). This version of this MIB module is part of RFCXXXX; see the RFC itself for full legal notices." -- revision REVISION "201206011000Z" -- June 1, 2012 Herberg, et al. Expires December 3, 2012 [Page 11] Internet-Draft The NHDP-MIB June 2012 DESCRIPTION "The first version of this MIB module, published as RFCXXXX. " -- RFC-Editor assigns XXXX ::=3D { mib-2 XXXX } -- to be assigned by IANA -- -- Top-Level Components of this MIB Module -- nhdpNotifications OBJECT IDENTIFIER ::=3D { nhdpMIB 0 } nhdpObjects OBJECT IDENTIFIER ::=3D { nhdpMIB 1 } nhdpConformance OBJECT IDENTIFIER ::=3D { nhdpMIB 2 } -- -- Textual Conventions -- -- Two new Textual Conventions have been defined in -- this MIB module for indexing into the following -- tables and indexing into other tables in other MIB modules. -- This was necessary because the NHDP protocol manages and -- indexes based upon dynamic address tuples, i.e., -- address sets, while SMI requires statically -- defined indexes for accessing its table rows. -- The NeighborIfIndex defines a unique (to the local router) -- index referencing a discovered virtual interface on another -- neighbor within the MANET. The NeighborRouterIndex defines a -- unique (to the local router) index referencing a discovered -- virtual neighbor within the MANET. -- -- Due to the nature of NHDP, -- different indexes may be related to common neighbor -- interfaces or common neighbor routers, but the information -- obtained through NHDP has not allowed the local router -- to relate these virtual objects (i.e., interfaces or routers) -- at this point in time. As more topology information -- is gathered by the local router, it may associate -- virtual interfaces or routers and collapse these -- indexes appropriately. -- Multiple addresses can be associated with a -- given NeighborIfIndex. Each NeighborIfIndex is -- associated with a NeighborRouterIndex. Throughout -- the nhdpStateObjGroup, the -- NeighborIfIndex and the NeighborRouterIndex are used -- to define the set of IpAddrs related to a virtual -- neighbor interface or virtual neighbor under discussion. Herberg, et al. Expires December 3, 2012 [Page 12] Internet-Draft The NHDP-MIB June 2012 NeighborIfIndex ::=3D TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "An arbitrary, locally unique identifier associated with a virtual interface of a discovered NHDP neighbor. Due to the nature of NHDP, the local router may not know if two distinct addresses belong to the same interface of a neighbor or to two different interfaces. As the local router gains more knowledge of its neighbors, its local view may change and this table will be updated to reflect the local router's current understanding associating address sets to neighbor interfaces. The local router identifies virtual neighbor interface through TOM: Change to "...identifies a virtual neighbor" the receipt of address lists advertised through an NHDP HELLO message. All objects of type NeighborIfIndex are assigned by the agent out of a common number space. The value for each discovered virtual neighbor interface may not remain constant from one re-initialization of the entity's network management agent to the next re-initialization. If the local router gains information associating two virtual interfaces on a neighbor as a common interface, then the agent must aggregate the two address sets to a single index chosen from the set of aggregated indexes, it must update all tables in this MIB module which are indexed by indexes of type NeighborIfIndex. It can then reuse freed index values following the next agent restart. The specific value is meaningful only within a given SNMP entity." SYNTAX Unsigned32 (1..2147483647) NeighborRouterIndex ::=3D TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "An arbitrary, locally unique identifier associated with a virtual discovered neighbor (one or two hop). Due to the nature of the NHDP protocol, the local router may identify multiple virtual neighbors which in fact are one and the same. Two hop neighbors with more than one advertised TOM: What is a "two hop neighbor"? I think you mean "neighbors that are tw= o hops away" or something. address will exhibit this behavior. As the Herberg, et al. Expires December 3, 2012 [Page 13] Internet-Draft The NHDP-MIB June 2012 local router's knowledge of its neighbors' topology increases, the local router will be able to associate multiple virtual neighbor indexes into a single virtual neighbor index chosen from the set of aggregated indexes, it must update all tables in this MIB module indexed by these indexes, and it can reuse the freed indexes following the next agent re-initialization. All objects of type NeighborRouterIndex are assigned by the agent out of a common number space. The NeighborRouterIndex defines a discovered NHDP peer virtual neighbor of the local router. The value for each discovered virtual neighbor index must remain constant at least from one re-initialization of the entity's network management agent to the next re-initialization, except that if an application is deleted and re-created. The specific value is meaningful only within a given SNMP entity. An NeighborRouterIndex value must not be re-used until the next agent restart." SYNTAX Unsigned32 (1..2147483647) -- -- nhdpObjects -- -- 1) Configuration Objects Group -- 2) State Objects Group -- 3) Performance Objects Group -- -- nhdpConfigurationObjGrp -- -- Contains the NHDP objects which configure specific options -- which determine the overall performance and operation of the -- discovery protocol. nhdpConfigurationObjGrp OBJECT IDENTIFIER ::=3D { nhdpObjects 1 } nhdpInterfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpInterfaceEntry Herberg, et al. Expires December 3, 2012 [Page 14] Internet-Draft The NHDP-MIB June 2012 MAX-ACCESS not-accessible STATUS current DESCRIPTION "nhdpInterfaceTable describes the configuration of the interfaces of this NHDP router. The ifIndex is from the interfaces group defined in the Interfaces Group MIB. If the corresponding entry with ifIndex value is deleted from the Interface Table, then the entry in this table is automatically deleted. The objects in this table are persistent and when written the entity SHOULD save the change to non-volatile storage." TOM: You must describe what happens to rows in this table after an agent re= start. REFERENCE "RFC2863 - The Interfaces Group MIB, McCloghrie, K., and F. Kastenholtz, June 2000." ::=3D { nhdpConfigurationObjGrp 1 } nhdpInterfaceEntry OBJECT-TYPE SYNTAX NhdpInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "nhdpInterfaceEntry describes one NHDP local interface configuration as indexed by its ifIndex as defined in the Standard MIB II Interface Table (RFC2863)." INDEX { nhdpIfIndex } ::=3D { nhdpInterfaceTable 1 } NhdpInterfaceEntry ::=3D Sequence { nhdpIfIndex InterfaceIndex, nhdpIfName DisplayString, nhdpIfStatus TruthValue, nhdpHelloInterval Unsigned32, nhdpHelloMinInterval Unsigned32, nhdpRefreshInterval Unsigned32, nhdpLHoldTime Unsigned32, nhdpHHoldTime Herberg, et al. Expires December 3, 2012 [Page 15] Internet-Draft The NHDP-MIB June 2012 Unsigned32, nhdpHystAcceptQuality Float32TC, nhdpHystRejectQuality Float32TC, nhdpInitialQuality Float32TC, nhdpInitialPending TruthValue, nhdpHpMaxJitter Unsigned32, nhdpHtMaxJitter Unsigned32, nhdpIfRowStatus RowStatus } nhdpIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The ifIndex for this interface." ::=3D { nhdpInterfaceEntry 1 } nhdpIfName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The textual name of the interface. The value of this object should be the name of the interface as assigned by the local device and should be suitable for use in commands entered at the device's `console'. This might be a text name, such as `le0' or a simple port number, such as `1', depending on the interface naming syntax of the device. If there is no local name, or this object is otherwise not applicable, then this object contains a zero-length string." ::=3D { nhdpInterfaceEntry 2 } TOM: You should use something other than DisplayString as per the MIB guide= lines. Please review all DisplayString uses from here on in the module, as= I will not repeat this comment. 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. TOM: You also need a DEFVAL for *every* read-create object. In this case D= EFVAL {""} nhdpIfStatus OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "nhdpIfStatus indicates whether this interface is a MANET interface. A value of true(1) indicates Herberg, et al. Expires December 3, 2012 [Page 16] Internet-Draft The NHDP-MIB June 2012 that the interface is a MANET interface. A value of false(2) indicates that the interface is not a MANET interface. This corresponds to the I_manet parameter in the Local Interface Set of NHDP. " DEFVAL { false } ::=3D { nhdpInterfaceEntry 3 } TOM: Why are you modeling interfaces that are non-MANET interfaces? If you = want to do this, you sould use AUGMENT; however, I do not think that you do= . I think what you want to do is only have entries here that ARE of type MA= NET. In this case you sould define a new IfType for a manet interface so t= hat you can quickly sort through the ifEntries to find MANET interfaces. T= o do this, you need to add an IANA entry requesting this new ifType. Ask me= if you need help doing this. -- -- Interface Parameters - Message Intervals -- nhdpHelloInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "nhdpHelloInterval corresponds to HELLO_INTERVAL of NHDP and represents the maximum time between the transmission of two successive HELLO messages on this MANET interface. The following constraint applies to this parameter: o nhdpHelloInterval >=3D nhdpHelloMinInterval" REFERENCE "Section 5 on Protocol Parameters and Constraints of RFC6130." DEFVAL { 2000 } ::=3D { nhdpInterfaceEntry 4 } nhdpHelloMinInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "nhdpHelloMinInterval corresponds to HELLO_MIN_INTERVAL of NHDP and represents the minimum interval between transmission of two successive HELLO messages on this MANET interface. The following constraint applies to this parameter: o nhdpHelloInterval >=3D nhdpHelloMinInterval" Herberg, et al. Expires December 3, 2012 [Page 17] Internet-Draft The NHDP-MIB June 2012 REFERENCE "Section 5 on Protocol Parameters and Constraints of RFC6130." DEFVAL { 500 } ::=3D { nhdpInterfaceEntry 5 } nhdpRefreshInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "nhdpRefreshInterval corresponds to REFRESH_INTERVAL of NHDP and represents the maximum interval between advertisements, in a HELLO message on this MANET interface, of each 1-hop neighbor network address and its status. The following constraint applies to this parameter: o nhdpRefreshInterval >=3D nhdpHelloInterval" REFERENCE "Section 5 on Protocol Parameters and Constraints of RFC6130." DEFVAL { 2000 } ::=3D { nhdpInterfaceEntry 6 } -- -- Interface Parameters - Information Validity times -- nhdpLHoldTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "nhdpLHoldTime corresponds to L_HOLD_TIME of NHDP and represents the period of advertisement, on this MANET interface, of former 1-hop neighbor network addresses as lost in HELLO messages, allowing recipients of these HELLO messages to accelerate removal of this information from their Link Sets. The following constraint applies to this Herberg, et al. Expires December 3, 2012 [Page 18] Internet-Draft The NHDP-MIB June 2012 parameter: o nhdpLHoldTime should be significantly greater than nhdpRefreshInterval" REFERENCE "Section 5 on Protocol Parameters and Constraints of RFC6130." DEFVAL { 6000 } ::=3D { nhdpInterfaceEntry 7 } nhdpHHoldTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "nhdpHHoldTime corresponds to H_HOLD_TIME of NHDP and is used as the Value in the VALIDITY_TIME Message TLV included in all HELLO messages on this MANET interface. It is then used by each router receiving such a HELLO message to indicate the validity of the information taken from that HELLO message and recorded in the receiving router's Information Bases. The following constraints apply to this parameter: o nhdpHHoldTime >=3D nhdpRefreshInterval o nhdpHHoldTime should be significantly greater than nhdpRefreshInterval o nhdpHHoldTime must be representable as described in RFC5497" REFERENCE "Section 5 on Protocol Parameters and Constraints of RFC6130." DEFVAL { 6000 } ::=3D { nhdpInterfaceEntry 8 } -- -- Interface Parameters - Link Quality -- nhdpHystAcceptQuality OBJECT-TYPE SYNTAX Float32TC MAX-ACCESS read-create STATUS current DESCRIPTION "nhdpHystAcceptQuality corresponds to HYST_ACCEPT of NHDP and represents the link Herberg, et al. Expires December 3, 2012 [Page 19] Internet-Draft The NHDP-MIB June 2012 quality threshold at or above which a link becomes usable, if it was not already so. The following constraint applies to this parameter: o 0 <=3D nhdpHystRejectQuality <=3D nhdpHystAcceptQuality <=3D 1.0" REFERENCE "Section 5 on Protocol Parameters and Constraints of RFC6130." -- DEFVAL { 1.0 } ::=3D { nhdpInterfaceEntry 9 } nhdpHystRejectQuality OBJECT-TYPE SYNTAX Float32TC MAX-ACCESS read-create STATUS current DESCRIPTION "nhdpHystRejectQuality corresponds to HYST_REJECT of NHDP and represents the link quality threshold below which a link becomes unusable, if it was not already so. The following constraint applies to this parameter: o 0 <=3D nhdpHystRejectQuality <=3D nhdpHystAcceptQuality <=3D 1.0" REFERENCE "Section 5 on Protocol Parameters and Constraints of RFC6130." -- DEFVAL { 0.0 } ::=3D { nhdpInterfaceEntry 10 } nhdpInitialQuality OBJECT-TYPE SYNTAX Float32TC MAX-ACCESS read-create STATUS current DESCRIPTION "nhdpInitialQuality corresponds to INITIAL_QUALITY of NHDP and represents the initial quality of a newly identified link. The following constraint applies to this parameter: o 0 <=3D nhdpInitialQuality <=3D 1.0" REFERENCE "Section 5 on Protocol Parameters and Herberg, et al. Expires December 3, 2012 [Page 20] Internet-Draft The NHDP-MIB June 2012 Constraints of RFC6130." -- DEFVAL { 1.0 } ::=3D { nhdpInterfaceEntry 11 } nhdpInitialPending OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "nhdpInitialPending corresponds to INITIAL_PENDING of NHDP. If true, then a newly identified link is considered pending, and is not usable until the link quality has reached or exceeded the nhdpHystAcceptQuality threshold. The following constraints apply to this parameter: o If nhdpInitialQuality >=3D nhdpHystAcceptQuality, then nhdpInitialPending :=3D false. o If nhdpInitialQuality < nhdpHystRejectQuality, then nhdpInitialPending :=3D true." REFERENCE "Section 5 on Protocol Parameters and Constraints of RFC6130." ::=3D { nhdpInterfaceEntry 12 } -- -- Interface Parameters - Jitter -- nhdpHpMaxJitter OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "nhdpHpMaxJitter corresponds to HP_MAXJITTER of NHDP and represents the value of MAXJITTER used in RFC5148 for periodically generated HELLO messages on this MANET interface. The following constraints apply to this parameter: o nhdpHpMaxJitter <=3D nhdpHelloInterval / 2 o If nhdpHelloInterval > 0, then nhdpHpMaxJitter <=3D nhdpHelloMinInterval " REFERENCE Herberg, et al. Expires December 3, 2012 [Page 21] Internet-Draft The NHDP-MIB June 2012 "Section 5 on Protocol Parameters and Constraints of RFC6130." DEFVAL { 500 } ::=3D { nhdpInterfaceEntry 13 } nhdpHtMaxJitter OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "nhdpHtMaxJitter corresponds to HT_MAXJITTER of NHDP and represents the value of MAXJITTER used in RFC5148 for externally triggered HELLO messages on this MANET interface. The following constraints apply to this parameter: o nhdpHtMaxJitter <=3D nhdpHelloInterval / 2 o If nhdpHelloInterval > 0, then nhdpHtMaxJitter <=3D nhdpHelloMinInterval" REFERENCE "Section 5 on Protocol Parameters and Constraints of RFC6130." DEFVAL { 500 } ::=3D { nhdpInterfaceEntry 14 } nhdpIfRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object permits management of the table by facilitating actions such as row creation, construction, and destruction. The value of this object has no effect on whether other objects in this conceptual row can be modified. An entry may not exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the nhdpLibLocalIfSetTable, nhdpInterfaceStateTable, nhdpIibLinkSetTable and the nhdpInterfacePerfTable must be deleted." Herberg, et al. Expires December 3, 2012 [Page 22] Internet-Draft The NHDP-MIB June 2012 REFERENCE "RFC6130." ::=3D { nhdpInterfaceEntry 15 } -- -- Router Parameters - Information Validity Time -- nhdpNHoldTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "nhdpNHoldTime corresponds to N_HOLD_TIME of NHDP and is used as the period during which former 1-hop neighbor network addresses are advertised as lost in HELLO messages, allowing recipients of these HELLO messages to accelerate removal of this information from their 2-Hop Sets. This object is persistent and when written the entity SHOULD save the change to non-volatile storage." REFERENCE "RFC6130. Section 5 on Protocol Parameters and Constraints." DEFVAL { 6000 } ::=3D { nhdpConfigurationObjGrp 2 } nhdpIHoldTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "nhdpIHoldTime corresponds to I_HOLD_TIME of NHDP and represents the period for which a recently used local interface network address is recorded. This object is persistent and when written the entity SHOULD save the change to non-volatile storage." REFERENCE Herberg, et al. Expires December 3, 2012 [Page 23] Internet-Draft The NHDP-MIB June 2012 "RFC6130. Section 5 on Protocol Parameters and Constraints." DEFVAL { 6000 } ::=3D { nhdpConfigurationObjGrp 3 } -- An NHDP router's Local Information Base (LIB) -- -- Local Interface Set Table -- nhdpLibLocalIfSetTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpLibLocalIfSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A router's Local Interface Set records all network addresses which are defined as local interface network addresses. The local interface is defined by the nhdpIfIndex. The Local Interface Set consists of Local Interface Address Tuples per network interface and their prefix lengths (in order to determine the network addresses related to the interface) and an indication of whether the interface is a MANET interface or not. Further guidance on the addition or removal of local addresses and network addresses is found in Section 9 of RFC6130." REFERENCE "RFC6130." ::=3D { nhdpConfigurationObjGrp 4 } nhdpLibLocalIfSetEntry OBJECT-TYPE SYNTAX NhdpLibLocalIfSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A router's Local Interface Set consists of Configured Interface Address Tuples for each network interface, and an indication of whether the interface is a MANET interface or not. (I_local_iface_addr_list, I_manet) " Herberg, et al. Expires December 3, 2012 [Page 24] Internet-Draft The NHDP-MIB June 2012 REFERENCE "RFC6130." INDEX { nhdpLibLocalIfSetIndex } ::=3D { nhdpLibLocalIfSetTable 1 } TOM: Why don't you use a second index here and/or extend the ifEntry here? = This table could in the worst case, mimic the ifEntry right? On some boxe= s, that could have thousands of entries so you do not want to have multiple= copies of this table. NhdpLibLocalIfSetEntry ::=3D SEQUENCE { nhdpLibLocalIfSetIndex Integer32, nhdpLibLocalIfSetIfIndex InterfaceIndex, nhdpLibLocalIfSetIpAddrType InetAddressType, nhdpLibLocalIfSetIpAddr InetAddress, nhdpLibLocalIfSetIpAddrPrefixLen InetAddressPrefixLength, nhdpLibLocalIfSetIsManet TruthValue, nhdpLibLocalIfSetRowStatus RowStatus } nhdpLibLocalIfSetIndex OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index for this table. Necessary because multiple addresses may be associated with a given nhdpIfIndex." REFERENCE "RFC6130." TOM: I think it is customary to include the full reference description in t= he REFERENCE clause. For example: "RFC 2863 - The Interfaces Group MIB, McCloghrie, K., and F. Kastenholtz, June 2000" ::=3D { nhdpLibLocalIfSetEntry 1 } nhdpLibLocalIfSetIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the local nhdpIfIndex for which this IP address was added." REFERENCE "RFC6130." ::=3D { nhdpLibLocalIfSetEntry 2 } nhdpLibLocalIfSetIpAddrType OBJECT-TYPE SYNTAX InetAddressType Herberg, et al. Expires December 3, 2012 [Page 25] Internet-Draft The NHDP-MIB June 2012 MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the nhdpLibLocalIfSetIpAddr in the InetAddress MIB (RFC4001). TOM: You typically use "RFC 4001" (i.e.: with the space between) in the DES= CRIPTION clause so that you do not distrupt ID-NITS which will flag this as= an unknown reference. Only the values ipv4(1) and ipv6(2) are supported." REFERENCE "RFC6130." ::=3D { nhdpLibLocalIfSetEntry 3 } nhdpLibLocalIfSetIpAddr OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) TOM: Why are you constraining the InetAddress to 4 or 16? This is uncommon. MAX-ACCESS read-create STATUS current DESCRIPTION "nhdpLibLocalIfSetIpAddr is an address of an interface of this router. This object is interpreted according to the setting of nhdpLibLocalIfSetIpAddrType." REFERENCE "RFC6130." ::=3D { nhdpLibLocalIfSetEntry 4 } nhdpLibLocalIfSetIpAddrPrefixLen OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the number of leading one bits that form the mask. The mask is logically-ANDed to the nhdpLibLocalIfSetIpAddr to determine the address prefix. A row match is true if the address used as an index falls within the network address range defined by the address prefix." REFERENCE "RFC6130." ::=3D { nhdpLibLocalIfSetEntry 5 } nhdpLibLocalIfSetIsManet OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION Herberg, et al. Expires December 3, 2012 [Page 26] Internet-Draft The NHDP-MIB June 2012 "Specifies whether this interface is a MANET interface or not." REFERENCE "RFC6130." ::=3D { nhdpLibLocalIfSetEntry 6 } nhdpLibLocalIfSetRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object permits management of the table by facilitating actions such as row creation, construction, and destruction. The value of this object has no effect on whether other objects in this conceptual row can be modified. An entry may not exist in the active state unless all objects in the entry have an appropriate value." REFERENCE "RFC6130." ::=3D { nhdpLibLocalIfSetEntry 7 } TOM: You need to be more precise in defining the RowStatus objects like thi= s: "This variable is used to create, modify, and/or delete a row in this table. When a row in this table is in active(1) state, no objects in that row can be modified by the agent except nhdpLibLocalIfSetRowStatus and nhdpLibLocalIfSetStorageType." TOM: 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. -- -- Removed Interface Addr Set Table -- nhdpLibRemovedIfAddrSetTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpLibRemovedIfAddrSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A router's Removed Interface Address Set records network addresses which were recently used as local interface network addresses. If a router's interface network addresses are immutable then the Removed Interface Address Set is always empty and may be omitted. It consists of Removed Interface Address Tuples, one per network address." REFERENCE "RFC6130." ::=3D { nhdpConfigurationObjGrp 5 } nhdpLibRemovedIfAddrSetEntry OBJECT-TYPE SYNTAX NhdpLibRemovedIfAddrSetEntry MAX-ACCESS not-accessible Herberg, et al. Expires December 3, 2012 [Page 27] Internet-Draft The NHDP-MIB June 2012 STATUS current DESCRIPTION "A router's Removed Interface Address Set consists of Removed Interface Address Tuples, one per network address: (IR_local_iface_addr, IR_time) The association between these addrs and the router's Interface is found in the Standard MIB II's IP address table (RFC1213)." REFERENCE "RFC6130." INDEX { nhdpLibRemovedIfAddrSetIndex } ::=3D { nhdpLibRemovedIfAddrSetTable 1 } NhdpLibRemovedIfAddrSetEntry ::=3D SEQUENCE { nhdpLibRemovedIfAddrSetIndex Integer32, nhdpLibRemovedIfAddrSetIpAddrType InetAddressType, nhdpLibRemovedIfAddrSetIpAddr InetAddress, nhdpLibRemovedIfAddrSetIpAddrPrefixLen InetAddressPrefixLength, nhdpLibRemovedIfAddrSetIfIndex InterfaceIndex, nhdpLibRemovedIfAddrSetIRTime TimeStamp } nhdpLibRemovedIfAddrSetIndex OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index for this table. Necessary because multiple addresses may be associated with a given nhdpIfIndex." REFERENCE "RFC6130." ::=3D { nhdpLibRemovedIfAddrSetEntry 1 } nhdpLibRemovedIfAddrSetIpAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only Herberg, et al. Expires December 3, 2012 [Page 28] Internet-Draft The NHDP-MIB June 2012 STATUS current DESCRIPTION "The type of the nhdpLibRemovedIfAddrSetIpAddr in the InetAddress MIB (RFC4001). Only the values ipv4(1) and ipv6(2) are supported." REFERENCE "RFC6130." ::=3D { nhdpLibRemovedIfAddrSetEntry 2 } nhdpLibRemovedIfAddrSetIpAddr OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpLibRemovedIfAddrSetIpAddr is a recently used address of an interface of this router." REFERENCE "RFC6130." ::=3D { nhdpLibRemovedIfAddrSetEntry 3 } nhdpLibRemovedIfAddrSetIpAddrPrefixLen OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of leading one bits that form the mask. The mask is logically-ANDed to the nhdpLibRemovedIfAddrSetIpAddr to determine the address prefix. A row match is true if the address used as an index falls within the network address range defined by the address prefix." REFERENCE "RFC6130." ::=3D { nhdpLibRemovedIfAddrSetEntry 4 } nhdpLibRemovedIfAddrSetIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the local IfIndex from which this IP address was recently removed." REFERENCE Herberg, et al. Expires December 3, 2012 [Page 29] Internet-Draft The NHDP-MIB June 2012 "RFC6130." ::=3D { nhdpLibRemovedIfAddrSetEntry 5 } nhdpLibRemovedIfAddrSetIRTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpLibRemovedIfAddrSetIRTime specifies the sysUptime when to expire this entry and remove it from the 'nhdpNibLostNeighborSetTable'" REFERENCE "RFC6130." ::=3D { nhdpLibRemovedIfAddrSetEntry 6 } -- -- nhdpStateObjGrp -- -- Contains information describing the current state of the NHDP -- process on this router. nhdpStateObjGrp OBJECT IDENTIFIER ::=3D { nhdpObjects 2 } nhdpUpTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time current NHDP process was initialized. " ::=3D { nhdpStateObjGrp 1 } nhdpInterfaceStateTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpInterfaceStateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "nhdpInterfaceStateTable lists state information related to specific interfaces of this NHDP router. The value of nhdpIfIndex is an ifIndex from the interfaces group defined in the Interfaces Group MIB. Herberg, et al. Expires December 3, 2012 [Page 30] Internet-Draft The NHDP-MIB June 2012 The objects in this table are persistent and when written the entity SHOULD save the change to non-volatile storage." REFERENCE "RFC 2863 - The Interfaces Group MIB, McCloghrie, K., and F. Kastenholtz, June 2000." ::=3D { nhdpStateObjGrp 2 } nhdpInterfaceStateEntry OBJECT-TYPE SYNTAX NhdpInterfaceStateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "nhdpInterfaceStateEntry describes one NHDP local interface state as indexed by its nhdpIfIndex." INDEX { nhdpIfIndex } ::=3D { nhdpInterfaceStateTable 1 } NhdpInterfaceStateEntry ::=3D SEQUENCE { nhdpIfStateUpTime TimeStamp } nhdpIfStateUpTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the sysUpTime when this interface was last initialized as a MANET interface." ::=3D { nhdpInterfaceStateEntry 1 } -- -- This table allows for the mapping between discovered -- remote interfaces and routers and their addresses. -- nhdpDiscIfSetTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpDiscIfSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A router's set of discovered interfaces on neighboring routers." Herberg, et al. Expires December 3, 2012 [Page 31] Internet-Draft The NHDP-MIB June 2012 REFERENCE "RFC6130." ::=3D { nhdpStateObjGrp 3 } nhdpDiscIfSetEntry OBJECT-TYPE SYNTAX NhdpDiscIfSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entries include the nhdpDiscRouterIndex of the discovered router, the nhdpDiscIfIndex of the discovered interface and the current set of addresses associated with this neighbor interface. The nhdpDiscIfIndex uniquely identifies the remote interface address sets through this table. It does not need to be unique across the MANET, but must be locally unique within this router." REFERENCE "RFC6130." INDEX { nhdpDiscIfSetIndex } ::=3D { nhdpDiscIfSetTable 1 } NhdpDiscIfSetEntry ::=3D SEQUENCE { nhdpDiscIfSetIndex Integer32, nhdpDiscIfIndex NeighborIfIndex, nhdpDiscRouterIndex NeighborRouterIndex, nhdpDiscIfSetIpAddrType InetAddressType, nhdpDiscIfSetIpAddr InetAddress, nhdpDiscIfSetIpAddrPrefixLen InetAddressPrefixLength } nhdpDiscIfSetIndex OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index for this table. Necessary because multiple addresses may be associated Herberg, et al. Expires December 3, 2012 [Page 32] Internet-Draft The NHDP-MIB June 2012 with a given nhdpDiscIfIndex." REFERENCE "RFC6130." ::=3D { nhdpDiscIfSetEntry 1 } nhdpDiscIfIndex OBJECT-TYPE SYNTAX NeighborIfIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The NHDP interface index (locally created) of a neighbor's interface. Used for cross indexing into other NHDP tables and other MIB modules." REFERENCE "RFC6130." ::=3D { nhdpDiscIfSetEntry 2 } nhdpDiscRouterIndex OBJECT-TYPE SYNTAX NeighborRouterIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The NHDP neighbor index (locally created) of a neighboring router. Used for cross indexing into other NHDP tables and other MIB modules." REFERENCE "RFC6130." ::=3D { nhdpDiscIfSetEntry 3 } nhdpDiscIfSetIpAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the nhdpDiscIfSetIpAddr in the InetAddress MIB (RFC4001). Only the values ipv4(1) and ipv6(2) are supported." REFERENCE "RFC6130." ::=3D { nhdpDiscIfSetEntry 4 } nhdpDiscIfSetIpAddr OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS read-only Herberg, et al. Expires December 3, 2012 [Page 33] Internet-Draft The NHDP-MIB June 2012 STATUS current DESCRIPTION "The nhdpDiscIfSetIpAddr is a recently used address of a neighbor of this router." REFERENCE "RFC6130." ::=3D { nhdpDiscIfSetEntry 5 } nhdpDiscIfSetIpAddrPrefixLen OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of leading one bits that form the mask. The mask is logically-ANDed to the nhdpDiscIfSetIpAddr to determine the address prefix. A row match is true if the address used as an index falls within the network address range defined by the address prefix." REFERENCE "RFC6130." ::=3D { nhdpDiscIfSetEntry 6 } -- Interface Information Base (IIB) -- -- Link Set -- nhdpIibLinkSetTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpIibLinkSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Link Set of an interface records all links from other routers which are, or recently were, 1-hop neighbors." REFERENCE "RFC6130." ::=3D { nhdpStateObjGrp 4 } nhdpIibLinkSetEntry OBJECT-TYPE SYNTAX NhdpIibLinkSetEntry MAX-ACCESS not-accessible STATUS current Herberg, et al. Expires December 3, 2012 [Page 34] Internet-Draft The NHDP-MIB June 2012 DESCRIPTION "A Link Set consists of Link Tuples, each representing a single link indexed by the local and remote interface pair: (L_neighbor_iface_addr_list, L_HEARD_time, L_SYM_time, L_quality, L_pending, L_lost, L_time). The local interface is indexed via the 'nhdpIfIndex'. The 1-Hop interface is indexed via the 'nhdpDiscIfIndex'. There should be an entry in this table for each local interface and associated 1-Hop neighbor reachable on this local interface. Note that L_quality is not included in the entries below, because updates may be required too frequently." REFERENCE "RFC6130." INDEX { nhdpIfIndex, nhdpDiscIfIndex } ::=3D { nhdpIibLinkSetTable 1 } NhdpIibLinkSetEntry ::=3D SEQUENCE { nhdpIibLinkSetLHeardTime TimeStamp, nhdpIibLinkSetLSymTime TimeStamp, nhdpIibLinkSetLPending TruthValue, nhdpIibLinkSetLLost TruthValue, nhdpIibLinkSetLTime TimeStamp } nhdpIibLinkSetLHeardTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpIibLinkSetLHeardTime corresponds to L_HEARD_time of NHDP and represents the time up to which the MANET interface of the 1-hop neighbor would be considered heard if Herberg, et al. Expires December 3, 2012 [Page 35] Internet-Draft The NHDP-MIB June 2012 not considering link quality." REFERENCE "RFC6130." ::=3D { nhdpIibLinkSetEntry 1 } nhdpIibLinkSetLSymTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpIibLinkSetLSymTime corresponds to L_SYM_time of NHDP and represents the time up to which the link to the 1-hop neighbor would be considered symmetric if not considering link quality." REFERENCE "RFC6130." ::=3D { nhdpIibLinkSetEntry 2 } nhdpIibLinkSetLPending OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpIibLinkSetLPending corresponds to L_pending of NHDP and is a boolean flag, describing if a link is considered pending (i.e., a candidate, but not yet established, link)." REFERENCE "RFC6130." ::=3D { nhdpIibLinkSetEntry 3 } nhdpIibLinkSetLLost OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpIibLinkSetLLost corresponds to L_lost of NHDP and is a boolean flag, describing if a link is considered lost due to low link quality." REFERENCE "RFC6130." ::=3D { nhdpIibLinkSetEntry 4 } nhdpIibLinkSetLTime OBJECT-TYPE SYNTAX TimeStamp Herberg, et al. Expires December 3, 2012 [Page 36] Internet-Draft The NHDP-MIB June 2012 MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpIibLinkSetLTime specifies the sysUptime when to expire this entry and remove it from the 'nhdpIibLinkSetTable'. " REFERENCE "RFC6130." ::=3D { nhdpIibLinkSetEntry 5 } -- -- 2-Hop Set -- nhdpIib2HopSetTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpIib2HopSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A 2-Hop Set of an interface records network addresses of symmetric 2-hop neighbors, and the symmetric links to symmetric 1-hop neighbors through which these symmetric 2-hop neighbors can be reached. It consists of 2-Hop Tuples." REFERENCE "RFC6130." ::=3D { nhdpStateObjGrp 5 } nhdpIib2HopSetEntry OBJECT-TYPE SYNTAX NhdpIib2HopSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "nhdpIib2HopSetTable consists of 2-Hop Tuples, each representing a single network address of a symmetric 2-hop neighbor, and a single MANET interface of a symmetric 1-hop neighbor. (N2_neighbor_iface_addr_list, N2_2hop_addr, N2_time). The entries include the 2-hop neighbor addresses, which act as the table index, and associated 1-hop symmetric link address set, designated through 'nhdpDiscIfIndex', and an expiration time. The 'nhdpIfIndex' in the INDEX is interface index of the local interface Herberg, et al. Expires December 3, 2012 [Page 37] Internet-Draft The NHDP-MIB June 2012 through which these 2-hop addresses are accessible. The 'nhdpDiscIfIndex' in the INDEX represents the 1-Hop neighbor interface through which these 2-Hop addresses are reachable." REFERENCE "RFC6130." INDEX { nhdpIfIndex, nhdpDiscIfIndex, nhdpIib2HopSetIpAddressType, nhdpIib2HopSetIpAddress } ::=3D { nhdpIib2HopSetTable 1 } NhdpIib2HopSetEntry ::=3D SEQUENCE { nhdpIib2HopSetIpAddressType InetAddressType, nhdpIib2HopSetIpAddress InetAddress, nhdpIib2HopSetIpAddrPrefixLen InetAddressPrefixLength, nhdpIib2HopSet1HopIfIndex NeighborIfIndex, nhdpIib2HopSetN2Time TimeStamp } nhdpIib2HopSetIpAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the nhdpIib2HopSetIpAddress in the InetAddress MIB module (RFC4001). Only the values ipv4(1) and ipv6(2) are supported." REFERENCE "RFC6130." ::=3D { nhdpIib2HopSetEntry 1 } nhdpIib2HopSetIpAddress OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "nhdpIib2HopSetIpAddr corresponds Herberg, et al. Expires December 3, 2012 [Page 38] Internet-Draft The NHDP-MIB June 2012 to N2_2hop_addr of NHDP and is a network address of a symmetric 2-hop neighbor that has a symmetric link (using any MANET interface) to the indicated symmetric 1-hop neighbor." REFERENCE "RFC6130." ::=3D { nhdpIib2HopSetEntry 2 } nhdpIib2HopSetIpAddrPrefixLen OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of leading one bits that form the mask. The mask is logically-ANDed to the nhdpIib2HopSetIpAddress to determine the address prefix. A row match is true if the address used as an index falls within the network address range defined by the address prefix." REFERENCE "RFC6130." ::=3D { nhdpIib2HopSetEntry 3 } nhdpIib2HopSet1HopIfIndex OBJECT-TYPE SYNTAX NeighborIfIndex MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpIib2HopSet1HopIfIndex is nhdpDiscIfIndex of the 1-hop neighbor which communicated the ipAddress of the 2-hop neighbor in this row entry." REFERENCE "RFC6130." ::=3D { nhdpIib2HopSetEntry 4 } nhdpIib2HopSetN2Time OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpIib2HopSetN2Time specifies the sysUptime when to expire this entry and remove it from the 'nhdpIib2HopSetTable'." REFERENCE "RFC6130." Herberg, et al. Expires December 3, 2012 [Page 39] Internet-Draft The NHDP-MIB June 2012 ::=3D { nhdpIib2HopSetEntry 5 } -- -- Neighbor Information Base (NIB) -- -- Each router maintains a Neighbor Information Base -- that records information about addresses of -- current and recently symmetric 1-hop neighbors. -- -- Neighbor Set -- -- The Neighbor Set Table is small because -- most of the corresponding information is found -- in the nhdpDiscoveredIfTable above. -- nhdpNibNeighborSetTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpNibNeighborSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A router's Neighbor Set records all network addresses of each 1-hop neighbor." REFERENCE "RFC6130." ::=3D { nhdpStateObjGrp 6 } nhdpNibNeighborSetEntry OBJECT-TYPE SYNTAX NhdpNibNeighborSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A router's Neighbor Set consists of Neighbor Tuples, each representing a single 1-hop neighbor: (N_neighbor_addr_list, N_symmetric) " REFERENCE "RFC6130." INDEX { nhdpDiscRouterIndex } ::=3D { nhdpNibNeighborSetTable 1 } NhdpNibNeighborSetEntry ::=3D Herberg, et al. Expires December 3, 2012 [Page 40] Internet-Draft The NHDP-MIB June 2012 SEQUENCE { nhdpNibNeighborSetNSymmetric TruthValue } nhdpNibNeighborSetNSymmetric OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpNibNeighborNSymmetric corresponds to N_symmetric of NHDP and is a boolean flag, describing if this is a symmetric 1-hop neighbor." REFERENCE "RFC6130." ::=3D { nhdpNibNeighborSetEntry 1 } -- -- Lost Neighbor Set -- nhdpNibLostNeighborSetTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpNibLostNeighborSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A router's Lost Neighbor Set records network addresses of routers which recently were symmetric 1-hop neighbors, but which are now advertised as lost." REFERENCE "RFC6130." ::=3D { nhdpStateObjGrp 7 } nhdpNibLostNeighborSetEntry OBJECT-TYPE SYNTAX NhdpNibLostNeighborSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A router's Lost Neighbor Set consists of Lost Neighbor Tuples, each representing a single such network address: (NL_neighbor_addr, NL_time)" REFERENCE "RFC6130." INDEX { nhdpDiscRouterIndex } ::=3D { nhdpNibLostNeighborSetTable 1 } Herberg, et al. Expires December 3, 2012 [Page 41] Internet-Draft The NHDP-MIB June 2012 NhdpNibLostNeighborSetEntry ::=3D SEQUENCE { nhdpNibLostNeighborSetNLTime TimeStamp } nhdpNibLostNeighborSetNLTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpNibLostNeighborSetNLTime specifies the sysUptime when to expire this entry and remove it from the 'nhdpNibLostNeighborSetTable'." REFERENCE "RFC6130." ::=3D { nhdpNibLostNeighborSetEntry 1 } -- -- nhdpPerformanceObjGrp -- -- Contains objects which help to characterize the performance of -- the NHDP process, typically counters. -- nhdpPerformanceObjGrp OBJECT IDENTIFIER ::=3D { nhdpObjects 3 } -- -- Objects per local interface -- nhdpInterfacePerfTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpInterfacePerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table summarizes performance objects that are measured per local NHDP interface." REFERENCE "RFC6130." ::=3D { nhdpPerformanceObjGrp 1 } nhdpInterfacePerfEntry OBJECT-TYPE SYNTAX NhdpInterfacePerfEntry MAX-ACCESS not-accessible Herberg, et al. Expires December 3, 2012 [Page 42] Internet-Draft The NHDP-MIB June 2012 STATUS current DESCRIPTION "A single entry contains performance counters for a local NHDP interface." INDEX { nhdpIfIndex } ::=3D { nhdpInterfacePerfTable 1 } NhdpInterfacePerfEntry ::=3D SEQUENCE { nhdpIfHelloMessageXmits Counter32, nhdpIfHelloMessageRecvd Counter32, nhdpIfHelloMessageXmitAccumulatedSize Counter64, nhdpIfHelloMessageRecvdAccumulatedSize Counter64, nhdpIfHelloMessageTriggeredXmits Counter32, nhdpIfHelloMessagePeriodicXmits Counter32, nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount Counter32, nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount Counter32, nhdpIfHelloMessageXmitAccumulatedLostNeighborCount Counter32 } nhdpIfHelloMessageXmits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter is incremented each time a HELLO message has been transmitted on that interface." ::=3D { nhdpInterfacePerfEntry 1 } nhdpIfHelloMessageRecvd OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter is incremented each time a HELLO message has been received on that interface." ::=3D { nhdpInterfacePerfEntry 2 } nhdpIfHelloMessageXmitAccumulatedSize OBJECT-TYPE Herberg, et al. Expires December 3, 2012 [Page 43] Internet-Draft The NHDP-MIB June 2012 SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter is incremented by the number of octets in a HELLO message each time a HELLO message has been sent." ::=3D { nhdpInterfacePerfEntry 3 } nhdpIfHelloMessageRecvdAccumulatedSize OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter is incremented by the number of octets in a HELLO message each time a HELLO message has been received." ::=3D { nhdpInterfacePerfEntry 4 } nhdpIfHelloMessageTriggeredXmits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter is incremented each time a triggered HELLO message has been sent." ::=3D { nhdpInterfacePerfEntry 5 } nhdpIfHelloMessagePeriodicXmits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter is incremented each time a periodic HELLO message has been sent." ::=3D { nhdpInterfacePerfEntry 6 } nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter is incremented by the number of advertised symmetric neighbors in a HELLO each time a HELLO message has been sent." ::=3D { nhdpInterfacePerfEntry 7 } nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount OBJECT-TYPE Herberg, et al. Expires December 3, 2012 [Page 44] Internet-Draft The NHDP-MIB June 2012 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter is incremented by the number of advertised heard neighbors in a HELLO each time a HELLO message has been sent." ::=3D { nhdpInterfacePerfEntry 8 } nhdpIfHelloMessageXmitAccumulatedLostNeighborCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter is incremented by the number of advertised lost neighbors in a HELLO each time a HELLO message has been sent." ::=3D { nhdpInterfacePerfEntry 9 } -- -- Objects per discovered neighbor interface -- nhdpDiscIfSetPerfTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpDiscIfSetPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A router's set of performance properties for each discovered interface of a neighbor." REFERENCE "RFC6130." ::=3D { nhdpPerformanceObjGrp 2 } nhdpDiscIfSetPerfEntry OBJECT-TYPE SYNTAX NhdpDiscIfSetPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "There is an entry for each discovered interface of a neighbor." REFERENCE "RFC6130." INDEX { nhdpDiscIfIndex } ::=3D { nhdpDiscIfSetPerfTable 1 } Herberg, et al. Expires December 3, 2012 [Page 45] Internet-Draft The NHDP-MIB June 2012 NhdpDiscIfSetPerfEntry ::=3D SEQUENCE { nhdpDiscIfRecvdPackets Counter32, nhdpDiscIfExpectedPackets Counter32 } nhdpDiscIfRecvdPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter increments each time this router receives a packet from that interface of the neighbor." REFERENCE "RFC6130." ::=3D { nhdpDiscIfSetPerfEntry 1 } nhdpDiscIfExpectedPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter increments by the number of missed packets from this neighbor based on the packet sequence number each time this router receives a packet from that interface of the neighbor." REFERENCE "RFC6130." ::=3D { nhdpDiscIfSetPerfEntry 2 } -- -- Objects concerning the neighbor set -- nhdpNibNeighborSetChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter increments each time the Neighbor Set changes. A change occurs whenever a new Neighbor Tuple has been added, a Neighbor Tuple has been removed or any entry of a Neighbor Tuple has been modified." Herberg, et al. Expires December 3, 2012 [Page 46] Internet-Draft The NHDP-MIB June 2012 ::=3D { nhdpPerformanceObjGrp 3 } -- -- Objects per discovered neighbor -- nhdpDiscNeighborSetPerfTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpDiscNeighborSetPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A router's set of discovered neighbors and their properties." REFERENCE "RFC6130." ::=3D { nhdpPerformanceObjGrp 4 } nhdpDiscNeighborSetPerfEntry OBJECT-TYPE SYNTAX NhdpDiscNeighborSetPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entries include the nhdpDiscRouterIndex of the discovered router, as well as performance objects related to changes of the Neighbor Set." REFERENCE "RFC6130." INDEX { nhdpDiscRouterIndex } ::=3D { nhdpDiscNeighborSetPerfTable 1 } NhdpDiscNeighborSetPerfEntry ::=3D SEQUENCE { nhdpDiscNeighborNibNeighborSetChanges Counter32, nhdpDiscNeighborNibNeighborSetUpTime TimeStamp, nhdpDiscNeighborNibNeighborSetReachableLinkChanges Counter32 } nhdpDiscNeighborNibNeighborSetChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the number of changes Herberg, et al. Expires December 3, 2012 [Page 47] Internet-Draft The NHDP-MIB June 2012 to the given Neighbor Tuple." REFERENCE "RFC6130." ::=3D { nhdpDiscNeighborSetPerfEntry 1 } nhdpDiscNeighborNibNeighborSetUpTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the sysUpTime when the neighbor becomes 'nbrup'. A neighbor is said to become 'nbrup' if a new nhdpNibNeighborSetEntry is created for a particular nhdpNibNeighborSetRouterIndex. It becomes 'nbrdown' if the entry for that neighbor has been deleted." REFERENCE "RFC6130." ::=3D { nhdpDiscNeighborSetPerfEntry 2 } nhdpDiscNeighborNibNeighborSetReachableLinkChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts each time the neighbor changes the interface(s) over which it is reachable. A change in the set of Link Tuples corresponding to the appropriate Neighbor Tuple is registered, i.e. a corresponding Link Tuple is added or removed from the set of all corresponding Link Tuples." REFERENCE "RFC6130." ::=3D { nhdpDiscNeighborSetPerfEntry 3 } -- -- Objects per discovered 2-hop neighbor -- nhdpIib2HopSetPerfTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpIib2HopSetPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains performance objects per Herberg, et al. Expires December 3, 2012 [Page 48] Internet-Draft The NHDP-MIB June 2012 discovered 2-hop neighbor." REFERENCE "RFC6130." ::=3D { nhdpPerformanceObjGrp 5 } nhdpIib2HopSetPerfEntry OBJECT-TYPE SYNTAX NhdpIib2HopSetPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entries contain performance objects per discovered 2-hop neighbor." REFERENCE "RFC6130." INDEX { nhdpDiscRouterIndex } ::=3D { nhdpIib2HopSetPerfTable 1 } NhdpIib2HopSetPerfEntry ::=3D SEQUENCE { nhdpIib2HopSetPerfChanges Counter32, nhdpIib2HopSetPerfUpTime TimeStamp } nhdpIib2HopSetPerfChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the changes of the union of all N2_neighbor_iface_addr_list of 2-Hop Tuples with an N2_2hop_addr equal to one of the given 2-hop neighbor's addresses." REFERENCE "RFC6130." ::=3D { nhdpIib2HopSetPerfEntry 1 } nhdpIib2HopSetPerfUpTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the sysUpTime when the 2-Hop Tuple corresponding to the given 2-hop neighbor IP address was registered in the nhdpIib2HopSetTable." Herberg, et al. Expires December 3, 2012 [Page 49] Internet-Draft The NHDP-MIB June 2012 REFERENCE "RFC6130." ::=3D { nhdpIib2HopSetPerfEntry 2 } -- -- nhdpNotifications -- nhdpNotificationsObjects OBJECT IDENTIFIER ::=3D { nhdpNotifications 0 } nhdpNotificationsControl OBJECT IDENTIFIER ::=3D { nhdpNotifications 1 } nhdpNotificationsStates OBJECT IDENTIFIER ::=3D { nhdpNotifications 2 } -- nhdpNotificationsObjects nhdpNbrStateChange NOTIFICATION-TYPE OBJECTS { nhdpIfName, -- The originator of -- the notification. nhdpNbrState -- The new state } STATUS current DESCRIPTION "nhdpNbrStateChange is a notification sent when a significant number of neighbors change their status (i.e. down, asymmetric, or symmetric) in a short time. The network administrator should select appropriate values for 'significant number of neighbors' and 'short time'." ::=3D { nhdpNotificationsObjects 1 } TOM: You need to provide some guidelines for what "significant number" mean= s. nhdp2HopNbrStateChange Notification-TYPE OBJECTS { nhdpIfName, -- The originator -- of the notification nhdp2HopNbrState -- The new state } STATUS current DESCRIPTION "nhdp2HopNbrStateChange is a notification sent when a significant number of 2-hop neighbors change their status (i.e. up or down) in a short time. The network administrator should select appropriate values for 'significant number of neighbors' and 'short time'." ::=3D { nhdpNotificationsObjects 2 } Herberg, et al. Expires December 3, 2012 [Page 50] Internet-Draft The NHDP-MIB June 2012 nhdpIfRxBadPacket NOTIFICATION-TYPE OBJECTS { nhdpDiscRouterIndex, -- The originator of -- the notification nhdpIfName, -- The interface on which the -- packet has been received nhdpPacketSrcAddrType, -- The type of the source IP -- address of the packet nhdpPacketSrcAddr -- The source IP address of -- the packet } STATUS current DESCRIPTION "nhdpIfRxBadPacket is a notification sent when a significant number of incoming packets have not been successfully parsed in a short time. The network administrator should select appropriate values for 'significant number of neighbors' and 'short time'." ::=3D { nhdpNotificationsObjects 3 } TOM: I am finding it very difficult to imagine how this would be implemente= d, and done so in a consistent manner that is interoperable. Similar to a= bove, you need to either allow the operator to define what "significant" is= , or be very clear in what triggers this notification (I prefer the latter)= . Also, I am concerned that there is no throttling of this notification.= What if %100 of the packets received are "bad" because the radio link is m= essed up? Would this be a DoS attack on the device because it is forced to= emit so many notifications that it overwhelms the CPU? Nhdpifstatechange NOTIFICATION-TYPE OBJECTS { nhdpIfName, -- The local interface nhdpIfState -- The new state } STATUS current DESCRIPTION "nhdpIfStateChange is a notification sent when the status of an interface of this router has changed (i.e. an IP address has been added or removed to the interface, or the interface has changed its status from up to down or vice versa)." ::=3D { nhdpNotificationsObjects 4 } -- nhdpNotificationsControl nhdpNbrStateChangeThreshold OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold value for the nhdpNbrStateChange object. If the number of occurrences exceeds this threshold within the previous nhdpNbrStateChangeWindow, Herberg, et al. Expires December 3, 2012 [Page 51] Internet-Draft The NHDP-MIB June 2012 then the nhdpNbrStateChange notification is to be sent. It is recommended that the value of this threshold be set to at least 10, and higher in dense topologies with frequent expected topology changes. " DEFVAL { 10 } ::=3D { nhdpNotificationsControl 1 } nhdpNbrStateChangeWindow OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-write STATUS current DESCRIPTION "A time window for the nhdpNbrStateChange object. If the number of occurrences exceeds the nhdpNbrStateChangeThreshold within the previous nhdpNbrStateChangeWindow, then the nhdpNbrStateChange notification is to be sent. It is recommended that the value for this window be set to at least 5 times the nhdpHelloInterval. This object represents the time in hundredths of a second. " DEFVAL { 1000 } ::=3D { nhdpNotificationsControl 2 } nhdp2HopNbrStateChangeThreshold OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold value for the nhdp2HopNbrStateChange object. If the number of occurrences exceeds this threshold within the previous nhdp2HopNbrStateChangeWindow, then the nhdp2HopNbrStateChange notification is to be sent. It is recommended that the value of this threshold be set to at least 10, and higher Herberg, et al. Expires December 3, 2012 [Page 52] Internet-Draft The NHDP-MIB June 2012 when topologies are expected to be highly dynamic. " DEFVAL { 10 } ::=3D { nhdpNotificationsControl 3 } nhdp2HopNbrStateChangeWindow OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-write STATUS current DESCRIPTION "A time window for the nhdp2HopNbrStateChange object. If the number of occurrences exceeds the nhdp2HopNbrStateChangeThreshold within the previous nhdp2HopNbrStateChangeWindow, then the nhdp2HopNbrStateChange notification is to be sent. It is recommended that the value for this window be set to at least 5 times nhdpHelloInterval. This object represents the time in hundredths of a second. " DEFVAL { 1000 } ::=3D { nhdpNotificationsControl 4 } nhdpIfRxBadPacketThreshold OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold value for the nhdpIfRxBadPacket object. If the number of occurrences exceeds this threshold within the previous nhdpIfRxBadPacketWindow, then the nhdpIfRxBadPacket notification is to be sent. " DEFVAL { 10 } ::=3D { nhdpNotificationsControl 5 } nhdpIfRxBadPacketWindow OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-write STATUS current DESCRIPTION Herberg, et al. Expires December 3, 2012 [Page 53] Internet-Draft The NHDP-MIB June 2012 "A time window for the nhdpIfRxBadPacket object. If the number of occurrences exceeds the nhdpIfRxBadPacketThreshold within the previous nhdpIfRxBadPacketWindow, then the nhdpIfRxBadPacket notification is to be sent. It is recommended that the value for this window be set to 5 times the nhdpHelloInterval. This object represents the time in hundredths of a second. " DEFVAL { 1000 } ::=3D { nhdpNotificationsControl 6 } -- nhdpNotificationStates nhdpNbrState OBJECT-TYPE SYNTAX INTEGER { down(0), asymmetric(1), symmetric(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "NHDP neighbor states. In NHDP it is not necessary to remove Protocol Tuples from Protocol Sets at the exact time indicated, only to behave as if the Protocol Tuples were removed at that time. This case is indicated here as 'down(0)', all other cases being indicated as 'assymetric(1)' or 'symmetric(2)'. If down, the direct neighbor is also added to the nhdpNibLostNeighborSetTable. " ::=3D { nhdpNotificationsStates 1 } nhdp2HopNbrState OBJECT-TYPE SYNTAX INTEGER { down(0), up(1) } MAX-ACCESS read-only STATUS current Herberg, et al. Expires December 3, 2012 [Page 54] Internet-Draft The NHDP-MIB June 2012 DESCRIPTION "NHDP 2-hop neighbor states. In NHDP it is not necessary to remove Protocol Tuples from Protocol Sets at the exact time indicated, only to behave as if the Protocol Tuples were removed at that time. This case is indicated here as 'down(0)', otherwise as 'up(1)'." ::=3D { nhdpNotificationsStates 2 } Nhdpifstate Object-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "NHDP MANET interface states. This indicates whether the interface is a MANET interface. A value of true(1) indicates that the interface is a MANET interface. A value of false(2) indicates that the interface is not a MANET interface. This corresponds to the I_manet parameter in the Local Interface Set." ::=3D { nhdpNotificationsStates 3 } TOM: This notification is potentially dangerous given how the IfTable relat= ionship is currently defined above to be essentially a 1:1 match with the I= fEntry. Imagine having to issue notifications constantly for IF state chan= ges for every interface in the normal IF-MIB and then here? Also, what val= ue does this notification add above/beyond the normal IfUp/Down notificatio= n if you define an ifType=3Dmanet as I suggested above? nhdpPacketSrcAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address type of the address of an inbound packet that cannot be identified by a neighbor instance. Only the values ipv4(1) and ipv6(2) are supported. " ::=3D { nhdpNotificationsStates 4 } nhdpPacketSrcAddr Object-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of an inbound packet that cannot be identified by a neighbor instance. When the last value of a notification using this object is needed, but no notifications of that type have been sent, the value pertaining to this object should be returned as 0.0.0.0 or :: respectively. " ::=3D { nhdpNotificationsStates 5 } Herberg, et al. Expires December 3, 2012 [Page 55] Internet-Draft The NHDP-MIB June 2012 -- -- nhdpConformance information -- nhdpCompliances OBJECT IDENTIFIER ::=3D { nhdpConformance 1 } nhdpMIBGroups OBJECT IDENTIFIER ::=3D { nhdpConformance 2 } -- Compliance Statements nhdpBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The basic implementation requirements for managed network entities that implement NHDP." MODULE -- this module MANDATORY-GROUPS { nhdpConfigurationGroup } ::=3D { nhdpCompliances 1 } nhdpFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The full implementation requirements for managed network entities that implement NHDP." MODULE -- this module MANDATORY-GROUPS { nhdpConfigurationGroup, nhdpStateGroup, nhdpNotificationObjectGroup, nhdpNotificationGroup, nhdpPerformanceGroup } ::=3D { nhdpCompliances 2 } -- -- Units of Conformance -- nhdpConfigurationGroup OBJECT-GROUP OBJECTS { nhdpIfName, nhdpIfStatus, nhdpHelloInterval, nhdpHelloMinInterval, nhdpRefreshInterval, Herberg, et al. Expires December 3, 2012 [Page 56] Internet-Draft The NHDP-MIB June 2012 nhdpLHoldTime, nhdpHHoldTime, nhdpHystAcceptQuality, nhdpHystRejectQuality, nhdpInitialQuality, nhdpInitialPending, nhdpHpMaxJitter, nhdpHtMaxJitter, nhdpNHoldTime, nhdpIHoldTime, nhdpIfRowStatus, nhdpLibLocalIfSetIfIndex, nhdpLibLocalIfSetIpAddrType, nhdpLibLocalIfSetIpAddr, nhdpLibLocalIfSetIpAddrPrefixLen, nhdpLibLocalIfSetIsManet, nhdpLibLocalIfSetRowStatus, nhdpLibRemovedIfAddrSetIpAddrType, nhdpLibRemovedIfAddrSetIpAddr, nhdpLibRemovedIfAddrSetIpAddrPrefixLen, nhdpLibRemovedIfAddrSetIfIndex, nhdpLibRemovedIfAddrSetIRTime } STATUS current DESCRIPTION "Set of NHDP configuration objects implemented in this module." ::=3D { nhdpMIBGroups 2 } nhdpStateGroup OBJECT-GROUP OBJECTS { nhdpUpTime, nhdpIfStateUpTime, nhdpDiscRouterIndex, nhdpDiscIfIndex, nhdpDiscIfSetIpAddrType, nhdpDiscIfSetIpAddr, nhdpDiscIfSetIpAddrPrefixLen, nhdpIibLinkSetLHeardTime, nhdpIibLinkSetLSymTime, nhdpIibLinkSetLPending, nhdpIibLinkSetLLost, nhdpIibLinkSetLTime, nhdpIib2HopSetIpAddrPrefixLen, nhdpIib2HopSet1HopIfIndex, nhdpIib2HopSetN2Time, nhdpNibNeighborSetNSymmetric, nhdpNibLostNeighborSetNLTime Herberg, et al. Expires December 3, 2012 [Page 57] Internet-Draft The NHDP-MIB June 2012 } STATUS current DESCRIPTION "Set of NHDP state objects implemented in this module." ::=3D { nhdpMIBGroups 3 } nhdpPerformanceGroup OBJECT-GROUP OBJECTS { nhdpIfHelloMessageXmits, nhdpIfHelloMessageRecvd, nhdpIfHelloMessageXmitAccumulatedSize, nhdpIfHelloMessageRecvdAccumulatedSize, nhdpIfHelloMessageTriggeredXmits, nhdpIfHelloMessagePeriodicXmits, nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount, nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount, nhdpIfHelloMessageXmitAccumulatedLostNeighborCount, nhdpDiscIfRecvdPackets, nhdpDiscIfExpectedPackets, nhdpNibNeighborSetChanges, nhdpDiscNeighborNibNeighborSetChanges, nhdpDiscNeighborNibNeighborSetUpTime, nhdpDiscNeighborNibNeighborSetReachableLinkChanges, nhdpIib2HopSetPerfChanges, nhdpIib2HopSetPerfUpTime } STATUS current DESCRIPTION "Set of NHDP performance objects implemented in this module." ::=3D { nhdpMIBGroups 4 } nhdpNotificationObjectGroup OBJECT-GROUP OBJECTS { nhdpNbrStateChangeThreshold, nhdpNbrStateChangeWindow, nhdp2HopNbrStateChangeThreshold, nhdp2HopNbrStateChangeWindow, nhdpIfRxBadPacketThreshold, nhdpIfRxBadPacketWindow, nhdpIfState, nhdpNbrState, nhdp2HopNbrState, nhdpPacketSrcAddrType, nhdpPacketSrcAddr } STATUS current Herberg, et al. Expires December 3, 2012 [Page 58] Internet-Draft The NHDP-MIB June 2012 DESCRIPTION "Set of NHDP notification objects implemented in this module." ::=3D { nhdpMIBGroups 5 } nhdpNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { nhdpNbrStateChange, nhdp2HopNbrStateChange, nhdpIfRxBadPacket, nhdpIfStateChange } STATUS current DESCRIPTION "Set of NHDP notifications implemented in this module." ::=3D { nhdpMIBGroups 6 } END 8. Security Considerations This MIB module defines objects for the configuration, monitoring and notification of the Neighborhood Discovery Protocol [RFC6130]. NHDP allows routers to acquire topological information up to two hops away by virtue of exchanging HELLO messages. The information acquired by NHDP may be used by routing protocols. The neighborhood information, exchanged between routers using NHDP, serves these routing protocols as a baseline for calculating paths to all destinations in the MANET, relay set selection for network-wide transmissions etc. There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o nhdpIfStatus - this writable object turns on or off the NHDP process for the specified interface. If disabled, higher level protocol functions, e.g., routing, would fail causing network-wide disruptions. Herberg, et al. Expires December 3, 2012 [Page 59] Internet-Draft The NHDP-MIB June 2012 o nhdpHelloInterval, nhdpHelloMinInterval, and nhdpRefreshInterval - these writable objects control the rate at which HELLO messages are sent on an interface. If set at too high a rate, this could represent a form of DOS attack by overloading interface resources. o nhdpHystAcceptQuality, nhdpHystRejectQuality, nhdpInitialQuality, nhdpInitialPending - these writable objects affect the perceived quality of the NHDP links and hence the overall stability of the network. If improperly set, these settings could result in network-wide disruptions. o nhdpInterfaceTable - this table contains writable objects that affect the overall performance and stability of the NHDP process. Failure of the NHDP process would result in network-wide failure. Particularly sensitive objects from this table are discussed in the previous list items. This is the only table in the NHDP-MIB module with writable objects. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o nhdpDiscIfSetTable - The object contains information on discovered neighbors, specifically their IP address in the nhdpDiscIfSetIpAddr object. This information provides an adversary broad information on the members of the MANET, located within this single table. This information can be use to expedite attacks on the other members of the MANET without having to go through a laborious discovery process on their own. This object is the index into the table, and has a MAX-ACCESS of 'not- accessible'. However, this information can be exposed using SNMP operations. MANET technology is often deployed to support communications of emergency services or military tactical applications. In these applications, it is imperative to maintain the proper operation of the communications network and to protect sensitive information related to its operation. Therefore, it is RECOMMENDED to provide support for the Transport Security Model (TSM) [RFC5591] in combination with TLS/DTLS [RFC6353]. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), there is no control as to who on the secure network is allowed to Herberg, et al. Expires December 3, 2012 [Page 60] Internet-Draft The NHDP-MIB June 2012 access and GET/SET (read/change/create/delete) the objects in this MIB module. Implementations MUST provide the security features described by the SNMPv3 framework (see [RFC3410] ), including full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations MAY also provide support for the Transport Security Model (TSM) [RFC5591] in combination with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353]. Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 9. IANA Considerations Editor's Note (to be removed prior to publication): the IANA is requested to assign a value for "XXXX" under the 'mib-2' subtree and to record the assignment in the SMI Numbers registry. When the assignment has been made, the RFC Editor is asked to replace "XXXX" (here and in the MIB module) with the assigned value and to remove this note. Note well: prior to official assignment by the IANA, a draft document MUST use placeholders (such as "XXXX" above) rather than actual numbers. See RFC4181 Section 4.5 for an example of how this is done in a draft MIB module. 10. Acknowledgements The authors wish to thank Thomas Clausen, Justin Dean, and Adrian Farrel for their detailed reviews and insightful comments to this document. This MIB document uses the template authored by D. Harrington which is based on contributions from the MIB Doctors, especially Juergen Schoenwaelder, Dave Perkins, C.M.Heard and Randy Presuhn. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Herberg, et al. Expires December 3, 2012 [Page 61] Internet-Draft The NHDP-MIB June 2012 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011. [RFC6340] Presuhn, R., "Textual Conventions for the Representation of Floating-Point Numbers", RFC 6340, August 2011. 11.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model", RFC 3826, June 2004. Herberg, et al. Expires December 3, 2012 [Page 62] Internet-Draft The NHDP-MIB June 2012 [RFC4750] Joyal, D., Galecki, P., Giacalone, S., Coltun, R., and F. Baker, "OSPF Version 2 Management Information Base", RFC 4750, December 2006. [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter Considerations in Mobile Ad Hoc Networks (MANETs)", RFC 5148, February 2008. [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", RFC 5591, June 2009. [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5592, June 2009. [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", RFC 6353, July 2011. [REPORT-MIB] Cole, R., Macker, J., and A. Bierman, "Definition of Managed Objects for Performance Reporting", work in progress draft-ietf-manet-report-mib-02, January 2012. Appendix A. *************************************************************** * Note to the RFC Editor (to be removed prior to publication) * * * * The reference to RFCXXXX within the DESCRIPTION clauses * * of the MIB module point to this draft and are to be * * assigned by the RFC Editor. * * * *************************************************************** Why is "Appendix A" as a section necessary? Are you telling the RFC editor= to remove the section and also modify the table of contents? Its just eas= ier to discard the section now. Authors' Addresses Ulrich Herberg LIX, Ecole Polytechnique Palaiseau Cedex, 91128 France EMail: ulrich@herberg.name URI: http://www.herberg.name/ Herberg, et al. Expires December 3, 2012 [Page 63] Internet-Draft The NHDP-MIB June 2012 Robert G. Cole US Army CERDEC 6010 Frankford Road, Bldg 6010 Aberdeen Proving Ground, Maryland 21005 USA Phone: +1 443 395 8744 EMail: robert.g.cole@us.army.mil URI: http://www.cs.jhu.edu/~rgcole/ Ian D Chakeres CenGen 9250 Bendix Road North Columbia, Maryland 560093 USA EMail: ian.chakeres@gmail.com URI: http://www.ianchak.com/ Herberg, et al. Expires December 3, 2012 [Page 64] < From: Adrian Farrel > Reply-To: "adrian@olddog.co.uk" > To: 'Ulrich Herberg' >, "'B= ert Wijnen (IETF)'" > Cc: "manet-chairs@tools.ietf.org" >, "draft-ietf-m= anet-nhdp-mib@tools.ietf.org" >, "'MIB Doctors (E-mail)'" > Subject: Re: [MIB-DOCTORS] Heads-up MIB review impending Ulrich, just in case you are no aware of http://www.ibr.cs.tu-bs.de/projects/libsmi= /tools/ Adrian From: Ulrich Herberg [mailto:ulrich@herberg.name] Sent: 22 May 2012 19:37 To: Bert Wijnen (IETF) Cc: Benoit Claise; Adrian Farrel; manet-chairs@tools.ietf.org; MIB Doctors (E-mail); draft-ietf-manet-nhdp-mib@too= ls.ietf.org Subject: Re: [MIB-DOCTORS] Heads-up MIB review impending Bert, On Tue, May 22, 2012 at 11:33 AM, Bert Wijnen (IETF) > wrote: Unfortunately, there is not a free version (at least not current) available as far as I know. I don;t understand why the author does not just make it open source and available to everyone. But that is his call I guess. Okay, I see. My company will likely not pay for that, and personally I'd ra= ther go to vacations than buy a MIB compiler ;-) Oh by the way, you also already user { mib-2 998 } for the MIB OID!!! that is not proper! You should use xxx or some such instead of 998 (as you indicate in the rfc-editor comment ;-) I know, that has been discovered in the IESG LC. The reason why we did not = put xxxx there is that smilint complains otherwise and fails to compile. It= will be fixed in the next revision of the draft (or in the RFC editor queu= e). Best Ulrich Bert On 5/22/12 7:03 PM, Ulrich Herberg wrote: Bert, thank you very much for this first review. We will work on fixing these and= spin a new version. By the way, is there a free version of SMICng available? I only have smilin= t. Best regards Ulrich On Tue, May 22, 2012 at 2:11 AM, Bert Wijnen (IETF) >> wrote: This is by no means a full MIB review, but I did a quick SMICng SYNTAX c= heck: W: f(nhdp.mi2), (778,5) Row "nhdpLibRemovedIfAddrSetEntry" has indexing that may create variables with more than 128 sub-ids W: f(nhdp.mi2), (1221,5) Row "nhdpIib2HopSetEntry" has indexing that may create variables with more than 128 sub-ids W: f(nhdp.mi2), (1117,16) Row "nhdpIibLinkSetEntry" does not have a consistent indexing scheme - index item nhdpDiscIfIndex from base row nhdpDiscIfSetEntry is not defined as an index item W: f(nhdp.mi2), (1376,15) Row "nhdpNibNeighborSetEntry" does not have a consistent indexing scheme - index item nhdpDiscRouterIndex from ba= se row nhdpDiscIfSetEntry is not defined as an index item W: f(nhdp.mi2), (1425,16) Row "nhdpNibLostNeighborSetEntry" does not hav= e a consistent indexing scheme - index item nhdpDiscRouterIndex from = base row nhdpDiscIfSetEntry is not defined as an index item W: f(nhdp.mi2), (1614,16) Row "nhdpDiscIfSetPerfEntry" does not have a consistent indexing scheme - index item nhdpDiscIfIndex from base r= ow nhdpDiscIfSetEntry is not defined as an index item W: f(nhdp.mi2), (1690,16) Row "nhdpDiscNeighborSetPerfEntry" does not have a consistent indexing scheme - index item nhdpDiscRouterIndex = from base row nhdpDiscIfSetEntry is not defined as an index item W: f(nhdp.mi2), (1768,16) Row "nhdpIib2HopSetPerfEntry" does not have a consistent indexing scheme - index item nhdpDiscRouterIndex from ba= se row nhdpDiscIfSetEntry is not defined as an index item W: f(nhdp.mi2), (1941,21) Variable "nhdpIfIndex" in notification "nhdpNbrStateChange" is an index for a table W: f(nhdp.mi2), (1956,21) Variable "nhdpIfIndex" in notification "nhdp2HopNbrStateChange" is an index for a table W: f(nhdp.mi2), (1973,21) Variable "nhdpIfIndex" in notification "nhdpIfRxBadPacket" is anindex for a table W: f(nhdp.mi2), (1992,21) Variable "nhdpIfIndex" in notification "nhdpIfStateChange" is anindex for a table W: f(nhdp.mi2), (2142,22) Duplicate item "nhdpPerformanceGroup" in MANDATORY-GROUPS for module "NHDP-MIB" The first Warning got me to look at: nhdpLibRemovedIfAddrSetEntry OBJECT-TYPE SYNTAX NhdpLibRemovedIfAddrSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A router's Removed Interface Address Set consists of Removed Interface Address Tuples, one per network address: (IR_local_iface_addr, IR_time) The association between these addrs and the router's Interface is found in the Standard MIB II's IP address table (RFC1213)." REFERENCE "RFC6130." INDEX { nhdpLibRemovedIfAddrSetIpAddrT__ype, nhdpLibRemovedIfAddrSetIpAddr } ::=3D { nhdpLibRemovedIfAddrSetTable 1 } NhdpLibRemovedIfAddrSetEntry ::=3D SEQUENCE { nhdpLibRemovedIfAddrSetIpAddrT__ype InetAddressType, nhdpLibRemovedIfAddrSetIpAddr InetAddress, nhdpLibRemovedIfAddrSetIpAddrP__refixLen InetAddressPrefixLength, nhdpLibRemovedIfAddrSetIfIndex InterfaceIndexOrZero, nhdpLibRemovedIfAddrSetIRTime TimeStamp } nhdpLibRemovedIfAddrSetIpAddrT__ype OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the nhdpLibRemovedIfAddrSetIpAddr in the InetAddress MIB (RFC4001). Only the values ipv4(1) and ipv6(2) are supported." REFERENCE "RFC6130." ::=3D { nhdpLibRemovedIfAddrSetEntry 1 } nhdpLibRemovedIfAddrSetIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpLibRemovedIfAddrSetIpAddr is a recently used address of an interface of this router." REFERENCE "RFC6130." ::=3D { nhdpLibRemovedIfAddrSetEntry 2 } And I note that: - the 2 INDEX obbjects are defined read-only. Normally they would be not-accessible!!! See RFC2578 - If this is ALWAYS true: nhdpLibRemovedIfAddrSetIpAddrT__ype OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the nhdpLibRemovedIfAddrSetIpAddr in the InetAddress MIB (RFC4001). Only the values ipv4(1) and ipv6(2) are supported." Then you could do: nhdpLibRemovedIfAddrSetIpAddr OBJECT-TYPE SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS read-only Otherwise you would have to add something to description clause to warn implementers that they should consider OID size. The third warning: W: f(nhdp.mi2), (1117,16) Row "nhdpIibLinkSetEntry" does not have a consistent indexing scheme - index item nhdpDiscIfIndex from bas= e row nhdpDiscIfSetEntry is not defined as an index item Seems a valid warning. But I am not 100% sure. I'd have to go and study more detauil to determine. Anyways, these "inconsistent indexing" warnings are indeed just warnings. It may be OK, but it would be good to check and make sure that this results in proper (i.e. unique) indexing values and that the indexing is indeed as intended. Sorry, not enough time to check more details now. Bert ----- Original Message ----- From: "Benoit Claise" = >> To: >> Cc: >>; >>; >> Sent: Tuesday, May 22, 2012 12:15 AM Subject: Re: [MIB-DOCTORS] Heads-up MIB review impending Dear all, I have deferred this draft for the next telechat. Regards, Benoit. Hi MIB doctors, We would really benefit from your expertise here. Can we please have a volunteer. If we don't find someone by the end of the day (on telechat for = this Thursday), I'm afraid that I will have to defer this draft to th= e next telechat... Regards, Benoit. Hi MIB doctors, My bad for not following up on this one. I will follow more = closely from now on. Can we please have a volunteer to review this MIB module, wh= ich is on the IESG telechat for next Thursday. Regards, Benoit. Hi MIB Doctors, Heads up to give you extra review time. https://datatracker.ietf.org/__doc/draft-ietf-manet-nhdp= -mib/ is going to IETF last call very soon and would benefit significantly from= a MIB Doctor review by the end of the last call. Thanks for the work you do. Adrian _________________________________________________ MIB-DOCTORS mailing list MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/__listinfo/mib-doctors _________________________________________________ MIB-DOCTORS mailing list MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/__listinfo/mib-doctors _________________________________________________ MIB-DOCTORS mailing list MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/__listinfo/mib-doctors _________________________________________________ MIB-DOCTORS mailing list MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/__listinfo/mib-doctors From tnadeau@juniper.net Thu Jun 7 04:46:50 2012 Return-Path: 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 52E1021F86D5 for ; Thu, 7 Jun 2012 04:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.417 X-Spam-Level: X-Spam-Status: No, score=-4.417 tagged_above=-999 required=5 tests=[AWL=-1.784, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, J_CHICKENPOX_31=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] 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 HZjIgIVPjJ4q for ; Thu, 7 Jun 2012 04:46:43 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id C903721F86D4 for ; Thu, 7 Jun 2012 04:46:37 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKT9CUmEVOi0WqcMEgsZd1rW5MLjsd7rX9@postini.com; Thu, 07 Jun 2012 04:46:42 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 7 Jun 2012 04:45:46 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 7 Jun 2012 07:45:45 -0400 From: Thomas Nadeau To: Ulrich Herberg Date: Thu, 7 Jun 2012 07:45:24 -0400 Thread-Topic: [MIB-DOCTORS] Heads-up MIB review impending Thread-Index: Ac1EoxLKFggykfxOSVWe8Fz1b3qbKA== Message-ID: <61B99065-6F2B-4A31-82C1-3335970507EF@juniper.net> References: <165b01cd385d$88067150$981353f0$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "MIB Doctors \(E-mail\)" , "draft-ietf-manet-nhdp-mib@tools.ietf.org" , "manet-chairs@tools.ietf.org" , "adrian@olddog.co.uk" Subject: Re: [MIB-DOCTORS] Heads-up MIB review impending X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 11:46:50 -0000 glad to help. please let me know of you have any questions or want to walk = through any needed changes. Tom On Jun 6, 2012, at 10:03 PM, "Ulrich Herberg" wrote: > Thomas, Benoit, > > thank you very much for the reviews. This is extremely valuable for > us, and we will work on addressing all your concerns in a new revision > in the following days. Since this is the first of several MIB > documents in the MANET WG, we want to get this one right, so the > following ones will be a piece of cake. > > Best regards > Ulrich and Bob > > On Wed, Jun 6, 2012 at 6:22 PM, Thomas Nadeau wrote= : >> >> Hi all, >> >> Here are my MIB Doctor review comments on the draft-ietf-manet-nhdp-mib-= 13 MIB. >> >> This document is clearly written and the examples are well done. >> >> My review is divided into two sections: General Comments, and specific c= omments inline starting with TOM: >> >> General Comments >> ---------------- >> >> >> 1. I did not re-compile the MIB as I am assuming Bert's comments from c= ompilation were sufficient. These comments are IN ADDITION to Bert's so pl= ease make fixes required from his comments too. >> >> 2. Please go through the objects in the module and look for uses of DISP= LAY-STRING and UNITS where possible. There are numerous cases where it shou= ld 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 behavi= ors. 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 ve= ry 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 fi= rst 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 w= ant 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 thin= k you want to do is have this relationship: >> >> ifEntry NhdpInterfaceEntry >> 1, ifType=3Dmols >> 2, ifType=3Dmpls >> 3, ifType=3Dmanet ---------> 3 >> 4, ifType =3D manet ---------> 4 >> 5, ifType =3D mpls >> >> That is, you do not have entries in the NhdpInterfaceEntry table for ifI= ndex-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 f= irst one. Please go through the document and make these corrections, and pl= ease 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 easies= t thing to do is create a StorageType object in each table and define its s= emantics. I have only noted one case of this, but there are a number of th= em. >> >> 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 "s= ignificant number"; you need to define what you expect this means. In fac= t, there is a lot of examples for defining explicit MIB variables like nhdp= NbrStateChangeThreshold that explicitly define this. This will help aid int= eroperability. All of the notifications suffer from this deficiency. >> >> >> 11. The notifications emitted here seem to be potentially of a high volu= me given that manet applications can include massive numbers of "mobile" de= vices. You really should include some limiting/throttling parameters as exp= licit MIB configuration values. I know that you have defined this in some = of the description clauses, but this is not easily interoperable, especiall= y if implementations really need to use smaller values. Also, the way thin= gs 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 o= verwhelms 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 ma= tch 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/Do= wn notification if you define an ifType=3Dmanet as I suggested above? >> >> 13. The nhdpPacketSrcAddr notification has no limits or throttling. Wh= at if %100 of the packets sent to the device match this criteria? Do you is= sue a notification for every one? >> >> >> >> >> >> >> Internet Engineering Task Force U. Herberg >> Internet-Draft LIX, Ecole Polytechnique >> Intended status: Standards Track R. Cole >> Expires: December 3, 2012 US Army CERDEC >> I. Chakeres >> CenGen >> June 1, 2012 >> >> >> Definition of Managed Objects for the Neighborhood Discovery Protocol >> draft-ietf-manet-nhdp-mib-14 >> >> 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. The MIB module defined in this memo, denoted NHDP-MIB, also >> reports state, performance information and notifications. This >> >> TOM: Change the above to: >> >> "reports state, performance information and notifications about NHDP.= This" >> >> >> additional state and performance information is useful to >> troubleshoot problems and performance issues during neighbor >> discovery. >> >> Status of This Memo >> >> This Internet-Draft is submitted in full conformance with the >> provisions of BCP 78 and BCP 79. >> >> Internet-Drafts are working documents of the Internet Engineering >> Task Force (IETF). Note that other groups may also distribute >> working documents as Internet-Drafts. The list of current Internet- >> Drafts is at http://datatracker.ietf.org/drafts/current/. >> >> Internet-Drafts are draft documents valid for a maximum of six months >> and may be updated, replaced, or obsoleted by other documents at any >> time. It is inappropriate to use Internet-Drafts as reference >> material or to cite them other than as "work in progress." >> >> This Internet-Draft will expire on December 3, 2012. >> >> Copyright Notice >> >> Copyright (c) 2012 IETF Trust and the persons identified as the >> document authors. All rights reserved. >> >> This document is subject to BCP 78 and the IETF Trust's Legal >> Provisions Relating to IETF Documents >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 1] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> (http://trustee.ietf.org/license-info) in effect on the date of >> publication of this document. Please review these documents >> carefully, as they describe your rights and restrictions with respect >> to this document. Code Components extracted from this document must >> include Simplified BSD License text as described in Section 4.e of >> the Trust Legal Provisions and are provided without warranty as >> described in the Simplified BSD License. >> >> Table of Contents >> >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 2. The Internet-Standard Management Framework . . . . . . . . . . 3 >> 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 4.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 4 >> 5.1. Notifications . . . . . . . . . . . . . . . . . . . . . . 4 >> 5.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 4 >> 5.1.2. Notification Generation . . . . . . . . . . . . . . . 5 >> 5.1.3. Limiting Frequency of Notifications . . . . . . . . . 5 >> 5.2. The Configuration Group . . . . . . . . . . . . . . . . . 6 >> 5.3. The State Group . . . . . . . . . . . . . . . . . . . . . 6 >> 5.4. The Performance Group . . . . . . . . . . . . . . . . . . 7 >> 5.5. Tables and Indexing . . . . . . . . . . . . . . . . . . . 7 >> 6. Relationship to Other MIB Modules . . . . . . . . . . . . . . 9 >> 6.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . . . 9 >> 6.2. Relationship to Routing Protocol MIB Modules Relying >> on the NHDP-MIB Module . . . . . . . . . . . . . . . . . . 9 >> 6.3. MIB Modules Required for IMPORTS . . . . . . . . . . . . . 10 >> 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 10 >> 8. Security Considerations . . . . . . . . . . . . . . . . . . . 59 >> 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 >> 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 61 >> 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 >> 11.1. Normative References . . . . . . . . . . . . . . . . . . . 61 >> 11.2. Informative References . . . . . . . . . . . . . . . . . . 62 >> Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . 63 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 2] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> 1. Introduction >> >> 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 [RFC6130] process >> on a router. The MIB module defined in this memo, denoted NHDP-MIB, >> also reports state, performance information and notifications. This >> additional state and performance information is useful to >> troubleshoot problems and performance issues during neighbor >> discovery. >> >> 2. The Internet-Standard Management Framework >> >> For a detailed overview of the documents that describe the current >> Internet-Standard Management Framework, please refer to Section 7 of >> [RFC3410]. >> >> Managed objects are accessed via a virtual information store, termed >> the Management Information Base or MIB. MIB objects are generally >> accessed through the Simple Network Management Protocol (SNMP). >> Objects in the MIB module are defined using the mechanisms defined in >> the Structure of Management Information (SMI). This memo specifies a >> MIB module that is compliant to the SMIv2, which is described in >> [RFC2578], [RFC2579] and [RFC2580]. >> >> 3. Conventions >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and >> OPTIONAL" in this document are to be interpreted as described in >> [RFC2119]. >> >> 4. Overview >> >> [RFC6130] allows a router in a Mobile Ad Hoc Network (MANET) to >> discover and track topological information of routers up to two hops >> away by virtue of exchanging HELLO messages. This information is >> useful for routers running various routing and multicast flooding >> protocols developed within the IETF MANET Working Group. >> >> 4.1. Terms >> >> The following definitions apply throughout this document: >> >> o Notification Objects - triggers and associated notification >> messages allowing for asynchronous tracking of pre-defined events >> on the managed router. >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 3] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> o Configuration Objects - switches, tables, objects which are >> initialized to default settings or set through the management >> interface defined by this MIB module. >> >> o State Objects - automatically generated values which define the >> current operating state of the NHDP protocol process in the >> router. >> >> o Performance Objects - automatically generated values which help an >> administrator or automated tool to assess the performance of the >> NHDP protocol process on the router and the overall discovery >> performance within the MANET. >> >> 5. Structure of the MIB Module >> >> This section presents the structure of the NHDP-MIB module. The MIB >> module is arranged into the following structure: >> >> o nhdpNotifications - objects defining NHDP-MIB notifications. >> >> o nhdpObjects - defining objects within this MIB module. The >> objects are arranged into the following groups: >> >> * Configuration Group - defining objects related to the >> configuration of the NHDP instance on the router. >> >> * State Group - defining objects which reflect the current state >> of the NHDP instance running on the router. >> >> * Performance Group - defining objects which are useful to a >> management station when characterizing the performance of NHDP >> on the router and in the MANET. >> >> o nhdpConformance - defining the minimal and maximal conformance >> requirements for implementations of this MIB module. >> >> 5.1. Notifications >> >> This section describes the use of notifications, and mechanisms to >> enhance the ability to manage NHDP networks. >> >> 5.1.1. Introduction >> >> Notifications can be emitted by an NHDP router as a reaction to a >> specific event. This allows a network manager to efficiently >> determine the source of problems or significant changes of >> configuration or topology, instead of polling a possibly large number >> of NHDP routers. >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 4] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> 5.1.2. Notification Generation >> >> When an exception event occurs, the application notifies the local >> agent, which sends a notification to the appropriate SNMP management >> stations. The message includes the notification type and may include >> a list of notification-specific variables. Section 7 contains the >> notification definitions, which includes the variable lists. At >> least one IP address of the NHDP router that originates the >> notification is included in the variable list so that the network >> manager may determine the source of the notification. >> >> 5.1.3. Limiting Frequency of Notifications >> >> To limit the frequency of notifications, the following additional >> mechanisms are suggested, similar to those in [RFC4750]: >> >> 5.1.3.1. Ignoring Initial Activity >> >> The majority of critical events occur when NHDP is first enabled on a >> router, at which time the symmetric neighbors and two-hop neighbors >> of the NHDP router are discovered. During this initial period, a >> potential flood of notifications is unnecessary since the events are >> expected. To avoid unnecessary notifications, a router SHOULD NOT >> originate expected notifications until a certain time interval has >> elapsed, which is to be predefined by the network manager. It is >> RECOMMENDED that this time interval is at least 3 x >> 'nhdpHelloInterval', so that symmetric neighbors are discovered. The >> suppression window for notifications is started when the >> 'nhdpIfStatus' transitions from its default value of 'false' to >> 'true' >> >> 5.1.3.2. Throttling Notifications >> >> The mechanism for throttling the notifications is the same as in >> [RFC4750] (i.e. the amount of transmitted notifications per time is >> bounded). >> >> Appropriate values for the window time and upper bound are to be >> selected by the network manager and depend on the deployment of the >> MANET. If NHDP is deployed on a lossy, wireless medium, sending too >> many notifications in a short time interval may lead to collisions >> and dropped packets. In particular, in dense deployments of NHDP >> routers (i.e. where each router has many neighbors), a change of the >> local topology may trigger many notifications at the same time. >> [RFC4750] recommends "7 notifications with a window time of 10 >> seconds" as upper bound. As NHDP is expected to be deployed in more >> >> TOM: Change to "as the upper bound." >> >> lossy channels than OSPF, it is RECOMMENDED to choose a lower >> threshold for the number of notifications per time than that. >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 5] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> Specifically it is RECOMMENDED to choose a threshold value for the >> objects reflecting the change be set to a value of '10' and have set >> the DEFAULT values for these objects within the Notifications Group >> to this value. Further, a time window for the change objects is >> defined within this MIB module. It is RECOMMENDED that if the number >> of occurrences exceeds the change threshold within the previous >> change window, then the notification is to be sent. Furthermore, it >> is RECOMMENDED that the value for this window be set to at least 5 >> times the 'nhdpHelloInterval'. >> >> 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'. >> >> 5.1.3.3. One Notification per Event >> >> Similar to the mechanism in [RFC4750], only one notification is sent >> per event. >> >> 5.2. The Configuration Group >> >> The NHDP router is configured with a set of controls. The >> authoritative list of configuration controls within the NHDP-MIB >> module are found within the MIB module itself. Generally, an attempt >> was made in developing the NHDP-MIB module to support all >> configuration objects defined in [RFC6130]. For all of the >> configuration parameters, the same constraints and default values of >> these parameters as defined in [RFC6130] are followed. Refer to >> [RFC5148] for guidance on setting jitter related parameters, e.g., >> nhdpMaxJitter. >> >> 5.3. The State Group >> >> The State Group reports current state information of a router running >> [RFC6130]. The NHDP-MIB State Group tables were designed to contain >> the complete set of state information defined within the information >> bases specified in Section 6, Section 7 and Section 8 of [RFC6130]. >> >> Two constructs, i.e., TEXTUAL CONVENTIONs, are defined to support of >> the tables in the State Group. The NHDP protocol stores and indexes >> information through sets of (dynamically defined) addresses, i.e., >> address sets. Within SMIv2 it is not possible to index tables with >> variably defined address sets. Hence, these TEXTUAL CONVENTIONS are >> defined to provide a local mapping between NHDP managed address sets >> and SMIv2 table indexing. These constructs are the NeighborIfIndex >> and NeighborRouterIndex. These are locally (to the NHDP router) >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 6] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> defined, unique identifiers of virtual neighbors and neighbor >> interfaces. Due to the nature of the NHDP protocol, the local router >> may have identified distinct address sets but is not able to >> associate these as a single interface. Hence, two or more >> NeighborIfIndexes pointing to multiple distinct address sets may in >> fact be related to a common neighbor interface. This ambiguity may >> also hold with respect to the assignment of the NeighborRouterIndex. >> The local MIB agent is responsible for managing, aggregating and >> retiring the defined indexes, and in updating MIB tables using these >> indexes as the local router learns more about its neighbors' >> topology. These constructs are used to define indexes to the >> appropriate State Group tables and to correlate table entries to >> address sets, virtual neighbor interfaces and virtual neighbors >> within the MANET. >> >> 5.4. The Performance Group >> >> The Performance Group reports values relevant to system performance. >> Unstable neighbors or 2-hop neighbors and frequent changes of sets >> can have a negative influence on the performance of NHDP. This MIB >> module defines several objects that can be polled in order to, e.g., >> calculate histories or monitor frequencies of changes. This may help >> the network administrator to determine unusual topology changes or >> other changes that affect stability and reliability of the MANET. >> One such framework is specified in [REPORT-MIB]. >> >> 5.5. Tables and Indexing >> >> The NHDP-MIB module contains a number of tables which record data >> related to: >> >> o the local NHDP router, >> >> o a local NHDP interface on the NHDP router, >> >> o other NHDP routers which are 1-hop removed from the local NHDP >> router, >> >> o interfaces on other NHDP routers which are 1-hop removed from the >> local NHDP router, and >> >> o other NHDP routers which are 2-hop removed from the local NHDP >> router. >> >> The NHDP-MIB module's tables are indexed via the following >> constructs: >> >> >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 7] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> o nhdpIfIndex - which is the IfIndex of the local router on which >> NHDP is enabled. >> >> o nhdpDiscIfIndex - a locally managed index representing a known >> interface on an NHDP neighboring router. >> >> o nhdpDiscRouterIndex - a locally managed index representing an ID >> of a known neighboring NHDP router. >> >> These tables and their indexing are: >> >> o nhdpInterfaceTable - describes the configuration of the interfaces >> of this NHDP router. This table has 'INDEX { nhdpIfIndex }'. >> >> o nhdpLibLocalIfSetTable - records all network addresses which are >> defined as local interface network addresses on this NHDP router. >> This table has 'INDEX { nhdpLibLocalIfSetIndex }'. >> >> o nhdpLibRemovedIfAddrSetTable - records network addresses which >> were recently used as local interface network addresses on this >> NHDP router but have been removed. This table has 'INDEX { >> nhdpLibRemovedIfAddrSetIndex }'. >> >> o nhdpInterfaceStateTable - records state information related to >> specific interfaces of this NHDP router. This table has 'INDEX { >> nhdpIfIndex }'. >> >> o nhdpDiscIfSetTable - include the nhdpDiscRouterIndex of the >> discovered router, the nhdpDiscIfIndex of the discovered interface >> and the current set of addresses associated with this neighbor >> interface. This table has 'INDEX { nhdpDiscIfSetIndex }'. >> >> o nhdpIibLinkSetTable - foreach local interface, this table records >> all links belonging to other routers which are, or recently were, >> 1-hop neighbors to this NHDP router. This table has 'INDEX { >> nhdpIfIndex, nhdpDiscIfIndex }'. >> >> o nhdpIib2HopSetTable - foreach local interface, this table records >> network addresses (one at a time) of symmetric 2-hop neighbors, >> and the symmetric links to symmetric 1-hop neighbors of this NHDP >> router through which these symmetric 2-hop neighbors can be >> reached. This table has 'INDEX { nhdpIfIndex, nhdpDiscIfIndex, >> nhdpIib2HopSetIpAddressType, nhdpIib2HopSetIpAddress }'. >> >> o nhdpNibNeighborSetTable - records all network addresses of each >> 1-hop neighbor to this NHDP router. This table has 'INDEX { >> nhdpDiscRouterIndex }'. >> >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 8] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> o nhdpNibLostNeighborSetTable - records network addresses of other >> NHDP routers which recently were symmetric 1-hop neighbors to this >> NHDP router, but which are now advertised as lost. This table has >> 'INDEX { nhdpDiscRouterIndex }'. >> >> o nhdpInterfacePerfTable - records performance objects that are >> measured foreach local NHDP interface on this NHDP router. This >> table has 'INDEX { nhdpIfIndex }'. >> >> o nhdpDiscIfSetPerfTable - records performance objects that are >> measured foreach discovered interface of a neighbor of this NHDP >> router. This table has 'INDEX { nhdpDiscIfIndex }'. >> >> o nhdpDiscNeighborSetPerfTable - records performance objects that >> are measured for discovered neighbors of this NHDP router. This >> table has 'INDEX { nhdpDiscRouterIndex }'. >> >> o nhdpIib2HopSetPerfTable - records performance objects that are >> measured for discovered 2-hop neighbors of this NHDP router. This >> table has 'INDEX { nhdpDiscRouterIndex }'. >> >> 6. Relationship to Other MIB Modules >> >> This section specifies the relationship of the MIB module contained >> in this document to other standards, particularly to standards >> containing other MIB modules. Definitions imported from other MIB >> modules and other MIB modules that SHOULD be implemented in >> conjunction with the MIB module contained within this document are >> identified in this section. >> >> 6.1. Relationship to the SNMPv2-MIB >> >> The 'system' group in the SNMPv2-MIB module [RFC3418] is defined as >> being mandatory for all systems, and the objects apply to the entity >> as a whole. The 'system' group provides identification of the >> management entity and certain other system-wide data. The NHDP-MIB >> module does not duplicate those objects. >> >> 6.2. Relationship to Routing Protocol MIB Modules Relying on the NHDP- >> MIB Module >> >> [RFC6130] allows routing protocols to rely on the neighborhood >> information that is discovered by means of HELLO message exchange. >> In order to allow for troubleshooting, fault isolation, and >> management of such routing protocols through a routing protocol MIB >> module, it may be desired to align the State Group tables of the >> NHDP-MIB module and the routing protocol MIB module. This is >> accomplished through the definition of two TEXTUAL-CONVENTIONS in the >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 9] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> NHDP-MIB module: the NeighborIfIndex and the NeighborRouterIndex. >> These object types are used to develop indexes into common NHDP-MIB >> module and routing protocol State Group tables. These objects are >> locally significant but should be locally common to the NHDP-MIB >> module and the routing protocol MIB module implemented on a common >> networked router. This will allow for improved cross referencing of >> information across the two MIB modules. >> >> 6.3. MIB Modules Required for IMPORTS >> >> The following NHDP-MIB module IMPORTS objects from SNMPv2-SMI >> [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], IF-MIB >> [RFC2863], INET-ADDRESS-MIB [RFC4001], and FLOAT-TC-MIB [RFC6340]. >> >> 7. Definitions >> >> This section contains the MIB module defined by the specification. >> >> NHDP-MIB DEFINITIONS ::=3D BEGIN >> >> -- This MIB module defines objects for the management of >> -- NHDP (RFC6130) - The Neighborhood Discovery Protocol, >> -- Clausen, T., Dearlove, C. and J. Dean, January 2011. >> >> IMPORTS >> >> MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, >> Counter32, Counter64, Integer32, Unsigned32, mib-2, >> TimeTicks >> FROM SNMPv2-SMI -- RFC2578 >> >> TEXTUAL-CONVENTION, TruthValue, TimeStamp, >> RowStatus, DisplayString >> FROM SNMPv2-TC -- RFC2579 >> >> MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP >> FROM SNMPv2-CONF -- STD58 >> >> InetAddressType, InetAddress, >> InetAddressPrefixLength >> FROM INET-ADDRESS-MIB -- RFC4001 >> >> InterfaceIndex >> FROM IF-MIB -- RFC2863 >> >> Float32TC >> FROM FLOAT-TC-MIB -- RFC6340 >> ; >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 10] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> nhdpMIB MODULE-IDENTITY >> LAST-UPDATED "201206011000Z" -- June 1, 2012 >> ORGANIZATION "IETF MANET Working Group" >> CONTACT-INFO >> "WG E-Mail: manet@ietf.org >> >> WG Chairs: sratliff@cisco.com >> jmacker@nrl.navy.mil >> >> >> Editors: Ulrich Herberg >> Ecole Polytechnique >> LIX >> 91128 Palaiseau Cedex >> France >> ulrich@herberg.name >> http://www.herberg.name/ >> >> Robert G. Cole >> US Army CERDEC >> Space and Terrestrial Communications >> 6010 Frankford Street >> Bldg 6010, Room 453H >> Aberdeen Proving Ground, MD 21005 >> USA >> +1 443 395-8744 >> robert.g.cole@us.army.mil >> http://www.cs.jhu.edu/~rgcole/ >> >> Ian D Chakeres >> CenGen >> 9250 Bendix Road North >> Columbia, Maryland 21045 >> USA >> ian.chakeres@gmail.com >> http://www.ianchak.com/" >> >> DESCRIPTION >> "This NHDP-MIB module is applicable to routers >> implementing the Neighborhood Discovery Protocol >> defined in RFC6130. >> >> Copyright (C) The IETF Trust (2012). This version >> of this MIB module is part of RFCXXXX; see the RFC >> itself for full legal notices." >> >> -- revision >> REVISION "201206011000Z" -- June 1, 2012 >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 11] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> DESCRIPTION >> "The first version of this MIB module, >> published as RFCXXXX. >> " >> -- RFC-Editor assigns XXXX >> ::=3D { mib-2 XXXX } -- to be assigned by IANA >> >> -- >> -- Top-Level Components of this MIB Module >> -- >> nhdpNotifications OBJECT IDENTIFIER ::=3D { nhdpMIB 0 } >> nhdpObjects OBJECT IDENTIFIER ::=3D { nhdpMIB 1 } >> nhdpConformance OBJECT IDENTIFIER ::=3D { nhdpMIB 2 } >> >> >> -- >> -- Textual Conventions >> -- >> -- Two new Textual Conventions have been defined in >> -- this MIB module for indexing into the following >> -- tables and indexing into other tables in other MIB modules. >> -- This was necessary because the NHDP protocol manages and >> -- indexes based upon dynamic address tuples, i.e., >> -- address sets, while SMI requires statically >> -- defined indexes for accessing its table rows. >> -- The NeighborIfIndex defines a unique (to the local router) >> -- index referencing a discovered virtual interface on another >> -- neighbor within the MANET. The NeighborRouterIndex defines a >> -- unique (to the local router) index referencing a discovered >> -- virtual neighbor within the MANET. >> -- >> -- Due to the nature of NHDP, >> -- different indexes may be related to common neighbor >> -- interfaces or common neighbor routers, but the information >> -- obtained through NHDP has not allowed the local router >> -- to relate these virtual objects (i.e., interfaces or routers) >> -- at this point in time. As more topology information >> -- is gathered by the local router, it may associate >> -- virtual interfaces or routers and collapse these >> -- indexes appropriately. >> >> -- Multiple addresses can be associated with a >> -- given NeighborIfIndex. Each NeighborIfIndex is >> -- associated with a NeighborRouterIndex. Throughout >> -- the nhdpStateObjGroup, the >> -- NeighborIfIndex and the NeighborRouterIndex are used >> -- to define the set of IpAddrs related to a virtual >> -- neighbor interface or virtual neighbor under discussion. >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 12] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> NeighborIfIndex ::=3D TEXTUAL-CONVENTION >> DISPLAY-HINT "d" >> STATUS current >> DESCRIPTION >> "An arbitrary, locally unique identifier associated with a >> virtual interface of a discovered NHDP neighbor. >> Due to the nature of NHDP, the local router >> may not know if two distinct addresses belong to the >> same interface of a neighbor or to two different >> interfaces. As the local router gains more >> knowledge of its neighbors, its local view may change and >> this table will be updated to reflect the local router's current >> understanding associating address sets to neighbor interfaces. >> The local router identifies virtual neighbor interface through >> >> TOM: Change to "...identifies a virtual neighbor" >> >> the receipt of address lists advertised through an >> NHDP HELLO message. >> >> All objects of type NeighborIfIndex are assigned by the agent >> out of a common number space. >> >> The value for each discovered virtual neighbor >> interface may not remain constant from >> one re-initialization of the entity's network management >> agent to the next re-initialization. If the >> local router gains information associating two virtual >> interfaces on a neighbor as a common interface, >> then the agent must aggregate the two address sets to >> a single index chosen from the set of aggregated indexes, >> it must update all tables in this >> MIB module which are indexed by indexes >> of type NeighborIfIndex. It can then reuse freed >> index values following the next agent restart. >> >> The specific value is meaningful only within a given SNMP >> entity." >> SYNTAX Unsigned32 (1..2147483647) >> >> >> NeighborRouterIndex ::=3D TEXTUAL-CONVENTION >> DISPLAY-HINT "d" >> STATUS current >> DESCRIPTION >> "An arbitrary, locally unique identifier associated with a >> virtual discovered neighbor (one or two hop). Due to the >> nature of the NHDP protocol, the local router may identify >> multiple virtual neighbors which in fact are one and >> the same. Two hop neighbors with more than one advertised >> >> TOM: What is a "two hop neighbor"? I think you mean "neighbors that are= two hops away" or something. >> >> address will exhibit this behavior. As the >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 13] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> local router's knowledge of its neighbors' topology >> increases, the local router will be able to associate >> multiple virtual neighbor indexes into a single virtual >> neighbor index chosen from the set of aggregated indexes, >> it must update all tables in this MIB module indexed by these >> indexes, and it can reuse the freed indexes following the >> next agent re-initialization. >> >> All objects of type NeighborRouterIndex are assigned by >> the agent out of a common number space. >> >> The NeighborRouterIndex defines a discovered NHDP peer >> virtual neighbor of the local router. >> The value for each discovered virtual neighbor index must remain >> constant at least from one re-initialization of the entity's >> network management agent to the next re-initialization, except >> that if an application is deleted and re-created. >> >> The specific value is meaningful only within a given SNMP >> entity. An NeighborRouterIndex value must not be re-used >> until the next agent restart." >> SYNTAX Unsigned32 (1..2147483647) >> >> >> >> -- >> -- nhdpObjects >> -- >> >> -- 1) Configuration Objects Group >> -- 2) State Objects Group >> -- 3) Performance Objects Group >> >> >> -- >> -- nhdpConfigurationObjGrp >> -- >> >> -- Contains the NHDP objects which configure specific options >> -- which determine the overall performance and operation of the >> -- discovery protocol. >> >> >> nhdpConfigurationObjGrp OBJECT IDENTIFIER ::=3D { nhdpObjects 1 } >> >> >> nhdpInterfaceTable OBJECT-TYPE >> SYNTAX SEQUENCE OF NhdpInterfaceEntry >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 14] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "nhdpInterfaceTable describes the >> configuration of the interfaces of this NHDP router. >> The ifIndex is from the interfaces group >> defined in the Interfaces Group MIB. If the >> corresponding entry with ifIndex value is deleted >> from the Interface Table, then the entry in >> this table is automatically deleted. >> >> The objects in this table are persistent and when >> written the entity SHOULD save the change to >> non-volatile storage." >> >> TOM: You must describe what happens to rows in this table after an agent= restart. >> >> REFERENCE >> "RFC2863 - The Interfaces Group MIB, McCloghrie, >> K., and F. Kastenholtz, June 2000." >> ::=3D { nhdpConfigurationObjGrp 1 } >> >> nhdpInterfaceEntry OBJECT-TYPE >> SYNTAX NhdpInterfaceEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "nhdpInterfaceEntry describes one NHDP >> local interface configuration as indexed by >> its ifIndex as defined in the Standard MIB II >> Interface Table (RFC2863)." >> INDEX { nhdpIfIndex } >> ::=3D { nhdpInterfaceTable 1 } >> >> NhdpInterfaceEntry ::=3D >> Sequence { >> nhdpIfIndex >> InterfaceIndex, >> nhdpIfName >> DisplayString, >> nhdpIfStatus >> TruthValue, >> nhdpHelloInterval >> Unsigned32, >> nhdpHelloMinInterval >> Unsigned32, >> nhdpRefreshInterval >> Unsigned32, >> nhdpLHoldTime >> Unsigned32, >> nhdpHHoldTime >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 15] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> Unsigned32, >> nhdpHystAcceptQuality >> Float32TC, >> nhdpHystRejectQuality >> Float32TC, >> nhdpInitialQuality >> Float32TC, >> nhdpInitialPending >> TruthValue, >> nhdpHpMaxJitter >> Unsigned32, >> nhdpHtMaxJitter >> Unsigned32, >> nhdpIfRowStatus >> RowStatus >> } >> >> nhdpIfIndex OBJECT-TYPE >> SYNTAX InterfaceIndex >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "The ifIndex for this interface." >> ::=3D { nhdpInterfaceEntry 1 } >> >> nhdpIfName OBJECT-TYPE >> SYNTAX DisplayString >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The textual name of the interface. The value of this >> object should be the name of the interface as assigned by >> the local device and should be suitable for use in commands >> entered at the device's `console'. This might be a text >> name, such as `le0' or a simple port number, such as `1', >> depending on the interface naming syntax of the device. >> >> If there is no local name, or this object is otherwise not >> applicable, then this object contains a zero-length string." >> ::=3D { nhdpInterfaceEntry 2 } >> >> >> TOM: You should use something other than DisplayString as per the MIB gu= idelines. Please review all DisplayString uses from here on in the module,= as I will not repeat this comment. >> >> 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. >> >> TOM: You also need a DEFVAL for *every* read-create object. In this case= DEFVAL {""} >> >> >> nhdpIfStatus OBJECT-TYPE >> SYNTAX TruthValue >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "nhdpIfStatus indicates whether this interface is >> a MANET interface. A value of true(1) indicates >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 16] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> that the interface is a MANET interface. A value of >> false(2) indicates that the interface is not a MANET >> interface. This corresponds to the I_manet parameter >> in the Local Interface Set of NHDP. >> " >> DEFVAL { false } >> ::=3D { nhdpInterfaceEntry 3 } >> >> TOM: Why are you modeling interfaces that are non-MANET interfaces? If y= ou want to do this, you sould use AUGMENT; however, I do not think that you= do. I think what you want to do is only have entries here that ARE of type= MANET. In this case you sould define a new IfType for a manet interface s= o that you can quickly sort through the ifEntries to find MANET interfaces.= To do this, you need to add an IANA entry requesting this new ifType. Ask= me if you need help doing this. >> >> >> -- >> -- Interface Parameters - Message Intervals >> -- >> >> nhdpHelloInterval OBJECT-TYPE >> SYNTAX Unsigned32 >> UNITS "milliseconds" >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "nhdpHelloInterval corresponds to >> HELLO_INTERVAL of NHDP and represents the >> maximum time between the transmission of two >> successive HELLO messages on this MANET interface. >> >> The following constraint applies to this >> parameter: >> o nhdpHelloInterval >=3D nhdpHelloMinInterval" >> REFERENCE >> "Section 5 on Protocol Parameters and >> Constraints of RFC6130." >> DEFVAL { 2000 } >> ::=3D { nhdpInterfaceEntry 4 } >> >> >> nhdpHelloMinInterval OBJECT-TYPE >> SYNTAX Unsigned32 >> UNITS "milliseconds" >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "nhdpHelloMinInterval corresponds to >> HELLO_MIN_INTERVAL of NHDP and represents >> the minimum interval between transmission >> of two successive HELLO messages on this >> MANET interface. >> >> The following constraint applies to this >> parameter: >> o nhdpHelloInterval >=3D nhdpHelloMinInterval" >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 17] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> REFERENCE >> "Section 5 on Protocol Parameters and >> Constraints of RFC6130." >> DEFVAL { 500 } >> ::=3D { nhdpInterfaceEntry 5 } >> >> >> nhdpRefreshInterval OBJECT-TYPE >> SYNTAX Unsigned32 >> UNITS "milliseconds" >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "nhdpRefreshInterval corresponds to >> REFRESH_INTERVAL of NHDP and represents the >> maximum interval between advertisements, in >> a HELLO message on this MANET interface, of >> each 1-hop neighbor network address and its >> status. >> >> The following constraint applies to this >> parameter: >> o nhdpRefreshInterval >=3D nhdpHelloInterval" >> REFERENCE >> "Section 5 on Protocol Parameters and >> Constraints of RFC6130." >> DEFVAL { 2000 } >> ::=3D { nhdpInterfaceEntry 6 } >> >> -- >> -- Interface Parameters - Information Validity times >> -- >> >> nhdpLHoldTime OBJECT-TYPE >> SYNTAX Unsigned32 >> UNITS "milliseconds" >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "nhdpLHoldTime corresponds to >> L_HOLD_TIME of NHDP and represents the period >> of advertisement, on this MANET interface, of >> former 1-hop neighbor network addresses as lost >> in HELLO messages, allowing recipients of these >> HELLO messages to accelerate removal of this >> information from their Link Sets. >> >> The following constraint applies to this >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 18] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> parameter: >> o nhdpLHoldTime should be significantly greater >> than nhdpRefreshInterval" >> REFERENCE >> "Section 5 on Protocol Parameters and >> Constraints of RFC6130." >> DEFVAL { 6000 } >> ::=3D { nhdpInterfaceEntry 7 } >> >> nhdpHHoldTime OBJECT-TYPE >> SYNTAX Unsigned32 >> UNITS "milliseconds" >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "nhdpHHoldTime corresponds to >> H_HOLD_TIME of NHDP and is used as the Value >> in the VALIDITY_TIME Message TLV included in all >> HELLO messages on this MANET interface. It is then >> used by each router receiving such a HELLO message >> to indicate the validity of the information taken >> from that HELLO message and recorded in the receiving >> router's Information Bases. >> >> The following constraints apply to this >> parameter: >> o nhdpHHoldTime >=3D nhdpRefreshInterval >> o nhdpHHoldTime should be significantly greater >> than nhdpRefreshInterval >> o nhdpHHoldTime must be representable as >> described in RFC5497" >> REFERENCE >> "Section 5 on Protocol Parameters and >> Constraints of RFC6130." >> DEFVAL { 6000 } >> ::=3D { nhdpInterfaceEntry 8 } >> >> -- >> -- Interface Parameters - Link Quality >> -- >> >> nhdpHystAcceptQuality OBJECT-TYPE >> SYNTAX Float32TC >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "nhdpHystAcceptQuality corresponds to >> HYST_ACCEPT of NHDP and represents the link >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 19] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> quality threshold at or above which a link becomes >> usable, if it was not already so. >> >> The following constraint applies to this >> parameter: >> o 0 <=3D nhdpHystRejectQuality >> <=3D nhdpHystAcceptQuality <=3D 1.0" >> REFERENCE >> "Section 5 on Protocol Parameters and >> Constraints of RFC6130." >> -- DEFVAL { 1.0 } >> ::=3D { nhdpInterfaceEntry 9 } >> >> nhdpHystRejectQuality OBJECT-TYPE >> SYNTAX Float32TC >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "nhdpHystRejectQuality corresponds to >> HYST_REJECT of NHDP and represents the >> link quality threshold below which a >> link becomes unusable, if it was not >> already so. >> >> The following constraint applies to this >> parameter: >> o 0 <=3D nhdpHystRejectQuality >> <=3D nhdpHystAcceptQuality <=3D 1.0" >> REFERENCE >> "Section 5 on Protocol Parameters and >> Constraints of RFC6130." >> -- DEFVAL { 0.0 } >> ::=3D { nhdpInterfaceEntry 10 } >> >> nhdpInitialQuality OBJECT-TYPE >> SYNTAX Float32TC >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "nhdpInitialQuality corresponds to >> INITIAL_QUALITY of NHDP and represents the >> initial quality of a newly identified link. >> >> The following constraint applies to this >> parameter: >> o 0 <=3D nhdpInitialQuality <=3D 1.0" >> REFERENCE >> "Section 5 on Protocol Parameters and >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 20] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> Constraints of RFC6130." >> -- DEFVAL { 1.0 } >> ::=3D { nhdpInterfaceEntry 11 } >> >> nhdpInitialPending OBJECT-TYPE >> SYNTAX TruthValue >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "nhdpInitialPending corresponds to >> INITIAL_PENDING of NHDP. If true, then a >> newly identified link is considered pending, and >> is not usable until the link quality has reached >> or exceeded the nhdpHystAcceptQuality threshold. >> >> The following constraints apply to this >> parameter: >> o If nhdpInitialQuality >=3D nhdpHystAcceptQuality, >> then nhdpInitialPending :=3D false. >> o If nhdpInitialQuality < nhdpHystRejectQuality, >> then nhdpInitialPending :=3D true." >> REFERENCE >> "Section 5 on Protocol Parameters and >> Constraints of RFC6130." >> ::=3D { nhdpInterfaceEntry 12 } >> >> -- >> -- Interface Parameters - Jitter >> -- >> nhdpHpMaxJitter OBJECT-TYPE >> SYNTAX Unsigned32 >> UNITS "milliseconds" >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "nhdpHpMaxJitter corresponds to >> HP_MAXJITTER of NHDP and represents the >> value of MAXJITTER used in RFC5148 for >> periodically generated HELLO messages on >> this MANET interface. >> >> The following constraints apply to this >> parameter: >> o nhdpHpMaxJitter <=3D nhdpHelloInterval / 2 >> o If nhdpHelloInterval > 0, then >> nhdpHpMaxJitter <=3D nhdpHelloMinInterval >> " >> REFERENCE >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 21] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> "Section 5 on Protocol Parameters and >> Constraints of RFC6130." >> DEFVAL { 500 } >> ::=3D { nhdpInterfaceEntry 13 } >> >> >> nhdpHtMaxJitter OBJECT-TYPE >> SYNTAX Unsigned32 >> UNITS "milliseconds" >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "nhdpHtMaxJitter corresponds to >> HT_MAXJITTER of NHDP and represents the >> value of MAXJITTER used in RFC5148 for >> externally triggered HELLO messages on this >> MANET interface. >> >> The following constraints apply to this >> parameter: >> o nhdpHtMaxJitter <=3D nhdpHelloInterval / 2 >> o If nhdpHelloInterval > 0, then >> nhdpHtMaxJitter <=3D nhdpHelloMinInterval" >> REFERENCE >> "Section 5 on Protocol Parameters and >> Constraints of RFC6130." >> DEFVAL { 500 } >> ::=3D { nhdpInterfaceEntry 14 } >> >> nhdpIfRowStatus OBJECT-TYPE >> SYNTAX RowStatus >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "This object permits management of the table >> by facilitating actions such as row creation, >> construction, and destruction. The value of >> this object has no effect on whether other >> objects in this conceptual row can be >> modified. >> >> An entry may not exist in the active state unless all >> objects in the entry have an appropriate value. >> >> If this object is not equal to active(1), all associated >> entries in the nhdpLibLocalIfSetTable, nhdpInterfaceStateTable, >> nhdpIibLinkSetTable and the nhdpInterfacePerfTable must be >> deleted." >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 22] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> REFERENCE >> "RFC6130." >> ::=3D { nhdpInterfaceEntry 15 } >> >> >> -- >> -- Router Parameters - Information Validity Time >> -- >> nhdpNHoldTime OBJECT-TYPE >> SYNTAX Unsigned32 >> UNITS "milliseconds" >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "nhdpNHoldTime corresponds to >> N_HOLD_TIME of NHDP and is used as the period >> during which former 1-hop neighbor network >> addresses are advertised as lost in HELLO >> messages, allowing recipients of these HELLO >> messages to accelerate removal of this information >> from their 2-Hop Sets. >> >> This object is persistent and when written >> the entity SHOULD save the change to >> non-volatile storage." >> REFERENCE >> "RFC6130. >> Section 5 on Protocol Parameters and >> Constraints." >> DEFVAL { 6000 } >> ::=3D { nhdpConfigurationObjGrp 2 } >> >> >> nhdpIHoldTime OBJECT-TYPE >> SYNTAX Unsigned32 >> UNITS "milliseconds" >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "nhdpIHoldTime corresponds to >> I_HOLD_TIME of NHDP and represents the period >> for which a recently used local interface network >> address is recorded. >> >> This object is persistent and when written >> the entity SHOULD save the change to >> non-volatile storage." >> REFERENCE >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 23] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> "RFC6130. >> Section 5 on Protocol Parameters and >> Constraints." >> DEFVAL { 6000 } >> ::=3D { nhdpConfigurationObjGrp 3 } >> >> >> -- An NHDP router's Local Information Base (LIB) >> >> -- >> -- Local Interface Set Table >> -- >> >> nhdpLibLocalIfSetTable OBJECT-TYPE >> SYNTAX SEQUENCE OF NhdpLibLocalIfSetEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "A router's Local Interface Set records all >> network addresses which are defined as local >> interface network addresses. The local interface >> is defined by the nhdpIfIndex. >> >> The Local Interface Set consists of Local Interface >> Address Tuples per network interface and their prefix >> lengths (in order to determine the network addresses >> related to the interface) and an indication of whether >> the interface is a MANET interface or not. >> >> Further guidance on the addition or removal of >> local addresses and network addresses is found >> in Section 9 of RFC6130." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpConfigurationObjGrp 4 } >> >> nhdpLibLocalIfSetEntry OBJECT-TYPE >> SYNTAX NhdpLibLocalIfSetEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "A router's Local Interface Set consists >> of Configured Interface Address Tuples for each network >> interface, and an indication of whether the interface >> is a MANET interface or not. >> >> (I_local_iface_addr_list, I_manet) >> " >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 24] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> REFERENCE >> "RFC6130." >> INDEX { nhdpLibLocalIfSetIndex } >> ::=3D { nhdpLibLocalIfSetTable 1 } >> >> >> TOM: Why don't you use a second index here and/or extend the ifEntry her= e? This table could in the worst case, mimic the ifEntry right? On some b= oxes, that could have thousands of entries so you do not want to have multi= ple copies of this table. >> >> >> NhdpLibLocalIfSetEntry ::=3D >> SEQUENCE { >> nhdpLibLocalIfSetIndex >> Integer32, >> nhdpLibLocalIfSetIfIndex >> InterfaceIndex, >> nhdpLibLocalIfSetIpAddrType >> InetAddressType, >> nhdpLibLocalIfSetIpAddr >> InetAddress, >> nhdpLibLocalIfSetIpAddrPrefixLen >> InetAddressPrefixLength, >> nhdpLibLocalIfSetIsManet >> TruthValue, >> nhdpLibLocalIfSetRowStatus >> RowStatus >> } >> >> nhdpLibLocalIfSetIndex OBJECT-TYPE >> SYNTAX Integer32 (0..65535) >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "The index for this table. Necessary >> because multiple addresses may be associated >> with a given nhdpIfIndex." >> REFERENCE >> "RFC6130." >> >> TOM: I think it is customary to include the full reference description i= n the REFERENCE clause. For example: >> >> "RFC 2863 - The Interfaces Group MIB, McCloghrie, K., >> and F. Kastenholtz, June 2000" >> >> >> >> ::=3D { nhdpLibLocalIfSetEntry 1 } >> >> nhdpLibLocalIfSetIfIndex OBJECT-TYPE >> SYNTAX InterfaceIndex >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "Specifies the local nhdpIfIndex for which this >> IP address was added." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpLibLocalIfSetEntry 2 } >> >> nhdpLibLocalIfSetIpAddrType OBJECT-TYPE >> SYNTAX InetAddressType >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 25] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "The type of the nhdpLibLocalIfSetIpAddr >> in the InetAddress MIB (RFC4001). >> >> TOM: You typically use "RFC 4001" (i.e.: with the space between) in the = DESCRIPTION clause so that you do not distrupt ID-NITS which will flag this= as an unknown reference. >> >> Only the values ipv4(1) and >> ipv6(2) are supported." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpLibLocalIfSetEntry 3 } >> >> nhdpLibLocalIfSetIpAddr OBJECT-TYPE >> SYNTAX InetAddress (SIZE(4|16)) >> >> TOM: Why are you constraining the InetAddress to 4 or 16? This is uncomm= on. >> >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "nhdpLibLocalIfSetIpAddr is an >> address of an interface of >> this router. >> >> This object is interpreted according to >> the setting of nhdpLibLocalIfSetIpAddrType." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpLibLocalIfSetEntry 4 } >> >> nhdpLibLocalIfSetIpAddrPrefixLen OBJECT-TYPE >> SYNTAX InetAddressPrefixLength >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "Indicates the number of leading one bits that >> form the mask. The mask is logically-ANDed >> to the nhdpLibLocalIfSetIpAddr to determine >> the address prefix. A row match is true >> if the address used as an index falls within >> the network address range defined by the >> address prefix." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpLibLocalIfSetEntry 5 } >> >> nhdpLibLocalIfSetIsManet OBJECT-TYPE >> SYNTAX TruthValue >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 26] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> "Specifies whether this interface is >> a MANET interface or not." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpLibLocalIfSetEntry 6 } >> >> nhdpLibLocalIfSetRowStatus OBJECT-TYPE >> SYNTAX RowStatus >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "This object permits management of the table >> by facilitating actions such as row creation, >> construction, and destruction. The value of >> this object has no effect on whether other >> objects in this conceptual row can be >> modified. >> >> An entry may not exist in the active state unless all >> objects in the entry have an appropriate value." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpLibLocalIfSetEntry 7 } >> >> TOM: You need to be more precise in defining the RowStatus objects like = this: >> >> "This variable is used to create, modify, and/or >> delete a row in this table. When a row in this >> table is in active(1) state, no objects in that row >> can be modified by the agent except >> nhdpLibLocalIfSetRowStatus and >> nhdpLibLocalIfSetStorageType." >> >> TOM: 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. >> >> -- >> -- Removed Interface Addr Set Table >> -- >> >> nhdpLibRemovedIfAddrSetTable OBJECT-TYPE >> SYNTAX SEQUENCE OF NhdpLibRemovedIfAddrSetEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "A router's Removed Interface Address Set records >> network addresses which were recently used as local >> interface network addresses. If a router's interface >> network addresses are immutable then the Removed >> Interface Address Set is always empty and may be omitted. >> It consists of Removed Interface Address Tuples, one >> per network address." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpConfigurationObjGrp 5 } >> >> nhdpLibRemovedIfAddrSetEntry OBJECT-TYPE >> SYNTAX NhdpLibRemovedIfAddrSetEntry >> MAX-ACCESS not-accessible >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 27] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> STATUS current >> DESCRIPTION >> "A router's Removed Interface Address Set consists >> of Removed Interface Address Tuples, one per network >> address: >> >> (IR_local_iface_addr, IR_time) >> >> The association between these addrs and >> the router's Interface is found in the >> Standard MIB II's IP address table >> (RFC1213)." >> REFERENCE >> "RFC6130." >> INDEX { nhdpLibRemovedIfAddrSetIndex } >> ::=3D { nhdpLibRemovedIfAddrSetTable 1 } >> >> NhdpLibRemovedIfAddrSetEntry ::=3D >> SEQUENCE { >> nhdpLibRemovedIfAddrSetIndex >> Integer32, >> nhdpLibRemovedIfAddrSetIpAddrType >> InetAddressType, >> nhdpLibRemovedIfAddrSetIpAddr >> InetAddress, >> nhdpLibRemovedIfAddrSetIpAddrPrefixLen >> InetAddressPrefixLength, >> nhdpLibRemovedIfAddrSetIfIndex >> InterfaceIndex, >> nhdpLibRemovedIfAddrSetIRTime >> TimeStamp >> } >> >> nhdpLibRemovedIfAddrSetIndex OBJECT-TYPE >> SYNTAX Integer32 (0..65535) >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "The index for this table. Necessary >> because multiple addresses may be associated >> with a given nhdpIfIndex." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpLibRemovedIfAddrSetEntry 1 } >> >> nhdpLibRemovedIfAddrSetIpAddrType OBJECT-TYPE >> SYNTAX InetAddressType >> MAX-ACCESS read-only >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 28] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> STATUS current >> DESCRIPTION >> "The type of the nhdpLibRemovedIfAddrSetIpAddr >> in the InetAddress MIB (RFC4001). >> >> Only the values ipv4(1) and >> ipv6(2) are supported." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpLibRemovedIfAddrSetEntry 2 } >> >> nhdpLibRemovedIfAddrSetIpAddr OBJECT-TYPE >> SYNTAX InetAddress (SIZE(4|16)) >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "nhdpLibRemovedIfAddrSetIpAddr is a >> recently used address of an interface of >> this router." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpLibRemovedIfAddrSetEntry 3 } >> >> nhdpLibRemovedIfAddrSetIpAddrPrefixLen OBJECT-TYPE >> SYNTAX InetAddressPrefixLength >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "Indicates the number of leading one bits that >> form the mask. The mask is logically-ANDed >> to the nhdpLibRemovedIfAddrSetIpAddr to determine >> the address prefix. A row match is true >> if the address used as an index falls within >> the network address range defined by the >> address prefix." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpLibRemovedIfAddrSetEntry 4 } >> >> >> nhdpLibRemovedIfAddrSetIfIndex OBJECT-TYPE >> SYNTAX InterfaceIndex >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "Specifies the local IfIndex from which this >> IP address was recently removed." >> REFERENCE >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 29] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> "RFC6130." >> ::=3D { nhdpLibRemovedIfAddrSetEntry 5 } >> >> nhdpLibRemovedIfAddrSetIRTime OBJECT-TYPE >> SYNTAX TimeStamp >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "nhdpLibRemovedIfAddrSetIRTime specifies the sysUptime >> when to expire this entry and remove it from the >> 'nhdpNibLostNeighborSetTable'" >> REFERENCE >> "RFC6130." >> ::=3D { nhdpLibRemovedIfAddrSetEntry 6 } >> >> >> >> -- >> -- nhdpStateObjGrp >> -- >> >> -- Contains information describing the current state of the NHDP >> -- process on this router. >> >> nhdpStateObjGrp OBJECT IDENTIFIER ::=3D { nhdpObjects 2 } >> >> >> nhdpUpTime OBJECT-TYPE >> SYNTAX TimeStamp >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The value of sysUpTime at the time current NHDP >> process was initialized. >> " >> ::=3D { nhdpStateObjGrp 1 } >> >> >> nhdpInterfaceStateTable OBJECT-TYPE >> SYNTAX SEQUENCE OF NhdpInterfaceStateEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "nhdpInterfaceStateTable lists state information >> related to specific interfaces of this NHDP router. >> The value of nhdpIfIndex is an ifIndex from the >> interfaces group defined in the Interfaces Group >> MIB. >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 30] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> The objects in this table are persistent and when >> written the entity SHOULD save the change to >> non-volatile storage." >> REFERENCE >> "RFC 2863 - The Interfaces Group MIB, McCloghrie, >> K., and F. Kastenholtz, June 2000." >> ::=3D { nhdpStateObjGrp 2 } >> >> nhdpInterfaceStateEntry OBJECT-TYPE >> SYNTAX NhdpInterfaceStateEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "nhdpInterfaceStateEntry describes one NHDP >> local interface state as indexed by >> its nhdpIfIndex." >> INDEX { nhdpIfIndex } >> ::=3D { nhdpInterfaceStateTable 1 } >> >> NhdpInterfaceStateEntry ::=3D >> SEQUENCE { >> nhdpIfStateUpTime >> TimeStamp >> } >> >> nhdpIfStateUpTime OBJECT-TYPE >> SYNTAX TimeStamp >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The value of the sysUpTime when this >> interface was last initialized as a >> MANET interface." >> ::=3D { nhdpInterfaceStateEntry 1 } >> >> >> -- >> -- This table allows for the mapping between discovered >> -- remote interfaces and routers and their addresses. >> -- >> >> nhdpDiscIfSetTable OBJECT-TYPE >> SYNTAX SEQUENCE OF NhdpDiscIfSetEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "A router's set of discovered interfaces on >> neighboring routers." >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 31] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> REFERENCE >> "RFC6130." >> ::=3D { nhdpStateObjGrp 3 } >> >> >> nhdpDiscIfSetEntry OBJECT-TYPE >> SYNTAX NhdpDiscIfSetEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "The entries include the nhdpDiscRouterIndex of >> the discovered router, the nhdpDiscIfIndex >> of the discovered interface and the >> current set of addresses associated >> with this neighbor interface. The >> nhdpDiscIfIndex uniquely identifies >> the remote interface address sets >> through this table. It does not need >> to be unique across the MANET, but must >> be locally unique within this router." >> REFERENCE >> "RFC6130." >> INDEX { nhdpDiscIfSetIndex } >> ::=3D { nhdpDiscIfSetTable 1 } >> >> NhdpDiscIfSetEntry ::=3D >> SEQUENCE { >> nhdpDiscIfSetIndex >> Integer32, >> nhdpDiscIfIndex >> NeighborIfIndex, >> nhdpDiscRouterIndex >> NeighborRouterIndex, >> nhdpDiscIfSetIpAddrType >> InetAddressType, >> nhdpDiscIfSetIpAddr >> InetAddress, >> nhdpDiscIfSetIpAddrPrefixLen >> InetAddressPrefixLength >> } >> >> nhdpDiscIfSetIndex OBJECT-TYPE >> SYNTAX Integer32 (0..65535) >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "The index for this table. Necessary >> because multiple addresses may be associated >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 32] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> with a given nhdpDiscIfIndex." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpDiscIfSetEntry 1 } >> >> nhdpDiscIfIndex OBJECT-TYPE >> SYNTAX NeighborIfIndex >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The NHDP interface index (locally created) >> of a neighbor's interface. Used for cross >> indexing into other NHDP tables and other >> MIB modules." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpDiscIfSetEntry 2 } >> >> nhdpDiscRouterIndex OBJECT-TYPE >> SYNTAX NeighborRouterIndex >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The NHDP neighbor index (locally created) >> of a neighboring router. Used for cross >> indexing into other NHDP tables and other >> MIB modules." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpDiscIfSetEntry 3 } >> >> nhdpDiscIfSetIpAddrType OBJECT-TYPE >> SYNTAX InetAddressType >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The type of the nhdpDiscIfSetIpAddr >> in the InetAddress MIB (RFC4001). >> >> Only the values ipv4(1) and >> ipv6(2) are supported." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpDiscIfSetEntry 4 } >> >> nhdpDiscIfSetIpAddr OBJECT-TYPE >> SYNTAX InetAddress (SIZE(4|16)) >> MAX-ACCESS read-only >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 33] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> STATUS current >> DESCRIPTION >> "The nhdpDiscIfSetIpAddr is a >> recently used address of a neighbor >> of this router." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpDiscIfSetEntry 5 } >> >> nhdpDiscIfSetIpAddrPrefixLen OBJECT-TYPE >> SYNTAX InetAddressPrefixLength >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "Indicates the number of leading one bits that >> form the mask. The mask is logically-ANDed >> to the nhdpDiscIfSetIpAddr to determine >> the address prefix. A row match is true >> if the address used as an index falls within >> the network address range defined by the >> address prefix." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpDiscIfSetEntry 6 } >> >> >> -- Interface Information Base (IIB) >> >> -- >> -- Link Set >> -- >> >> nhdpIibLinkSetTable OBJECT-TYPE >> SYNTAX SEQUENCE OF NhdpIibLinkSetEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "A Link Set of an interface records all links >> from other routers which are, or recently >> were, 1-hop neighbors." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpStateObjGrp 4 } >> >> nhdpIibLinkSetEntry OBJECT-TYPE >> SYNTAX NhdpIibLinkSetEntry >> MAX-ACCESS not-accessible >> STATUS current >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 34] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> DESCRIPTION >> "A Link Set consists of Link Tuples, each >> representing a single link indexed by the >> local and remote interface pair: >> >> (L_neighbor_iface_addr_list, L_HEARD_time, >> L_SYM_time, L_quality, L_pending, >> L_lost, L_time). >> >> The local interface is indexed via the >> 'nhdpIfIndex'. The 1-Hop interface is >> indexed via the 'nhdpDiscIfIndex'. There >> should be an entry in this table for each >> local interface and associated 1-Hop >> neighbor reachable on this local interface. >> >> Note that L_quality is not included in the >> entries below, because updates may be >> required too frequently." >> REFERENCE >> "RFC6130." >> INDEX { nhdpIfIndex, >> nhdpDiscIfIndex } >> ::=3D { nhdpIibLinkSetTable 1 } >> >> NhdpIibLinkSetEntry ::=3D >> SEQUENCE { >> nhdpIibLinkSetLHeardTime >> TimeStamp, >> nhdpIibLinkSetLSymTime >> TimeStamp, >> nhdpIibLinkSetLPending >> TruthValue, >> nhdpIibLinkSetLLost >> TruthValue, >> nhdpIibLinkSetLTime >> TimeStamp >> } >> >> nhdpIibLinkSetLHeardTime OBJECT-TYPE >> SYNTAX TimeStamp >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "nhdpIibLinkSetLHeardTime corresponds >> to L_HEARD_time of NHDP and represents the >> time up to which the MANET interface of the >> 1-hop neighbor would be considered heard if >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 35] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> not considering link quality." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpIibLinkSetEntry 1 } >> >> nhdpIibLinkSetLSymTime OBJECT-TYPE >> SYNTAX TimeStamp >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "nhdpIibLinkSetLSymTime corresponds >> to L_SYM_time of NHDP and represents the time >> up to which the link to the 1-hop neighbor >> would be considered symmetric if not considering >> link quality." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpIibLinkSetEntry 2 } >> >> nhdpIibLinkSetLPending OBJECT-TYPE >> SYNTAX TruthValue >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "nhdpIibLinkSetLPending corresponds >> to L_pending of NHDP and is a boolean flag, >> describing if a link is considered pending >> (i.e., a candidate, but not yet established, >> link)." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpIibLinkSetEntry 3 } >> >> nhdpIibLinkSetLLost OBJECT-TYPE >> SYNTAX TruthValue >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "nhdpIibLinkSetLLost corresponds >> to L_lost of NHDP and is a boolean flag, >> describing if a link is considered lost due >> to low link quality." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpIibLinkSetEntry 4 } >> >> nhdpIibLinkSetLTime OBJECT-TYPE >> SYNTAX TimeStamp >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 36] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "nhdpIibLinkSetLTime specifies the sysUptime >> when to expire this entry and remove it from the >> 'nhdpIibLinkSetTable'. >> " >> REFERENCE >> "RFC6130." >> ::=3D { nhdpIibLinkSetEntry 5 } >> >> >> -- >> -- 2-Hop Set >> -- >> nhdpIib2HopSetTable OBJECT-TYPE >> SYNTAX SEQUENCE OF NhdpIib2HopSetEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "A 2-Hop Set of an interface records network >> addresses of symmetric 2-hop neighbors, and >> the symmetric links to symmetric 1-hop neighbors >> through which these symmetric 2-hop neighbors >> can be reached. It consists of 2-Hop Tuples." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpStateObjGrp 5 } >> >> nhdpIib2HopSetEntry OBJECT-TYPE >> SYNTAX NhdpIib2HopSetEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "nhdpIib2HopSetTable consists of 2-Hop Tuples, >> each representing a single network address of >> a symmetric 2-hop neighbor, and a single MANET >> interface of a symmetric 1-hop neighbor. >> >> (N2_neighbor_iface_addr_list, >> N2_2hop_addr, N2_time). >> >> The entries include the 2-hop neighbor addresses, >> which act as the table index, and associated >> 1-hop symmetric link address set, designated >> through 'nhdpDiscIfIndex', and an expiration time. >> The 'nhdpIfIndex' in the INDEX is >> interface index of the local interface >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 37] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> through which these 2-hop addresses are >> accessible. The 'nhdpDiscIfIndex' in the >> INDEX represents the 1-Hop neighbor interface >> through which these 2-Hop addresses are >> reachable." >> REFERENCE >> "RFC6130." >> INDEX { nhdpIfIndex, >> nhdpDiscIfIndex, >> nhdpIib2HopSetIpAddressType, >> nhdpIib2HopSetIpAddress >> } >> ::=3D { nhdpIib2HopSetTable 1 } >> >> NhdpIib2HopSetEntry ::=3D >> SEQUENCE { >> nhdpIib2HopSetIpAddressType >> InetAddressType, >> nhdpIib2HopSetIpAddress >> InetAddress, >> nhdpIib2HopSetIpAddrPrefixLen >> InetAddressPrefixLength, >> nhdpIib2HopSet1HopIfIndex >> NeighborIfIndex, >> nhdpIib2HopSetN2Time >> TimeStamp >> } >> >> nhdpIib2HopSetIpAddressType OBJECT-TYPE >> SYNTAX InetAddressType >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "The type of the nhdpIib2HopSetIpAddress >> in the InetAddress MIB module (RFC4001). >> >> Only the values ipv4(1) and >> ipv6(2) are supported." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpIib2HopSetEntry 1 } >> >> nhdpIib2HopSetIpAddress OBJECT-TYPE >> SYNTAX InetAddress (SIZE(4|16)) >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "nhdpIib2HopSetIpAddr corresponds >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 38] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> to N2_2hop_addr of NHDP and is a network >> address of a symmetric 2-hop neighbor that >> has a symmetric link (using any MANET >> interface) to the indicated symmetric >> 1-hop neighbor." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpIib2HopSetEntry 2 } >> >> nhdpIib2HopSetIpAddrPrefixLen OBJECT-TYPE >> SYNTAX InetAddressPrefixLength >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "Indicates the number of leading one bits that >> form the mask. The mask is logically-ANDed >> to the nhdpIib2HopSetIpAddress to determine >> the address prefix. A row match is true >> if the address used as an index falls within >> the network address range defined by the >> address prefix." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpIib2HopSetEntry 3 } >> >> nhdpIib2HopSet1HopIfIndex OBJECT-TYPE >> SYNTAX NeighborIfIndex >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "nhdpIib2HopSet1HopIfIndex is >> nhdpDiscIfIndex of the 1-hop >> neighbor which communicated the ipAddress >> of the 2-hop neighbor in this row entry." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpIib2HopSetEntry 4 } >> >> nhdpIib2HopSetN2Time OBJECT-TYPE >> SYNTAX TimeStamp >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "nhdpIib2HopSetN2Time specifies the sysUptime >> when to expire this entry and remove it from the >> 'nhdpIib2HopSetTable'." >> REFERENCE >> "RFC6130." >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 39] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> ::=3D { nhdpIib2HopSetEntry 5 } >> >> >> -- >> -- Neighbor Information Base (NIB) >> -- >> -- Each router maintains a Neighbor Information Base >> -- that records information about addresses of >> -- current and recently symmetric 1-hop neighbors. >> >> >> -- >> -- Neighbor Set >> -- >> -- The Neighbor Set Table is small because >> -- most of the corresponding information is found >> -- in the nhdpDiscoveredIfTable above. >> -- >> >> nhdpNibNeighborSetTable OBJECT-TYPE >> SYNTAX SEQUENCE OF NhdpNibNeighborSetEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "A router's Neighbor Set records all >> network addresses of each 1-hop >> neighbor." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpStateObjGrp 6 } >> >> nhdpNibNeighborSetEntry OBJECT-TYPE >> SYNTAX NhdpNibNeighborSetEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "A router's Neighbor Set consists >> of Neighbor Tuples, each representing >> a single 1-hop neighbor: >> >> (N_neighbor_addr_list, N_symmetric) >> " >> REFERENCE >> "RFC6130." >> INDEX { nhdpDiscRouterIndex } >> ::=3D { nhdpNibNeighborSetTable 1 } >> >> NhdpNibNeighborSetEntry ::=3D >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 40] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> SEQUENCE { >> nhdpNibNeighborSetNSymmetric >> TruthValue >> } >> >> nhdpNibNeighborSetNSymmetric OBJECT-TYPE >> SYNTAX TruthValue >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "nhdpNibNeighborNSymmetric corresponds >> to N_symmetric of NHDP and is a boolean flag, >> describing if this is a symmetric 1-hop neighbor." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpNibNeighborSetEntry 1 } >> >> >> -- >> -- Lost Neighbor Set >> -- >> nhdpNibLostNeighborSetTable OBJECT-TYPE >> SYNTAX SEQUENCE OF NhdpNibLostNeighborSetEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "A router's Lost Neighbor Set records network >> addresses of routers which recently were >> symmetric 1-hop neighbors, but which are now >> advertised as lost." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpStateObjGrp 7 } >> >> nhdpNibLostNeighborSetEntry OBJECT-TYPE >> SYNTAX NhdpNibLostNeighborSetEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "A router's Lost Neighbor Set consists of >> Lost Neighbor Tuples, each representing a >> single such network address: >> >> (NL_neighbor_addr, NL_time)" >> REFERENCE >> "RFC6130." >> INDEX { nhdpDiscRouterIndex } >> ::=3D { nhdpNibLostNeighborSetTable 1 } >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 41] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> NhdpNibLostNeighborSetEntry ::=3D >> SEQUENCE { >> nhdpNibLostNeighborSetNLTime >> TimeStamp >> } >> >> nhdpNibLostNeighborSetNLTime OBJECT-TYPE >> SYNTAX TimeStamp >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "nhdpNibLostNeighborSetNLTime >> specifies the sysUptime >> when to expire this entry and remove it from the >> 'nhdpNibLostNeighborSetTable'." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpNibLostNeighborSetEntry 1 } >> >> >> >> -- >> -- nhdpPerformanceObjGrp >> -- >> >> -- Contains objects which help to characterize the performance of >> -- the NHDP process, typically counters. >> -- >> nhdpPerformanceObjGrp OBJECT IDENTIFIER ::=3D { nhdpObjects 3 } >> >> -- >> -- Objects per local interface >> -- >> >> nhdpInterfacePerfTable OBJECT-TYPE >> SYNTAX SEQUENCE OF NhdpInterfacePerfEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "This table summarizes performance objects that are >> measured per local NHDP interface." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpPerformanceObjGrp 1 } >> >> nhdpInterfacePerfEntry OBJECT-TYPE >> SYNTAX NhdpInterfacePerfEntry >> MAX-ACCESS not-accessible >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 42] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> STATUS current >> DESCRIPTION >> "A single entry contains performance counters for >> a local NHDP interface." >> INDEX { nhdpIfIndex } >> ::=3D { nhdpInterfacePerfTable 1 } >> >> NhdpInterfacePerfEntry ::=3D >> SEQUENCE { >> nhdpIfHelloMessageXmits >> Counter32, >> nhdpIfHelloMessageRecvd >> Counter32, >> nhdpIfHelloMessageXmitAccumulatedSize >> Counter64, >> nhdpIfHelloMessageRecvdAccumulatedSize >> Counter64, >> nhdpIfHelloMessageTriggeredXmits >> Counter32, >> nhdpIfHelloMessagePeriodicXmits >> Counter32, >> nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount >> Counter32, >> nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount >> Counter32, >> nhdpIfHelloMessageXmitAccumulatedLostNeighborCount >> Counter32 >> } >> >> nhdpIfHelloMessageXmits OBJECT-TYPE >> SYNTAX Counter32 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "A counter is incremented each time a HELLO >> message has been transmitted on that interface." >> ::=3D { nhdpInterfacePerfEntry 1 } >> >> nhdpIfHelloMessageRecvd OBJECT-TYPE >> SYNTAX Counter32 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "A counter is incremented each time a >> HELLO message has been received on that interface." >> ::=3D { nhdpInterfacePerfEntry 2 } >> >> nhdpIfHelloMessageXmitAccumulatedSize OBJECT-TYPE >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 43] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> SYNTAX Counter64 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "A counter is incremented by the number of octets in >> a HELLO message each time a >> HELLO message has been sent." >> ::=3D { nhdpInterfacePerfEntry 3 } >> >> nhdpIfHelloMessageRecvdAccumulatedSize OBJECT-TYPE >> SYNTAX Counter64 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "A counter is incremented by the number of octets in >> a HELLO message each time a >> HELLO message has been received." >> ::=3D { nhdpInterfacePerfEntry 4 } >> >> nhdpIfHelloMessageTriggeredXmits OBJECT-TYPE >> SYNTAX Counter32 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "A counter is incremented each time a triggered >> HELLO message has been sent." >> ::=3D { nhdpInterfacePerfEntry 5 } >> >> nhdpIfHelloMessagePeriodicXmits OBJECT-TYPE >> SYNTAX Counter32 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "A counter is incremented each time a periodic >> HELLO message has been sent." >> ::=3D { nhdpInterfacePerfEntry 6 } >> >> nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount OBJECT-TYPE >> SYNTAX Counter32 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "A counter is incremented by the number of advertised >> symmetric neighbors in a HELLO each time a HELLO >> message has been sent." >> ::=3D { nhdpInterfacePerfEntry 7 } >> >> nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount OBJECT-TYPE >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 44] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> SYNTAX Counter32 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "A counter is incremented by the number of advertised >> heard neighbors in a HELLO each time a HELLO >> message has been sent." >> ::=3D { nhdpInterfacePerfEntry 8 } >> >> nhdpIfHelloMessageXmitAccumulatedLostNeighborCount OBJECT-TYPE >> SYNTAX Counter32 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "A counter is incremented by the number of advertised >> lost neighbors in a HELLO each time a HELLO >> message has been sent." >> ::=3D { nhdpInterfacePerfEntry 9 } >> >> >> >> -- >> -- Objects per discovered neighbor interface >> -- >> nhdpDiscIfSetPerfTable OBJECT-TYPE >> SYNTAX SEQUENCE OF NhdpDiscIfSetPerfEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "A router's set of performance properties for >> each discovered interface of a neighbor." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpPerformanceObjGrp 2 } >> >> >> nhdpDiscIfSetPerfEntry OBJECT-TYPE >> SYNTAX NhdpDiscIfSetPerfEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "There is an entry for each discovered >> interface of a neighbor." >> REFERENCE >> "RFC6130." >> INDEX { nhdpDiscIfIndex } >> ::=3D { nhdpDiscIfSetPerfTable 1 } >> >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 45] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> NhdpDiscIfSetPerfEntry ::=3D >> SEQUENCE { >> nhdpDiscIfRecvdPackets >> Counter32, >> nhdpDiscIfExpectedPackets >> Counter32 >> } >> >> nhdpDiscIfRecvdPackets OBJECT-TYPE >> SYNTAX Counter32 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "This counter increments each >> time this router receives a packet from that interface >> of the neighbor." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpDiscIfSetPerfEntry 1 } >> >> nhdpDiscIfExpectedPackets OBJECT-TYPE >> SYNTAX Counter32 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "This counter increments by the number >> of missed packets from this neighbor based >> on the packet sequence number each time this >> router receives a packet from that interface >> of the neighbor." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpDiscIfSetPerfEntry 2 } >> >> >> >> -- >> -- Objects concerning the neighbor set >> -- >> nhdpNibNeighborSetChanges OBJECT-TYPE >> SYNTAX Counter32 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "This counter increments each time the Neighbor Set changes. >> A change occurs whenever a new Neighbor Tuple has been >> added, a Neighbor Tuple has been removed or any entry of >> a Neighbor Tuple has been modified." >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 46] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> ::=3D { nhdpPerformanceObjGrp 3 } >> >> >> >> -- >> -- Objects per discovered neighbor >> -- >> nhdpDiscNeighborSetPerfTable OBJECT-TYPE >> SYNTAX SEQUENCE OF NhdpDiscNeighborSetPerfEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "A router's set of discovered neighbors and >> their properties." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpPerformanceObjGrp 4 } >> >> nhdpDiscNeighborSetPerfEntry OBJECT-TYPE >> SYNTAX NhdpDiscNeighborSetPerfEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "The entries include the nhdpDiscRouterIndex of >> the discovered router, as well as performance >> objects related to changes of the Neighbor >> Set." >> REFERENCE >> "RFC6130." >> INDEX { nhdpDiscRouterIndex } >> ::=3D { nhdpDiscNeighborSetPerfTable 1 } >> >> NhdpDiscNeighborSetPerfEntry ::=3D >> SEQUENCE { >> nhdpDiscNeighborNibNeighborSetChanges >> Counter32, >> nhdpDiscNeighborNibNeighborSetUpTime >> TimeStamp, >> nhdpDiscNeighborNibNeighborSetReachableLinkChanges >> Counter32 >> } >> >> nhdpDiscNeighborNibNeighborSetChanges OBJECT-TYPE >> SYNTAX Counter32 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "This object returns the number of changes >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 47] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> to the given Neighbor Tuple." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpDiscNeighborSetPerfEntry 1 } >> >> >> nhdpDiscNeighborNibNeighborSetUpTime OBJECT-TYPE >> SYNTAX TimeStamp >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "This object returns the sysUpTime when >> the neighbor becomes 'nbrup'. A neighbor is >> said to become 'nbrup' if a new nhdpNibNeighborSetEntry >> is created for a particular nhdpNibNeighborSetRouterIndex. >> It becomes 'nbrdown' if the entry for that neighbor >> has been deleted." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpDiscNeighborSetPerfEntry 2 } >> >> nhdpDiscNeighborNibNeighborSetReachableLinkChanges OBJECT-TYPE >> SYNTAX Counter32 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "This object counts each time the neighbor changes >> the interface(s) over which it is reachable. >> A change in the set of Link Tuples corresponding >> to the appropriate Neighbor Tuple is registered, >> i.e. a corresponding Link Tuple is added or removed >> from the set of all corresponding Link Tuples." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpDiscNeighborSetPerfEntry 3 } >> >> >> >> >> -- >> -- Objects per discovered 2-hop neighbor >> -- >> nhdpIib2HopSetPerfTable OBJECT-TYPE >> SYNTAX SEQUENCE OF NhdpIib2HopSetPerfEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "This table contains performance objects per >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 48] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> discovered 2-hop neighbor." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpPerformanceObjGrp 5 } >> >> nhdpIib2HopSetPerfEntry OBJECT-TYPE >> SYNTAX NhdpIib2HopSetPerfEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "The entries contain performance objects per >> discovered 2-hop neighbor." >> REFERENCE >> "RFC6130." >> INDEX { nhdpDiscRouterIndex } >> ::=3D { nhdpIib2HopSetPerfTable 1 } >> >> NhdpIib2HopSetPerfEntry ::=3D >> SEQUENCE { >> nhdpIib2HopSetPerfChanges >> Counter32, >> nhdpIib2HopSetPerfUpTime >> TimeStamp >> } >> >> nhdpIib2HopSetPerfChanges OBJECT-TYPE >> SYNTAX Counter32 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "This object counts the changes of the union of all >> N2_neighbor_iface_addr_list of 2-Hop Tuples with an >> N2_2hop_addr equal to one of the given 2-hop >> neighbor's addresses." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpIib2HopSetPerfEntry 1 } >> >> >> nhdpIib2HopSetPerfUpTime OBJECT-TYPE >> SYNTAX TimeStamp >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "This object returns the sysUpTime >> when the 2-Hop Tuple >> corresponding to the given 2-hop neighbor IP address >> was registered in the nhdpIib2HopSetTable." >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 49] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> REFERENCE >> "RFC6130." >> ::=3D { nhdpIib2HopSetPerfEntry 2 } >> >> >> >> >> >> -- >> -- nhdpNotifications >> -- >> >> nhdpNotificationsObjects OBJECT IDENTIFIER ::=3D { nhdpNotifications 0 } >> nhdpNotificationsControl OBJECT IDENTIFIER ::=3D { nhdpNotifications 1 } >> nhdpNotificationsStates OBJECT IDENTIFIER ::=3D { nhdpNotifications 2 } >> >> >> -- nhdpNotificationsObjects >> >> nhdpNbrStateChange NOTIFICATION-TYPE >> OBJECTS { nhdpIfName, -- The originator of >> -- the notification. >> nhdpNbrState -- The new state >> } >> STATUS current >> DESCRIPTION >> "nhdpNbrStateChange is a notification sent when a >> significant number of neighbors change their status >> (i.e. down, asymmetric, or symmetric) in a short >> time. The network administrator should select >> appropriate values for 'significant number of >> neighbors' and 'short time'." >> ::=3D { nhdpNotificationsObjects 1 } >> >> TOM: You need to provide some guidelines for what "significant number" m= eans. >> >> nhdp2HopNbrStateChange Notification-TYPE >> OBJECTS { nhdpIfName, -- The originator >> -- of the notification >> nhdp2HopNbrState -- The new state >> } >> STATUS current >> DESCRIPTION >> "nhdp2HopNbrStateChange is a notification sent >> when a significant number of 2-hop neighbors >> change their status (i.e. up or down) in a short >> time. The network administrator should select >> appropriate values for 'significant number of >> neighbors' and 'short time'." >> ::=3D { nhdpNotificationsObjects 2 } >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 50] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> nhdpIfRxBadPacket NOTIFICATION-TYPE >> OBJECTS { nhdpDiscRouterIndex, -- The originator of >> -- the notification >> nhdpIfName, -- The interface on which the >> -- packet has been received >> nhdpPacketSrcAddrType, -- The type of the source IP >> -- address of the packet >> nhdpPacketSrcAddr -- The source IP address of >> -- the packet >> } >> STATUS current >> DESCRIPTION >> "nhdpIfRxBadPacket is a notification sent when a >> significant number of incoming packets have not >> been successfully parsed in a short time. The >> network administrator should select appropriate >> values for 'significant number of neighbors' >> and 'short time'." >> ::=3D { nhdpNotificationsObjects 3 } >> >> >> TOM: I am finding it very difficult to imagine how this would be impleme= nted, and done so in a consistent manner that is interoperable. Similar t= o above, you need to either allow the operator to define what "significant"= is, or be very clear in what triggers this notification (I prefer the latt= er). >> >> Also, I am concerned that there is no throttling of this notification= . What if %100 of the packets received are "bad" because the radio link is = messed up? Would this be a DoS attack on the device because it is forced t= o emit so many notifications that it overwhelms the CPU? >> >> Nhdpifstatechange NOTIFICATION-TYPE >> OBJECTS { nhdpIfName, -- The local interface >> nhdpIfState -- The new state >> } >> STATUS current >> DESCRIPTION >> "nhdpIfStateChange is a notification sent when >> the status of an interface of this router has >> changed (i.e. an IP address has been added or >> removed to the interface, or the interface has >> changed its status from up to down or vice versa)." >> ::=3D { nhdpNotificationsObjects 4 } >> >> >> >> >> -- nhdpNotificationsControl >> >> nhdpNbrStateChangeThreshold OBJECT-TYPE >> SYNTAX Integer32 (0..255) >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "A threshold value for the >> nhdpNbrStateChange object. If the >> number of occurrences exceeds this threshold >> within the previous nhdpNbrStateChangeWindow, >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 51] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> then the nhdpNbrStateChange notification >> is to be sent. >> >> It is recommended that the value of this >> threshold be set to at least 10, and higher >> in dense topologies with frequent expected >> topology changes. >> " >> DEFVAL { 10 } >> ::=3D { nhdpNotificationsControl 1 } >> >> nhdpNbrStateChangeWindow OBJECT-TYPE >> SYNTAX TimeTicks >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "A time window for the >> nhdpNbrStateChange object. If the >> number of occurrences exceeds the >> nhdpNbrStateChangeThreshold >> within the previous nhdpNbrStateChangeWindow, >> then the nhdpNbrStateChange notification >> is to be sent. >> >> It is recommended that the value for this >> window be set to at least 5 times the >> nhdpHelloInterval. >> >> This object represents the time in hundredths >> of a second. >> " >> DEFVAL { 1000 } >> ::=3D { nhdpNotificationsControl 2 } >> >> nhdp2HopNbrStateChangeThreshold OBJECT-TYPE >> SYNTAX Integer32 (0..255) >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "A threshold value for the >> nhdp2HopNbrStateChange object. If the >> number of occurrences exceeds this threshold >> within the previous nhdp2HopNbrStateChangeWindow, >> then the nhdp2HopNbrStateChange notification >> is to be sent. >> >> It is recommended that the value of this >> threshold be set to at least 10, and higher >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 52] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> when topologies are expected to be highly dynamic. >> " >> DEFVAL { 10 } >> ::=3D { nhdpNotificationsControl 3 } >> >> nhdp2HopNbrStateChangeWindow OBJECT-TYPE >> SYNTAX TimeTicks >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "A time window for the >> nhdp2HopNbrStateChange object. If the >> number of occurrences exceeds the >> nhdp2HopNbrStateChangeThreshold >> within the previous nhdp2HopNbrStateChangeWindow, >> then the nhdp2HopNbrStateChange notification >> is to be sent. >> >> It is recommended that the value for this >> window be set to at least 5 times >> nhdpHelloInterval. >> >> This object represents the time in hundredths >> of a second. >> " >> DEFVAL { 1000 } >> ::=3D { nhdpNotificationsControl 4 } >> >> nhdpIfRxBadPacketThreshold OBJECT-TYPE >> SYNTAX Integer32 (0..255) >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "A threshold value for the >> nhdpIfRxBadPacket object. If the >> number of occurrences exceeds this threshold >> within the previous nhdpIfRxBadPacketWindow, >> then the nhdpIfRxBadPacket notification >> is to be sent. >> " >> DEFVAL { 10 } >> ::=3D { nhdpNotificationsControl 5 } >> >> nhdpIfRxBadPacketWindow OBJECT-TYPE >> SYNTAX TimeTicks >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 53] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> "A time window for the >> nhdpIfRxBadPacket object. If the >> number of occurrences exceeds the >> nhdpIfRxBadPacketThreshold >> within the previous nhdpIfRxBadPacketWindow, >> then the nhdpIfRxBadPacket notification >> is to be sent. >> >> It is recommended that the value for this >> window be set to 5 times the nhdpHelloInterval. >> >> This object represents the time in hundredths >> of a second. >> " >> DEFVAL { 1000 } >> ::=3D { nhdpNotificationsControl 6 } >> >> >> >> -- nhdpNotificationStates >> >> nhdpNbrState OBJECT-TYPE >> SYNTAX INTEGER { >> down(0), >> asymmetric(1), >> symmetric(2) >> } >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "NHDP neighbor states. In NHDP it is not >> necessary to remove Protocol Tuples from Protocol Sets >> at the exact time indicated, only to behave as if the >> Protocol Tuples were removed at that time. This case is >> indicated here as 'down(0)', all other cases being >> indicated as 'assymetric(1)' or 'symmetric(2)'. If down, >> the direct neighbor is also added to the >> nhdpNibLostNeighborSetTable. >> " >> ::=3D { nhdpNotificationsStates 1 } >> >> nhdp2HopNbrState OBJECT-TYPE >> SYNTAX INTEGER { >> down(0), >> up(1) >> } >> MAX-ACCESS read-only >> STATUS current >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 54] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> DESCRIPTION >> "NHDP 2-hop neighbor states. In NHDP it is not >> necessary to remove Protocol Tuples from Protocol Sets >> at the exact time indicated, only to behave as if the >> Protocol Tuples were removed at that time. This case is >> indicated here as 'down(0)', otherwise as 'up(1)'." >> ::=3D { nhdpNotificationsStates 2 } >> >> Nhdpifstate Object-TYPE >> SYNTAX TruthValue >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "NHDP MANET interface states. This indicates whether >> the interface is a MANET interface. A value of true(1) >> indicates that the interface is a MANET interface. >> A value of false(2) indicates that the interface is >> not a MANET interface. This corresponds to the I_manet >> parameter in the Local Interface Set." >> ::=3D { nhdpNotificationsStates 3 } >> >> >> TOM: This notification is potentially dangerous given how the IfTable re= lationship is currently defined above to be essentially a 1:1 match with th= e IfEntry. Imagine having to issue notifications constantly for IF state c= hanges for every interface in the normal IF-MIB and then here? Also, what = value does this notification add above/beyond the normal IfUp/Down notifica= tion if you define an ifType=3Dmanet as I suggested above? >> >> >> nhdpPacketSrcAddrType OBJECT-TYPE >> SYNTAX InetAddressType >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The IP address type of the >> address of an inbound packet that >> cannot be identified by a neighbor instance. >> >> Only the values ipv4(1) and ipv6(2) are supported. >> " >> ::=3D { nhdpNotificationsStates 4 } >> >> nhdpPacketSrcAddr Object-TYPE >> SYNTAX InetAddress (SIZE(4|16)) >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The IP address of an inbound packet that >> cannot be identified by a neighbor instance. When >> the last value of a notification using this object is >> needed, but no notifications of that type have been sent, >> the value pertaining to this object should >> be returned as 0.0.0.0 or :: respectively. >> " >> ::=3D { nhdpNotificationsStates 5 } >> >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 55] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> -- >> -- nhdpConformance information >> -- >> >> nhdpCompliances OBJECT IDENTIFIER ::=3D { nhdpConformance 1 } >> nhdpMIBGroups OBJECT IDENTIFIER ::=3D { nhdpConformance 2 } >> >> >> -- Compliance Statements >> nhdpBasicCompliance MODULE-COMPLIANCE >> STATUS current >> DESCRIPTION >> "The basic implementation requirements for >> managed network entities that implement >> NHDP." >> MODULE -- this module >> >> MANDATORY-GROUPS { nhdpConfigurationGroup } >> ::=3D { nhdpCompliances 1 } >> >> >> nhdpFullCompliance MODULE-COMPLIANCE >> STATUS current >> DESCRIPTION >> "The full implementation requirements for >> managed network entities that implement >> NHDP." >> MODULE -- this module >> >> MANDATORY-GROUPS { nhdpConfigurationGroup, >> nhdpStateGroup, >> nhdpNotificationObjectGroup, >> nhdpNotificationGroup, >> nhdpPerformanceGroup } >> ::=3D { nhdpCompliances 2 } >> >> >> -- >> -- Units of Conformance >> -- >> >> nhdpConfigurationGroup OBJECT-GROUP >> OBJECTS { >> nhdpIfName, >> nhdpIfStatus, >> nhdpHelloInterval, >> nhdpHelloMinInterval, >> nhdpRefreshInterval, >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 56] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> nhdpLHoldTime, >> nhdpHHoldTime, >> nhdpHystAcceptQuality, >> nhdpHystRejectQuality, >> nhdpInitialQuality, >> nhdpInitialPending, >> nhdpHpMaxJitter, >> nhdpHtMaxJitter, >> nhdpNHoldTime, >> nhdpIHoldTime, >> nhdpIfRowStatus, >> nhdpLibLocalIfSetIfIndex, >> nhdpLibLocalIfSetIpAddrType, >> nhdpLibLocalIfSetIpAddr, >> nhdpLibLocalIfSetIpAddrPrefixLen, >> nhdpLibLocalIfSetIsManet, >> nhdpLibLocalIfSetRowStatus, >> nhdpLibRemovedIfAddrSetIpAddrType, >> nhdpLibRemovedIfAddrSetIpAddr, >> nhdpLibRemovedIfAddrSetIpAddrPrefixLen, >> nhdpLibRemovedIfAddrSetIfIndex, >> nhdpLibRemovedIfAddrSetIRTime >> } >> STATUS current >> DESCRIPTION >> "Set of NHDP configuration objects implemented >> in this module." >> ::=3D { nhdpMIBGroups 2 } >> >> nhdpStateGroup OBJECT-GROUP >> OBJECTS { >> nhdpUpTime, >> nhdpIfStateUpTime, >> nhdpDiscRouterIndex, >> nhdpDiscIfIndex, >> nhdpDiscIfSetIpAddrType, >> nhdpDiscIfSetIpAddr, >> nhdpDiscIfSetIpAddrPrefixLen, >> nhdpIibLinkSetLHeardTime, >> nhdpIibLinkSetLSymTime, >> nhdpIibLinkSetLPending, >> nhdpIibLinkSetLLost, >> nhdpIibLinkSetLTime, >> nhdpIib2HopSetIpAddrPrefixLen, >> nhdpIib2HopSet1HopIfIndex, >> nhdpIib2HopSetN2Time, >> nhdpNibNeighborSetNSymmetric, >> nhdpNibLostNeighborSetNLTime >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 57] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> } >> STATUS current >> DESCRIPTION >> "Set of NHDP state objects implemented >> in this module." >> ::=3D { nhdpMIBGroups 3 } >> >> nhdpPerformanceGroup OBJECT-GROUP >> OBJECTS { >> nhdpIfHelloMessageXmits, >> nhdpIfHelloMessageRecvd, >> nhdpIfHelloMessageXmitAccumulatedSize, >> nhdpIfHelloMessageRecvdAccumulatedSize, >> nhdpIfHelloMessageTriggeredXmits, >> nhdpIfHelloMessagePeriodicXmits, >> nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount, >> nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount, >> nhdpIfHelloMessageXmitAccumulatedLostNeighborCount, >> nhdpDiscIfRecvdPackets, >> nhdpDiscIfExpectedPackets, >> nhdpNibNeighborSetChanges, >> nhdpDiscNeighborNibNeighborSetChanges, >> nhdpDiscNeighborNibNeighborSetUpTime, >> nhdpDiscNeighborNibNeighborSetReachableLinkChanges, >> nhdpIib2HopSetPerfChanges, >> nhdpIib2HopSetPerfUpTime >> } >> STATUS current >> DESCRIPTION >> "Set of NHDP performance objects implemented >> in this module." >> ::=3D { nhdpMIBGroups 4 } >> >> nhdpNotificationObjectGroup OBJECT-GROUP >> OBJECTS { >> nhdpNbrStateChangeThreshold, >> nhdpNbrStateChangeWindow, >> nhdp2HopNbrStateChangeThreshold, >> nhdp2HopNbrStateChangeWindow, >> nhdpIfRxBadPacketThreshold, >> nhdpIfRxBadPacketWindow, >> nhdpIfState, >> nhdpNbrState, >> nhdp2HopNbrState, >> nhdpPacketSrcAddrType, >> nhdpPacketSrcAddr >> } >> STATUS current >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 58] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> DESCRIPTION >> "Set of NHDP notification objects implemented >> in this module." >> ::=3D { nhdpMIBGroups 5 } >> >> >> >> nhdpNotificationGroup NOTIFICATION-GROUP >> NOTIFICATIONS { >> nhdpNbrStateChange, >> nhdp2HopNbrStateChange, >> nhdpIfRxBadPacket, >> nhdpIfStateChange >> } >> STATUS current >> DESCRIPTION >> "Set of NHDP notifications implemented >> in this module." >> ::=3D { nhdpMIBGroups 6 } >> >> >> END >> >> 8. Security Considerations >> >> This MIB module defines objects for the configuration, monitoring and >> notification of the Neighborhood Discovery Protocol [RFC6130]. NHDP >> allows routers to acquire topological information up to two hops away >> by virtue of exchanging HELLO messages. The information acquired by >> NHDP may be used by routing protocols. The neighborhood information, >> exchanged between routers using NHDP, serves these routing protocols >> as a baseline for calculating paths to all destinations in the MANET, >> relay set selection for network-wide transmissions etc. >> >> There are a number of management objects defined in this MIB module >> with a MAX-ACCESS clause of read-write and/or read-create. Such >> objects may be considered sensitive or vulnerable in some network >> environments. The support for SET operations in a non-secure >> environment without proper protection can have a negative effect on >> network operations. These are the tables and objects and their >> sensitivity/vulnerability: >> >> o nhdpIfStatus - this writable object turns on or off the NHDP >> process for the specified interface. If disabled, higher level >> protocol functions, e.g., routing, would fail causing network-wide >> disruptions. >> >> >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 59] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> o nhdpHelloInterval, nhdpHelloMinInterval, and nhdpRefreshInterval - >> these writable objects control the rate at which HELLO messages >> are sent on an interface. If set at too high a rate, this could >> represent a form of DOS attack by overloading interface resources. >> >> o nhdpHystAcceptQuality, nhdpHystRejectQuality, nhdpInitialQuality, >> nhdpInitialPending - these writable objects affect the perceived >> quality of the NHDP links and hence the overall stability of the >> network. If improperly set, these settings could result in >> network-wide disruptions. >> >> o nhdpInterfaceTable - this table contains writable objects that >> affect the overall performance and stability of the NHDP process. >> Failure of the NHDP process would result in network-wide failure. >> Particularly sensitive objects from this table are discussed in >> the previous list items. This is the only table in the NHDP-MIB >> module with writable objects. >> >> Some of the readable objects in this MIB module (i.e., objects with a >> MAX-ACCESS other than not-accessible) may be considered sensitive or >> vulnerable in some network environments. It is thus important to >> control even GET and/or NOTIFY access to these objects and possibly >> to even encrypt the values of these objects when sending them over >> the network via SNMP. These are the tables and objects and their >> sensitivity/vulnerability: >> >> o nhdpDiscIfSetTable - The object contains information on discovered >> neighbors, specifically their IP address in the >> nhdpDiscIfSetIpAddr object. This information provides an >> adversary broad information on the members of the MANET, located >> within this single table. This information can be use to expedite >> attacks on the other members of the MANET without having to go >> through a laborious discovery process on their own. This object >> is the index into the table, and has a MAX-ACCESS of 'not- >> accessible'. However, this information can be exposed using SNMP >> operations. >> >> MANET technology is often deployed to support communications of >> emergency services or military tactical applications. In these >> applications, it is imperative to maintain the proper operation of >> the communications network and to protect sensitive information >> related to its operation. Therefore, it is RECOMMENDED to provide >> support for the Transport Security Model (TSM) [RFC5591] in >> combination with TLS/DTLS [RFC6353]. >> >> SNMP versions prior to SNMPv3 did not include adequate security. >> Even if the network itself is secure (for example by using IPsec), >> there is no control as to who on the secure network is allowed to >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 60] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> access and GET/SET (read/change/create/delete) the objects in this >> MIB module. >> >> Implementations MUST provide the security features described by the >> SNMPv3 framework (see [RFC3410] ), including full support for >> authentication and privacy via the User-based Security Model (USM) >> [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations >> MAY also provide support for the Transport Security Model (TSM) >> [RFC5591] in combination with a secure transport such as SSH >> [RFC5592] or TLS/DTLS [RFC6353]. >> >> Further, deployment of SNMP versions prior to SNMPv3 is NOT >> RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to >> enable cryptographic security. It is then a customer/operator >> responsibility to ensure that the SNMP entity giving access to an >> instance of this MIB module is properly configured to give access to >> the objects only to those principals (users) that have legitimate >> rights to indeed GET or SET (change/create/delete) them. >> >> 9. IANA Considerations >> >> Editor's Note (to be removed prior to publication): the IANA is >> requested to assign a value for "XXXX" under the 'mib-2' subtree and >> to record the assignment in the SMI Numbers registry. When the >> assignment has been made, the RFC Editor is asked to replace "XXXX" >> (here and in the MIB module) with the assigned value and to remove >> this note. Note well: prior to official assignment by the IANA, a >> draft document MUST use placeholders (such as "XXXX" above) rather >> than actual numbers. See RFC4181 Section 4.5 for an example of how >> this is done in a draft MIB module. >> >> 10. Acknowledgements >> >> The authors wish to thank Thomas Clausen, Justin Dean, and Adrian >> Farrel for their detailed reviews and insightful comments to this >> document. >> >> This MIB document uses the template authored by D. Harrington which >> is based on contributions from the MIB Doctors, especially Juergen >> Schoenwaelder, Dave Perkins, C.M.Heard and Randy Presuhn. >> >> 11. References >> >> 11.1. Normative References >> >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement Levels", BCP 14, RFC 2119, March 1997. >> >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 61] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. >> Schoenwaelder, Ed., "Structure of Management >> Information Version 2 (SMIv2)", STD 58, RFC 2578, >> April 1999. >> >> [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. >> Schoenwaelder, Ed., "Textual Conventions for SMIv2", >> STD 58, RFC 2579, April 1999. >> >> [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, >> "Conformance Statements for SMIv2", STD 58, RFC 2580, >> April 1999. >> >> [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group >> MIB", RFC 2863, June 2000. >> >> [RFC3418] Presuhn, R., "Management Information Base (MIB) for the >> Simple Network Management Protocol (SNMP)", STD 62, >> RFC 3418, December 2002. >> >> [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. >> Schoenwaelder, "Textual Conventions for Internet >> Network Addresses", RFC 4001, February 2005. >> >> [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc >> Network (MANET) Neighborhood Discovery Protocol >> (NHDP)", RFC 6130, April 2011. >> >> [RFC6340] Presuhn, R., "Textual Conventions for the >> Representation of Floating-Point Numbers", RFC 6340, >> August 2011. >> >> 11.2. Informative References >> >> [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, >> "Introduction and Applicability Statements for >> Internet-Standard Management Framework", RFC 3410, >> December 2002. >> >> [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security >> Model (USM) for version 3 of the Simple Network >> Management Protocol (SNMPv3)", STD 62, RFC 3414, >> December 2002. >> >> [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The >> Advanced Encryption Standard (AES) Cipher Algorithm in >> the SNMP User-based Security Model", RFC 3826, >> June 2004. >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 62] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> [RFC4750] Joyal, D., Galecki, P., Giacalone, S., Coltun, R., and >> F. Baker, "OSPF Version 2 Management Information Base", >> RFC 4750, December 2006. >> >> [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter >> Considerations in Mobile Ad Hoc Networks (MANETs)", >> RFC 5148, February 2008. >> >> [RFC5591] Harrington, D. and W. Hardaker, "Transport Security >> Model for the Simple Network Management Protocol >> (SNMP)", RFC 5591, June 2009. >> >> [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure >> Shell Transport Model for the Simple Network Management >> Protocol (SNMP)", RFC 5592, June 2009. >> >> [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport >> Model for the Simple Network Management Protocol >> (SNMP)", RFC 6353, July 2011. >> >> [REPORT-MIB] Cole, R., Macker, J., and A. Bierman, "Definition of >> Managed Objects for Performance Reporting", work in >> progress draft-ietf-manet-report-mib-02, January 2012. >> >> Appendix A. >> >> >> *************************************************************** >> * Note to the RFC Editor (to be removed prior to publication) * >> * * >> * The reference to RFCXXXX within the DESCRIPTION clauses * >> * of the MIB module point to this draft and are to be * >> * assigned by the RFC Editor. * >> * * >> *************************************************************** >> >> >> Why is "Appendix A" as a section necessary? Are you telling the RFC edi= tor to remove the section and also modify the table of contents? Its just = easier to discard the section now. >> >> Authors' Addresses >> >> Ulrich Herberg >> LIX, Ecole Polytechnique >> Palaiseau Cedex, 91128 >> France >> >> EMail: ulrich@herberg.name >> URI: http://www.herberg.name/ >> >> >> >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 63] >> Internet-Draft The NHDP-MIB June 2012 >> >> >> Robert G. Cole >> US Army CERDEC >> 6010 Frankford Road, Bldg 6010 >> Aberdeen Proving Ground, Maryland 21005 >> USA >> >> Phone: +1 443 395 8744 >> EMail: robert.g.cole@us.army.mil >> URI: http://www.cs.jhu.edu/~rgcole/ >> >> >> Ian D Chakeres >> CenGen >> 9250 Bendix Road North >> Columbia, Maryland 560093 >> USA >> >> EMail: ian.chakeres@gmail.com >> URI: http://www.ianchak.com/ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Herberg, et al. Expires December 3, 2012 [Page 64] >> < >> >> From: Adrian Farrel > >> Reply-To: "adrian@olddog.co.uk" > >> To: 'Ulrich Herberg' >, = "'Bert Wijnen (IETF)'" > >> Cc: "manet-chairs@tools.ietf.org" >, "draft-iet= f-manet-nhdp-mib@tools.ietf.org" >, "'MIB Doctors (E-mail)'" > >> Subject: Re: [MIB-DOCTORS] Heads-up MIB review impending >> >> Ulrich, >> >> just in case you are no aware of http://www.ibr.cs.tu-bs.de/projects/lib= smi/tools/ >> >> Adrian >> >> From: Ulrich Herberg [mailto:ulrich@herberg.name] >> Sent: 22 May 2012 19:37 >> To: Bert Wijnen (IETF) >> Cc: Benoit Claise; Adrian Farrel; manet-chairs@tools.ietf.org; MIB Doctors (E-mail); draft-ietf-manet-nhdp-mib@= tools.ietf.org >> Subject: Re: [MIB-DOCTORS] Heads-up MIB review impending >> >> Bert, >> On Tue, May 22, 2012 at 11:33 AM, Bert Wijnen (IETF) > wrote: >> Unfortunately, there is not a free version (at least not current) >> available as far as I know. I don;t understand why the author does not >> just make it open source and available to everyone. >> But that is his call I guess. >> >> Okay, I see. My company will likely not pay for that, and personally I'd= rather go to vacations than buy a MIB compiler ;-) >> >> >> >> Oh by the way, you also already user { mib-2 998 } for the MIB OID!!! >> that is not proper! You should use xxx or some such instead of 998 >> (as you indicate in the rfc-editor comment ;-) >> >> I know, that has been discovered in the IESG LC. The reason why we did n= ot put xxxx there is that smilint complains otherwise and fails to compile.= It will be fixed in the next revision of the draft (or in the RFC editor q= ueue). >> >> Best >> Ulrich >> >> >> Bert >> >> >> On 5/22/12 7:03 PM, Ulrich Herberg wrote: >> Bert, >> >> thank you very much for this first review. We will work on fixing these = and spin a new version. >> >> By the way, is there a free version of SMICng available? I only have smi= lint. >> >> Best regards >> Ulrich >> On Tue, May 22, 2012 at 2:11 AM, Bert Wijnen (IETF) >> wrote: >> >> This is by no means a full MIB review, but I did a quick SMICng SYNTAX = check: >> >> W: f(nhdp.mi2), (778,5) Row "nhdpLibRemovedIfAddrSetEntry" has indexing >> that may create variables with more than 128 sub-ids >> W: f(nhdp.mi2), (1221,5) Row "nhdpIib2HopSetEntry" has indexing that ma= y >> create variables with more than 128 sub-ids >> W: f(nhdp.mi2), (1117,16) Row "nhdpIibLinkSetEntry" does not have a >> consistent indexing scheme - index item nhdpDiscIfIndex from base >> row nhdpDiscIfSetEntry is not defined as an index item >> W: f(nhdp.mi2), (1376,15) Row "nhdpNibNeighborSetEntry" does not have a >> consistent indexing scheme - index item nhdpDiscRouterIndex from b= ase >> row nhdpDiscIfSetEntry is not defined as an index item >> W: f(nhdp.mi2), (1425,16) Row "nhdpNibLostNeighborSetEntry" does not ha= ve >> a consistent indexing scheme - index item nhdpDiscRouterIndex from= base >> row nhdpDiscIfSetEntry is not defined as an index item >> W: f(nhdp.mi2), (1614,16) Row "nhdpDiscIfSetPerfEntry" does not have a >> consistent indexing scheme - index item nhdpDiscIfIndex from base = row >> nhdpDiscIfSetEntry is not defined as an index item >> W: f(nhdp.mi2), (1690,16) Row "nhdpDiscNeighborSetPerfEntry" does not >> have a consistent indexing scheme - index item nhdpDiscRouterIndex= from >> base row nhdpDiscIfSetEntry is not defined as an index item >> W: f(nhdp.mi2), (1768,16) Row "nhdpIib2HopSetPerfEntry" does not have a >> consistent indexing scheme - index item nhdpDiscRouterIndex from b= ase >> row nhdpDiscIfSetEntry is not defined as an index item >> W: f(nhdp.mi2), (1941,21) Variable "nhdpIfIndex" in notification >> "nhdpNbrStateChange" is an index for a table >> W: f(nhdp.mi2), (1956,21) Variable "nhdpIfIndex" in notification >> "nhdp2HopNbrStateChange" is an index for a table >> W: f(nhdp.mi2), (1973,21) Variable "nhdpIfIndex" in notification >> "nhdpIfRxBadPacket" is anindex for a table >> W: f(nhdp.mi2), (1992,21) Variable "nhdpIfIndex" in notification >> "nhdpIfStateChange" is anindex for a table >> W: f(nhdp.mi2), (2142,22) Duplicate item "nhdpPerformanceGroup" >> in MANDATORY-GROUPS for module "NHDP-MIB" >> >> >> The first Warning got me to look at: >> nhdpLibRemovedIfAddrSetEntry OBJECT-TYPE >> SYNTAX NhdpLibRemovedIfAddrSetEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "A router's Removed Interface Address Set consists >> of Removed Interface Address Tuples, one per network >> address: >> >> (IR_local_iface_addr, IR_time) >> >> The association between these addrs and >> the router's Interface is found in the >> >> Standard MIB II's IP address table >> (RFC1213)." >> REFERENCE >> "RFC6130." >> INDEX { nhdpLibRemovedIfAddrSetIpAddrT__ype, >> >> nhdpLibRemovedIfAddrSetIpAddr } >> ::=3D { nhdpLibRemovedIfAddrSetTable 1 } >> >> NhdpLibRemovedIfAddrSetEntry ::=3D >> SEQUENCE { >> nhdpLibRemovedIfAddrSetIpAddrT__ype >> InetAddressType, >> nhdpLibRemovedIfAddrSetIpAddr >> InetAddress, >> nhdpLibRemovedIfAddrSetIpAddrP__refixLen >> >> InetAddressPrefixLength, >> nhdpLibRemovedIfAddrSetIfIndex >> InterfaceIndexOrZero, >> nhdpLibRemovedIfAddrSetIRTime >> TimeStamp >> } >> nhdpLibRemovedIfAddrSetIpAddrT__ype OBJECT-TYPE >> >> SYNTAX InetAddressType >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The type of the nhdpLibRemovedIfAddrSetIpAddr >> in the InetAddress MIB (RFC4001). >> >> Only the values ipv4(1) and >> ipv6(2) are supported." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpLibRemovedIfAddrSetEntry 1 } >> >> nhdpLibRemovedIfAddrSetIpAddr OBJECT-TYPE >> SYNTAX InetAddress >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "nhdpLibRemovedIfAddrSetIpAddr is a >> recently used address of an interface of >> this router." >> REFERENCE >> "RFC6130." >> ::=3D { nhdpLibRemovedIfAddrSetEntry 2 } >> >> And I note that: >> >> - the 2 INDEX obbjects are defined read-only. Normally they would be >> not-accessible!!! See RFC2578 >> - If this is ALWAYS true: >> nhdpLibRemovedIfAddrSetIpAddrT__ype OBJECT-TYPE >> >> SYNTAX InetAddressType >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The type of the nhdpLibRemovedIfAddrSetIpAddr >> in the InetAddress MIB (RFC4001). >> >> Only the values ipv4(1) and >> ipv6(2) are supported." >> Then you could do: >> nhdpLibRemovedIfAddrSetIpAddr OBJECT-TYPE >> SYNTAX InetAddress (SIZE(4|16)) >> MAX-ACCESS read-only >> Otherwise you would have to add something to description clause to >> warn implementers that they should consider OID size. >> >> The third warning: >> W: f(nhdp.mi2), (1117,16) Row "nhdpIibLinkSetEntry" does not have a >> consistent indexing scheme - index item nhdpDiscIfIndex from ba= se >> row nhdpDiscIfSetEntry is not defined as an index item >> Seems a valid warning. But I am not 100% sure. I'd have to go and study >> more detauil to determine. >> Anyways, these "inconsistent indexing" warnings are indeed just >> warnings. It may be OK, but it would be good to check and make sure >> that this results in proper (i.e. unique) indexing values and that the >> indexing is indeed as intended. >> >> Sorry, not enough time to check more details now. >> >> Bert >> ----- Original Message ----- From: "Benoit Claise" >> >> >> To: >> >> Cc: >>; >>; >> >> >> >> Sent: Tuesday, May 22, 2012 12:15 AM >> >> Subject: Re: [MIB-DOCTORS] Heads-up MIB review impending >> >> >> Dear all, >> >> I have deferred this draft for the next telechat. >> >> Regards, Benoit. >> >> Hi MIB doctors, >> >> We would really benefit from your expertise here. >> Can we please have a volunteer. >> If we don't find someone by the end of the day (on telechat for= this >> Thursday), I'm afraid that I will have to defer this draft to t= he next >> telechat... >> >> Regards, Benoit. >> >> Hi MIB doctors, >> >> My bad for not following up on this one. I will follow more= closely from now >> on. >> Can we please have a volunteer to review this MIB module, w= hich is on the >> IESG telechat for next Thursday. >> >> Regards, Benoit. >> >> Hi MIB Doctors, >> >> Heads up to give you extra review time. >> https://datatracker.ietf.org/__doc/draft-ietf-manet-nhd= p-mib/ >> >> is going to >> IETF >> last call very soon and would benefit significantly fro= m a MIB Doctor >> review by >> the end of the last call. >> >> Thanks for the work you do. >> >> Adrian >> _________________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org > >> https://www.ietf.org/mailman/__listinfo/mib-doctors >> >> >> >> _________________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org > >> https://www.ietf.org/mailman/__listinfo/mib-doctors >> >> >> >> _________________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org > >> https://www.ietf.org/mailman/__listinfo/mib-doctors >> >> >> >> _________________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org > >> https://www.ietf.org/mailman/__listinfo/mib-doctors >> >> >> From aldrin.ietf@gmail.com Tue Jun 12 21:01:15 2012 Return-Path: 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 6429511E80A4; Tue, 12 Jun 2012 21:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.531 X-Spam-Level: X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, 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 94XkSir4t15E; Tue, 12 Jun 2012 21:01:14 -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 19CD811E808D; Tue, 12 Jun 2012 21:01:12 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so1715931pbc.31 for ; Tue, 12 Jun 2012 21:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=6/DA3DrVbgTFAg54DXsmn0s+dZbKcxZ6JCYJGkE2plc=; b=DSb/FSzxllIlqVsqvTipYBisXwQgqFtVzeDrIiES3J01jXPbHZ765VRccftFB+RPTa tWnNvwwCnaLLypWMQka0fCBJ5ffBQPqT0Jk2aGjFNBDm6Kq5uNrzrKDeT943DvZazUjy sv+ogoqAYgM8kTsxAqioTTzOAJLwKDE7Ncpjhh1OK30zx3FaBkgDrJFaRoehIzfgOXyJ KKb3Wual2yvek1m244nwy+KcvdTMADdydhhzSK66zXiPUSpgJ6ZZIPpfNFXNmScj2PuY PzjTpwe5vgCQymtEpreMbrPGFVr8lS+Vbz4dO8knIn855Tl7vqn1EaVZV4J0/0X/WxRs L4pg== Received: by 10.68.197.136 with SMTP id iu8mr45590802pbc.111.1339560071767; Tue, 12 Jun 2012 21:01:11 -0700 (PDT) Received: from [192.168.1.2] (c-107-3-156-34.hsd1.ca.comcast.net. [107.3.156.34]) by mx.google.com with ESMTPS id ql3sm4251707pbc.72.2012.06.12.21.01.09 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jun 2012 21:01:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Sam Aldrin X-Priority: 3 In-Reply-To: <0eb801cd4219$c9fc8e80$6701a8c0@JoanPC> Date: Tue, 12 Jun 2012 21:01:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <808F402F-A29C-4BD6-A48E-FF48C265ACA0@gmail.com> References: <0eb801cd4219$c9fc8e80$6701a8c0@JoanPC> To: Joan Cucchiara X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Wed, 13 Jun 2012 07:25:36 -0700 Cc: Swallow George , mpls@ietf.org, "MIB Doctors \(E-mail\)" , Kannan KV Sampath , venkat.mahalingams@gmail.com, Ross Callon , Loa Andersson Subject: Re: [MIB-DOCTORS] MIB Dr. Review: draft-ietf-mpls-tp-te-mib-03.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 04:01:15 -0000 Hi Joan, Thank you for the detailed review. Appreciate that very much. Please find my comments inline with %sam. -sam On Jun 3, 2012, at 11:17 PM, Joan Cucchiara wrote: >=20 > Hello, >=20 > This document is clearly written and the examples are great! Thanks = for that! >=20 > Review is divided into sections. General Comments are followed by = specific sections. > The MIB Modules were compiled by smiLint and results are in each MIB = Modules' > section. There are some warnings, but think these should be fixed. >=20 > My major concern is contained in the General Comments section below. >=20 > Thanks, > -Joan >=20 >=20 > General Comments > ----------------- >=20 > Major concern: >=20 > I would like to express that I can see why the MIB Modules > are designed as they are. Namely, so mplsTunnelTable (in rfc3812) > can be used for MPLS-TP Tunnels also. I do see there is likely to > be value in doing that. However, my concern is that > the semantic definition of two indices for mplsTunnelTable > (mplsTunnelIngressLSRId, mplsTunnelEgressLSRId) > are being semantically redefined in the MPLS-TE-EXT-STD-MIB, and this > breaks the rules of the SMI and there is a chance that legacy > implementations could be jeopardized. >=20 > The index being proposed is: mplsNodeConfigLocalId >=20 > mplsNodeConfigLocalId OBJECT-TYPE > SYNTAX MplsLocalId > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This object allows the administrator to assign a unique > local identifier to map Global_Node_ID or ICC." > ::=3D { mplsNodeConfigEntry 1 } >=20 > Where the TC MplsLocalId is: >=20 > MplsLocalId ::=3D TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION > "This textual convention is used in accommodating the bigger > size Global_Node_ID and/or ICC with lower size LSR > identifier in order to index the mplsTunnelTable. >=20 > The Local Identifier is configured between 1 and 16777215, > as valid IP address range starts from 16777216(01.00.00.00). > This range is chosen to identify the mplsTunnelTable's > Ingress/Egress LSR-id is IP address or Local identifier, > if the configured range is not IP address, administrator is > expected to retrieve the complete information > (Global_Node_ID or ICC) from mplsNodeConfigTable. This way, > existing mplsTunnelTable is reused for bidirectional tunnel > extensions for MPLS based transport networks. >=20 > This Local Identifier allows the administrator to assign > a unique identifier to map Global_Node_ID and/or ICC." > SYNTAX Unsigned32(1..16777215) >=20 >=20 >=20 > The MPLS-TE-STD-MIB (rfc3812) and the MPLS-TC-STD-MIB (rfc3811) > have described the MplsExtendedTunnelId as: >=20 > MplsTunnelEntry ::=3D SEQUENCE { > ..... > mplsTunnelIngressLSRId MplsExtendedTunnelId, > mplsTunnelEgressLSRId MplsExtendedTunnelId, >=20 >=20 >=20 > mplsTunnelIngressLSRId OBJECT-TYPE > SYNTAX MplsExtendedTunnelId > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Identity of the ingress LSR associated with this > tunnel instance. When the MPLS signalling protocol > is rsvp(2) this value SHOULD be equal to the Tunnel > Sender Address in the Sender Template object and MAY > be equal to the Extended Tunnel Id field in the > SESSION object. When the MPLS signalling protocol is > crldp(3) this value SHOULD be equal to the Ingress > LSR Router ID field in the LSPID TLV object." > REFERENCE > "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, > Awduche et al, RFC 3209, December 2001 > 2. Constraint-Based LSP Setup using LDP, Jamoussi > (Editor), RFC 3212, January 2002" > ::=3D { mplsTunnelEntry 3 } >=20 > mplsTunnelEgressLSRId OBJECT-TYPE > SYNTAX MplsExtendedTunnelId > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Identity of the egress LSR associated with this > tunnel instance." > ::=3D { mplsTunnelEntry 4 } >=20 >=20 > The TC from MPLS-TC-STD-MIB (rfc3811) is: > MplsExtendedTunnelId ::=3D TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "A unique identifier for an MPLS Tunnel. This may > represent an IPv4 address of the ingress or egress > LSR for the tunnel. This value is derived from the > Extended Tunnel Id in RSVP or the Ingress Router ID > for CR-LDP." > REFERENCE > "RSVP-TE: Extensions to RSVP for LSP Tunnels, > [RFC3209]. >=20 > Constraint-Based LSP Setup using LDP, [RFC3212]." > SYNTAX Unsigned32(0..4294967295) >=20 >=20 > So, while I agree that mplsTunnelIngressLSRID and = mplsTunnelEgressLSRId > and mplsNodeConfigLocalId are all 32-bit values, the following 2 TCs = are not semantically the same: >=20 >=20 > MplsExtendedTunnelId ::=3D TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "A unique identifier for an MPLS Tunnel. This may > represent an IPv4 address of the ingress or egress > LSR for the tunnel. This value is derived from the > Extended Tunnel Id in RSVP or the Ingress Router ID > for CR-LDP." > REFERENCE > "RSVP-TE: Extensions to RSVP for LSP Tunnels, > [RFC3209]. >=20 > Constraint-Based LSP Setup using LDP, [RFC3212]." > SYNTAX Unsigned32(0..4294967295) >=20 > MplsLocalId ::=3D TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION > "This textual convention is used in accommodating the bigger > size Global_Node_ID and/or ICC with lower size LSR > identifier in order to index the mplsTunnelTable. >=20 > The Local Identifier is configured between 1 and 16777215, > as valid IP address range starts from 16777216(01.00.00.00). > This range is chosen to identify the mplsTunnelTable's > Ingress/Egress LSR-id is IP address or Local identifier, > if the configured range is not IP address, administrator is > expected to retrieve the complete information > (Global_Node_ID or ICC) from mplsNodeConfigTable. This way, > existing mplsTunnelTable is reused for bidirectional tunnel > extensions for MPLS based transport networks. >=20 > This Local Identifier allows the administrator to assign > a unique identifier to map Global_Node_ID and/or ICC." > SYNTAX Unsigned32(1..16777215) >=20 > Therefore, I believe this is a semantic redefinition and could = potentially cause > issues for some legacy implementations. %sam - Very good point. Thinking more about it, we should be able to use = mplsExtendedTunnelId itself, instead of mplsLocalId. As the = mplsExtendedTunnelId could have IP address or LSR identifier, we should = just use it as LSR identifier. Instead of specifying or mandating what = the identifier should be, we should leave as implementation specific, = when used for identifying Egress and Egress LSR's.=20 Having said that, we could still provide text with guidance, like we did = to describe what LocalId is and how it is derived to identify Egress and = Ingress LSR's for TP tunnels. At the end of the day, the Egress LSR and = Ingress LSR identifiers should be unique, for a TP tunnel, on a given = LSR (based on GlobalID etc). We will reword the text and make appropriate changes to reflect the = same. This will ensure the semantics are not redefined and legacy = implementations are nor broken. >=20 >=20 >=20 >=20 > *) There were some warning generated by smiLint that should probably > be fixed (please see individual MIB Modules discussion below.) >=20 %Sam - nod. >=20 >=20 >=20 > *) MIB should be capitalized consistently. Sometimes mib is used, so > please use capitals. %sam - nod >=20 >=20 > *) There are 4 MIB Modules in this document which pertain to > MPLS-TP. The proposal is to root them under mplsStdMIB. > This has not been the convention for sometime. However, if the > authors feel strongly about using mplsStdMIB, then please let me > know. %sam - we went back and forth on this, amongst ourselves and gotten some = feed back from WG chairs and others as well. Essentially, MPLS-TP is = MPLS, so, we shouldn't be defining it as MPLS-TP. So, all the changes or = extensions we are proposing are not just for MPLS-TP but MPLS in = general. In the future, we should be able to use these extensions not = only for TP tunnels, but other types, which we already foresee = happening. This was the primary reason for not forking out MPLS-TP = specific MIB's, rather re-use and hang off of existing MPLS MIB's. Does that answer your concern? >=20 >=20 >=20 > *) The word "traps" appears as a MIB comment in the MIB Modules. = Please either remove > the comment or use the notifications where appropriate. Traps are a = SNMPv1 > mechanism. %sam - nod >=20 >=20 > *) MIB Guidelines suggest naming conventions to be used > within a MIB Module (for tables, rows and objects within a row), > This was not followed in these MIB Modules. As an example: >=20 > MPLS-TE-EXT-STD-MIB has the following table names: >=20 > mplsNodeConfigTable > mplsNodeIpMapTable > mplsNodeIccMapTable > mplsTunnelExtTable >=20 > This is also the case in the other MIB Module(s). Please take a look > at Appendix C of the MIB Guidelines (rfc4181). %sam - nod. >=20 >=20 >=20 > Section 4. Motivations > ---------------------- > Awkward. Section doesn't specify motivations, expect something > like, This document provides a MIB Module which supports > configuration of .... and monitoring of ....etc. %sam - nod. >=20 >=20 > Section 7. MIB Module Interdependencies >=20 >=20 > How is this possible, since MPLS-TE-STD-MIB was defined so long ago? >=20 > .. - MPLS-TE-STD-MIB [RFC3812] contains references to objects = in > MPLS-ID-STD-MIB. %sam - it is a mistake. will fix it. >=20 >=20 >=20 >=20 > MPLS-TC-EXT-STD-MIB > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >=20 > *) The name of this MIB Module is misleading. > The TCs defined are specific to MPLS-TP so could this name > be more specific, for example, MPLS-TP-TC-STD-MIB ? %sam - same reasoning given above. We want to keep MIB generic and not = TP specific. This was the guidance we got, to remove 'TP', as we had = 'TP' in every object as well.=20 >=20 > *) These TCs should have references. They are > originally defined elsewhere, so why aren't their references? >=20 %sam - will add. >=20 >=20 >=20 > *) MplsNodeId >=20 > DESCRIPTION > ...LSR's /32 IPv4 loopback address >=20 > What is meant by /32 ? %sam - :-). will fix it. >=20 >=20 >=20 >=20 >=20 > MPLS-ID-STD-MIB > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >=20 > SMILINT > ------- >=20 > mibs/MPLS-ID-STD-MIB:70: [5] {identifier-external-case-match} warning: = identifier `mplsGlobalId' differs from = `MPLS-TC-EXT-STD-MIB::MplsGlobalId' only in case > mibs/MPLS-TC-EXT-STD-MIB:61: [6] {previous-definition} info: previous = definition of `MplsGlobalId' > mibs/MPLS-ID-STD-MIB:94: [5] {identifier-external-case-match} warning: = identifier `mplsNodeId' differs from `MPLS-TC-EXT-STD-MIB::MplsNodeId' = only in case > mibs/MPLS-TC-EXT-STD-MIB:88: [6] {previous-definition} info: previous = definition of `MplsNodeId' >=20 > mibs/MPLS-ID-STD-MIB:4: [5] {import-unused} warning: identifier = `NOTIFICATION-TYPE' imported from module `SNMPv2-SMI' is never used > mibs/MPLS-ID-STD-MIB:6: [5] {import-unused} warning: identifier = `NOTIFICATION-GROUP' imported from module `SNMPv2-CONF' is never used >=20 %sam - nod. >=20 >=20 >=20 > MPLS-LSR-EXT-MIB > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > *) The name of this MIB Module is too broad because MIB Module > is specific to MPLS-TP, so something like MPLS-TP-LSR-EXT-MIB > would be more appropriate IMHO. %sam - same reasons given above. >=20 > *) Is mplsXCExtTunnelPointer supposed to be read-only? > The DESCRIPTION seems to indicate read-create? > (leads to following question regarding compliance stmts....) >=20 %sam - will fix it. Initially we had it as read create. >=20 > *) The FullCompliance and ReadOnlyCompliance > are confusing. Why does the mplsXCExtTunnelPointer object > appear in both? >=20 %sam - will fix it. >=20 >=20 >=20 >=20 > MPLS-TE-EXT-MIB > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > SMILINT > mibs/MPLS-TE-EXT-STD-MIB:22: [4] {module-identity-registration} = warning: uncontrolled IETF module identity registration > mibs/MPLS-TE-EXT-STD-MIB:4: [5] {import-unused} warning: identifier = `Unsigned32' imported from module `SNMPv2-SMI' is never used > mibs/MPLS-TE-EXT-STD-MIB:5: [5] {import-unused} warning: identifier = `Gauge32' imported from module `SNMPv2-SMI' is never used > mibs/MPLS-TE-EXT-STD-MIB:5: [5] {import-unused} warning: identifier = `NOTIFICATION-TYPE' imported from module `SNMPv2-SMI' is never used > mibs/MPLS-TE-EXT-STD-MIB:9: [5] {import-unused} warning: identifier = `NOTIFICATION-GROUP' imported from module `SNMPv2-CONF' is never used >=20 >=20 > *) Warnings of severity [5] should be fixed. %sam - nod >=20 >=20 > *) The name of this MIB Module is too broad also. MIB is specific > to MPLS-TP and the name of the MIB Module should reflect that. > One example is, MPLS-TP-TE-EXT-MIB. %sam - same reasons given above. >=20 >=20 >=20 >=20 From robert.g.cole.civ@mail.mil Wed Jun 13 11:35:23 2012 Return-Path: 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 ; 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 ; 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 ; 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)" To: "'MIB Doctors (E-mail)'" , Thomas Nadeau 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: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 18:35:23 -0000 ------=_NextPart_000_0F4A_01CD4971.B7AB95A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 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 ------=_NextPart_000_0F4A_01CD4971.B7AB95A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIS3DCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEwTCCA6mgAwIBAgIDDNszMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQwHhcNMTAwMjI1MDAwMDAwWhcN MTMwMjI0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1DT0xFLlJP QkVSVC5HUkFOT1QuMTM2NjU2MDM5MDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKU7 jo5hPKcK6V92Cni9Bu445V7UQJBLIu1eX3brV/yB6uFNd+lIdV5n6RBpE1QcsIUEyS1GVDvTR/Qs kbUInPJC8ioZCX/V5Y2J8nRNidXoLX4SdeQ3Gc6jLPn+1W8KHRdATHy+SYGcrHnePyRAhTO73rN3 97CqgOaxnS4wo/Eanw9Re5UGq70cN/G7376Oxa7A2xdtY9w8gLUilFmcYXuwR7FGxcnDhsqAW3fv tgM18ZWn/hioEhmRZz514jXPnHCvSPAkofjb4Mjucnku8uNowu+PMw5Yqv9wimBEitvQGPnyac41 MNtsflnmVqWswTwhzVzIGdodKZTw2h6byTcCAwEAAaOCAWwwggFoMB8GA1UdIwQYMBaAFFSqcyrH s3fqzSJAeUh7EfunmSKCMD8GA1UdHwQ4MDYwNKAyoDCGLmh0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0 Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMjQwDgYDVR0PAQH/BAQDAgUgMCMGA1UdIAQcMBowCwYJYIZI AWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUyGOLOF3I71SMIzwNIujoox8W0CowbQYIKwYB BQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3JsLmRpc2EubWlsL2dldHNpZ24/RE9EJTIw RU1BSUwlMjBDQS0yNDAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwJAYDVR0RBB0w G4EZcm9iZXJ0LmcuY29sZUB1cy5hcm15Lm1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVT MA0GCSqGSIb3DQEBBQUAA4IBAQAVD+rqDKxhGbV78baC+EUC3jiDUO6C41wsmB4ckt5akJPvVrB4 mjlnoG0lm19qovC98eO0vPQMUx1F6/jP9/xg32W2Ks2HZUR3ipZWBEqVi8i20Wz4sVFgXHkJjoP5 bju0XvJk/d6wze65iZqFuILuPplugaHg7iC5B/NAMELTGx8hoK3LVqmIIyMpEFlrxTygIkyuI+NK IqcbLtBOEW0bP7TNyBh/VShmtrXAtpPP0AAi+kaUURcG1x2xdPCR3cD2bjWYkfxQYeZRl2zTuOMg Mpr9pG3MuImao/C+v6IaXGuAU8xS8hSEbHGNLrXjJ9UIxw0K45WxjR7CrPFIJ4R5MIIFDDCCA/Sg AwIBAgIDDNswMA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjQwHhcNMTAwMjI1MDAwMDAwWhcNMTMwMjI0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UE CxMDVVNBMSYwJAYDVQQDEx1DT0xFLlJPQkVSVC5HUkFOT1QuMTM2NjU2MDM5MDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOsVn1k8Ax7kkzWXvrNf7oI7iy5zEeLACdGKrODL9riDBNUF HvD4JtafUcwq03s4Daq0tscNL8J1ONDeML5s0X8UeNfCyexrkSpPwY9g/zVO6mJmG4OunTz/7fc2 G0ZR64VYlEBZeQ88JIMIs6bYXiO9SxuOCS47aGx/CGqdpFwt713bBAQvzAjLUSWBvjZN2bviTQrY wAg1/1AnlxY6Zl4YPBSV9c1TbtTQNjbRyFRabiqNMh0XaQ0ZHxQgsGOqNwfyMlmadL2m3ILhKpFh oMfOV01at2eDj8+wFvDXLXAL1f3HAQKv5W5GEoBYNDqp/ULDBJcXVPT8mYWzxMkca/MCAwEAAaOC AbcwggGzMB8GA1UdIwQYMBaAFFSqcyrHs3fqzSJAeUh7EfunmSKCMD8GA1UdHwQ4MDYwNKAyoDCG Lmh0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMjQwDgYDVR0PAQH/ BAQDAgbAMCMGA1UdIAQcMBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUBeVx RkqbKuf17SKV2ZZOsCXLQ+gwbQYIKwYBBQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3Js LmRpc2EubWlsL2dldHNpZ24/RE9EJTIwRU1BSUwlMjBDQS0yNDAgBggrBgEFBQcwAYYUaHR0cDov L29jc3AuZGlzYS5taWwwRAYDVR0RBD0wO4EZcm9iZXJ0LmcuY29sZUB1cy5hcm15Lm1pbKAeBgor BgEEAYI3FAIDoBAMDjEzNjY1NjAzOTBAbWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMw KQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUA A4IBAQBhwXMphuaV+lhIZbI35yGpZ7zy/uXNyr41+/dibahnAIisIIHFSTeEk9GFepxqV45hagTo //0UycQ/ShOIHzV/+u3l/97k+l8imMdbjhgklb2UFROSz7TJzhO3w4S7g7DpU+GTxE2Uax+iD2t0 Bmio3ut9fr/dWvi6OTYVFMTW7M6pd8gOPqmg8ADGdljGsSotMAhXzFJgAPtnsca5HfyYpGi0NQj0 ucT/sWUGwnnjlqtYyP+SY2pOPpbN9gACkv8UKJMkik5GEFobaHbI8KWr4FFOXAIAauW1DvGFq5Pe WdDgj39r6PkdOLg3v+B9/hnkP6uOyH5Oi9pcHb+d/hPuMIIFjzCCBHegAwIBAgIBRTANBgkqhkiG 9w0BAQUFADBbMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQL EwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNRG9EIFJvb3QgQ0EgMjAeFw0wOTAxMjYyMDI2 MTVaFw0xNTAxMjUyMDI2MTVaMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1l bnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQClLlh6od7mmlv2AvHV1Nw1I5p7bihkdBpw PJYdzMKfdAQ8DDmSIQgNEk6g1zeo0snGJ50o+lXXshcEGc4yvPB5nvVoqy7MzzcEsvgKZZpJIBQl wbwSaqBCbRsItIehQiKrE5naAgE5H14IV2tg3hN+aGp+QfWJgDh6/Zey0uKWSzaAYrbsJbvQD6ej zVGo99J5VZA0JqPkXM27aCZ0CTeh5q/N5D6ZR/9/wke8ZYS6MimjDvDColt66rJKfQvGw26svRB/ T6l2Oj0CASwqMLT3yKDSmDp8CNBaiQ+1ioL6DTAeftbRx7ZDJ7EoqQzjswd432JkmkWMTs2vDq6c WDbfAgMBAAGjggJaMIICVjAOBgNVHQ8BAf8EBAMCAYYwHwYDVR0jBBgwFoAUSXS7DF66ev4CVO97 oMaVxgmAcJYwHQYDVR0OBBYEFFSqcyrHs3fqzSJAeUh7EfunmSKCMAwGA1UdJAQFMAOAAQAwEgYD VR0TAQH/BAgwBgEB/wIBADCBnwYDVR0gBIGXMIGUMAsGCWCGSAFlAgELBTALBglghkgBZQIBCwkw CwYJYIZIAWUCAQsKMAsGCWCGSAFlAgELEjALBglghkgBZQIBCxMwCwYJYIZIAWUCAQsUMAwGCmCG SAFlAwIBAwYwDAYKYIZIAWUDAgEDBzAMBgpghkgBZQMCAQMIMAwGCmCGSAFlAwIBAw0wDAYKYIZI AWUDAgEDETA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLmRpc2EubWlsL2dldGNybD9Eb0Ql MjBSb290JTIwQ0ElMjAyMIH+BggrBgEFBQcBAQSB8TCB7jA/BggrBgEFBQcwAoYzaHR0cDovL2Ny bC5kaXNhLm1pbC9nZXRJc3N1ZWRUbz9Eb0QlMjBSb290JTIwQ0ElMjAyMCAGCCsGAQUFBzABhhRo dHRwOi8vb2NzcC5kaXNhLm1pbDCBiAYIKwYBBQUHMAKGfGxkYXA6Ly9jcmwuZ2RzLmRpc2EubWls L2NuJTNkRG9EJTIwUm9vdCUyMENBJTIwMiUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNkVS5T LiUyMEdvdmVybm1lbnQlMmNjJTNkVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwDQYJKoZIhvcNAQEF BQADggEBAHIW3DlzY02T6Tccz7LtnNhN9wwySomes8q68wSscWYxpiq9un1U2C8JY0qICOhsE6Hs XntWFzAtyNLt141HRGnPEW/L2OdSdbVRyKodafAZHzDwB8c2vc4M3jt2/QrOy7YTutaFi/FcEpHK r+h/EqisLYvWdlCU7Db6ow/fxjLqx3NG/IQami/E6CccSMJGNvYX7O1nMg+4ouC30l6QBhOUIWFD bH3zO2tl7ePbqP/Fm7KS5+tf7u+/8zmMs/UX0obVw2xKOmw/nq/oWx02W6YmFUYLRmvH1ICq564c uCtO+iFyn1+fga+07lvJlymJfOnceOJO4HSf0oZ4ZqLHmKgxggL+MIIC+gIBATBkMF0xCzAJBgNV BAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMD UEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQCAwzbMDAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA2MTMxODM1MDJaMCMGCSqGSIb3 DQEJBDEWBBQflB3JMEmqpJdRbXUTmvNPLL9GODAkBgkqhkiG9w0BCQ8xFzAVMAoGCCqGSIb3DQMH MAcGBSsOAwIaMHMGCSsGAQQBgjcQBDFmMGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJ TCBDQS0yNAIDDNszMHUGCyqGSIb3DQEJEAILMWagZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMP VS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9E IEVNQUlMIENBLTI0AgMM2zMwDQYJKoZIhvcNAQEBBQAEggEASOgrIEXIH1rrSrJ5TNQoVTwfSAyx 4FBwZvs991EFp5K+yl/XkWx4bKWvBtO0BoL7GcJTAkLb6lxPPtOLukJIGC1CWvXbQNh8BBTvEGN2 01ebEURKfZkQzRi8cJADHRYTperPzrF9w1MNWWROu/tl8OItHNJrffWudSeru6dSI7Lznz97Ff0t R+oqu6ItKhmq+fv5v3kTsRGnq9spExXZ1zyl7Wpfshq8VEX+lapYDQJVEEm/Y47MXwCwAuY1f9bW 63e3KSdVk/tNC0WAg2w0F7HsgJgIHXLBvYgwdXnPXnWBtciF7Rn44UwJ2wBzkVYolu46q/ggVVBB bI4JLQFESQAAAAAAAA== ------=_NextPart_000_0F4A_01CD4971.B7AB95A0-- From tnadeau@juniper.net Wed Jun 13 12:01:50 2012 Return-Path: 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 ADC3411E80CB for ; Wed, 13 Jun 2012 12:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.233 X-Spam-Level: X-Spam-Status: No, score=-3.233 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, RCVD_IN_DNSWL_MED=-4] 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 6yNbAd8ndk2M for ; Wed, 13 Jun 2012 12:01:49 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8AF11E80AD for ; Wed, 13 Jun 2012 12:01:48 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKT9jjmiTj1H3LHKqkRCstqME31haxbUUw@postini.com; Wed, 13 Jun 2012 12:01:48 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 13 Jun 2012 11:58:59 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 13 Jun 2012 14:58:59 -0400 From: Thomas Nadeau To: "Cole, Robert G CIV USARMY CERDEC (US)" , "'MIB Doctors (E-mail)'" Date: Wed, 13 Jun 2012 14:58:55 -0400 Thread-Topic: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED) Thread-Index: Ac1JlpapozEJuzCLSpmCso0uetduFA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ulrich Herberg Subject: Re: [MIB-DOCTORS] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 19:01:50 -0000 On 6/13/12 2:35 PM, "Cole, Robert G CIV USARMY CERDEC (US)" wrote: >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 } > ::=3D { nhdpInterfaceTable 1 } > > NhdpInterfaceEntry ::=3D > 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 } > ::=3D { ipv4InterfaceTable 1 }nhdpIfRowStatus > >Ipv4InterfaceEntry ::=3D 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." > ::=3D { ipv4InterfaceEntry 1 } >" > >What is your recommendation? I appreciate the reference but my points from earlier still apply. = In the reference, I believe operationally you avoid entries that do not have the correct ifType for the Ipv4InterfaceEntry. Remember that if that were not the case, then what you get is a direct one-to-one mapping of IPv4 interfaces attributes for EVERY IfTable entry. This is a bad idea given that there are a wide array of devices that have a small set of their interfaces possessing IPv4 characteristics. In your MIB you are effectively doing this. If you really wanted t= hat you should use AUGMENTS, but that doesn't seem like what you want. The simple way to correct this situation is to define an ifType for NHDP interfaces and explicitly exclude non-NHDP interfaces from being returned. This effectively "extends" - or more appropriately - "selectively extends" the IfTable entries. --Tom > >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 revie= w. 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 ro= ws 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]). Desig= ners > SHOULD consider using SnmpAdminString, Utf8String, or > LongUtf8String for such objects. > > > > 5. You need a DEFVAL for *every* read-create object. I have noted t= he >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=3Dmols > 2, ifType=3Dmpls > 3, ifType=3Dmanet ---------> 3 > 4, ifType =3D manet ---------> 4 > 5, ifType =3D mpls > > That is, you do not have entries in the NhdpInterfaceEntry table fo= r >ifIndex-es 1, 2 and 5. > > > 7. I think it is customary to include the full reference descriptio= n 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. Th= is 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 e= asiest >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 sp= ecify > what happens to dynamically-created rows after an agent rest= art. > > > > > > 10. In the notifications section, there is ambiguous terminology li= ke >"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 ho= w 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=3Dmanet as I suggested above? > > 13. The nhdpPacketSrcAddr notification has no limits or throttlin= g. >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 i= t can >be >resolved in discussion with you. > >Ok. > > > > > > - While reading through the document, I've been really wait= ing for an > applicability statement section. > > > So, I think you are asking "Why would any application that is not u= sing >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 mana= gement >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 exchan= ge packets > with router B, and router B is able to exchange packets wit= h router C, > this does not guarantee that router A and router C can exch= ange packets > directly" got me thinking about the management and operatio= nal aspects. > How do you plan on using this MIB module, taking into accou= nt 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 necessaril= y >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 coul= d 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 imple= menters 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 sta= tement (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 h= is (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 w= ith >any >other module? Who consumes Notifications from other modules? > >In the case of (*) > > > > > > * Do you expect all MANET routers to always have connectivi= ty to a >static > NMS? > > > Why ever not? It is a routed IP network. If there is a management s= tation >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 > >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 Manag= ed Objects for the > Optimized Link State Routing Protocol > * draft-ietf-manet-report-mib-02 Definition of Manag= ed Objects for > Performance Reporting > * draft-ietf-manet-smf-mib-04 Definition of Managed Objec= ts for the > Manet Simplified Multicast Framework Relay Set > However, this document is the first MANET MIB module to rea= ch the IESG, > so those operational questions are important. > > > Agreed. The authors of those other documents are waiting on the rev= iew 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 i= nformation 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 par= t 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 Inform= ation Base > (MIB) for use with network management protocols in the I= nternet > community. In particular, it describes objects for conf= iguring > 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 > > From robert.g.cole.civ@mail.mil Wed Jun 13 13:02:47 2012 Return-Path: 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 4812421F859A for ; Wed, 13 Jun 2012 13:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.316 X-Spam-Level: X-Spam-Status: No, score=-0.316 tagged_above=-999 required=5 tests=[AWL=1.083, BAYES_00=-2.599, 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 SeUkD8ReXner for ; Wed, 13 Jun 2012 13:02:42 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.11]) by ietfa.amsl.com (Postfix) with ESMTP id 788C521F8596 for ; Wed, 13 Jun 2012 13:02:38 -0700 (PDT) Received: from UCOLHP3M.easf.csd.disa.mil (131.64.100.152) by ucolhp3l.easf.csd.disa.mil (131.64.100.11) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 13 Jun 2012 20:02:12 +0000 Received: from UCOLHP4J.easf.csd.disa.mil ([169.254.8.107]) by UCOLHP3M.easf.csd.disa.mil ([131.64.100.152]) with mapi id 14.02.0283.003; Wed, 13 Jun 2012 20:02:12 +0000 From: "Cole, Robert G CIV USARMY CERDEC (US)" To: Thomas Nadeau , "'MIB Doctors (E-mail)'" Thread-Topic: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED) Thread-Index: Ac1EcXKJSTnPFQ2MTQ6r8Xl0rB1SRAATYRUAATFut1AAA48u0AAA6YeAAAHfJCA= Date: Wed, 13 Jun 2012 20:02:12 +0000 Message-ID: References: In-Reply-To: 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_0FFF_01CD497D.E1CAB3F0" MIME-Version: 1.0 Cc: "adrian@olddog.co.uk" , Ulrich Herberg Subject: Re: [MIB-DOCTORS] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 20:02:47 -0000 ------=_NextPart_000_0FFF_01CD497D.E1CAB3F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Classification: UNCLASSIFIED Caveats: NONE Tom, -you wrote- I appreciate the reference but my points from earlier still apply. In the reference, I believe operationally you avoid entries that do not have the correct ifType for the Ipv4InterfaceEntry. Remember that if that were not the case, then what you get is a direct one-to-one mapping of IPv4 interfaces attributes for EVERY IfTable entry. This is a bad idea given that there are a wide array of devices that have a small set of their interfaces possessing IPv4 characteristics. RGC> I do not see in reading through the reference RFC 4293, how this behavior is identified. I agree with you that this is desirable. I just do not see the mechanism that informs the implementer to scope the ifType. In your MIB you are effectively doing this. If you really wanted that you should use AUGMENTS, but that doesn't seem like what you want. The simple way to correct this situation is to define an ifType for NHDP interfaces and explicitly exclude non-NHDP interfaces from being returned. This effectively "extends" - or more appropriately - "selectively extends" the IfTable entries. RGC> You are right; it is this later case and behavior we want to achieve. Where do I define an ifType for NHDP interfaces? Also more generally, should I be defining an ifType for MANET interfaces? Thanks, Bob --Tom > >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 > >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 > > Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_0FFF_01CD497D.E1CAB3F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIS3DCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEwTCCA6mgAwIBAgIDDNszMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQwHhcNMTAwMjI1MDAwMDAwWhcN MTMwMjI0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1DT0xFLlJP QkVSVC5HUkFOT1QuMTM2NjU2MDM5MDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKU7 jo5hPKcK6V92Cni9Bu445V7UQJBLIu1eX3brV/yB6uFNd+lIdV5n6RBpE1QcsIUEyS1GVDvTR/Qs kbUInPJC8ioZCX/V5Y2J8nRNidXoLX4SdeQ3Gc6jLPn+1W8KHRdATHy+SYGcrHnePyRAhTO73rN3 97CqgOaxnS4wo/Eanw9Re5UGq70cN/G7376Oxa7A2xdtY9w8gLUilFmcYXuwR7FGxcnDhsqAW3fv tgM18ZWn/hioEhmRZz514jXPnHCvSPAkofjb4Mjucnku8uNowu+PMw5Yqv9wimBEitvQGPnyac41 MNtsflnmVqWswTwhzVzIGdodKZTw2h6byTcCAwEAAaOCAWwwggFoMB8GA1UdIwQYMBaAFFSqcyrH s3fqzSJAeUh7EfunmSKCMD8GA1UdHwQ4MDYwNKAyoDCGLmh0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0 Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMjQwDgYDVR0PAQH/BAQDAgUgMCMGA1UdIAQcMBowCwYJYIZI AWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUyGOLOF3I71SMIzwNIujoox8W0CowbQYIKwYB BQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3JsLmRpc2EubWlsL2dldHNpZ24/RE9EJTIw RU1BSUwlMjBDQS0yNDAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwJAYDVR0RBB0w G4EZcm9iZXJ0LmcuY29sZUB1cy5hcm15Lm1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVT MA0GCSqGSIb3DQEBBQUAA4IBAQAVD+rqDKxhGbV78baC+EUC3jiDUO6C41wsmB4ckt5akJPvVrB4 mjlnoG0lm19qovC98eO0vPQMUx1F6/jP9/xg32W2Ks2HZUR3ipZWBEqVi8i20Wz4sVFgXHkJjoP5 bju0XvJk/d6wze65iZqFuILuPplugaHg7iC5B/NAMELTGx8hoK3LVqmIIyMpEFlrxTygIkyuI+NK IqcbLtBOEW0bP7TNyBh/VShmtrXAtpPP0AAi+kaUURcG1x2xdPCR3cD2bjWYkfxQYeZRl2zTuOMg Mpr9pG3MuImao/C+v6IaXGuAU8xS8hSEbHGNLrXjJ9UIxw0K45WxjR7CrPFIJ4R5MIIFDDCCA/Sg AwIBAgIDDNswMA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjQwHhcNMTAwMjI1MDAwMDAwWhcNMTMwMjI0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UE CxMDVVNBMSYwJAYDVQQDEx1DT0xFLlJPQkVSVC5HUkFOT1QuMTM2NjU2MDM5MDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOsVn1k8Ax7kkzWXvrNf7oI7iy5zEeLACdGKrODL9riDBNUF HvD4JtafUcwq03s4Daq0tscNL8J1ONDeML5s0X8UeNfCyexrkSpPwY9g/zVO6mJmG4OunTz/7fc2 G0ZR64VYlEBZeQ88JIMIs6bYXiO9SxuOCS47aGx/CGqdpFwt713bBAQvzAjLUSWBvjZN2bviTQrY wAg1/1AnlxY6Zl4YPBSV9c1TbtTQNjbRyFRabiqNMh0XaQ0ZHxQgsGOqNwfyMlmadL2m3ILhKpFh oMfOV01at2eDj8+wFvDXLXAL1f3HAQKv5W5GEoBYNDqp/ULDBJcXVPT8mYWzxMkca/MCAwEAAaOC AbcwggGzMB8GA1UdIwQYMBaAFFSqcyrHs3fqzSJAeUh7EfunmSKCMD8GA1UdHwQ4MDYwNKAyoDCG Lmh0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMjQwDgYDVR0PAQH/ BAQDAgbAMCMGA1UdIAQcMBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUBeVx RkqbKuf17SKV2ZZOsCXLQ+gwbQYIKwYBBQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3Js LmRpc2EubWlsL2dldHNpZ24/RE9EJTIwRU1BSUwlMjBDQS0yNDAgBggrBgEFBQcwAYYUaHR0cDov L29jc3AuZGlzYS5taWwwRAYDVR0RBD0wO4EZcm9iZXJ0LmcuY29sZUB1cy5hcm15Lm1pbKAeBgor BgEEAYI3FAIDoBAMDjEzNjY1NjAzOTBAbWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMw KQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUA A4IBAQBhwXMphuaV+lhIZbI35yGpZ7zy/uXNyr41+/dibahnAIisIIHFSTeEk9GFepxqV45hagTo //0UycQ/ShOIHzV/+u3l/97k+l8imMdbjhgklb2UFROSz7TJzhO3w4S7g7DpU+GTxE2Uax+iD2t0 Bmio3ut9fr/dWvi6OTYVFMTW7M6pd8gOPqmg8ADGdljGsSotMAhXzFJgAPtnsca5HfyYpGi0NQj0 ucT/sWUGwnnjlqtYyP+SY2pOPpbN9gACkv8UKJMkik5GEFobaHbI8KWr4FFOXAIAauW1DvGFq5Pe WdDgj39r6PkdOLg3v+B9/hnkP6uOyH5Oi9pcHb+d/hPuMIIFjzCCBHegAwIBAgIBRTANBgkqhkiG 9w0BAQUFADBbMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQL EwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNRG9EIFJvb3QgQ0EgMjAeFw0wOTAxMjYyMDI2 MTVaFw0xNTAxMjUyMDI2MTVaMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1l bnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQClLlh6od7mmlv2AvHV1Nw1I5p7bihkdBpw PJYdzMKfdAQ8DDmSIQgNEk6g1zeo0snGJ50o+lXXshcEGc4yvPB5nvVoqy7MzzcEsvgKZZpJIBQl wbwSaqBCbRsItIehQiKrE5naAgE5H14IV2tg3hN+aGp+QfWJgDh6/Zey0uKWSzaAYrbsJbvQD6ej zVGo99J5VZA0JqPkXM27aCZ0CTeh5q/N5D6ZR/9/wke8ZYS6MimjDvDColt66rJKfQvGw26svRB/ T6l2Oj0CASwqMLT3yKDSmDp8CNBaiQ+1ioL6DTAeftbRx7ZDJ7EoqQzjswd432JkmkWMTs2vDq6c WDbfAgMBAAGjggJaMIICVjAOBgNVHQ8BAf8EBAMCAYYwHwYDVR0jBBgwFoAUSXS7DF66ev4CVO97 oMaVxgmAcJYwHQYDVR0OBBYEFFSqcyrHs3fqzSJAeUh7EfunmSKCMAwGA1UdJAQFMAOAAQAwEgYD VR0TAQH/BAgwBgEB/wIBADCBnwYDVR0gBIGXMIGUMAsGCWCGSAFlAgELBTALBglghkgBZQIBCwkw CwYJYIZIAWUCAQsKMAsGCWCGSAFlAgELEjALBglghkgBZQIBCxMwCwYJYIZIAWUCAQsUMAwGCmCG SAFlAwIBAwYwDAYKYIZIAWUDAgEDBzAMBgpghkgBZQMCAQMIMAwGCmCGSAFlAwIBAw0wDAYKYIZI AWUDAgEDETA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLmRpc2EubWlsL2dldGNybD9Eb0Ql MjBSb290JTIwQ0ElMjAyMIH+BggrBgEFBQcBAQSB8TCB7jA/BggrBgEFBQcwAoYzaHR0cDovL2Ny bC5kaXNhLm1pbC9nZXRJc3N1ZWRUbz9Eb0QlMjBSb290JTIwQ0ElMjAyMCAGCCsGAQUFBzABhhRo dHRwOi8vb2NzcC5kaXNhLm1pbDCBiAYIKwYBBQUHMAKGfGxkYXA6Ly9jcmwuZ2RzLmRpc2EubWls L2NuJTNkRG9EJTIwUm9vdCUyMENBJTIwMiUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNkVS5T LiUyMEdvdmVybm1lbnQlMmNjJTNkVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwDQYJKoZIhvcNAQEF BQADggEBAHIW3DlzY02T6Tccz7LtnNhN9wwySomes8q68wSscWYxpiq9un1U2C8JY0qICOhsE6Hs XntWFzAtyNLt141HRGnPEW/L2OdSdbVRyKodafAZHzDwB8c2vc4M3jt2/QrOy7YTutaFi/FcEpHK r+h/EqisLYvWdlCU7Db6ow/fxjLqx3NG/IQami/E6CccSMJGNvYX7O1nMg+4ouC30l6QBhOUIWFD bH3zO2tl7ePbqP/Fm7KS5+tf7u+/8zmMs/UX0obVw2xKOmw/nq/oWx02W6YmFUYLRmvH1ICq564c uCtO+iFyn1+fga+07lvJlymJfOnceOJO4HSf0oZ4ZqLHmKgxggL+MIIC+gIBATBkMF0xCzAJBgNV BAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMD UEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQCAwzbMDAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA2MTMyMDAyMDdaMCMGCSqGSIb3 DQEJBDEWBBTnrWFR1nm5qIMIL9ceXoFvvv1wXjAkBgkqhkiG9w0BCQ8xFzAVMAoGCCqGSIb3DQMH MAcGBSsOAwIaMHMGCSsGAQQBgjcQBDFmMGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJ TCBDQS0yNAIDDNszMHUGCyqGSIb3DQEJEAILMWagZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMP VS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9E IEVNQUlMIENBLTI0AgMM2zMwDQYJKoZIhvcNAQEBBQAEggEA2aEhqc0BCSQ/ptauPQukm9sj3A5I RA6wKSx7XShYuyKaOUyyeCDe4ZbhkCYyT2cXlOwHQ23qjHFic1oDip71+5Wyv7eI8dvVQWu6UZCX Fe8diHk+GQuPMUJLP7m5lYBSy70haOt8Ka/hd/bajrj5MQ+v3MgqfsRXsjm7OW5m737ZY7lKlgui r5B64oJXV1U3ira3nar+zWra1vdJ9jRJNsqCtgjNs5qCommQZvasRLA2fWTAT8y2K8UfE06Gnlo+ GU5MgDHuX70npk1Po/kbBigDS6W/O3s/V07ZRVfieNd5F5mYlDlMkbj5KaT5p7biCnoK60Y+crGj 7LavtuNHRQAAAAAAAA== ------=_NextPart_000_0FFF_01CD497D.E1CAB3F0-- From tnadeau@juniper.net Wed Jun 13 13:16:36 2012 Return-Path: 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 289CF21F845F for ; Wed, 13 Jun 2012 13:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.316 X-Spam-Level: X-Spam-Status: No, score=-4.316 tagged_above=-999 required=5 tests=[AWL=1.083, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] 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 Di4gWK0P2RkJ for ; Wed, 13 Jun 2012 13:16:32 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 76AAD21F8433 for ; Wed, 13 Jun 2012 13:16:32 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKT9j1GlZX8Dvis6BCbmPU0/woGS8uZH0Z@postini.com; Wed, 13 Jun 2012 13:16:32 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 13 Jun 2012 13:15:57 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 13 Jun 2012 16:15:56 -0400 From: Thomas Nadeau To: "Cole, Robert G CIV USARMY CERDEC (US)" , "'MIB Doctors (E-mail)'" Date: Wed, 13 Jun 2012 16:15:53 -0400 Thread-Topic: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED) Thread-Index: Ac1JoVctLmwyI6KjRGWyPJNQrEAwyA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "adrian@olddog.co.uk" , Ulrich Herberg Subject: Re: [MIB-DOCTORS] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 20:16:36 -0000 On 6/13/12 4:02 PM, "Cole, Robert G CIV USARMY CERDEC (US)" wrote: >Classification: UNCLASSIFIED >Caveats: NONE > >Tom, > > >-you wrote- > I appreciate the reference but my points from earlier still apply. >In the reference, I believe operationally you avoid entries that do not >have >the correct ifType for the Ipv4InterfaceEntry. Remember that if that were >not the case, then what you get is a direct one-to-one mapping of IPv4 >interfaces attributes for EVERY IfTable entry. This is a bad idea given >that there are a wide array of devices that have a small set of their >interfaces possessing IPv4 characteristics. > >RGC> I do not see in reading through the reference RFC 4293, how this >behavior is identified. I agree with you that this is desirable. I just >do >not see the mechanism that informs the implementer to scope the ifType. TOM: The reference doesn't explicitly say this, but that is how I believe its implemented. > > In your MIB you are effectively doing this. If you really wanted >that you should use AUGMENTS, but that doesn't seem like what you want. >The >simple way to correct this situation is to define an ifType for NHDP >interfaces and explicitly exclude non-NHDP interfaces from being returned. > This effectively "extends" - or more appropriately - "selectively >extends" >the IfTable entries. > >RGC> You are right; it is this later case and behavior we want to achieve. >Where do I define an ifType for NHDP interfaces? Also more generally, >should I be defining an ifType for MANET interfaces? You do this in an IANA section. Take a look at how we did this in RFC3811/12/13. It is pretty straight-forward. You can also see how to scope its use tightly to avoid scale issues. I think you would want an ifType for MANET - I was mistaken earlier when I said NHDP. --Tom > >Thanks, Bob > > > --Tom > > >> >>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=3Dmols >> 2, ifType=3Dmpls >> 3, ifType=3Dmanet ---------> 3 >> 4, ifType =3D manet ---------> 4 >> 5, ifType =3D 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=3Dmanet 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 >> >>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 >> >> > > >Classification: UNCLASSIFIED >Caveats: NONE > > From robert.g.cole.civ@mail.mil Wed Jun 13 14:20:30 2012 Return-Path: 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 3870711E809C for ; Wed, 13 Jun 2012 14:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=0.722, BAYES_00=-2.599, 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 brEFpahS+zw5 for ; Wed, 13 Jun 2012 14:20:28 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAA911E8097 for ; Wed, 13 Jun 2012 14:20:28 -0700 (PDT) Received: from UCOLHP3A.easf.csd.disa.mil (131.64.100.148) by UCOLHP4Z.easf.csd.disa.mil (131.64.100.6) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 13 Jun 2012 21:20:14 +0000 Received: from UCOLHP4J.easf.csd.disa.mil ([169.254.8.107]) by UCOLHP3A.easf.csd.disa.mil ([131.64.100.148]) with mapi id 14.02.0283.003; Wed, 13 Jun 2012 21:20:14 +0000 From: "Cole, Robert G CIV USARMY CERDEC (US)" To: "'tnadeau@juniper.net'" , "'mib-doctors@ietf.org'" Thread-Topic: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED) Thread-Index: Ac1EcXKJSTnPFQ2MTQ6r8Xl0rB1SRAATYRUAATFut1AAA48u0AAA6YeAAAHfJCAAAND/gAACPyQi Date: Wed, 13 Jun 2012 21:20:13 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.77.13] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'adrian@olddog.co.uk'" , "'ulrich@herberg.name'" Subject: Re: [MIB-DOCTORS] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 21:20:30 -0000 Tom, thx. Will do. Bob ----- Original Message ----- From: Thomas Nadeau [mailto:tnadeau@juniper.net] Sent: Wednesday, June 13, 2012 08:15 PM=0A= To: Cole, Robert G CIV USARMY CERDEC (US); 'MIB Doctors (E-mail)' Cc: Ulrich Herberg ; Benoit Claise = ; adrian@olddog.co.uk Subject: Re: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with= DISCUSS and COMMENT) (UNCLASSIFIED) On 6/13/12 4:02 PM, "Cole, Robert G CIV USARMY CERDEC (US)" wrote: >Classification: UNCLASSIFIED >Caveats: NONE > >Tom, > > >-you wrote- > I appreciate the reference but my points from earlier still apply. >In the reference, I believe operationally you avoid entries that do not >have >the correct ifType for the Ipv4InterfaceEntry. Remember that if that were >not the case, then what you get is a direct one-to-one mapping of IPv4 >interfaces attributes for EVERY IfTable entry. This is a bad idea given >that there are a wide array of devices that have a small set of their >interfaces possessing IPv4 characteristics. > >RGC> I do not see in reading through the reference RFC 4293, how this >behavior is identified. I agree with you that this is desirable. I just >do >not see the mechanism that informs the implementer to scope the ifType. TOM: The reference doesn't explicitly say this, but that is how I believe its implemented. > > In your MIB you are effectively doing this. If you really wanted >that you should use AUGMENTS, but that doesn't seem like what you want. >The >simple way to correct this situation is to define an ifType for NHDP >interfaces and explicitly exclude non-NHDP interfaces from being returned. > This effectively "extends" - or more appropriately - "selectively >extends" >the IfTable entries. > >RGC> You are right; it is this later case and behavior we want to achieve. >Where do I define an ifType for NHDP interfaces? Also more generally, >should I be defining an ifType for MANET interfaces? You do this in an IANA section. Take a look at how we did this in RFC3811/12/13. It is pretty straight-forward. You can also see how to scope its use tightly to avoid scale issues. I think you would want an ifType for MANET - I was mistaken earlier when I said NHDP. --Tom > >Thanks, Bob > > > --Tom > > >> >>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=3Dmols >> 2, ifType=3Dmpls >> 3, ifType=3Dmanet ---------> 3 >> 4, ifType =3D manet ---------> 4 >> 5, ifType =3D 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=3Dmanet 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 >> >>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 >> >> > > >Classification: UNCLASSIFIED >Caveats: NONE > > From tnadeau@juniper.net Thu Jun 14 04:41:53 2012 Return-Path: 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 9DFF421F85D4 for ; Thu, 14 Jun 2012 04:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.857 X-Spam-Level: X-Spam-Status: No, score=-4.857 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] 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 aRbg1Wjb3nrw for ; Thu, 14 Jun 2012 04:41:52 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 7300221F85C2 for ; Thu, 14 Jun 2012 04:41:50 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKT9nN/OsSYnUvTyWqIKGW8i7JkSDPiGBE@postini.com; Thu, 14 Jun 2012 04:41:51 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 14 Jun 2012 04:38:58 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 14 Jun 2012 07:38:57 -0400 From: Thomas Nadeau To: Ulrich Herberg , "Cole, Robert G CIV USARMY CERDEC (US)" Date: Thu, 14 Jun 2012 07:38:54 -0400 Thread-Topic: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED) Thread-Index: Ac1KIkhzdIJsm4zrSq+CYypuXCUacw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mib-doctors@ietf.org" , "adrian@olddog.co.uk" Subject: Re: [MIB-DOCTORS] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 11:41:53 -0000 Yes, that would be very helpful! 8) --Tom From: Ulrich Herberg > To: "Cole, Robert G CIV USARMY CERDEC (US)" > Cc: Thomas Nadeau >, "mib-d= octors@ietf.org" >, "bclaise@cisco.com" >, "adrian@olddog.co.uk" > Subject: Re: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with= DISCUSS and COMMENT) (UNCLASSIFIED) Hi, regarding the list of interfaces, in RFC6130 (NHDP), *all* interfaces are l= isted in the Local Interface Set, not just the MANET interfaces. The reason= is that these addresses are also advertised in HELLO messages (e.g., so th= at these addresses can be used by routing protocols). If we only list MANET= interfaces in the NHDP-MIB module, this would not reflect the state in NHD= P. Maybe we should add a comment in the description that only MANET interfa= ces are listed in the MIB module and others in the IfTable? Best Ulrich On Wed, Jun 13, 2012 at 2:20 PM, Cole, Robert G CIV USARMY CERDEC (US) > wrote: Tom, thx. Will do. Bob ----- Original Message ----- From: Thomas Nadeau [mailto:tnadeau@juniper.net= ] Sent: Wednesday, June 13, 2012 08:15 PM To: Cole, Robert G CIV USARMY CERDEC (US); 'MIB Doctors (E-mail)' > Cc: Ulrich Herberg >; Benoi= t Claise >; adrian@olddog.co.uk= > Subject: Re: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with= DISCUSS and COMMENT) (UNCLASSIFIED) On 6/13/12 4:02 PM, "Cole, Robert G CIV USARMY CERDEC (US)" > wrote: >Classification: UNCLASSIFIED >Caveats: NONE > >Tom, > > >-you wrote- > I appreciate the reference but my points from earlier still apply. >In the reference, I believe operationally you avoid entries that do not >have >the correct ifType for the Ipv4InterfaceEntry. Remember that if that were >not the case, then what you get is a direct one-to-one mapping of IPv4 >interfaces attributes for EVERY IfTable entry. This is a bad idea given >that there are a wide array of devices that have a small set of their >interfaces possessing IPv4 characteristics. > >RGC> I do not see in reading through the reference RFC 4293, how this >behavior is identified. I agree with you that this is desirable. I just >do >not see the mechanism that informs the implementer to scope the ifType. TOM: The reference doesn't explicitly say this, but that is how I believe its implemented. > > In your MIB you are effectively doing this. If you really wanted >that you should use AUGMENTS, but that doesn't seem like what you want. >The >simple way to correct this situation is to define an ifType for NHDP >interfaces and explicitly exclude non-NHDP interfaces from being returned. > This effectively "extends" - or more appropriately - "selectively >extends" >the IfTable entries. > >RGC> You are right; it is this later case and behavior we want to achieve. >Where do I define an ifType for NHDP interfaces? Also more generally, >should I be defining an ifType for MANET interfaces? You do this in an IANA section. Take a look at how we did this in RFC3811/12/13. It is pretty straight-forward. You can also see how to scope its use tightly to avoid scale issues. I think you would want an ifType for MANET - I was mistaken earlier when I said NHDP. --Tom > >Thanks, Bob > > > --Tom > > >> >>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=3Dmols >> 2, ifType=3Dmpls >> 3, ifType=3Dmanet ---------> 3 >> 4, ifType =3D manet ---------> 4 >> 5, ifType =3D 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=3Dmanet 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 >>> >>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 >> >> > > >Classification: UNCLASSIFIED >Caveats: NONE > > From bclaise@cisco.com Mon Jun 18 16:53:16 2012 Return-Path: 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 3C4DB11E809A; Mon, 18 Jun 2012 16:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.932 X-Spam-Level: X-Spam-Status: No, score=-7.932 tagged_above=-999 required=5 tests=[AWL=2.667, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 xJoXh7VjUhxj; Mon, 18 Jun 2012 16:53:15 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4BC11E8079; Mon, 18 Jun 2012 16:53:14 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q5INrDRM007641; Tue, 19 Jun 2012 01:53:13 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q5INrA48006188; Tue, 19 Jun 2012 01:53:11 +0200 (CEST) Message-ID: <4FDFBF66.8040401@cisco.com> Date: Tue, 19 Jun 2012 01:53:10 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: aaa-doctors@ietf.org, "MIB Doctors (E-mail)" , YANG Doctors , ops-dir@ietf.org, IETF DNS Directorate References: <20120618222152.3456.73705.idtracker@ietfa.amsl.com> In-Reply-To: <20120618222152.3456.73705.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120618222152.3456.73705.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [MIB-DOCTORS] Fwd: UPDATED Agenda and Package for the June 21, 2012 Teleconference X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 23:53:16 -0000 Dear all, Please find below the agenda of the June 21th IESG telechat. Please send your questions, comments and concerns before June 20th COB. Thanks and Regards, Ron and Benoit. -------- Original Message -------- 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-nfsv4-pnfs-block-disk-protection-02 pNFS block disk protection (Proposed Standard) Note: Spencer Shepler (sshepler@microsoft.com) is the document shepherd. Token: Martin Stiemerling o draft-ietf-appsawg-media-type-regs-13 Media Type Specifications and Registration Procedures (Best Current Practice) Token: Barry Leiba o draft-ietf-pim-ecmp-03 Protocol Independent Multicast ECMP Redirect (Proposed Standard) Note: Mike McBride (mmcbride7@gmail.com) is the document shepherd. Token: Adrian Farrel o draft-ietf-mif-dns-server-selection-09 Improved Recursive DNS Server Selection for Multi-Interfaced Nodes (Proposed Standard) Note: Hui Deng (denghui02@hotmail.com ) is the document shepherd. Token: Ralph Droms o draft-ietf-pwe3-cbit-negotiation-04 Pseudowire Control Word Negotiation Mechanism Update (Proposed Standard) Note: Andrew Malis (amalis@gmail.com) is the document shepherd. Token: Stewart Bryant o draft-ietf-trill-rbridge-channel-06 TRILL: RBridge Channel Support (Proposed Standard) Note: Erik Nordmark (nordmark@acm.org) is the document shepherd. Token: Ralph Droms o draft-ietf-6man-rfc3484bis-05 Default Address Selection for Internet Protocol version 6 (IPv6) (Proposed Standard) Note: Bob Hinden (bob.hinden@gmail.com) is the document shepherd. Token: Brian Haberman o draft-ietf-trill-clear-correct-03 TRILL: Clarifications, Corrections, and Updates (Proposed Standard) Note: Erik Nordmark (nordmark@acm.org) is the document shepherd. Token: Ralph Droms o draft-ietf-vcarddav-oma-cab-extensions-03 vCard Format extension : represent vCard extensions defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) group (Proposed Standard) Note: Simon Perreault (simon.perreault@viagenie.ca) is the document shepherd. Token: Pete Resnick 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items o draft-kucherawy-marf-source-ports-04 Source Ports in ARF Reports (Proposed Standard) Note: The document shepherd is John Levine . Token: Barry Leiba 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-grow-simple-va-09 Simple Virtual Aggregation (S-VA) (Informational) Note: Peter Schoenmaker is the document shepherd. Token: Ronald Bonica o draft-ietf-cdni-problem-statement-06 Content Distribution Network Interconnection (CDNI) Problem Statement (Informational) Note: Richard Woundy (richard_woundy@cable.comcast.com) is the Document Shepherd. Token: Martin Stiemerling o draft-ietf-pim-pop-count-06 Population Count Extensions to PIM (Experimental) Note: Mike McBride (mmcbride7@gmail.com) is the document shepherd. Token: Adrian Farrel o draft-ietf-spfbis-experiment-11 Resolution of The SPF and Sender ID Experiments (Informational) Token: Pete Resnick 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-polk-ipr-disclosure-04 Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules (Informational) Token: Russ Housley o draft-farrresnickel-ipr-sanctions-06 Sanctions Available for Application to Violators of IETF IPR Policy (Informational) Token: Russ Housley 3.2.2 Returning Items o draft-templin-aero-11 Asymmetric Extended Route Optimization (AERO) (Experimental) Token: Stewart Bryant 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items NONE 3.3.2 Returning Items o draft-despres-6a44-01 Native IPv6 Behind NAT44 CPEs (6a44) (Experimental) Note: ISE Submission Token: Ralph Droms 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o IMAP MOVE extension (imapmove) 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE From bclaise@cisco.com Tue Jun 26 23:52:33 2012 Return-Path: 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 3E9AC21F8593 for ; Tue, 26 Jun 2012 23:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.098 X-Spam-Level: X-Spam-Status: No, score=-8.098 tagged_above=-999 required=5 tests=[AWL=2.501, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 k+-M2d04H48L for ; Tue, 26 Jun 2012 23:52:32 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1929E21F8592 for ; Tue, 26 Jun 2012 23:52:31 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q5R6q2pt015502; Wed, 27 Jun 2012 08:52:03 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q5R6pxq6021715; Wed, 27 Jun 2012 08:52:00 +0200 (CEST) Message-ID: <4FEAAD8E.9070108@cisco.com> Date: Wed, 27 Jun 2012 08:51:59 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" References: <4FE898E0.30902@joelhalpern.com> In-Reply-To: <4FE898E0.30902@joelhalpern.com> X-Forwarded-Message-Id: <4FE898E0.30902@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Joel M. Halpern" , Terry Manderson Subject: [MIB-DOCTORS] I-D Action: draft-ietf-lisp-mib-04.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 06:52:33 -0000 MIB-doctors, Heads-up. We will be receiving a MIB-doctor request. The WG last-call should happen after Vancouver. Any taker? Thanks to the LISP chairs for being proactive. Regards, Benoit. -------- Original Message -------- Subject: I-D Action: draft-ietf-lisp-mib-04.txt Date: Mon, 25 Jun 2012 09:45:25 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: lisp@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP MIB Author(s) : Gregg Schudel Amit Jain Victor Moreno Filename : draft-ietf-lisp-mib-04.txt Pages : 55 Date : 2012-06-25 Abstract: This document defines managed objects for the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including basic configuration information, LISP status, and operational statistics. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-mib-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-lisp-mib-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From dromasca@avaya.com Wed Jun 27 03:18:58 2012 Return-Path: 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 4AA9E21F867C for ; Wed, 27 Jun 2012 03:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.517 X-Spam-Level: X-Spam-Status: No, score=-103.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 iGsIsYG7EoCe for ; Wed, 27 Jun 2012 03:18:57 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5425921F8671 for ; Wed, 27 Jun 2012 03:18:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQPAAnd6k+HCzI1/2dsb2JhbABFrleHTYEHghgBAQEBAwEBAQ8eCjQLDAQCAQgNAQMDAQEBCwYMCwEGASYfCQgBAQQBEggBGYdpC5wFnTWLNxqFEGADlkSEZoUOhH2CYYFd X-IronPort-AV: E=Sophos;i="4.77,483,1336363200"; d="scan'208";a="312808691" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Jun 2012 06:16:30 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 27 Jun 2012 06:00:20 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jun 2012 12:18:52 +0200 Message-ID: In-Reply-To: <4FEAAD8E.9070108@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] I-D Action: draft-ietf-lisp-mib-04.txt Thread-Index: Ac1UMW/n2nDa00zxROa7QHizx8OTGAAHIRfg References: <4FE898E0.30902@joelhalpern.com> <4FEAAD8E.9070108@cisco.com> From: "Romascanu, Dan (Dan)" To: "Benoit Claise" , "MIB Doctors (E-mail)" Cc: "Joel M. Halpern" , Terry Manderson Subject: Re: [MIB-DOCTORS] I-D Action: draft-ietf-lisp-mib-04.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 10:18:58 -0000 Hi, Why is an early MIB-doctor review required for this document? Is the MIB module putting any special challenges from a modeling or SMI complexity point of view?=20 Regards, Dan > -----Original Message----- > From: mib-doctors-bounces@ietf.org [mailto:mib-doctors-bounces@ietf.org] > On Behalf Of Benoit Claise > Sent: Wednesday, June 27, 2012 9:52 AM > To: MIB Doctors (E-mail) > Cc: Joel M. Halpern; Terry Manderson > Subject: [MIB-DOCTORS] I-D Action: draft-ietf-lisp-mib-04.txt >=20 > MIB-doctors, >=20 > Heads-up. We will be receiving a MIB-doctor request. > The WG last-call should happen after Vancouver. > Any taker? >=20 > Thanks to the LISP chairs for being proactive. >=20 > Regards, Benoit. >=20 >=20 > -------- Original Message -------- > Subject: I-D Action: draft-ietf-lisp-mib-04.txt > Date: Mon, 25 Jun 2012 09:45:25 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > CC: lisp@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Locator/ID Separation Protocol > Working Group of the IETF. >=20 > Title : LISP MIB > Author(s) : Gregg Schudel > Amit Jain > Victor Moreno > Filename : draft-ietf-lisp-mib-04.txt > Pages : 55 > Date : 2012-06-25 >=20 > Abstract: > This document defines managed objects for the Locator/ID Separation > Protocol (LISP). These objects provide information useful for > monitoring LISP devices, including basic configuration information, > LISP status, and operational statistics. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-mib >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-lisp-mib-04 >=20 > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-mib-04 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From bclaise@cisco.com Wed Jun 27 03:27:51 2012 Return-Path: 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 A0B2A21F85B6 for ; Wed, 27 Jun 2012 03:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.932 X-Spam-Level: X-Spam-Status: No, score=-8.932 tagged_above=-999 required=5 tests=[AWL=1.667, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 DeqsRFBRS3ar for ; Wed, 27 Jun 2012 03:27:51 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id BF6D321F84EA for ; Wed, 27 Jun 2012 03:27:50 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q5RARNe6010989; Wed, 27 Jun 2012 12:27:23 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q5RARMWv014190; Wed, 27 Jun 2012 12:27:22 +0200 (CEST) Message-ID: <4FEAE00A.2030200@cisco.com> Date: Wed, 27 Jun 2012 12:27:22 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4FE898E0.30902@joelhalpern.com> <4FEAAD8E.9070108@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "MIB Doctors \(E-mail\)" , "Joel M. Halpern" , Terry Manderson Subject: Re: [MIB-DOCTORS] I-D Action: draft-ietf-lisp-mib-04.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 10:27:51 -0000 Hi Dan, Not as far as I know, but I let Joel and Terry answered that one. My message is mainly: looking at the difficulties in finding a MIB doctor for the last MIB module review, combined with the coming holiday period, let's plan a little bit in advance if possible. So if someone has got some LISP knowledge, and some interest to review this one, just let the community know. Regards, Benoit. > Hi, > > Why is an early MIB-doctor review required for this document? Is the MIB > module putting any special challenges from a modeling or SMI complexity > point of view? > > Regards, > > Dan > > > > >> -----Original Message----- >> From: mib-doctors-bounces@ietf.org > [mailto:mib-doctors-bounces@ietf.org] >> On Behalf Of Benoit Claise >> Sent: Wednesday, June 27, 2012 9:52 AM >> To: MIB Doctors (E-mail) >> Cc: Joel M. Halpern; Terry Manderson >> Subject: [MIB-DOCTORS] I-D Action: draft-ietf-lisp-mib-04.txt >> >> MIB-doctors, >> >> Heads-up. We will be receiving a MIB-doctor request. >> The WG last-call should happen after Vancouver. >> Any taker? >> >> Thanks to the LISP chairs for being proactive. >> >> Regards, Benoit. >> >> >> -------- Original Message -------- >> Subject: I-D Action: draft-ietf-lisp-mib-04.txt >> Date: Mon, 25 Jun 2012 09:45:25 -0700 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> CC: lisp@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Locator/ID Separation Protocol >> Working Group of the IETF. >> >> Title : LISP MIB >> Author(s) : Gregg Schudel >> Amit Jain >> Victor Moreno >> Filename : draft-ietf-lisp-mib-04.txt >> Pages : 55 >> Date : 2012-06-25 >> >> Abstract: >> This document defines managed objects for the Locator/ID > Separation >> Protocol (LISP). These objects provide information useful for >> monitoring LISP devices, including basic configuration > information, >> LISP status, and operational statistics. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-lisp-mib >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-lisp-mib-04 >> >> A diff from previous version is available at: >> http://tools.ietf.org/rfcdiff?url2=draft-ietf-lisp-mib-04 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> >> >> >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors > From dromasca@avaya.com Wed Jun 27 04:10:25 2012 Return-Path: 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 012BF21F86B8 for ; Wed, 27 Jun 2012 04:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.52 X-Spam-Level: X-Spam-Status: No, score=-103.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 x7SwelHACEBG for ; Wed, 27 Jun 2012 04:10:21 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1D521F86B5 for ; Wed, 27 Jun 2012 04:10:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQPABDp6k/GmAcF/2dsb2JhbABFrleHToEHghgBAQEBAgEBAQEPHgoxAwYFDAQCAQgNAQMDAQEBCwYMCwEGASYfCQgBAQQTCAELDodkBQubdp08izcahRBgA5ZEhGaFDoR9gmGBXQ X-IronPort-AV: E=Sophos;i="4.77,483,1336363200"; d="scan'208";a="354842526" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 27 Jun 2012 07:07:21 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Jun 2012 07:07:51 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jun 2012 13:10:18 +0200 Message-ID: In-Reply-To: <4FEAE00A.2030200@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] I-D Action: draft-ietf-lisp-mib-04.txt Thread-Index: Ac1UT3Wh7parQp1sRSCLV3xTdeBp6QABSfQQ References: <4FE898E0.30902@joelhalpern.com> <4FEAAD8E.9070108@cisco.com> <4FEAE00A.2030200@cisco.com> From: "Romascanu, Dan (Dan)" To: "Benoit Claise" Cc: "MIB Doctors \(E-mail\)" , "Joel M. Halpern" , Terry Manderson Subject: Re: [MIB-DOCTORS] I-D Action: draft-ietf-lisp-mib-04.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 11:10:25 -0000 Hi Benoit,=20 Thanks for the clarification. Having a reviewer assigned and follow the work in early stages certainly helps, but usually MIB Doctors reviews are performed after the WG submits the I-D to the IESG, to make sure that the content is agreed to be stable and correct from the point of view of the experts in the respective technology. This should be clearly articulated IMO - so that nobody in the LISP WG waits for the MIB Doctor review without good reason. Regards, Dan > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Wednesday, June 27, 2012 1:27 PM > To: Romascanu, Dan (Dan) > Cc: MIB Doctors (E-mail); Joel M. Halpern; Terry Manderson > Subject: Re: [MIB-DOCTORS] I-D Action: draft-ietf-lisp-mib-04.txt >=20 > Hi Dan, >=20 > Not as far as I know, but I let Joel and Terry answered that one. >=20 > My message is mainly: looking at the difficulties in finding a MIB > doctor for the last MIB module review, combined with the coming holiday > period, let's plan a little bit in advance if possible. So if someone > has got some LISP knowledge, and some interest to review this one, just > let the community know. >=20 > Regards, Benoit. > > Hi, > > > > Why is an early MIB-doctor review required for this document? Is the > MIB > > module putting any special challenges from a modeling or SMI > complexity > > point of view? > > > > Regards, > > > > Dan > > > > > > > > > >> -----Original Message----- > >> From: mib-doctors-bounces@ietf.org > > [mailto:mib-doctors-bounces@ietf.org] > >> On Behalf Of Benoit Claise > >> Sent: Wednesday, June 27, 2012 9:52 AM > >> To: MIB Doctors (E-mail) > >> Cc: Joel M. Halpern; Terry Manderson > >> Subject: [MIB-DOCTORS] I-D Action: draft-ietf-lisp-mib-04.txt > >> > >> MIB-doctors, > >> > >> Heads-up. We will be receiving a MIB-doctor request. > >> The WG last-call should happen after Vancouver. > >> Any taker? > >> > >> Thanks to the LISP chairs for being proactive. > >> > >> Regards, Benoit. > >> > >> > >> -------- Original Message -------- > >> Subject: I-D Action: draft-ietf-lisp-mib-04.txt > >> Date: Mon, 25 Jun 2012 09:45:25 -0700 > >> From: internet-drafts@ietf.org > >> Reply-To: internet-drafts@ietf.org > >> To: i-d-announce@ietf.org > >> CC: lisp@ietf.org > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> This draft is a work item of the Locator/ID Separation Protocol > >> Working Group of the IETF. > >> > >> Title : LISP MIB > >> Author(s) : Gregg Schudel > >> Amit Jain > >> Victor Moreno > >> Filename : draft-ietf-lisp-mib-04.txt > >> Pages : 55 > >> Date : 2012-06-25 > >> > >> Abstract: > >> This document defines managed objects for the Locator/ID > > Separation > >> Protocol (LISP). These objects provide information useful for > >> monitoring LISP devices, including basic configuration > > information, > >> LISP status, and operational statistics. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-lisp-mib > >> > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-ietf-lisp-mib-04 > >> > >> A diff from previous version is available at: > >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-mib-04 > >> > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> I-D-Announce mailing list > >> I-D-Announce@ietf.org > >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> Internet-Draft directories: http://www.ietf.org/shadow.html > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> > >> > >> > >> > >> _______________________________________________ > >> MIB-DOCTORS mailing list > >> MIB-DOCTORS@ietf.org > >> https://www.ietf.org/mailman/listinfo/mib-doctors > > From hhazewinkel@gmail.com Wed Jun 27 04:18:51 2012 Return-Path: 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 C322A21F86C7 for ; Wed, 27 Jun 2012 04:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 Ws-VZsI3eupZ for ; Wed, 27 Jun 2012 04:18:51 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE0121F86C6 for ; Wed, 27 Jun 2012 04:18:50 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so757307wib.13 for ; Wed, 27 Jun 2012 04:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=iPkEFtX+4YUo+G2Aap6DjwjHXdB8g3XljxuNFqe+r/w=; b=TqWsE4IRJAJ2txSHLeP2cy+Q5THTzC4CXmfXkdW3jMZMyCQ98Pmzwg8bPvrpWkZ0Xg S25h7e220B/R69cfUJTQ/LUV7zIgfs7fs62dRfZdcP+pcrI5aVdIoCacRTPGgO9SZOGo lkc4ImnBkD/XXNksyZlqTOsj5J20J0SHVHqrtfiARMUKFgVCTiBeiZtgo9DzjF5CEta2 w7+L/OYn9cqQNL2n3iMisAMgVzy94bDcHvBKnedrQXzGmEMf9/m2SfB+HhJnEQqAZDCA 2FC41+VSJ62NISJubqJWNqIAKAXneiH527pSaUMTfXHPmxBau/yU1tcsxj8x1OJw1D/B Yb7A== Received: by 10.180.83.168 with SMTP id r8mr3877702wiy.22.1340795929448; Wed, 27 Jun 2012 04:18:49 -0700 (PDT) Received: from iprofslaptop019.iprofs.local ([87.213.99.166]) by mx.google.com with ESMTPS id y2sm9850592wix.7.2012.06.27.04.18.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jun 2012 04:18:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-87--436010127 From: Harrie Hazewinkel In-Reply-To: Date: Wed, 27 Jun 2012 13:18:46 +0200 Message-Id: <3C4EC7A2-FFF9-43D8-A80F-8B07EB2F36F2@gmail.com> References: <4FE898E0.30902@joelhalpern.com> <4FEAAD8E.9070108@cisco.com> <4FEAE00A.2030200@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1084) Cc: "MIB Doctors \(E-mail\)" , "Joel M. Halpern" , Terry Manderson Subject: Re: [MIB-DOCTORS] I-D Action: draft-ietf-lisp-mib-04.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 11:18:51 -0000 --Apple-Mail-87--436010127 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hallo, I did a very quick scan to see how much work it would and may know next = week more if I would have the time. What I noticed was the imports. In section 8.1 is only one of the imports mentioned, looks odd although = the other imports are the standard SNMP framework (SMI, etc..). But the document reference for the import = (IANA-ADDRESS-FAMILY-NUMBERS-MIB) is=20 placed in the informative references and should go in the normative = references. Harrie >>>> -------- Original Message -------- >>>> Subject: I-D Action: draft-ietf-lisp-mib-04.txt >>>> Date: Mon, 25 Jun 2012 09:45:25 -0700 >>>> From: internet-drafts@ietf.org >>>> Reply-To: internet-drafts@ietf.org >>>> To: i-d-announce@ietf.org >>>> CC: lisp@ietf.org >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Locator/ID Separation Protocol >>>> Working Group of the IETF. >>>>=20 >>>> Title : LISP MIB >>>> Author(s) : Gregg Schudel >>>> Amit Jain >>>> Victor Moreno >>>> Filename : draft-ietf-lisp-mib-04.txt >>>> Pages : 55 >>>> Date : 2012-06-25 >>>>=20 >>>> Abstract: >>>> This document defines managed objects for the Locator/ID >>> Separation >>>> Protocol (LISP). These objects provide information useful for >>>> monitoring LISP devices, including basic configuration >>> information, >>>> LISP status, and operational statistics. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-lisp-mib >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-lisp-mib-04 >>>>=20 >>>> A diff from previous version is available at: >>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-mib-04 >>>>=20 >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> MIB-DOCTORS mailing list >>>> MIB-DOCTORS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mib-doctors >>>=20 >=20 > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors Harrie hhazewinkel@gmail.com --Apple-Mail-87--436010127 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii placed in the informative references and should go in the = normative references.
  -------- Original Message = --------
Subject:= I-D Action: = draft-ietf-lisp-mib-04.txt
Date: Mon, 25 Jun 2012 09:45:25 = -0700
From: = internet-drafts@ietf.org
<= /blockquote>
Reply-To: internet-drafts@ietf.org
<= /blockquote>
To: i-d-announce@ietf.org
CC: lisp@ietf.org


A New = Internet-Draft is available from the on-line = Internet-Drafts
directories.
=   This draft is a work item of the Locator/ID Separation = Protocol
Working = Group of the IETF.

Title =           : LISP = MIB
Author(s) =       : Gregg = Schudel
=             &n= bsp;           &nbs= p;  Amit = Jain
=             &n= bsp;           &nbs= p;  Victor = Moreno
Filename =        : = draft-ietf-lisp-mib-04.txt
= Pages =           : = 55
Date =            : = 2012-06-25

Abstract:
=     This document defines managed objects for the = Locator/ID
Separation
=     Protocol (LISP).  These objects provide = information useful = for
=     monitoring LISP devices, including basic = configuration
information,
=     LISP status, and operational = statistics.


The = IETF datatracker status page for this draft = is:
https://data= tracker.ietf.org/doc/draft-ietf-lisp-mib
=

There's = also a htmlized version available = at:
http://tools.ie= tf.org/html/draft-ietf-lisp-mib-04

A diff = from previous version is available = at:
http:= //tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-mib-04


Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-d= rafts/

_______________________________________________
I-D-Announce mailing = list
I-D-Announce@ietf.org
https://www.ie= tf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf= /1shadow-sites.txt





_______________________________________________
MIB-DOCTORS mailing = list
MIB-DOCTORS@ietf.org
https://www.iet= f.org/mailman/listinfo/mib-doctors


__________________________= _____________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://w= ww.ietf.org/mailman/listinfo/mib-doctors

<= div>


= --Apple-Mail-87--436010127-- From j.schoenwaelder@jacobs-university.de Wed Jun 27 05:13:03 2012 Return-Path: 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 A092E21F8673 for ; Wed, 27 Jun 2012 05:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.196 X-Spam-Level: X-Spam-Status: No, score=-103.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 BK-9xTH1XT8u for ; Wed, 27 Jun 2012 05:13:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D722D21F85E5 for ; Wed, 27 Jun 2012 05:13:02 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3325C20C3B; Wed, 27 Jun 2012 14:13:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id V-V2Y3qKOzWe; Wed, 27 Jun 2012 14:13:02 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9DDAF20C39; Wed, 27 Jun 2012 14:13:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E344A202C5B9; Wed, 27 Jun 2012 14:13:00 +0200 (CEST) Date: Wed, 27 Jun 2012 14:13:00 +0200 From: Juergen Schoenwaelder To: Harrie Hazewinkel Message-ID: <20120627121300.GF49359@elstar.local> Mail-Followup-To: Harrie Hazewinkel , Benoit Claise , "MIB Doctors (E-mail)" , "Joel M. Halpern" , Terry Manderson References: <4FE898E0.30902@joelhalpern.com> <4FEAAD8E.9070108@cisco.com> <4FEAE00A.2030200@cisco.com> <3C4EC7A2-FFF9-43D8-A80F-8B07EB2F36F2@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C4EC7A2-FFF9-43D8-A80F-8B07EB2F36F2@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "MIB Doctors \(E-mail\)" , "Joel M. Halpern" , Terry Manderson Subject: Re: [MIB-DOCTORS] I-D Action: draft-ietf-lisp-mib-04.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 12:13:03 -0000 On Wed, Jun 27, 2012 at 01:18:46PM +0200, Harrie Hazewinkel wrote: > Hallo, > > I did a very quick scan to see how much work it would and may know next week > more if I would have the time. > > > What I noticed was the imports. > > > In section 8.1 is only one of the imports mentioned, looks odd although the other imports > are the standard SNMP framework (SMI, etc..). > > > But the document reference for the import (IANA-ADDRESS-FAMILY-NUMBERS-MIB) is > placed in the informative references and should go in the normative references. > I think the most important thing to tell people is that their MIB module(s) must compile and that they should read RFC 4181 and check in particular the appendices. Perhaps we should simply return all MIB modules right away if they do not even compile. The LISP-MIB module has some rather serious syntax errors. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From tnadeau@juniper.net Wed Jun 27 05:45:11 2012 Return-Path: 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 5A7AF21F85C9 for ; Wed, 27 Jun 2012 05:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.638 X-Spam-Level: X-Spam-Status: No, score=-5.638 tagged_above=-999 required=5 tests=[AWL=0.961, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 oX3Wqxx2kN1w for ; Wed, 27 Jun 2012 05:45:10 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3259621F8596 for ; Wed, 27 Jun 2012 05:44:48 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKT+sAPNkVTRIbfBi2tTQfciuDoWbSHrtd@postini.com; Wed, 27 Jun 2012 05:45:10 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 27 Jun 2012 05:41:11 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 27 Jun 2012 05:41:11 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 27 Jun 2012 08:41:10 -0400 From: Thomas Nadeau To: Juergen Schoenwaelder , Harrie Hazewinkel Date: Wed, 27 Jun 2012 08:41:06 -0400 Thread-Topic: [MIB-DOCTORS] I-D Action: draft-ietf-lisp-mib-04.txt Thread-Index: Ac1UYiDX2B+L/dzhTzesbyBSA0vVIQ== Message-ID: In-Reply-To: <20120627121300.GF49359@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "MIB Doctors \(E-mail\)" , "Joel M. Halpern" , Terry Manderson Subject: Re: [MIB-DOCTORS] I-D Action: draft-ietf-lisp-mib-04.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 12:45:11 -0000 On 6/27/12 8:13 AM, "Juergen Schoenwaelder" wrote: >On Wed, Jun 27, 2012 at 01:18:46PM +0200, Harrie Hazewinkel wrote: >> Hallo, >>=20 >> I did a very quick scan to see how much work it would and may know next >>week >> more if I would have the time. >>=20 >>=20 >> What I noticed was the imports. >>=20 >>=20 >> In section 8.1 is only one of the imports mentioned, looks odd although >>the other imports >> are the standard SNMP framework (SMI, etc..). >>=20 >>=20 >> But the document reference for the import >>(IANA-ADDRESS-FAMILY-NUMBERS-MIB) is >> placed in the informative references and should go in the normative >>references. >>=20 > >I think the most important thing to tell people is that their MIB >module(s) must compile and that they should read RFC 4181 and check in >particular the appendices. Perhaps we should simply return all MIB >modules right away if they do not even compile. The LISP-MIB module >has some rather serious syntax errors. I've suggested a few times that it be done as part of id-nits, or as a second pass if a MIB is detected. --Tom > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 >_______________________________________________ >MIB-DOCTORS mailing list >MIB-DOCTORS@ietf.org >https://www.ietf.org/mailman/listinfo/mib-doctors From robert.g.cole.civ@mail.mil Wed Jun 27 11:04:24 2012 Return-Path: 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 A7A8A11E8114 for ; Wed, 27 Jun 2012 11:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.858 X-Spam-Level: X-Spam-Status: No, score=-0.858 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, 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 jmMSbQuNP87S for ; Wed, 27 Jun 2012 11:04:23 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.9]) by ietfa.amsl.com (Postfix) with ESMTP id ADBA311E8113 for ; Wed, 27 Jun 2012 11:04:20 -0700 (PDT) Received: from UCOLHP3G.easf.csd.disa.mil (131.64.100.146) by ucolhp2w.easf.csd.disa.mil (131.64.100.9) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 27 Jun 2012 18:04:11 +0000 Received: from UCOLHP4J.easf.csd.disa.mil ([169.254.8.172]) by UCOLHP3G.easf.csd.disa.mil ([1.211.145.134]) with mapi id 14.02.0283.003; Wed, 27 Jun 2012 18:04:10 +0000 From: "Cole, Robert G CIV USARMY CERDEC (US)" To: Ulrich Herberg , Thomas Nadeau Thread-Topic: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED) Thread-Index: AQHNVImUSTnPFQ2MTQ6r8Xl0rB1SRJcOc2gA Date: Wed, 27 Jun 2012 18:04:08 +0000 Message-ID: References: In-Reply-To: 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_0221_01CD546D.B93D6770" MIME-Version: 1.0 Cc: "MIB Doctors \(E-mail\)" , "adrian@olddog.co.uk" Subject: Re: [MIB-DOCTORS] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 18:04:25 -0000 ------=_NextPart_000_0221_01CD546D.B93D6770 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Classification: UNCLASSIFIED Caveats: NONE Ulrich, One observation. I had proposed ifType=manet instead of type 'nhdp' to designate an interface which would carry any MANET protocol (e.g., NHDP, AODV, OLSR, etc). As you point out, I believe the ifStackTable could be used to indicate that we wish to run 'manet' over ifType=802.3 or Ethernet or 802.11 or whatever. And that seems to me to be a reasonable approach. Then in the NHDP-MIB our nhdpIfTable would only contain rows for the interfaces that we are running manet protocols over, as indicated in the ifTable and ifStackTable. Bob -----Original Message----- From: Ulrich Herberg [mailto:ulrich@herberg.name] Sent: Wednesday, June 27, 2012 1:24 PM To: Thomas Nadeau Cc: Cole, Robert G CIV USARMY CERDEC (US); MIB Doctors (E-mail); Benoit Claise; adrian@olddog.co.uk Subject: Re: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED) Thomas, I understand now better how the ifType works, as defined in RFC2863. Essentially, we would request from IANA to allocate a new "MANET" IANAifType in http://www.iana.org/assignments/ianaiftype-mib I just want to make sure that this is the correct thing to do. A MANET interface is specified in RFC6130 as an interface that runs NHDP (i.e., a protocol above IP in the stack). I have the impression that most of the other ifType are below the IP layer. It would also imply that we have to add plenty of entries in the ifStackTable (MANET above 802.11, MANET above 802.15.4 etc), right? And it means that, e.g., DYMO/AODV (even though specified in the MANET WG) would not use the MANET ifType, because the reactive MANET protocol does not use NHDP. If all that is as intended, then we can go ahead and change it in the MIB-module. Thanks Ulrich On Wed, Jun 13, 2012 at 1:15 PM, Thomas Nadeau wrote: On 6/13/12 4:02 PM, "Cole, Robert G CIV USARMY CERDEC (US)" wrote: >Classification: UNCLASSIFIED >Caveats: NONE > >Tom, > > >-you wrote- > I appreciate the reference but my points from earlier still apply. >In the reference, I believe operationally you avoid entries that do not >have >the correct ifType for the Ipv4InterfaceEntry. Remember that if that were >not the case, then what you get is a direct one-to-one mapping of IPv4 >interfaces attributes for EVERY IfTable entry. This is a bad idea given >that there are a wide array of devices that have a small set of their >interfaces possessing IPv4 characteristics. > >RGC> I do not see in reading through the reference RFC 4293, how this >behavior is identified. I agree with you that this is desirable. I just >do >not see the mechanism that informs the implementer to scope the ifType. TOM: The reference doesn't explicitly say this, but that is how I believe its implemented. > > In your MIB you are effectively doing this. If you really wanted >that you should use AUGMENTS, but that doesn't seem like what you want. >The >simple way to correct this situation is to define an ifType for NHDP >interfaces and explicitly exclude non-NHDP interfaces from being returned. > This effectively "extends" - or more appropriately - "selectively >extends" >the IfTable entries. > >RGC> You are right; it is this later case and behavior we want to achieve. >Where do I define an ifType for NHDP interfaces? Also more generally, >should I be defining an ifType for MANET interfaces? You do this in an IANA section. Take a look at how we did this in RFC3811/12/13. It is pretty straight-forward. You can also see how to scope its use tightly to avoid scale issues. I think you would want an ifType for MANET - I was mistaken earlier when I said NHDP. --Tom > >Thanks, Bob > > > --Tom > > >> >>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 >> >>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 >> >> > > >Classification: UNCLASSIFIED >Caveats: NONE > > Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_0221_01CD546D.B93D6770 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIS3DCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEwTCCA6mgAwIBAgIDDNszMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQwHhcNMTAwMjI1MDAwMDAwWhcN MTMwMjI0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1DT0xFLlJP QkVSVC5HUkFOT1QuMTM2NjU2MDM5MDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKU7 jo5hPKcK6V92Cni9Bu445V7UQJBLIu1eX3brV/yB6uFNd+lIdV5n6RBpE1QcsIUEyS1GVDvTR/Qs kbUInPJC8ioZCX/V5Y2J8nRNidXoLX4SdeQ3Gc6jLPn+1W8KHRdATHy+SYGcrHnePyRAhTO73rN3 97CqgOaxnS4wo/Eanw9Re5UGq70cN/G7376Oxa7A2xdtY9w8gLUilFmcYXuwR7FGxcnDhsqAW3fv tgM18ZWn/hioEhmRZz514jXPnHCvSPAkofjb4Mjucnku8uNowu+PMw5Yqv9wimBEitvQGPnyac41 MNtsflnmVqWswTwhzVzIGdodKZTw2h6byTcCAwEAAaOCAWwwggFoMB8GA1UdIwQYMBaAFFSqcyrH s3fqzSJAeUh7EfunmSKCMD8GA1UdHwQ4MDYwNKAyoDCGLmh0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0 Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMjQwDgYDVR0PAQH/BAQDAgUgMCMGA1UdIAQcMBowCwYJYIZI AWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUyGOLOF3I71SMIzwNIujoox8W0CowbQYIKwYB BQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3JsLmRpc2EubWlsL2dldHNpZ24/RE9EJTIw RU1BSUwlMjBDQS0yNDAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwJAYDVR0RBB0w G4EZcm9iZXJ0LmcuY29sZUB1cy5hcm15Lm1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVT MA0GCSqGSIb3DQEBBQUAA4IBAQAVD+rqDKxhGbV78baC+EUC3jiDUO6C41wsmB4ckt5akJPvVrB4 mjlnoG0lm19qovC98eO0vPQMUx1F6/jP9/xg32W2Ks2HZUR3ipZWBEqVi8i20Wz4sVFgXHkJjoP5 bju0XvJk/d6wze65iZqFuILuPplugaHg7iC5B/NAMELTGx8hoK3LVqmIIyMpEFlrxTygIkyuI+NK IqcbLtBOEW0bP7TNyBh/VShmtrXAtpPP0AAi+kaUURcG1x2xdPCR3cD2bjWYkfxQYeZRl2zTuOMg Mpr9pG3MuImao/C+v6IaXGuAU8xS8hSEbHGNLrXjJ9UIxw0K45WxjR7CrPFIJ4R5MIIFDDCCA/Sg AwIBAgIDDNswMA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjQwHhcNMTAwMjI1MDAwMDAwWhcNMTMwMjI0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UE CxMDVVNBMSYwJAYDVQQDEx1DT0xFLlJPQkVSVC5HUkFOT1QuMTM2NjU2MDM5MDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOsVn1k8Ax7kkzWXvrNf7oI7iy5zEeLACdGKrODL9riDBNUF HvD4JtafUcwq03s4Daq0tscNL8J1ONDeML5s0X8UeNfCyexrkSpPwY9g/zVO6mJmG4OunTz/7fc2 G0ZR64VYlEBZeQ88JIMIs6bYXiO9SxuOCS47aGx/CGqdpFwt713bBAQvzAjLUSWBvjZN2bviTQrY wAg1/1AnlxY6Zl4YPBSV9c1TbtTQNjbRyFRabiqNMh0XaQ0ZHxQgsGOqNwfyMlmadL2m3ILhKpFh oMfOV01at2eDj8+wFvDXLXAL1f3HAQKv5W5GEoBYNDqp/ULDBJcXVPT8mYWzxMkca/MCAwEAAaOC AbcwggGzMB8GA1UdIwQYMBaAFFSqcyrHs3fqzSJAeUh7EfunmSKCMD8GA1UdHwQ4MDYwNKAyoDCG Lmh0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMjQwDgYDVR0PAQH/ BAQDAgbAMCMGA1UdIAQcMBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUBeVx RkqbKuf17SKV2ZZOsCXLQ+gwbQYIKwYBBQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3Js LmRpc2EubWlsL2dldHNpZ24/RE9EJTIwRU1BSUwlMjBDQS0yNDAgBggrBgEFBQcwAYYUaHR0cDov L29jc3AuZGlzYS5taWwwRAYDVR0RBD0wO4EZcm9iZXJ0LmcuY29sZUB1cy5hcm15Lm1pbKAeBgor BgEEAYI3FAIDoBAMDjEzNjY1NjAzOTBAbWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMw KQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUA A4IBAQBhwXMphuaV+lhIZbI35yGpZ7zy/uXNyr41+/dibahnAIisIIHFSTeEk9GFepxqV45hagTo //0UycQ/ShOIHzV/+u3l/97k+l8imMdbjhgklb2UFROSz7TJzhO3w4S7g7DpU+GTxE2Uax+iD2t0 Bmio3ut9fr/dWvi6OTYVFMTW7M6pd8gOPqmg8ADGdljGsSotMAhXzFJgAPtnsca5HfyYpGi0NQj0 ucT/sWUGwnnjlqtYyP+SY2pOPpbN9gACkv8UKJMkik5GEFobaHbI8KWr4FFOXAIAauW1DvGFq5Pe WdDgj39r6PkdOLg3v+B9/hnkP6uOyH5Oi9pcHb+d/hPuMIIFjzCCBHegAwIBAgIBRTANBgkqhkiG 9w0BAQUFADBbMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQL EwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNRG9EIFJvb3QgQ0EgMjAeFw0wOTAxMjYyMDI2 MTVaFw0xNTAxMjUyMDI2MTVaMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1l bnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQClLlh6od7mmlv2AvHV1Nw1I5p7bihkdBpw PJYdzMKfdAQ8DDmSIQgNEk6g1zeo0snGJ50o+lXXshcEGc4yvPB5nvVoqy7MzzcEsvgKZZpJIBQl wbwSaqBCbRsItIehQiKrE5naAgE5H14IV2tg3hN+aGp+QfWJgDh6/Zey0uKWSzaAYrbsJbvQD6ej zVGo99J5VZA0JqPkXM27aCZ0CTeh5q/N5D6ZR/9/wke8ZYS6MimjDvDColt66rJKfQvGw26svRB/ T6l2Oj0CASwqMLT3yKDSmDp8CNBaiQ+1ioL6DTAeftbRx7ZDJ7EoqQzjswd432JkmkWMTs2vDq6c WDbfAgMBAAGjggJaMIICVjAOBgNVHQ8BAf8EBAMCAYYwHwYDVR0jBBgwFoAUSXS7DF66ev4CVO97 oMaVxgmAcJYwHQYDVR0OBBYEFFSqcyrHs3fqzSJAeUh7EfunmSKCMAwGA1UdJAQFMAOAAQAwEgYD VR0TAQH/BAgwBgEB/wIBADCBnwYDVR0gBIGXMIGUMAsGCWCGSAFlAgELBTALBglghkgBZQIBCwkw CwYJYIZIAWUCAQsKMAsGCWCGSAFlAgELEjALBglghkgBZQIBCxMwCwYJYIZIAWUCAQsUMAwGCmCG SAFlAwIBAwYwDAYKYIZIAWUDAgEDBzAMBgpghkgBZQMCAQMIMAwGCmCGSAFlAwIBAw0wDAYKYIZI AWUDAgEDETA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLmRpc2EubWlsL2dldGNybD9Eb0Ql MjBSb290JTIwQ0ElMjAyMIH+BggrBgEFBQcBAQSB8TCB7jA/BggrBgEFBQcwAoYzaHR0cDovL2Ny bC5kaXNhLm1pbC9nZXRJc3N1ZWRUbz9Eb0QlMjBSb290JTIwQ0ElMjAyMCAGCCsGAQUFBzABhhRo dHRwOi8vb2NzcC5kaXNhLm1pbDCBiAYIKwYBBQUHMAKGfGxkYXA6Ly9jcmwuZ2RzLmRpc2EubWls L2NuJTNkRG9EJTIwUm9vdCUyMENBJTIwMiUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNkVS5T LiUyMEdvdmVybm1lbnQlMmNjJTNkVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwDQYJKoZIhvcNAQEF BQADggEBAHIW3DlzY02T6Tccz7LtnNhN9wwySomes8q68wSscWYxpiq9un1U2C8JY0qICOhsE6Hs XntWFzAtyNLt141HRGnPEW/L2OdSdbVRyKodafAZHzDwB8c2vc4M3jt2/QrOy7YTutaFi/FcEpHK r+h/EqisLYvWdlCU7Db6ow/fxjLqx3NG/IQami/E6CccSMJGNvYX7O1nMg+4ouC30l6QBhOUIWFD bH3zO2tl7ePbqP/Fm7KS5+tf7u+/8zmMs/UX0obVw2xKOmw/nq/oWx02W6YmFUYLRmvH1ICq564c uCtO+iFyn1+fga+07lvJlymJfOnceOJO4HSf0oZ4ZqLHmKgxggL+MIIC+gIBATBkMF0xCzAJBgNV BAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMD UEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQCAwzbMDAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA2MjcxODA0MDlaMCMGCSqGSIb3 DQEJBDEWBBT5bNEeR8rSUvP60b95e5LhGnlrRTAkBgkqhkiG9w0BCQ8xFzAVMAoGCCqGSIb3DQMH MAcGBSsOAwIaMHMGCSsGAQQBgjcQBDFmMGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJ TCBDQS0yNAIDDNszMHUGCyqGSIb3DQEJEAILMWagZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMP VS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9E IEVNQUlMIENBLTI0AgMM2zMwDQYJKoZIhvcNAQEBBQAEggEAplqBBYEbSOdZ3dA3fUbEkdH7qAv2 /SMrxDuDR5LRVTw+hDvA95GU3E6oZakQkQvdCEhTPBQ7zT09zm/dooUiUFT73wHm4cp1dHtK/Y2a K+rVzlb2OYmOwkCBOJJpU3+JIxg+SAZEs9LeT8n0DJc2xB8hEcNvd+7PkM+lBdwMHewy+LcTLpYK 11KB9OLJ1Ze9e0IPI5/+WmPM4GonURFIu2C2gUnKJ5gyidk4tVDx2VwMQ2GjcXxy4nPPedxQf50c rouZuD+1vur5uCcjPN6RbLh7lotKKW2nPrpgdTX+ldco2BEv9k4J7G7qASXOOgzDIujwpn0zlrHB PLfm6NvSlgAAAAAAAA== ------=_NextPart_000_0221_01CD546D.B93D6770-- From robert.g.cole.civ@mail.mil Wed Jun 27 11:48:07 2012 Return-Path: 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 8B81211E811E for ; Wed, 27 Jun 2012 11:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.966 X-Spam-Level: X-Spam-Status: No, score=-0.966 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, 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 7jaWgB54+SLb for ; Wed, 27 Jun 2012 11:48:06 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8847D11E8118 for ; Wed, 27 Jun 2012 11:48:05 -0700 (PDT) Received: from UCOLHP3D.easf.csd.disa.mil (131.64.100.143) by ucolhp2w.easf.csd.disa.mil (131.64.100.9) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 27 Jun 2012 18:47:43 +0000 Received: from UCOLHP4J.easf.csd.disa.mil ([169.254.8.172]) by UCOLHP3D.easf.csd.disa.mil ([131.64.100.143]) with mapi id 14.02.0283.003; Wed, 27 Jun 2012 18:47:43 +0000 From: "Cole, Robert G CIV USARMY CERDEC (US)" To: Ulrich Herberg Thread-Topic: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED) Thread-Index: AQHNVImUSTnPFQ2MTQ6r8Xl0rB1SRJcOc2gAgAAFXwCAAARV0A== Date: Wed, 27 Jun 2012 18:47:42 +0000 Message-ID: References: In-Reply-To: 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_0352_01CD5473.CF086AE0" MIME-Version: 1.0 Cc: "adrian@olddog.co.uk" , "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 18:48:07 -0000 ------=_NextPart_000_0352_01CD5473.CF086AE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Classification: UNCLASSIFIED Caveats: NONE Ulrich, I guess I lean towards your former option, i.e., "- introduce an ifType=manet that applies for all MANET protocols. In the NHDP-MIB, the interface table would only list ifType=manet. However, in case another MANET protocol (not NHDP) is used on an interface, that interface would still be listed in the NHDP-MIB interface table. I don't think that is what we want." Then the nhdpIfStatus object would be defined to indicate whether or not NHDP is configured to run over that interface. And type 'manet' would restrict the total list of interfaces. Then looking forward to the SMF-MIB, where SMF does not require NHDP to operate, the smfInterfaceTable's smfIfAdminStatus would have a comparable semantic, i.e., "smfIfAdminStatus OBJECT-TYPE SYNTAX SmfStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The SMF interface's administrative status. The value 'enabled' denotes that the interface is running the SMF forwarding process. The value 'disabled' denotes that the interface is external to the SMF forwarding process. " ::= { smfInterfaceEntry 3 } " This would generally hold true for other manet control protocols, e.g., DSR, AODV, etc Bob -----Original Message----- From: Ulrich Herberg [mailto:ulrich@herberg.name] Sent: Wednesday, June 27, 2012 2:16 PM To: Cole, Robert G CIV USARMY CERDEC (US) Cc: Thomas Nadeau; MIB Doctors (E-mail); Benoit Claise; adrian@olddog.co.uk Subject: Re: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED) Bob, we have to be careful how to name the ifType, since RFC6130 defines a "MANET interface" as: "An interface participating in a MANET and using this neighborhood discovery protocol", i.e. it is specific to the usage of NHDP. Therefore, if we choose ifType=manet, but actually mean every MANET routing protocol (incl. DYMO), that may be confusing. I wonder if it was a good idea to linking "MANET interface" specifically for usage of NHDP in RFC6130... but it's too late to change it. I see several options: - introduce an ifType=manet that applies for all MANET protocols. In the NHDP-MIB, the interface table would only list ifType=manet. However, in case another MANET protocol (not NHDP) is used on an interface, that interface would still be listed in the NHDP-MIB interface table. I don't think that is what we want. - introduce an ifType=nhdp that applies only for NHDP. In that case, only these interfaces would be listed in the NHDP-MIB interface table, which is correct. The question is, do we still need a ifType=manet, and ifType=nhdp would be above the stack of ifType=manet? Best regards Ulrich On Wed, Jun 27, 2012 at 11:04 AM, Cole, Robert G CIV USARMY CERDEC (US) wrote: Classification: UNCLASSIFIED Caveats: NONE Ulrich, One observation. I had proposed ifType=manet instead of type 'nhdp' to designate an interface which would carry any MANET protocol (e.g., NHDP, AODV, OLSR, etc). As you point out, I believe the ifStackTable could be used to indicate that we wish to run 'manet' over ifType=802.3 or Ethernet or 802.11 or whatever. And that seems to me to be a reasonable approach. Then in the NHDP-MIB our nhdpIfTable would only contain rows for the interfaces that we are running manet protocols over, as indicated in the ifTable and ifStackTable. Bob -----Original Message----- From: Ulrich Herberg [mailto:ulrich@herberg.name] Sent: Wednesday, June 27, 2012 1:24 PM To: Thomas Nadeau Cc: Cole, Robert G CIV USARMY CERDEC (US); MIB Doctors (E-mail); Benoit Claise; adrian@olddog.co.uk Subject: Re: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED) Thomas, I understand now better how the ifType works, as defined in RFC2863. Essentially, we would request from IANA to allocate a new "MANET" IANAifType in http://www.iana.org/assignments/ianaiftype-mib I just want to make sure that this is the correct thing to do. A MANET interface is specified in RFC6130 as an interface that runs NHDP (i.e., a protocol above IP in the stack). I have the impression that most of the other ifType are below the IP layer. It would also imply that we have to add plenty of entries in the ifStackTable (MANET above 802.11, MANET above 802.15.4 etc), right? And it means that, e.g., DYMO/AODV (even though specified in the MANET WG) would not use the MANET ifType, because the reactive MANET protocol does not use NHDP. If all that is as intended, then we can go ahead and change it in the MIB-module. Thanks Ulrich On Wed, Jun 13, 2012 at 1:15 PM, Thomas Nadeau wrote: On 6/13/12 4:02 PM, "Cole, Robert G CIV USARMY CERDEC (US)" wrote: >Classification: UNCLASSIFIED >Caveats: NONE > >Tom, > > >-you wrote- > I appreciate the reference but my points from earlier still apply. >In the reference, I believe operationally you avoid entries that do not >have >the correct ifType for the Ipv4InterfaceEntry. Remember that if that were >not the case, then what you get is a direct one-to-one mapping of IPv4 >interfaces attributes for EVERY IfTable entry. This is a bad idea given >that there are a wide array of devices that have a small set of their >interfaces possessing IPv4 characteristics. > >RGC> I do not see in reading through the reference RFC 4293, how this >behavior is identified. I agree with you that this is desirable. I just >do >not see the mechanism that informs the implementer to scope the ifType. TOM: The reference doesn't explicitly say this, but that is how I believe its implemented. > > In your MIB you are effectively doing this. If you really wanted >that you should use AUGMENTS, but that doesn't seem like what you want. >The >simple way to correct this situation is to define an ifType for NHDP >interfaces and explicitly exclude non-NHDP interfaces from being returned. > This effectively "extends" - or more appropriately - "selectively >extends" >the IfTable entries. > >RGC> You are right; it is this later case and behavior we want to achieve. >Where do I define an ifType for NHDP interfaces? Also more generally, >should I be defining an ifType for MANET interfaces? You do this in an IANA section. Take a look at how we did this in RFC3811/12/13. It is pretty straight-forward. You can also see how to scope its use tightly to avoid scale issues. I think you would want an ifType for MANET - I was mistaken earlier when I said NHDP. --Tom > >Thanks, Bob > > > --Tom > > >> >>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 >> >>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 >> >> > > >Classification: UNCLASSIFIED >Caveats: NONE > > Classification: UNCLASSIFIED Caveats: NONE Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_0352_01CD5473.CF086AE0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIS3DCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEwTCCA6mgAwIBAgIDDNszMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQwHhcNMTAwMjI1MDAwMDAwWhcN MTMwMjI0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1DT0xFLlJP QkVSVC5HUkFOT1QuMTM2NjU2MDM5MDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKU7 jo5hPKcK6V92Cni9Bu445V7UQJBLIu1eX3brV/yB6uFNd+lIdV5n6RBpE1QcsIUEyS1GVDvTR/Qs kbUInPJC8ioZCX/V5Y2J8nRNidXoLX4SdeQ3Gc6jLPn+1W8KHRdATHy+SYGcrHnePyRAhTO73rN3 97CqgOaxnS4wo/Eanw9Re5UGq70cN/G7376Oxa7A2xdtY9w8gLUilFmcYXuwR7FGxcnDhsqAW3fv tgM18ZWn/hioEhmRZz514jXPnHCvSPAkofjb4Mjucnku8uNowu+PMw5Yqv9wimBEitvQGPnyac41 MNtsflnmVqWswTwhzVzIGdodKZTw2h6byTcCAwEAAaOCAWwwggFoMB8GA1UdIwQYMBaAFFSqcyrH s3fqzSJAeUh7EfunmSKCMD8GA1UdHwQ4MDYwNKAyoDCGLmh0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0 Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMjQwDgYDVR0PAQH/BAQDAgUgMCMGA1UdIAQcMBowCwYJYIZI AWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUyGOLOF3I71SMIzwNIujoox8W0CowbQYIKwYB BQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3JsLmRpc2EubWlsL2dldHNpZ24/RE9EJTIw RU1BSUwlMjBDQS0yNDAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwJAYDVR0RBB0w G4EZcm9iZXJ0LmcuY29sZUB1cy5hcm15Lm1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVT MA0GCSqGSIb3DQEBBQUAA4IBAQAVD+rqDKxhGbV78baC+EUC3jiDUO6C41wsmB4ckt5akJPvVrB4 mjlnoG0lm19qovC98eO0vPQMUx1F6/jP9/xg32W2Ks2HZUR3ipZWBEqVi8i20Wz4sVFgXHkJjoP5 bju0XvJk/d6wze65iZqFuILuPplugaHg7iC5B/NAMELTGx8hoK3LVqmIIyMpEFlrxTygIkyuI+NK IqcbLtBOEW0bP7TNyBh/VShmtrXAtpPP0AAi+kaUURcG1x2xdPCR3cD2bjWYkfxQYeZRl2zTuOMg Mpr9pG3MuImao/C+v6IaXGuAU8xS8hSEbHGNLrXjJ9UIxw0K45WxjR7CrPFIJ4R5MIIFDDCCA/Sg AwIBAgIDDNswMA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjQwHhcNMTAwMjI1MDAwMDAwWhcNMTMwMjI0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UE CxMDVVNBMSYwJAYDVQQDEx1DT0xFLlJPQkVSVC5HUkFOT1QuMTM2NjU2MDM5MDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOsVn1k8Ax7kkzWXvrNf7oI7iy5zEeLACdGKrODL9riDBNUF HvD4JtafUcwq03s4Daq0tscNL8J1ONDeML5s0X8UeNfCyexrkSpPwY9g/zVO6mJmG4OunTz/7fc2 G0ZR64VYlEBZeQ88JIMIs6bYXiO9SxuOCS47aGx/CGqdpFwt713bBAQvzAjLUSWBvjZN2bviTQrY wAg1/1AnlxY6Zl4YPBSV9c1TbtTQNjbRyFRabiqNMh0XaQ0ZHxQgsGOqNwfyMlmadL2m3ILhKpFh oMfOV01at2eDj8+wFvDXLXAL1f3HAQKv5W5GEoBYNDqp/ULDBJcXVPT8mYWzxMkca/MCAwEAAaOC AbcwggGzMB8GA1UdIwQYMBaAFFSqcyrHs3fqzSJAeUh7EfunmSKCMD8GA1UdHwQ4MDYwNKAyoDCG Lmh0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMjQwDgYDVR0PAQH/ BAQDAgbAMCMGA1UdIAQcMBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUBeVx RkqbKuf17SKV2ZZOsCXLQ+gwbQYIKwYBBQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3Js LmRpc2EubWlsL2dldHNpZ24/RE9EJTIwRU1BSUwlMjBDQS0yNDAgBggrBgEFBQcwAYYUaHR0cDov L29jc3AuZGlzYS5taWwwRAYDVR0RBD0wO4EZcm9iZXJ0LmcuY29sZUB1cy5hcm15Lm1pbKAeBgor BgEEAYI3FAIDoBAMDjEzNjY1NjAzOTBAbWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMw KQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUA A4IBAQBhwXMphuaV+lhIZbI35yGpZ7zy/uXNyr41+/dibahnAIisIIHFSTeEk9GFepxqV45hagTo //0UycQ/ShOIHzV/+u3l/97k+l8imMdbjhgklb2UFROSz7TJzhO3w4S7g7DpU+GTxE2Uax+iD2t0 Bmio3ut9fr/dWvi6OTYVFMTW7M6pd8gOPqmg8ADGdljGsSotMAhXzFJgAPtnsca5HfyYpGi0NQj0 ucT/sWUGwnnjlqtYyP+SY2pOPpbN9gACkv8UKJMkik5GEFobaHbI8KWr4FFOXAIAauW1DvGFq5Pe WdDgj39r6PkdOLg3v+B9/hnkP6uOyH5Oi9pcHb+d/hPuMIIFjzCCBHegAwIBAgIBRTANBgkqhkiG 9w0BAQUFADBbMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQL EwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNRG9EIFJvb3QgQ0EgMjAeFw0wOTAxMjYyMDI2 MTVaFw0xNTAxMjUyMDI2MTVaMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1l bnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQClLlh6od7mmlv2AvHV1Nw1I5p7bihkdBpw PJYdzMKfdAQ8DDmSIQgNEk6g1zeo0snGJ50o+lXXshcEGc4yvPB5nvVoqy7MzzcEsvgKZZpJIBQl wbwSaqBCbRsItIehQiKrE5naAgE5H14IV2tg3hN+aGp+QfWJgDh6/Zey0uKWSzaAYrbsJbvQD6ej zVGo99J5VZA0JqPkXM27aCZ0CTeh5q/N5D6ZR/9/wke8ZYS6MimjDvDColt66rJKfQvGw26svRB/ T6l2Oj0CASwqMLT3yKDSmDp8CNBaiQ+1ioL6DTAeftbRx7ZDJ7EoqQzjswd432JkmkWMTs2vDq6c WDbfAgMBAAGjggJaMIICVjAOBgNVHQ8BAf8EBAMCAYYwHwYDVR0jBBgwFoAUSXS7DF66ev4CVO97 oMaVxgmAcJYwHQYDVR0OBBYEFFSqcyrHs3fqzSJAeUh7EfunmSKCMAwGA1UdJAQFMAOAAQAwEgYD VR0TAQH/BAgwBgEB/wIBADCBnwYDVR0gBIGXMIGUMAsGCWCGSAFlAgELBTALBglghkgBZQIBCwkw CwYJYIZIAWUCAQsKMAsGCWCGSAFlAgELEjALBglghkgBZQIBCxMwCwYJYIZIAWUCAQsUMAwGCmCG SAFlAwIBAwYwDAYKYIZIAWUDAgEDBzAMBgpghkgBZQMCAQMIMAwGCmCGSAFlAwIBAw0wDAYKYIZI AWUDAgEDETA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLmRpc2EubWlsL2dldGNybD9Eb0Ql MjBSb290JTIwQ0ElMjAyMIH+BggrBgEFBQcBAQSB8TCB7jA/BggrBgEFBQcwAoYzaHR0cDovL2Ny bC5kaXNhLm1pbC9nZXRJc3N1ZWRUbz9Eb0QlMjBSb290JTIwQ0ElMjAyMCAGCCsGAQUFBzABhhRo dHRwOi8vb2NzcC5kaXNhLm1pbDCBiAYIKwYBBQUHMAKGfGxkYXA6Ly9jcmwuZ2RzLmRpc2EubWls L2NuJTNkRG9EJTIwUm9vdCUyMENBJTIwMiUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNkVS5T LiUyMEdvdmVybm1lbnQlMmNjJTNkVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwDQYJKoZIhvcNAQEF BQADggEBAHIW3DlzY02T6Tccz7LtnNhN9wwySomes8q68wSscWYxpiq9un1U2C8JY0qICOhsE6Hs XntWFzAtyNLt141HRGnPEW/L2OdSdbVRyKodafAZHzDwB8c2vc4M3jt2/QrOy7YTutaFi/FcEpHK r+h/EqisLYvWdlCU7Db6ow/fxjLqx3NG/IQami/E6CccSMJGNvYX7O1nMg+4ouC30l6QBhOUIWFD bH3zO2tl7ePbqP/Fm7KS5+tf7u+/8zmMs/UX0obVw2xKOmw/nq/oWx02W6YmFUYLRmvH1ICq564c uCtO+iFyn1+fga+07lvJlymJfOnceOJO4HSf0oZ4ZqLHmKgxggL+MIIC+gIBATBkMF0xCzAJBgNV BAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMD UEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQCAwzbMDAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA2MjcxODQ3NDNaMCMGCSqGSIb3 DQEJBDEWBBRNm+w1XJjVOEPguKMdc6/Z9EsmiTAkBgkqhkiG9w0BCQ8xFzAVMAoGCCqGSIb3DQMH MAcGBSsOAwIaMHMGCSsGAQQBgjcQBDFmMGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJ TCBDQS0yNAIDDNszMHUGCyqGSIb3DQEJEAILMWagZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMP VS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9E IEVNQUlMIENBLTI0AgMM2zMwDQYJKoZIhvcNAQEBBQAEggEAE/koEt2wO+ykXwnURTNFy0dD/Sgv skYF3GV3Q6b+5ZLQZmka2vilonoC2qzUoJBrTB7kemp4IVC8hdLjX4jaEEUN4tJGaIGLjrKpsgD/ 8vlYDLjhgnW/wGS6feH7x8KXI4qGreu35h0bLfCRu1qyu+dttzV8o/EcQFTOtMnVY2TvL9UeWPf8 ZOKL9dJV0hSfo+SYEfr+IppiLFecDO2zAfYFY73XC7N2/MYDX9b07q1hc9XVb1N7+DEZCdKSpuCM vPEfojn0xV0VyKk2OTCf0ZEOo3AQY06lapG7CjT0E+K2iaLss5RgItDq9iRmdCYGkbswHvW/5mHw Fqy5wTxfRwAAAAAAAA== ------=_NextPart_000_0352_01CD5473.CF086AE0-- From tnadeau@juniper.net Wed Jun 27 11:57:25 2012 Return-Path: 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 EEE6111E80A5 for ; Wed, 27 Jun 2012 11:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.278 X-Spam-Level: X-Spam-Status: No, score=-5.278 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] 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 uhKimHKqsGSR for ; Wed, 27 Jun 2012 11:57:22 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id B044E11E80A1 for ; Wed, 27 Jun 2012 11:57:20 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKT+tXjuWPAjJMU1gK1HEUD0UQzBNqbyj1@postini.com; Wed, 27 Jun 2012 11:57:22 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 27 Jun 2012 11:55:17 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 27 Jun 2012 11:55:17 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 27 Jun 2012 14:55:16 -0400 From: Thomas Nadeau To: Ulrich Herberg , "Cole, Robert G CIV USARMY CERDEC (US)" Date: Wed, 27 Jun 2012 14:55:12 -0400 Thread-Topic: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED) Thread-Index: Ac1UlmOuw97YgzalRnSpQ0YByZI4IA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "MIB Doctors \(E-mail\)" , "adrian@olddog.co.uk" Subject: Re: [MIB-DOCTORS] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 18:57:25 -0000 From: Ulrich Herberg > To: "Cole, Robert G CIV USARMY CERDEC (US)" > Cc: Thomas Nadeau >, "MIB D= octors (E-mail)" >, Benoi= t Claise >, "adrian@olddog.co.u= k" > Subject: Re: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with= DISCUSS and COMMENT) (UNCLASSIFIED) Bob, okay, that convinced me. Only slight disadvantage is that ifType=3Dmanet would not correspond to "MA= NET interface" according to RFC6130, but to all MANET protocols. The questi= on would then be, how (and where) is the terminology defined for the "MANET= interface that is not limited to NHDP"? Adrian, any advice on that? Thomas, would that solution be good for you? TOM: Yes. This is along the lines of what I suggested earlier. --Tom Best Ulrich On Wed, Jun 27, 2012 at 11:47 AM, Cole, Robert G CIV USARMY CERDEC (US) > wrote: Classification: UNCLASSIFIED Caveats: NONE Ulrich, I guess I lean towards your former option, i.e., "- introduce an ifType=3Dmanet that applies for all MANET protocols. In the NHDP-MIB, the interface table would only list ifType=3Dmanet. However, in c= ase another MANET protocol (not NHDP) is used on an interface, that interface would still be listed in the NHDP-MIB interface table. I don't think that i= s what we want." Then the nhdpIfStatus object would be defined to indicate whether or not NHDP is configured to run over that interface. And type 'manet' would restrict the total list of interfaces. Then looking forward to the SMF-MIB, where SMF does not require NHDP to operate, the smfInterfaceTable's smfIfAdminStatus would have a comparable semantic, i.e., "smfIfAdminStatus OBJECT-TYPE SYNTAX SmfStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The SMF interface's administrative status. The value 'enabled' denotes that the interface is running the SMF forwarding process. The value 'disabled' denotes that the interface is external to the SMF forwarding process. " ::=3D { smfInterfaceEntry 3 } " This would generally hold true for other manet control protocols, e.g., DSR= , AODV, etc Bob -----Original Message----- From: Ulrich Herberg [mailto:ulrich@herberg.name] Sent: Wednesday, June 27, 2012 2:16 PM To: Cole, Robert G CIV USARMY CERDEC (US) Cc: Thomas Nadeau; MIB Doctors (E-mail); Benoit Claise; adrian@olddog.co.uk= Subject: Re: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED) Bob, we have to be careful how to name the ifType, since RFC6130 defines a "MANE= T interface" as: "An interface participating in a MANET and using this neighborhood discovery protocol", i.e. it is specific to the usage of NHDP. Therefore, if we choose ifType=3Dmanet, but actually mean every MANET routi= ng protocol (incl. DYMO), that may be confusing. I wonder if it was a good idea to linking "MANET interface" specifically fo= r usage of NHDP in RFC6130... but it's too late to change it. I see several options: - introduce an ifType=3Dmanet that applies for all MANET protocols. In the NHDP-MIB, the interface table would only list ifType=3Dmanet. However, in c= ase another MANET protocol (not NHDP) is used on an interface, that interface would still be listed in the NHDP-MIB interface table. I don't think that i= s what we want. - introduce an ifType=3Dnhdp that applies only for NHDP. In that case, only these interfaces would be listed in the NHDP-MIB interface table, which is correct. The question is, do we still need a ifType=3Dmanet, and ifType=3Dn= hdp would be above the stack of ifType=3Dmanet? Best regards Ulrich On Wed, Jun 27, 2012 at 11:04 AM, Cole, Robert G CIV USARMY CERDEC (US) > wrote: Classification: UNCLASSIFIED Caveats: NONE Ulrich, One observation. I had proposed ifType=3Dmanet instead of type 'nhd= p' to designate an interface which would carry any MANET protocol (e.g., NHDP, AODV, OLSR, etc). As you point out, I believe the ifStackTable could be used to indicate that we wish to run 'manet' over ifType=3D802.3 or Ethernet or 802.11 or whatever. And that seems to me to be a reasonable approach. Then in the NHDP-MIB our nhdpIfTable would only contain rows for the interfaces that we are running manet protocols over, as indicated in the ifTable and ifStackTable. Bob -----Original Message----- From: Ulrich Herberg [mailto:ulrich@herberg.name] Sent: Wednesday, June 27, 2012 1:24 PM To: Thomas Nadeau Cc: Cole, Robert G CIV USARMY CERDEC (US); MIB Doctors (E-mail); Benoit Claise; adrian@olddog.co.uk Subject: Re: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED) Thomas, I understand now better how the ifType works, as defined in RFC2863. Essentially, we would request from IANA to allocate a new "MANET" IANAifType in http://www.iana.org/assignments/ianaiftype-mib I just want to make sure that this is the correct thing to do. A MANET interface is specified in RFC6130 as an interface that runs NHDP (i.e., a protocol above IP in the stack). I have the impression that most of the other ifType are below the IP layer. It would also imply that we have to add plenty of entries in the ifStackTable (MANET above 802.11, MANET above 802.15.4 etc), right? And it means that, e.g., DYMO/AODV (even though specified in the MANET WG) would not use the MANET ifType, because the reactive MANET protocol does not use NHDP. If all that is as intended, then we can go ahead and change it in the MIB-module. Thanks Ulrich On Wed, Jun 13, 2012 at 1:15 PM, Thomas Nadeau > wrote: On 6/13/12 4:02 PM, "Cole, Robert G CIV USARMY CERDEC (US)" > wrote: >Classification: UNCLASSIFIED >Caveats: NONE > >Tom, > > >-you wrote- > I appreciate the reference but my points from earlier still apply. >In the reference, I believe operationally you avoid entries that do not >have >the correct ifType for the Ipv4InterfaceEntry. Remember that if that were >not the case, then what you get is a direct one-to-one mapping of IPv4 >interfaces attributes for EVERY IfTable entry. This is a bad idea given >that there are a wide array of devices that have a small set of their >interfaces possessing IPv4 characteristics. > >RGC> I do not see in reading through the reference RFC 4293, how this >behavior is identified. I agree with you that this is desirable. I just >do >not see the mechanism that informs the implementer to scope the ifType. TOM: The reference doesn't explicitly say this, but that is how I believe its implemented. > > In your MIB you are effectively doing this. If you really wanted >that you should use AUGMENTS, but that doesn't seem like what you want. >The >simple way to correct this situation is to define an ifType for NHDP >interfaces and explicitly exclude non-NHDP interfaces from being returned. > This effectively "extends" - or more appropriately - "selectively >extends" >the IfTable entries. > >RGC> You are right; it is this later case and behavior we want to achieve. >Where do I define an ifType for NHDP interfaces? Also more generally, >should I be defining an ifType for MANET interfaces? You do this in an IANA section. Take a look at how we did this in RFC3811/12/13. It is pretty straight-forward. You can also see how to scope its use tightly to avoid scale issues. I think you would want an ifType for MANET - I was mistaken earlier when I said NHDP. --Tom > >Thanks, Bob > > > --Tom > > >> >>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=3Dmols >> 2, ifType=3Dmpls >> 3, ifType=3Dmanet ---------> 3 >> 4, ifType =3D manet ---------> 4 >> 5, ifType =3D 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=3Dmanet 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 >>> >>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 >> >> > > >Classification: UNCLASSIFIED >Caveats: NONE > > Classification: UNCLASSIFIED Caveats: NONE Classification: UNCLASSIFIED Caveats: NONE From robert.g.cole.civ@mail.mil Wed Jun 27 12:14:25 2012 Return-Path: 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 01FD811E80A5 for ; Wed, 27 Jun 2012 12:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, 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 g3u31IBsgvP1 for ; Wed, 27 Jun 2012 12:14:23 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.9]) by ietfa.amsl.com (Postfix) with ESMTP id C131D11E8086 for ; Wed, 27 Jun 2012 12:14:22 -0700 (PDT) Received: from UCOLHP3P.easf.csd.disa.mil (131.64.100.155) by ucolhp2w.easf.csd.disa.mil (131.64.100.9) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 27 Jun 2012 19:14:17 +0000 Received: from UCOLHP4J.easf.csd.disa.mil ([169.254.8.172]) by UCOLHP3P.easf.csd.disa.mil ([131.64.100.155]) with mapi id 14.02.0283.003; Wed, 27 Jun 2012 19:14:17 +0000 From: "Cole, Robert G CIV USARMY CERDEC (US)" To: Thomas Nadeau , Ulrich Herberg Thread-Topic: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED) Thread-Index: AQHNVImUSTnPFQ2MTQ6r8Xl0rB1SRJcOc2gAgAAFXwCAAARV0IAABjsAgAAAWACAAAU9MA== Date: Wed, 27 Jun 2012 19:14:16 +0000 Message-ID: References: In-Reply-To: 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_035F_01CD5477.85A18950" MIME-Version: 1.0 Cc: "MIB Doctors \(E-mail\)" , "adrian@olddog.co.uk" Subject: Re: [MIB-DOCTORS] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 19:14:25 -0000 ------=_NextPart_000_035F_01CD5477.85A18950 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Classification: UNCLASSIFIED Caveats: NONE Great, then it's a go :-) Bob -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@juniper.net] Sent: Wednesday, June 27, 2012 2:55 PM To: Ulrich Herberg; Cole, Robert G CIV USARMY CERDEC (US) Cc: MIB Doctors (E-mail); Benoit Claise; adrian@olddog.co.uk Subject: Re: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED) From: Ulrich Herberg > To: "Cole, Robert G CIV USARMY CERDEC (US)" > Cc: Thomas Nadeau >, "MIB Doctors (E-mail)" >, Benoit Claise >, "adrian@olddog.co.uk" > Subject: Re: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED) Bob, okay, that convinced me. Only slight disadvantage is that ifType=manet would not correspond to "MANET interface" according to RFC6130, but to all MANET protocols. The question would then be, how (and where) is the terminology defined for the "MANET interface that is not limited to NHDP"? Adrian, any advice on that? Thomas, would that solution be good for you? TOM: Yes. This is along the lines of what I suggested earlier. --Tom Best Ulrich On Wed, Jun 27, 2012 at 11:47 AM, Cole, Robert G CIV USARMY CERDEC (US) > wrote: Classification: UNCLASSIFIED Caveats: NONE Ulrich, I guess I lean towards your former option, i.e., "- introduce an ifType=manet that applies for all MANET protocols. In the NHDP-MIB, the interface table would only list ifType=manet. However, in case another MANET protocol (not NHDP) is used on an interface, that interface would still be listed in the NHDP-MIB interface table. I don't think that is what we want." Then the nhdpIfStatus object would be defined to indicate whether or not NHDP is configured to run over that interface. And type 'manet' would restrict the total list of interfaces. Then looking forward to the SMF-MIB, where SMF does not require NHDP to operate, the smfInterfaceTable's smfIfAdminStatus would have a comparable semantic, i.e., "smfIfAdminStatus OBJECT-TYPE SYNTAX SmfStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The SMF interface's administrative status. The value 'enabled' denotes that the interface is running the SMF forwarding process. The value 'disabled' denotes that the interface is external to the SMF forwarding process. " ::= { smfInterfaceEntry 3 } " This would generally hold true for other manet control protocols, e.g., DSR, AODV, etc Bob -----Original Message----- From: Ulrich Herberg [mailto:ulrich@herberg.name] Sent: Wednesday, June 27, 2012 2:16 PM To: Cole, Robert G CIV USARMY CERDEC (US) Cc: Thomas Nadeau; MIB Doctors (E-mail); Benoit Claise; adrian@olddog.co.uk Subject: Re: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED) Bob, we have to be careful how to name the ifType, since RFC6130 defines a "MANET interface" as: "An interface participating in a MANET and using this neighborhood discovery protocol", i.e. it is specific to the usage of NHDP. Therefore, if we choose ifType=manet, but actually mean every MANET routing protocol (incl. DYMO), that may be confusing. I wonder if it was a good idea to linking "MANET interface" specifically for usage of NHDP in RFC6130... but it's too late to change it. I see several options: - introduce an ifType=manet that applies for all MANET protocols. In the NHDP-MIB, the interface table would only list ifType=manet. However, in case another MANET protocol (not NHDP) is used on an interface, that interface would still be listed in the NHDP-MIB interface table. I don't think that is what we want. - introduce an ifType=nhdp that applies only for NHDP. In that case, only these interfaces would be listed in the NHDP-MIB interface table, which is correct. The question is, do we still need a ifType=manet, and ifType=nhdp would be above the stack of ifType=manet? Best regards Ulrich On Wed, Jun 27, 2012 at 11:04 AM, Cole, Robert G CIV USARMY CERDEC (US) > wrote: Classification: UNCLASSIFIED Caveats: NONE Ulrich, One observation. I had proposed ifType=manet instead of type 'nhdp' to designate an interface which would carry any MANET protocol (e.g., NHDP, AODV, OLSR, etc). As you point out, I believe the ifStackTable could be used to indicate that we wish to run 'manet' over ifType=802.3 or Ethernet or 802.11 or whatever. And that seems to me to be a reasonable approach. Then in the NHDP-MIB our nhdpIfTable would only contain rows for the interfaces that we are running manet protocols over, as indicated in the ifTable and ifStackTable. Bob -----Original Message----- From: Ulrich Herberg [mailto:ulrich@herberg.name] Sent: Wednesday, June 27, 2012 1:24 PM To: Thomas Nadeau Cc: Cole, Robert G CIV USARMY CERDEC (US); MIB Doctors (E-mail); Benoit Claise; adrian@olddog.co.uk Subject: Re: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED) Thomas, I understand now better how the ifType works, as defined in RFC2863. Essentially, we would request from IANA to allocate a new "MANET" IANAifType in http://www.iana.org/assignments/ianaiftype-mib I just want to make sure that this is the correct thing to do. A MANET interface is specified in RFC6130 as an interface that runs NHDP (i.e., a protocol above IP in the stack). I have the impression that most of the other ifType are below the IP layer. It would also imply that we have to add plenty of entries in the ifStackTable (MANET above 802.11, MANET above 802.15.4 etc), right? And it means that, e.g., DYMO/AODV (even though specified in the MANET WG) would not use the MANET ifType, because the reactive MANET protocol does not use NHDP. If all that is as intended, then we can go ahead and change it in the MIB-module. Thanks Ulrich On Wed, Jun 13, 2012 at 1:15 PM, Thomas Nadeau > wrote: On 6/13/12 4:02 PM, "Cole, Robert G CIV USARMY CERDEC (US)" > wrote: >Classification: UNCLASSIFIED >Caveats: NONE > >Tom, > > >-you wrote- > I appreciate the reference but my points from earlier still apply. >In the reference, I believe operationally you avoid entries that do not >have >the correct ifType for the Ipv4InterfaceEntry. Remember that if that were >not the case, then what you get is a direct one-to-one mapping of IPv4 >interfaces attributes for EVERY IfTable entry. This is a bad idea given >that there are a wide array of devices that have a small set of their >interfaces possessing IPv4 characteristics. > >RGC> I do not see in reading through the reference RFC 4293, how this >behavior is identified. I agree with you that this is desirable. I just >do >not see the mechanism that informs the implementer to scope the ifType. TOM: The reference doesn't explicitly say this, but that is how I believe its implemented. > > In your MIB you are effectively doing this. If you really wanted >that you should use AUGMENTS, but that doesn't seem like what you want. >The >simple way to correct this situation is to define an ifType for NHDP >interfaces and explicitly exclude non-NHDP interfaces from being returned. > This effectively "extends" - or more appropriately - "selectively >extends" >the IfTable entries. > >RGC> You are right; it is this later case and behavior we want to achieve. >Where do I define an ifType for NHDP interfaces? Also more generally, >should I be defining an ifType for MANET interfaces? You do this in an IANA section. Take a look at how we did this in RFC3811/12/13. It is pretty straight-forward. You can also see how to scope its use tightly to avoid scale issues. I think you would want an ifType for MANET - I was mistaken earlier when I said NHDP. --Tom > >Thanks, Bob > > > --Tom > > >> >>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 >>> >>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 >> >> > > >Classification: UNCLASSIFIED >Caveats: NONE > > Classification: UNCLASSIFIED Caveats: NONE Classification: UNCLASSIFIED Caveats: NONE Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_035F_01CD5477.85A18950 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIS3DCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEwTCCA6mgAwIBAgIDDNszMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQwHhcNMTAwMjI1MDAwMDAwWhcN MTMwMjI0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1DT0xFLlJP QkVSVC5HUkFOT1QuMTM2NjU2MDM5MDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKU7 jo5hPKcK6V92Cni9Bu445V7UQJBLIu1eX3brV/yB6uFNd+lIdV5n6RBpE1QcsIUEyS1GVDvTR/Qs kbUInPJC8ioZCX/V5Y2J8nRNidXoLX4SdeQ3Gc6jLPn+1W8KHRdATHy+SYGcrHnePyRAhTO73rN3 97CqgOaxnS4wo/Eanw9Re5UGq70cN/G7376Oxa7A2xdtY9w8gLUilFmcYXuwR7FGxcnDhsqAW3fv tgM18ZWn/hioEhmRZz514jXPnHCvSPAkofjb4Mjucnku8uNowu+PMw5Yqv9wimBEitvQGPnyac41 MNtsflnmVqWswTwhzVzIGdodKZTw2h6byTcCAwEAAaOCAWwwggFoMB8GA1UdIwQYMBaAFFSqcyrH s3fqzSJAeUh7EfunmSKCMD8GA1UdHwQ4MDYwNKAyoDCGLmh0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0 Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMjQwDgYDVR0PAQH/BAQDAgUgMCMGA1UdIAQcMBowCwYJYIZI AWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUyGOLOF3I71SMIzwNIujoox8W0CowbQYIKwYB BQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3JsLmRpc2EubWlsL2dldHNpZ24/RE9EJTIw RU1BSUwlMjBDQS0yNDAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwJAYDVR0RBB0w G4EZcm9iZXJ0LmcuY29sZUB1cy5hcm15Lm1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVT MA0GCSqGSIb3DQEBBQUAA4IBAQAVD+rqDKxhGbV78baC+EUC3jiDUO6C41wsmB4ckt5akJPvVrB4 mjlnoG0lm19qovC98eO0vPQMUx1F6/jP9/xg32W2Ks2HZUR3ipZWBEqVi8i20Wz4sVFgXHkJjoP5 bju0XvJk/d6wze65iZqFuILuPplugaHg7iC5B/NAMELTGx8hoK3LVqmIIyMpEFlrxTygIkyuI+NK IqcbLtBOEW0bP7TNyBh/VShmtrXAtpPP0AAi+kaUURcG1x2xdPCR3cD2bjWYkfxQYeZRl2zTuOMg Mpr9pG3MuImao/C+v6IaXGuAU8xS8hSEbHGNLrXjJ9UIxw0K45WxjR7CrPFIJ4R5MIIFDDCCA/Sg AwIBAgIDDNswMA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjQwHhcNMTAwMjI1MDAwMDAwWhcNMTMwMjI0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UE CxMDVVNBMSYwJAYDVQQDEx1DT0xFLlJPQkVSVC5HUkFOT1QuMTM2NjU2MDM5MDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOsVn1k8Ax7kkzWXvrNf7oI7iy5zEeLACdGKrODL9riDBNUF HvD4JtafUcwq03s4Daq0tscNL8J1ONDeML5s0X8UeNfCyexrkSpPwY9g/zVO6mJmG4OunTz/7fc2 G0ZR64VYlEBZeQ88JIMIs6bYXiO9SxuOCS47aGx/CGqdpFwt713bBAQvzAjLUSWBvjZN2bviTQrY wAg1/1AnlxY6Zl4YPBSV9c1TbtTQNjbRyFRabiqNMh0XaQ0ZHxQgsGOqNwfyMlmadL2m3ILhKpFh oMfOV01at2eDj8+wFvDXLXAL1f3HAQKv5W5GEoBYNDqp/ULDBJcXVPT8mYWzxMkca/MCAwEAAaOC AbcwggGzMB8GA1UdIwQYMBaAFFSqcyrHs3fqzSJAeUh7EfunmSKCMD8GA1UdHwQ4MDYwNKAyoDCG Lmh0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMjQwDgYDVR0PAQH/ BAQDAgbAMCMGA1UdIAQcMBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUBeVx RkqbKuf17SKV2ZZOsCXLQ+gwbQYIKwYBBQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3Js LmRpc2EubWlsL2dldHNpZ24/RE9EJTIwRU1BSUwlMjBDQS0yNDAgBggrBgEFBQcwAYYUaHR0cDov L29jc3AuZGlzYS5taWwwRAYDVR0RBD0wO4EZcm9iZXJ0LmcuY29sZUB1cy5hcm15Lm1pbKAeBgor BgEEAYI3FAIDoBAMDjEzNjY1NjAzOTBAbWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMw KQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUA A4IBAQBhwXMphuaV+lhIZbI35yGpZ7zy/uXNyr41+/dibahnAIisIIHFSTeEk9GFepxqV45hagTo //0UycQ/ShOIHzV/+u3l/97k+l8imMdbjhgklb2UFROSz7TJzhO3w4S7g7DpU+GTxE2Uax+iD2t0 Bmio3ut9fr/dWvi6OTYVFMTW7M6pd8gOPqmg8ADGdljGsSotMAhXzFJgAPtnsca5HfyYpGi0NQj0 ucT/sWUGwnnjlqtYyP+SY2pOPpbN9gACkv8UKJMkik5GEFobaHbI8KWr4FFOXAIAauW1DvGFq5Pe WdDgj39r6PkdOLg3v+B9/hnkP6uOyH5Oi9pcHb+d/hPuMIIFjzCCBHegAwIBAgIBRTANBgkqhkiG 9w0BAQUFADBbMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQL EwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNRG9EIFJvb3QgQ0EgMjAeFw0wOTAxMjYyMDI2 MTVaFw0xNTAxMjUyMDI2MTVaMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1l bnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQClLlh6od7mmlv2AvHV1Nw1I5p7bihkdBpw PJYdzMKfdAQ8DDmSIQgNEk6g1zeo0snGJ50o+lXXshcEGc4yvPB5nvVoqy7MzzcEsvgKZZpJIBQl wbwSaqBCbRsItIehQiKrE5naAgE5H14IV2tg3hN+aGp+QfWJgDh6/Zey0uKWSzaAYrbsJbvQD6ej zVGo99J5VZA0JqPkXM27aCZ0CTeh5q/N5D6ZR/9/wke8ZYS6MimjDvDColt66rJKfQvGw26svRB/ T6l2Oj0CASwqMLT3yKDSmDp8CNBaiQ+1ioL6DTAeftbRx7ZDJ7EoqQzjswd432JkmkWMTs2vDq6c WDbfAgMBAAGjggJaMIICVjAOBgNVHQ8BAf8EBAMCAYYwHwYDVR0jBBgwFoAUSXS7DF66ev4CVO97 oMaVxgmAcJYwHQYDVR0OBBYEFFSqcyrHs3fqzSJAeUh7EfunmSKCMAwGA1UdJAQFMAOAAQAwEgYD VR0TAQH/BAgwBgEB/wIBADCBnwYDVR0gBIGXMIGUMAsGCWCGSAFlAgELBTALBglghkgBZQIBCwkw CwYJYIZIAWUCAQsKMAsGCWCGSAFlAgELEjALBglghkgBZQIBCxMwCwYJYIZIAWUCAQsUMAwGCmCG SAFlAwIBAwYwDAYKYIZIAWUDAgEDBzAMBgpghkgBZQMCAQMIMAwGCmCGSAFlAwIBAw0wDAYKYIZI AWUDAgEDETA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLmRpc2EubWlsL2dldGNybD9Eb0Ql MjBSb290JTIwQ0ElMjAyMIH+BggrBgEFBQcBAQSB8TCB7jA/BggrBgEFBQcwAoYzaHR0cDovL2Ny bC5kaXNhLm1pbC9nZXRJc3N1ZWRUbz9Eb0QlMjBSb290JTIwQ0ElMjAyMCAGCCsGAQUFBzABhhRo dHRwOi8vb2NzcC5kaXNhLm1pbDCBiAYIKwYBBQUHMAKGfGxkYXA6Ly9jcmwuZ2RzLmRpc2EubWls L2NuJTNkRG9EJTIwUm9vdCUyMENBJTIwMiUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNkVS5T LiUyMEdvdmVybm1lbnQlMmNjJTNkVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwDQYJKoZIhvcNAQEF BQADggEBAHIW3DlzY02T6Tccz7LtnNhN9wwySomes8q68wSscWYxpiq9un1U2C8JY0qICOhsE6Hs XntWFzAtyNLt141HRGnPEW/L2OdSdbVRyKodafAZHzDwB8c2vc4M3jt2/QrOy7YTutaFi/FcEpHK r+h/EqisLYvWdlCU7Db6ow/fxjLqx3NG/IQami/E6CccSMJGNvYX7O1nMg+4ouC30l6QBhOUIWFD bH3zO2tl7ePbqP/Fm7KS5+tf7u+/8zmMs/UX0obVw2xKOmw/nq/oWx02W6YmFUYLRmvH1ICq564c uCtO+iFyn1+fga+07lvJlymJfOnceOJO4HSf0oZ4ZqLHmKgxggL+MIIC+gIBATBkMF0xCzAJBgNV BAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMD UEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQCAwzbMDAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA2MjcxOTE0MThaMCMGCSqGSIb3 DQEJBDEWBBTfcqGbqPv+9C78CU9HTeiYIrfPGDAkBgkqhkiG9w0BCQ8xFzAVMAoGCCqGSIb3DQMH MAcGBSsOAwIaMHMGCSsGAQQBgjcQBDFmMGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJ TCBDQS0yNAIDDNszMHUGCyqGSIb3DQEJEAILMWagZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMP VS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9E IEVNQUlMIENBLTI0AgMM2zMwDQYJKoZIhvcNAQEBBQAEggEAfQRCmLbBURKD6Ip86fwJCyhOr+k7 pmx1xPVUp/fmg9/+L0cp+UI6B5kN7IH7As+Y6EE3f1uBOp6JaE/Ms2MVR3legEe5qu5Vae8/hpZB p72fE3YU6rRaLg5phP2RVEFe9jePV/typxNfOXoLZBEaexXxcdUunYBjqWQxNC9WOrcmUBcgvbFg cD8HhRNBw/vJrHFPAqKc9CLWCuT9H+CfLwiFT8KnKggMcKw/tUffHgZO9NnmAzU2KkMGiOV9D36K zGlbzMJQ5y22tlovyJ1SCTYUfhogHKw+9jzPoWaWukTm3/p/dU5WSnCQM16ys3NjrVPOzVTEMg8R 90mEErCQoQAAAAAAAA== ------=_NextPart_000_035F_01CD5477.85A18950--