From ma-miyazawa@kddilabs.jp Mon Jan 31 19:01:03 2011 Return-Path: X-Original-To: mib-doctors@core3.amsl.com Delivered-To: mib-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 702BE3A6A86; Mon, 31 Jan 2011 19:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 905i2IHCtNjT; Mon, 31 Jan 2011 19:01:02 -0800 (PST) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by core3.amsl.com (Postfix) with ESMTP id E1BB63A68F1; Mon, 31 Jan 2011 19:01:00 -0800 (PST) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id C1AFF17480C4; Tue, 1 Feb 2011 12:04:11 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCUoOU2vrXiT; Tue, 1 Feb 2011 12:04:11 +0900 (JST) Received: from platinum.inc.kddilabs.jp (platinum.inc.kddilabs.jp [IPv6:2001:200:601:1300:172:19:83:254]) by mandala.kddilabs.jp (Postfix) with ESMTP id E65A51748198; Tue, 1 Feb 2011 12:04:08 +0900 (JST) Received: from miyazawaPC (ebisu.kddilabs.jp [IPv6:2001:200:601:11::214]) by platinum.inc.kddilabs.jp (Postfix) with ESMTP id 382C7578063; Tue, 1 Feb 2011 12:04:05 +0900 (JST) From: "Masanori Miyazawa" To: "'Joan Cucchiara'" , , "'MIB Doctors (E-mail)'" , "'Tomohiro Otani'" , , "'Thomas D. Nadeau'" References: <00ce01cbb34d$e6aa1130$6501a8c0@JoanPC> In-Reply-To: <00ce01cbb34d$e6aa1130$6501a8c0@JoanPC> Date: Tue, 1 Feb 2011 12:04:07 +0900 Message-ID: <005b01cbc1bc$b27733c0$17659b40$@jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuzTjblYmPrL3F6QjW5rXXyAGGNPAOYfF2Q Content-Language: ja X-Mailman-Approved-At: Tue, 01 Feb 2011 02:43:36 -0800 Subject: Re: [MIB-DOCTORS] MIB Dr. review of draft-ietf-ccamp-gmpls-ted-mib-07 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 03:01:03 -0000 Hi, Joan Thank you for your review in this doc. According to your comments, I think we will revise the document. Thank you Masanori > -----Original Message----- > From: Joan Cucchiara [mailto:jcucchiara@mindspring.com] > Sent: Friday, January 14, 2011 3:16 AM > To: ccamp@ietf.org; MIB Doctors (E-mail); Tomohiro Otani; Masanori > Miyazawa; ke-kumaki@kddilabs.jp; Thomas D. Nadeau > Cc: Joan Cucchiara; Dan Romascanu (E-mail) > Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-ted-mib-07 > > > Hi Masonori, > > Thank you for the new version of this document. There were many good > updates, particularly, the Conformance section. > > Please see following comments. > > Thanks, > -Joan > > > > COMPILER RESULTS > ------------------------------ > * MIB compiles cleanly with smicngPRO > > * MIB compiles cleanly with smiLint > > > DOCUMENT COMMENTS > ------------------------------------- > *) NIT: Does not strip cleanly with smicPRO's mstrip. > (This does not have to be fixed for MIB Dr. purposes, > only mention as an fyi.) > > > *) Author contact info needs to be updated. > > *) Dates and copyright need to be updated > > *) RFC references probably need to be updated. > > RFC3784 was obsoleted by RFC5305 > RFC4205 was obsoleted by RFC5307 > > IANA-GMPLS-TC-MIB needs to be added to Informative Reference Section. > > > > > *) 2. Introduction > > Since this document supports both OSPFv2 and OSPFv3, please > say this explicitly. > > *) The following 2 RFCs should be referenced also. > > a. OSPFv3 MIB is defined in rfc5643 > b. TE extensions to OSPFv3 are described in RFC5329 > > > > *) 3.3 Acronyms > > These should be in alphabetical order (or some order that > is defined at the beginning of this subsection.) > > Should include TED: Traffic Engineering Database > > > > *) Section 4. Motivations > > The motivation statement leads one to believe that this > document will provide "for the management of all of the > extensions to the OSPF and ISIS protocol.". > > There are 2 inconsistencies here: > a) Since this is a read-only MIB, (no configuration) then the > statement should be revised because management includes configuration. > b) As previously mentioned, the use of OSPF and then references > to OSPFv2 is misleading, please use OSPFv2, and include OSPFv3 > along with relevant documents. > > > *) Section 5.1 > > s/information of/information for/ > > > *) Section 5.3 > > s/This is also independently utilized,because/Also, this is utilized > independently > because/ > > > *) Section 5.4 > > This is referred to as Switch Capable and also > as Switching Capability, please be consistent. If SwCap is > supposed to be Switching Capability, then please use that > Switching Capablity consistently. > > > > > > COMMENTS ON MIB MODULE > -------------------------------------------- > > > *) TEXTUAL-CONVENTIONS > > The names of these TCs are already used in the OSPFv2 MIB > and while this may have been done intentionally, would prefer > a TED specific name. > > For example: > > RouterID, AreaID, LinkStateID are used in OSPFv2-MIB (RFC4750) > > Could these be renamed to be prefixed with "Ted" > and suffixed with "TC", such as TedRouterIdTC" ? > > > > > *) tedCreateDeleteNotificationMaxRate and > tedStatusChangeNotificationMaxRate > > a) Why are these objects not located closer to the Notifications? > > b) tedCreateDeleteNotificationMaxRate, has a DEFVAL {0}. The DESCRIPTION > clause > does not indicate that 0 has a special value (as it does for > tedStatusChangeNotificationMaxRate, > so just want to check on this? Do you really mean 0 here? > > *) tedInfoStatus object > > I think there is still some confusion about my request for status/state > information. > Obviously, if there are rows in these tables, then > the MIB has been configured by some means other than SNMP, and granted > notifications are sent (unless > they are dropped due to throttling or lost), but what is the Operational > Status > link? > > The RowPointer object, tedLinkInformationData, might provide this > information, however, > the DESCRIPTION clause makes it sound completely optional since it looks > like 0.0 > can be entered under any circumstance, so again, I have to ask, how is an > operator > supposed to know if the TE link is acting as intended? > > If tedLinkInformationData is supposed to provide this, then it needs to > be > rewritten to > be mandatory. That means that there are dependencies on other MIBs also. > That is > unclear in this document. > > In summary, tedInfoStatus object does not provide any additional > information, as > I can see if the MIB is populated. What I'm asking for is Operational > Status/State > information. > > > Please discuss. > > > *) tedSwCapSwitchingType > > Please rename to tedSwCapType. > > > > > *) tedNotificationAreaId and tedNotificationRouterId > > Not sure why these are needed. Couldn't you include > an object from the tedTable (such as tedLinkInformationSource) > rather than have these accessible for Notify objects. Seems like > extra work on all parts and not sure I see the advantage when > you already have this info in a table. > > Please discuss. > > > > *) 8. Security Considerations > > s/read-write../read-write./ > > *) 10.1 Normative References > > a) Some of the Informative References should > probably moved to Normative, specifically, any of the MIB > docs that are IMPORTED or appear in a REFERENCE clause. > > > *) 10.2 Informative References > > a) NIT: should be listed in increasing RFC Order. > From dromasca@avaya.com Fri Feb 11 02:42:05 2011 Return-Path: X-Original-To: mib-doctors@core3.amsl.com Delivered-To: mib-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0DD43A69DD; Fri, 11 Feb 2011 02:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.388 X-Spam-Level: X-Spam-Status: No, score=-102.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeB1vlvIRSRj; Fri, 11 Feb 2011 02:42:04 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 65DE03A694F; Fri, 11 Feb 2011 02:42:03 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL6hVE2HCzI1/2dsb2JhbACldXOicQKZDIMdgj8Ej0iCcg X-IronPort-AV: E=Sophos;i="4.60,454,1291611600"; d="scan'208";a="231941379" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Feb 2011 05:42:14 -0500 X-IronPort-AV: E=Sophos;i="4.60,454,1291611600"; d="scan'208";a="598383733" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Feb 2011 05:42:13 -0500 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: Fri, 11 Feb 2011 11:42:02 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package of the February 17, 2011 IESG Teleconference Thread-Index: AcvJeSItu6QAh6cmSkyNXunF0bCz7gAXtbug From: "Romascanu, Dan (Dan)" To: , , "YANG Doctors" , , "IETF DNS Directorate" Subject: [MIB-DOCTORS] FW: PRELIMINARY Agenda and Package of the February 17, 2011 IESG Teleconference X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 10:42:05 -0000 Please find below the preliminary agenda of the 2/17 IESG telechat.=20 Please send me your questions, comments and concerns about the document brought up for approval before 2/16 COB.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary .... 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-tsvwg-iana-ports-09 Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry (BCP) Note: AD review comments will be addressed after IETF LC.Gorry Fairhurst (gorry@erg.abdn.ac.uk) is the document shepherd. Token: Alexey Melnikov o draft-ietf-isis-ieee-aq-04 IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging (Proposed Standard) Note: David Ward (dward@juniper.net) is the document shepherd. Token: Stewart Bryant o draft-ietf-6man-prefixlen-p2p-01 Using 127-bit IPv6 Prefixes on Inter-Router Links (Proposed Standard) Note: Bob Hinden (bob.hinden@gmail.com) is the document shepherd. Token: Jari Arkko o draft-ietf-isis-reg-purge-00 IS-IS Registry Extension for Purges (Proposed Standard) Note: David Ward (dward@juniper.net) is the document shepherd. Token: Stewart Bryant o draft-ietf-isis-purge-tlv-05 Purge Originator Identification TLV for IS-IS (Proposed Standard) Note: David Ward (dward@juniper.net) is the document shepherd. Token: Stewart Bryant o draft-ietf-pim-registry-04 A Registry for PIM Message Types (Proposed Standard) Note: Mike McBride (mmcbride@cisco.com) is the document shepherd. Token: Adrian Farrel 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items o draft-turner-akf-algs-update-02 Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type (Proposed Standard) Note: Sean Turner (turners@ieca.com) is the document Shepherd. Token: Tim Polk o draft-turner-ekpct-algs-update-02 Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type (Proposed Standard) Note: Sean Turner (turners@ieca.com) is the document Shepherd. Token: Tim Polk o draft-arkko-dual-stack-extra-lite-05 Scalable Operation of Address Translators with Per-Interface Bindings (Proposed Standard) Token: Ralph Droms o draft-cheshire-dnsext-special-names-01 Special-Use Domain Names (Proposed Standard) Token: Ralph Droms 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-mipshop-transient-bce-pmipv6-07 Transient Binding for Proxy Mobile IPv6 (Experimental) Note: Vijay Devarapalli (vijay@wichorus.com) is the Document Shepherd Token: Jari Arkko o draft-ietf-pce-inter-layer-req-15 PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering (Informational) Note: Julien Meuric (julien.meuric@orange-ftgroup.com) is the document shepherd. Token: Stewart Bryant o draft-ietf-intarea-shared-addressing-issues-03 Issues with IP Address Sharing (Informational) Note: Julien Laganier (julienl@qualcomm.com) is the document shepherd. Token: Jari Arkko o draft-ietf-ccamp-rwa-wson-framework-12 Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) (Informational) Note: Lou Berger (lberger@labn.net) is the document shepherd. Token: Adrian Farrel 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-mraihi-totp-timebased-07 TOTP: Time-based One-time Password Algorithm (Informational) Note: Hannes Tschofenig (Hannes.Tschofenig@gmx.net) is the document shepherd. Token: Sean Turner o draft-eastlake-sha2b-06 US Secure Hash Algorithms (SHA and SHA based HMAC and HKDF) (Informational) Note: I agreed to sponsor this document since I was the sponsor for RFC 4634. Token: Russ Housley o draft-ymbk-aplusp-08 The A+P Approach to the IPv4 Address Shortage (Experimental) Token: Ron Bonica 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items o draft-irtf-rrg-design-goals-06 Design Goals for Scalable Internet Routing (Informational) Note: Independent submission via IRTF. Joel Halpern (jmh@joelhalpern.com) is the document shepherd. Token: Jari Arkko o draft-irtf-dtnrg-sdnv-08 Using Self-Delimiting Numeric Values in Protocols (Informational) Note: IRTF Submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd. Token: Ralph Droms o draft-irtf-dtnrg-bundle-security-17 Bundle Security Protocol Specification (Experimental) Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd. Token: Sean Turner o draft-irtf-dtnrg-bundle-metadata-block-09 Delay-Tolerant Networking Metadata Extension Block (Experimental) Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd. Token: Peter Saint-Andre o draft-irtf-dtnrg-bundle-previous-hop-block-12 Delay-Tolerant Networking Previous Hop Insertion Block (Experimental) Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd. Token: Tim Polk o draft-irtf-dtnrg-iana-bp-registries-01 Delay-Tolerant Networks (DTN) Bundle Protocol IANA Registries (Informational) Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd. Token: Jari Arkko From dromasca@avaya.com Tue Feb 22 09:26:03 2011 Return-Path: X-Original-To: mib-doctors@core3.amsl.com Delivered-To: mib-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 300543A696A; Tue, 22 Feb 2011 09:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.91 X-Spam-Level: X-Spam-Status: No, score=-101.91 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_46=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdtYNhVXKbLh; Tue, 22 Feb 2011 09:26:02 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 07ACE3A6966; Tue, 22 Feb 2011 09:26:01 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPOAY02HCzI1/2dsb2JhbACmF3OlCwKZJoVeBI9o X-IronPort-AV: E=Sophos;i="4.62,207,1297054800"; d="scan'208";a="60256634" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 22 Feb 2011 12:26:27 -0500 X-IronPort-AV: E=Sophos;i="4.62,207,1297054800"; d="scan'208";a="603695799" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 Feb 2011 12:25:52 -0500 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: Tue, 22 Feb 2011 18:25:33 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: netconf / snmp informal meeting in Prague Thread-Index: AcvStYKs6ZgiM0ecQAy/kmOso/M5cQ== From: "Romascanu, Dan (Dan)" To: , "YANG Doctors" Subject: [MIB-DOCTORS] netconf / snmp informal meeting in Prague X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 17:26:03 -0000 Andy Bierman suggested that we gather in Prague with the best experts in NETCONF/NETMOD and SNMP.=20 His initial problem statement included (and he may want to add or correct, but I am using words from two of his mails): -------------- I want to make standards and implementation progress on retrieving MIB data through NETCONF, and exploring other integration points, such as locking. IMO we should finish up the draft, and get the details finalized. I am also interested in getting yuma to use the output of smidump to implement MIB.yang modules that are compatible with net-snmp. But I think it helps move us forward if we can show our standards working in running open-source code. Reverse-engineering the standard from the tool helps get that done :-) My concern is that we are approaching the entire problem space in a fragmented and disjoint manner. That's the nature of lots of WGs and work items within those WGs. We are kind of ignoring the multi-protocol architecture. A standard plan for if/how SNMP, SYSLOG, NETCONF, CLI/SSH, SMIv2, and YANG all work together to allow application developers to get the most 'bang for the buck' out of these IETF + industry standards. I really like how the COaP plan of implementing open-source along with the documents. That really helped YANG. We should do that for more drafts. The SNMP integration is important to me. NETCONF is not going to reinvent device instrumentation. It will be a convergence point to access CLI show command data, SNMP data, and some new data. The smidump -fyang output is critical to ease of this integration. I hope an open-source yuma + net-snmp implementation will help work out the operational problems. (IMO, just read+notify at first). ----------------- The plan is to get together on Sunday night and go out for dinner after the Welcome Reception. To avoid the noise in restaurant I would like to get a count of people participating and try to book a restaurant with a separate room. So please RSVP to me if you plan to attend. I thought MIB Doctors and YANG Doctors lists are a good starting point, but in case somebody is missing please forward.=20 Thanks and Regards,=20 Dan From dromasca@avaya.com Thu Feb 24 23:17:00 2011 Return-Path: X-Original-To: mib-doctors@core3.amsl.com Delivered-To: mib-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 002833A6925; Thu, 24 Feb 2011 23:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gfmss0Kc94Ww; Thu, 24 Feb 2011 23:16:59 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id D4FA13A692F; Thu, 24 Feb 2011 23:16:54 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADrmZk2HCzI1/2dsb2JhbACmO3SkBgKZMYJ/gmEEj3U X-IronPort-AV: E=Sophos;i="4.62,224,1297054800"; d="scan'208";a="234108342" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Feb 2011 02:17:44 -0500 X-IronPort-AV: E=Sophos;i="4.62,224,1297054800"; d="scan'208";a="605294388" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 25 Feb 2011 02:17:43 -0500 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: Fri, 25 Feb 2011 08:17:30 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the March 3, 2011 Telechat Thread-Index: AcvUf1egQMDPTbyiQ9qe5Om3iB5y+gAOc9nA From: "Romascanu, Dan (Dan)" To: "IETF DNS Directorate" , , , , "YANG Doctors" Subject: [MIB-DOCTORS] FW: PRELIMINARY Agenda and Package for the March 3, 2011 Telechat X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 07:17:00 -0000 =20 Please find below the preliminary agenda of the 3/3 IESG telechat. Please send me your comments, questions and concerns related to the documents and WG charters on the agenda before 3/2 COB.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary ... 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-netconf-rfc4742bis-07 Using the NETCONF Configuration Protocol over Secure Shell (SSH) (Proposed Standard) Note: Mehmet Ersue (mehmet.ersue@nsn.com) is the document shepherd. Token: Dan Romascanu o draft-ietf-netconf-4741bis-09 Network Configuration Protocol (NETCONF) (Proposed Standard) Note: Bert Wijnen (bertietf@bwijnen.net) is the document shepherd. Token: Dan Romascanu o draft-ietf-hokey-ldn-discovery-06 The Local Domain Name DHCPv6 Option (Proposed Standard) Note: The document shepherd is Tina Tsou Token: Tim Polk o draft-ietf-payload-rfc4695-bis-01 RTP Payload Format for MIDI (Proposed Standard) Note: Roni Even (even.roni@huawei.com) is the document shepherd. Token: Robert Sparks 2.1.2 Returning Items o draft-ietf-sipcore-199-05 Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog (Proposed Standard) Note: Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com) is the document shepherd. Token: Robert Sparks 2.2 Individual Submissions 2.2.1 New Items o draft-holsten-about-uri-scheme-06 The 'about' URI scheme (Proposed Standard) Token: Alexey Melnikov o draft-bryan-metalinkhttp-20 Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP Header Fields (Proposed Standard) Token: Alexey Melnikov Was deferred by Alexey Melnikov on 2011-02-17 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-speermint-voipthreats-07 Session Peering for Multimedia Interconnect (SPEERMINT) Security Threats and Suggested Countermeasures (Informational) Note: Jason Livingood (Jason_Livingood@cable.comcast.com) is the document shepherd. Token: Gonzalo Camarillo o draft-ietf-6lowpan-usecases-09 Design and Application Spaces for 6LoWPANs (Informational) Note: Geoff Mulligan (geoff.ietf@mulligan.com)is the document shepherd. Token: Ralph Droms o draft-ietf-hip-over-hip-05 Host Identity Protocol Signaling Message Transport Modes (Experimental) Note: Gonzalo Camarillo (gonzalo.camarillo@ericsson.com) is the document shepherd Token: Ralph Droms o draft-ietf-hip-cert-09 Host Identity Protocol Certificates (Experimental) Note: Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com) is the document shepherd. Token: Ralph Droms 3.1.2 Returning Items o draft-ietf-v6ops-v6-in-mobile-networks-03 Mobile Networks Considerations for IPv6 Deployment (Informational) Note: Fred Baker (fred@cisco.com) is the document shepherd. Token: Ron Bonica 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-mraihi-mutual-oath-hotp-variants-13 OCRA: OATH Challenge-Response Algorithms (Informational) Note: Hannes Tschofenig (Hannes.Tschofenig@gmx.net) is the document shepherd. Token: Sean Turner Was deferred by Tim Polk on 2011-02-08 o draft-meadors-multiple-attachments-ediint-10 Multiple Attachments for EDIINT (Informational) Token: Alexey Melnikov o draft-josefsson-rc4-test-vectors-02 Test vectors for the stream cipher RC4 (Informational) Note: Simon Josefsson (simon@josefsson.org) is the Document Shepherd. Token: Sean Turner o draft-mrw-nat66-07 IPv6-to-IPv6 Network Prefix Translation (Experimental) Token: Ron Bonica 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items NONE 3.3.2 Returning Items NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o Verification Involving PSTN Reachability (vipr) Token: Robert Sparks o Address Resolution for Massive numbers of hosts in the Data center (armd) Token: Ron Bonica 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review o DNS Extensions (dnsext) Token: Ralph Droms 4.2.2 Proposed for Approval NONE ------------------------------------------------------------------------ From biermana@Brocade.com Fri Feb 25 10:18:55 2011 Return-Path: X-Original-To: mib-doctors@core3.amsl.com Delivered-To: mib-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA2283A67EE; Fri, 25 Feb 2011 10:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.786 X-Spam-Level: X-Spam-Status: No, score=-0.786 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_34=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L978x6z7Mmzt; Fri, 25 Feb 2011 10:18:55 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by core3.amsl.com (Postfix) with ESMTP id DA5653A67F2; Fri, 25 Feb 2011 10:18:54 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p1PIHWXk004482; Fri, 25 Feb 2011 10:19:45 -0800 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0b-000f0801.pphosted.com with ESMTP id upe1q06kr-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 25 Feb 2011 10:19:44 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 25 Feb 2011 10:26:49 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Fri, 25 Feb 2011 10:19:43 -0800 From: Andy Bierman To: "Romascanu, Dan (Dan)" , "mib-doctors@ietf.org" , YANG Doctors Date: Fri, 25 Feb 2011 10:19:41 -0800 Thread-Topic: netconf / snmp informal meeting in Prague Thread-Index: AcvStYKs6ZgiM0ecQAy/kmOso/M5cQCYli3w Message-ID: References: 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 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-02-25_06:2011-02-25, 2011-02-25, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1102250099 X-Mailman-Approved-At: Sun, 27 Feb 2011 02:06:00 -0800 Subject: Re: [MIB-DOCTORS] netconf / snmp informal meeting in Prague X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 18:18:55 -0000 Hi, I realize that many people are not interested in working on integration of SNMP data into NETCONF, or NETCONF/SNMP coexistence. But maybe social integration leads to better problem-space understanding and better standards. The immediate goal for mib-doctors is to understand (and hopefully like) the SMIv2-to-YANG draft t= hat Juergen is going to finish soon. Andy -----Original Message----- From: yang-doctors-bounces@ietf.org [mailto:yang-doctors-bounces@ietf.org] = On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, February 22, 2011 9:26 AM To: mib-doctors@ietf.org; YANG Doctors Subject: [yang-doctors] netconf / snmp informal meeting in Prague Andy Bierman suggested that we gather in Prague with the best experts in NETCONF/NETMOD and SNMP.=20 His initial problem statement included (and he may want to add or correct, but I am using words from two of his mails): -------------- I want to make standards and implementation progress on retrieving MIB data through NETCONF, and exploring other integration points, such as locking. IMO we should finish up the draft, and get the details finalized. I am also interested in getting yuma to use the output of smidump to implement MIB.yang modules that are compatible with net-snmp. But I think it helps move us forward if we can show our standards working in running open-source code. Reverse-engineering the standard from the tool helps get that done :-) My concern is that we are approaching the entire problem space in a fragmented and disjoint manner. That's the nature of lots of WGs and work items within those WGs. We are kind of ignoring the multi-protocol architecture. A standard plan for if/how SNMP, SYSLOG, NETCONF, CLI/SSH, SMIv2, and YANG all work together to allow application developers to get the most 'bang for the buck' out of these IETF + industry standards. I really like how the COaP plan of implementing open-source along with the documents. That really helped YANG. We should do that for more drafts. The SNMP integration is important to me. NETCONF is not going to reinvent device instrumentation. It will be a convergence point to access CLI show command data, SNMP data, and some new data. The smidump -fyang output is critical to ease of this integration. I hope an open-source yuma + net-snmp implementation will help work out the operational problems. (IMO, just read+notify at first). ----------------- The plan is to get together on Sunday night and go out for dinner after the Welcome Reception. To avoid the noise in restaurant I would like to get a count of people participating and try to book a restaurant with a separate room. So please RSVP to me if you plan to attend. I thought MIB Doctors and YANG Doctors lists are a good starting point, but in case somebody is missing please forward.=20 Thanks and Regards,=20 Dan _______________________________________________ yang-doctors mailing list yang-doctors@ietf.org https://www.ietf.org/mailman/listinfo/yang-doctors From ma-miyazawa@kddilabs.jp Mon Feb 28 07:31:30 2011 Return-Path: X-Original-To: mib-doctors@core3.amsl.com Delivered-To: mib-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7596E3A69F3; Mon, 28 Feb 2011 07:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1KiYH-8z2f0; Mon, 28 Feb 2011 07:31:28 -0800 (PST) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by core3.amsl.com (Postfix) with ESMTP id 028123A693D; Mon, 28 Feb 2011 07:31:27 -0800 (PST) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 647BE1748218; Tue, 1 Mar 2011 00:32:26 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atpalwl61GSo; Tue, 1 Mar 2011 00:32:25 +0900 (JST) Received: from platinum.inc.kddilabs.jp (platinum.inc.kddilabs.jp [IPv6:2001:200:601:1300:172:19:83:254]) by mandala.kddilabs.jp (Postfix) with ESMTP id C14FC1748213; Tue, 1 Mar 2011 00:32:25 +0900 (JST) Received: from miyazawaPC (ebisu.kddilabs.jp [IPv6:2001:200:601:11::214]) by platinum.inc.kddilabs.jp (Postfix) with ESMTP id 781C3578063; Tue, 1 Mar 2011 00:32:25 +0900 (JST) From: "Masanori Miyazawa" To: "'Joan Cucchiara'" , , "'MIB Doctors (E-mail)'" , "'Tomohiro Otani'" , , "'Thomas D. Nadeau'" References: <00ce01cbb34d$e6aa1130$6501a8c0@JoanPC> In-Reply-To: <00ce01cbb34d$e6aa1130$6501a8c0@JoanPC> Date: Tue, 1 Mar 2011 00:32:25 +0900 Message-ID: <012b01cbd75c$b36d5100$1a47f300$@jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuzTjblYmPrL3F6QjW5rXXyAGGNPAkDVr8A Content-Language: ja X-Mailman-Approved-At: Mon, 28 Feb 2011 07:35:06 -0800 Subject: Re: [MIB-DOCTORS] MIB Dr. review of draft-ietf-ccamp-gmpls-ted-mib-07 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 15:31:30 -0000 Hi, Joan Thank you for your comments. In accordance with your comments, I am revising the documents. Please see our answer to your comments as below and let us know if you have any question With best regards, Masanori DOCUMENT COMMENTS ------------------------------------- *) NIT: Does not strip cleanly with smicPRO's mstrip. (This does not have to be fixed for MIB Dr. purposes, only mention as an fyi.) *) Author contact info needs to be updated. "Update in next version" *) Dates and copyright need to be updated " Update in next version " *) RFC references probably need to be updated. RFC3784 was obsoleted by RFC5305 RFC4205 was obsoleted by RFC5307 " Update in next version " IANA-GMPLS-TC-MIB needs to be added to Informative Reference Section. " Update in next version " *) 2. Introduction Since this document supports both OSPFv2 and OSPFv3, please say this explicitly. "Modify in next version" *) The following 2 RFCs should be referenced also. a. OSPFv3 MIB is defined in rfc5643 b. TE extensions to OSPFv3 are described in RFC5329 " Modify in next version " *) 3.3 Acronyms These should be in alphabetical order (or some order that is defined at the beginning of this subsection.) Should include TED: Traffic Engineering Database " Modify in next version " *) Section 4. Motivations The motivation statement leads one to believe that this document will provide "for the management of all of the extensions to the OSPF and ISIS protocol.". There are 2 inconsistencies here: a) Since this is a read-only MIB, (no configuration) then the statement should be revised because management includes configuration. b) As previously mentioned, the use of OSPF and then references to OSPFv2 is misleading, please use OSPFv2, and include OSPFv3 along with relevant documents. " Modify in next version as shown below" The existing OSPFv2, OSPFv3, ISIS, MPLS and GMPLS MIBs do not provide for the management interface to retrieve topology information for the MPLS and GMPLS network. *) Section 5.1 s/information of/information for/ " Modify in next version " *) Section 5.3 s/This is also independently utilized,because/Also, this is utilized independently because/ "Modified" *) Section 5.4 This is referred to as Switch Capable and also as Switching Capability, please be consistent. If SwCap is supposed to be Switching Capability, then please use that Switching Capablity consistently. " We use Switching Capability consistently in this document." COMMENTS ON MIB MODULE -------------------------------------------- *) TEXTUAL-CONVENTIONS The names of these TCs are already used in the OSPFv2 MIB and while this may have been done intentionally, would prefer a TED specific name. For example: RouterID, AreaID, LinkStateID are used in OSPFv2-MIB (RFC4750) Could these be renamed to be prefixed with "Ted" and suffixed with "TC", such as TedRouterIdTC" ? " Modify in next version " *) tedCreateDeleteNotificationMaxRate and tedStatusChangeNotificationMaxRate a) Why are these objects not located closer to the Notifications? b) tedCreateDeleteNotificationMaxRate, has a DEFVAL {0}. The DESCRIPTION clause does not indicate that 0 has a special value (as it does for tedStatusChangeNotificationMaxRate, so just want to check on this? Do you really mean 0 here? "DEFVAL was deleted from tedCreateDeleteNotificationMaxRate" *) tedInfoStatus object I think there is still some confusion about my request for status/state information. Obviously, if there are rows in these tables, then the MIB has been configured by some means other than SNMP, and granted notifications are sent (unless they are dropped due to throttling or lost), but what is the Operational Status link? The RowPointer object, tedLinkInformationData, might provide this information, however, the DESCRIPTION clause makes it sound completely optional since it looks like 0.0 can be entered under any circumstance, so again, I have to ask, how is an operator supposed to know if the TE link is acting as intended? If tedLinkInformationData is supposed to provide this, then it needs to be rewritten to be mandatory. That means that there are dependencies on other MIBs also. That is unclear in this document. In summary, tedInfoStatus object does not provide any additional information, as I can see if the MIB is populated. What I'm asking for is Operational Status/State information. Please discuss. "Thank you for your comment. We think the definition of tedInfosStatus in previous version was wrong, as you indeicated . It took into account only a state/status of this MIB itself, not link information. In order to take into account the operational status of TE link, we think it is necessary to create new object such as, for example, "tedLinkState" in tedTable as shown below. If you have comments, please let us know. " tedLinkState OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-only STATUS current DESCRIPTION " " ::={ tedEntry X } *) tedSwCapSwitchingType Please rename to tedSwCapType. " Modify in next version " *) tedNotificationAreaId and tedNotificationRouterId Not sure why these are needed. Couldn't you include an object from the tedTable (such as tedLinkInformationSource) rather than have these accessible for Notify objects. Seems like extra work on all parts and not sure I see the advantage when you already have this info in a table. Please discuss. " In version 6 of ted mib, tedAreaId, tedRouterId and tedLinkStateId were utilzed as the Index of notification because it is useful to treat as the notification with unique value by using combination of these objects. But, it cause some error on SMICngPro as shown below. Therefore, we decided to utilize new objects such as tedNotificationAreaId, tedNotificationRouteId and tedNotificationLinkStateId. We think we want to use tedAreaId, tedRouterId and tedLinkStateId as the index of notification again. What do you think?" OUTPUT from SMICngPRO --------------------- W: f(TED-MIB.my), (777,10) Variable "tedAreaId" in notification "tedStatusChange" is an index for a table W: f(TED-MIB.my), (777,21) Variable "tedRouterId" in notification "tedStatusChange" is an index for a table W: f(TED-MIB.my), (777,34) Variable "tedLinkStateId" in notification "tedStatusChange" is an index for a table " *) 8. Security Considerations s/read-write../read-write./ " Modify in next version " *) 10.1 Normative References a) Some of the Informative References should probably moved to Normative, specifically, any of the MIB docs that are IMPORTED or appear in a REFERENCE clause. " Modify in next version " *) 10.2 Informative References a) NIT: should be listed in increasing RFC Order. " Modify in next version " > -----Original Message----- > From: Joan Cucchiara [mailto:jcucchiara@mindspring.com] > Sent: Friday, January 14, 2011 3:16 AM > To: ccamp@ietf.org; MIB Doctors (E-mail); Tomohiro Otani; Masanori > Miyazawa; ke-kumaki@kddilabs.jp; Thomas D. Nadeau > Cc: Joan Cucchiara; Dan Romascanu (E-mail) > Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-ted-mib-07 > > > Hi Masonori, > > Thank you for the new version of this document. There were many good > updates, particularly, the Conformance section. > > Please see following comments. > > Thanks, > -Joan > > > > COMPILER RESULTS > ------------------------------ > * MIB compiles cleanly with smicngPRO > > * MIB compiles cleanly with smiLint > > > DOCUMENT COMMENTS > ------------------------------------- > *) NIT: Does not strip cleanly with smicPRO's mstrip. > (This does not have to be fixed for MIB Dr. purposes, > only mention as an fyi.) > > > *) Author contact info needs to be updated. > > *) Dates and copyright need to be updated > > *) RFC references probably need to be updated. > > RFC3784 was obsoleted by RFC5305 > RFC4205 was obsoleted by RFC5307 > > IANA-GMPLS-TC-MIB needs to be added to Informative Reference Section. > > > > > *) 2. Introduction > > Since this document supports both OSPFv2 and OSPFv3, please > say this explicitly. > > *) The following 2 RFCs should be referenced also. > > a. OSPFv3 MIB is defined in rfc5643 > b. TE extensions to OSPFv3 are described in RFC5329 > > > > *) 3.3 Acronyms > > These should be in alphabetical order (or some order that > is defined at the beginning of this subsection.) > > Should include TED: Traffic Engineering Database > > > > *) Section 4. Motivations > > The motivation statement leads one to believe that this > document will provide "for the management of all of the > extensions to the OSPF and ISIS protocol.". > > There are 2 inconsistencies here: > a) Since this is a read-only MIB, (no configuration) then the > statement should be revised because management includes configuration. > b) As previously mentioned, the use of OSPF and then references > to OSPFv2 is misleading, please use OSPFv2, and include OSPFv3 > along with relevant documents. > > > *) Section 5.1 > > s/information of/information for/ > > > *) Section 5.3 > > s/This is also independently utilized,because/Also, this is utilized > independently > because/ > > > *) Section 5.4 > > This is referred to as Switch Capable and also > as Switching Capability, please be consistent. If SwCap is > supposed to be Switching Capability, then please use that > Switching Capablity consistently. > > > > > > COMMENTS ON MIB MODULE > -------------------------------------------- > > > *) TEXTUAL-CONVENTIONS > > The names of these TCs are already used in the OSPFv2 MIB > and while this may have been done intentionally, would prefer > a TED specific name. > > For example: > > RouterID, AreaID, LinkStateID are used in OSPFv2-MIB (RFC4750) > > Could these be renamed to be prefixed with "Ted" > and suffixed with "TC", such as TedRouterIdTC" ? > > > > > *) tedCreateDeleteNotificationMaxRate and > tedStatusChangeNotificationMaxRate > > a) Why are these objects not located closer to the Notifications? > > b) tedCreateDeleteNotificationMaxRate, has a DEFVAL {0}. The DESCRIPTION > clause > does not indicate that 0 has a special value (as it does for > tedStatusChangeNotificationMaxRate, > so just want to check on this? Do you really mean 0 here? > > *) tedInfoStatus object > > I think there is still some confusion about my request for status/state > information. > Obviously, if there are rows in these tables, then > the MIB has been configured by some means other than SNMP, and granted > notifications are sent (unless > they are dropped due to throttling or lost), but what is the Operational > Status > link? > > The RowPointer object, tedLinkInformationData, might provide this > information, however, > the DESCRIPTION clause makes it sound completely optional since it looks > like 0.0 > can be entered under any circumstance, so again, I have to ask, how is an > operator > supposed to know if the TE link is acting as intended? > > If tedLinkInformationData is supposed to provide this, then it needs to > be > rewritten to > be mandatory. That means that there are dependencies on other MIBs also. > That is > unclear in this document. > > In summary, tedInfoStatus object does not provide any additional > information, as > I can see if the MIB is populated. What I'm asking for is Operational > Status/State > information. > > > Please discuss. > > > *) tedSwCapSwitchingType > > Please rename to tedSwCapType. > > > > > *) tedNotificationAreaId and tedNotificationRouterId > > Not sure why these are needed. Couldn't you include > an object from the tedTable (such as tedLinkInformationSource) > rather than have these accessible for Notify objects. Seems like > extra work on all parts and not sure I see the advantage when > you already have this info in a table. > > Please discuss. > > > > *) 8. Security Considerations > > s/read-write../read-write./ > > *) 10.1 Normative References > > a) Some of the Informative References should > probably moved to Normative, specifically, any of the MIB > docs that are IMPORTED or appear in a REFERENCE clause. > > > *) 10.2 Informative References > > a) NIT: should be listed in increasing RFC Order. >