From owner-snmpconf@seymour39.snmp.com Thu Jan 2 09:24:49 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05115 for ; Thu, 2 Jan 2003 09:24:49 -0500 (EST) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3/m.000221) id JAA28505 for snmpconf-outgoing; Thu, 2 Jan 2003 09:10:03 -0500 (EST) Message-Id: <200301021409.JAA28498@seymour39.snmp.com> Content-Type: text/plain; charset="iso-8859-1" From: Jon Saperia To: snmpconf@snmp.com, Randy Bush , "Wayne F. Tackabury" Subject: Re: snmpconf "bcp" Version 11 published Date: Thu, 2 Jan 2003 09:16:08 -0500 X-Mailer: KMail [version 1.3.2] Cc: snmpconf@snmp.com References: <5.1.0.14.0.20021230170212.02a8ea60@mail.goldwiretech.com> In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit On Monday 30 December 2002 10:27 pm, Randy Bush wrote: > > -- The "references" section is now called "Informative > > References". This is consistent with the notion that this is to > > be an Informational RFC, and has no particular pronouncements on > > its own. > > uh, to be precise, any of the references which MUST be read to > understand this document are normative, not informational. > > randy Do you have a specific suggestion for changing the title of the section? If not, we can leave it alone or change back to just 'references' as in previous draft which I assume could be done by the RFC editor if you wanted. /jon -- Jon Saperia saperia@jdscons.com Phone: 978-461-0249 Fax: 617-249-0874 http://www.jdscons.com/ From owner-snmpconf@seymour39.snmp.com Thu Jan 2 11:22:27 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07664 for ; Thu, 2 Jan 2003 11:22:27 -0500 (EST) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3/m.000221) id LAA07987 for snmpconf-outgoing; Thu, 2 Jan 2003 11:09:34 -0500 (EST) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15583DA4F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: snmpconf@snmp.com, Randy Bush , "Wayne F. Tackabury" Subject: RE: snmpconf "bcp" Version 11 published Date: Thu, 2 Jan 2003 17:08:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com WQhy doesn't wayne post a suggested set of normative and informative references, so we can take a quick look to check how we feel about them. It seems to me that several SNMP documents (RFCs) are a MUST read on irder to be able to understand this document. There are possibly others. And there are certainly quite a few that are nice background info, but not REQUIRED reading. For example, the pttrs to documents that contain the MIB-fragment that is being used as an example, those probably contain good background info, but I beleiev the the bcp doc itself has enough context about the example that such doc is not normative. Thanks, Bert > -----Original Message----- > From: Jon Saperia [mailto:saperia@jdscons.com] > Sent: donderdag 2 januari 2003 15:16 > To: snmpconf@snmp.com; Randy Bush; Wayne F. Tackabury > Cc: snmpconf@snmp.com > Subject: Re: snmpconf "bcp" Version 11 published > > > On Monday 30 December 2002 10:27 pm, Randy Bush wrote: > > > -- The "references" section is now called "Informative > > > References". This is consistent with the notion that this is to > > > be an Informational RFC, and has no particular pronouncements on > > > its own. > > > > uh, to be precise, any of the references which MUST be read to > > understand this document are normative, not informational. > > > > randy > > Do you have a specific suggestion for changing the title of > the section? > If not, we can leave it alone or change back to just > 'references' as in > previous draft which I assume could be done by the RFC editor if you > wanted. > > /jon > -- > Jon Saperia > > saperia@jdscons.com > Phone: 978-461-0249 > Fax: 617-249-0874 > http://www.jdscons.com/ > From owner-snmpconf@seymour39.snmp.com Thu Jan 2 11:34:59 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07877 for ; Thu, 2 Jan 2003 11:34:58 -0500 (EST) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3/m.000221) id LAA08351 for snmpconf-outgoing; Thu, 2 Jan 2003 11:23:35 -0500 (EST) Message-Id: <200301021623.LAA08346@seymour39.snmp.com> Content-Type: text/plain; charset="iso-8859-1" From: Jon Saperia To: snmpconf@snmp.com, "Wijnen, Bert (Bert)" , Randy Bush , "Wayne F. Tackabury" Subject: Re: snmpconf "bcp" Version 11 published Date: Thu, 2 Jan 2003 11:29:45 -0500 X-Mailer: KMail [version 1.3.2] References: <7D5D48D2CAA3D84C813F5B154F43B15583DA4F@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15583DA4F@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit On Thursday 02 January 2003 11:08 am, Wijnen, Bert (Bert) wrote: > WQhy doesn't wayne post a suggested set of normative and informative > references, so we can take a quick look to check how we feel > about them. It seems to me that several SNMP documents (RFCs) are > a MUST read on irder to be able to understand this document. > There are possibly others. And there are certainly quite a few that > are nice background info, but not REQUIRED reading. For example, > the pttrs to documents that contain the MIB-fragment that is > being used as an example, those probably contain good background > info, but I beleiev the the bcp doc itself has enough context > about the example that such doc is not normative. > > Thanks, > Bert The references are in the document in the references section. Am I missing something? I think we are just quibbling about the title of the section, are we not? /jon > > > -----Original Message----- > > From: Jon Saperia [mailto:saperia@jdscons.com] > > Sent: donderdag 2 januari 2003 15:16 > > To: snmpconf@snmp.com; Randy Bush; Wayne F. Tackabury > > Cc: snmpconf@snmp.com > > Subject: Re: snmpconf "bcp" Version 11 published > > > > On Monday 30 December 2002 10:27 pm, Randy Bush wrote: > > > > -- The "references" section is now called "Informative > > > > References". This is consistent with the notion that this is to > > > > be an Informational RFC, and has no particular pronouncements on > > > > its own. > > > > > > uh, to be precise, any of the references which MUST be read to > > > understand this document are normative, not informational. > > > > > > randy > > > > Do you have a specific suggestion for changing the title of > > the section? > > If not, we can leave it alone or change back to just > > 'references' as in > > previous draft which I assume could be done by the RFC editor if you > > wanted. > > > > /jon > > -- > > Jon Saperia > > > > saperia@jdscons.com > > Phone: 978-461-0249 > > Fax: 617-249-0874 > > http://www.jdscons.com/ -- Jon Saperia saperia@jdscons.com Phone: 978-461-0249 Fax: 617-249-0874 http://www.jdscons.com/ From owner-snmpconf@seymour39.snmp.com Thu Jan 2 11:44:06 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08068 for ; Thu, 2 Jan 2003 11:44:05 -0500 (EST) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3/m.000221) id LAA08558 for snmpconf-outgoing; Thu, 2 Jan 2003 11:34:03 -0500 (EST) Message-Id: <5.1.0.14.0.20030102112656.02c27008@mail.goldwiretech.com> X-Sender: wayne-pop@mail.goldwiretech.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 02 Jan 2003 11:32:02 -0500 To: "Wijnen, Bert (Bert)" , snmpconf@snmp.com, Randy Bush From: "Wayne F. Tackabury" Subject: RE: snmpconf "bcp" Version 11 published In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15583DA4F@nl0006exch001u.nl.l ucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com At 05:08 PM 1/2/2003 +0100, Wijnen, Bert (Bert) wrote: >WQhy doesn't wayne post a suggested set of normative and informative >references, so we can take a quick look to check how we feel >about them. That's roughly how I was subdividing them when I was making an attempt myself at this previously. However, Randy's guideline for dividing them up ("what must be read to understand the document"), whose simplicity I rather like actually, didn't seem to be the rule of thumb used by other recent IESG approved docs (from tewg, ipo), which seemed like it was more about what-is-definining-a-standard vs. what-is-describing-a-framework. So, I took Bert's other out of saying "in an informational RFC, all references are informative" :). If there is some room for interpretation here, though, I'll run by how I broke down the references in a post to the list in a little while. Regards, Wayne From owner-snmpconf@seymour39.snmp.com Thu Jan 2 13:46:30 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11331 for ; Thu, 2 Jan 2003 13:46:30 -0500 (EST) Received: by seymour39.snmp.com (8.9.3/m.000221) id NAA11284 for snmpconf-outgoing; Thu, 2 Jan 2003 13:34:58 -0500 (EST) Message-Id: <200301021834.NAA11278@seymour39.snmp.com> To: snmpconf@snmp.com Subject: snmpconf quarterly list instructions mailing Date: Thu, 02 Jan 2003 13:34:55 -0500 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com The snmpconf list is for discussing the business of the Configuration Management using SNMP (snmpconf) working group of the IETF. This working group is an open forum for raising and discussing issues related to network device configuration management and SNMP. To remove yourself from the snmpconf discussion list, send a message to snmpconf-request@majordomo.snmp.com containing just the word unsubscribe in the message body (not in the subject). If you have subscribed at an address other than your email from address, send the message unsubscribe address-to-unsubscribe. A http archive is available at http://www.snmp.com/snmpconf/mailing-list/index.html Please send any questions or comments about the management of this list to owner-snmpconf@majordomo.snmp.com. From owner-snmpconf@seymour39.snmp.com Thu Jan 2 15:47:36 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13756 for ; Thu, 2 Jan 2003 15:47:36 -0500 (EST) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3/m.000221) id PAA13714 for snmpconf-outgoing; Thu, 2 Jan 2003 15:36:01 -0500 (EST) Message-Id: <5.1.0.14.0.20030102152826.02d43ce0@mail.goldwiretech.com> X-Sender: wayne-pop@mail.goldwiretech.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 02 Jan 2003 15:34:02 -0500 To: snmpconf@snmp.com From: "Wayne F. Tackabury" Subject: snmpconf Normaformational references Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Here's a proposal for breakdown of references per the most recent thread. Let me know if this sounds about right--I'd like to try to sneak in another draft tomorrow to get before the i-d editor returns from vacation, so let me know by start of business then. One question is whether "architecture" documents like [1] and the applications document [14] would go into the informative camp. My read of all advice to authors makes it sound like it could go either way. Normative: [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M., and K. McCloghrie, "Structure and Identification of Man- agement Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduc- tion to Community-based SNMPv2", RFC 1901, January 1996. [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Pro- cessing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Con- trol Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, q(Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2) q, RFC 1907, January 1996. [18] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [44] McCloghrie, k., "SNMPv2 Management Information Base for the Inter- net Protocol using SMIv2", RFC 2011, November 1996. Informational: [17] McCloghrie, K., and Kastenholz, F., "The Interfaces Group MIB", RFC 2863, June 2000. [19] Brown, C., and F. Baker, "Management Information Base for Frame Relay DTEs Using SMIv2", RFC 2115, September 1997. [20] Baker, F, "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [21] Hawkinson, J., and T. Bates, "Guidelines for Creation, Selection, and Registration of an Autonomous System (AS)", RFC 1930, March 1996. [22] Decker, E., Langille, P., Rijsinghani, A., and K. McCloghrie, "Def- initions of Managed Objects for Bridges", RFC 1493, July 1993. [23] Levi, D., and J. Schoenwaelder "Definitions of Managed Objects for Scheduling Management Operations", RFC 2591, May 1999. [24] Bell, E., Smith, A., Langille, P., Rijsinghani, A., and K. McCloghrie, "Definitions of Managed Objects for Bridges with Traf- fic Classes, Multicast Filtering and Virtual LAN Extensions, RFC 2674, August 1999. [25] Baker, F., "IP Forwarding Table MIB", RFC 2096, January 1997. [26] St. Johns, M., "Radio Frequency (RF) Interface Management Informa- tion Base for MCNS/DOCSIS compliant RF interfaces", RFC 2670, August 1999. [27] Baker, F., and R. Coltun, "OSPF Version 2 Management Information Base", RFC 1850, November 1995. [28] Blake, S. Black, D., Carlson M., Davies E. Wang Z., Weiss W., "An Architecture for Differentiated Services ", RFC 2475, December 1998. [29] Willis, S. and J. Chu., "Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2", RFC 1657, July 1994. [30] Waldbusser, S."Remote Network Monitoring Management Information Base", RFC 2819, May 2000. [31] McCloghrie, K., and Hanson, G., "The Inverted Stack Table Extension to the Interfaces Group MIB", RFC 2863, June 2000. [32] McCloghrie, K. and Bierman, A., "Entity MIB (Version 2)", RFC 2737, December, 1999. [33] ITU-T,, Recommendation M.3010., PRINCIPLES FOR A TELECOMMUNICATIONS MANAGEMENT NETWORK. February, 2000. [34] Waldbusser, S., Saperia, J., and Hongal, T., "Policy Based Manage- ment MIB", Work-in-progress. [35] Heintz, L., "SNMP Row Operations Extensions", Work-in-progress. [36] Zeltserman, D., "A Practical Guide to Snmpv3 and Network Manage- ment", Prentice Hall, 1999. [37] Noto, M., Spiegel, E., and Tesink, K., "Definitions of Textual Con- ventions and OBJECT-IDENTITIES for ATM Management", RFC 2514, February, 1999. [38] Kassaveri, R., and Stewart, B., "Distributed Management Expression MIB", RFC 2982, October, 2000. [39] Daniele, M., Haberman, B., Routhier, S., and Schoenwaelder, J., "Textual Conventions for Internet Network Addresses", RFC 2851, June 2000. [40] St. Johns, M., "DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems", RFC 2669, August, 1999. [41] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and Wald- busser, S., "Terminology for Policy-Based Management", work-in- progress, July, 2001. **note from Wayne: I think this has a RFC number now** [42] http://wwww.cisco.com/univercd/cc/td/product/software/ios113ed/ 11ed_cr/secur_c/scprt/scacls.pdf. [43] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997. Regards, Wayne From owner-snmpconf@seymour39.snmp.com Fri Jan 3 08:55:02 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09173 for ; Fri, 3 Jan 2003 08:55:02 -0500 (EST) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3/m.000221) id IAA10943 for snmpconf-outgoing; Fri, 3 Jan 2003 08:42:23 -0500 (EST) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15583DB27@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: snmpconf@snmp.com, Randy Bush , "Wayne F. Tackabury" Subject: RE: snmpconf "bcp" Version 11 published Date: Fri, 3 Jan 2003 14:41:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com > The references are in the document in the references section. yes > Am I missing something? I think we are just quibbling about the title of > the section, are we not? We're talking about splitting the list of references into two. The first part are then titled "Normative references" The second part are titled "Informative References" see: http://www.rfc-editor.org/policy.html, specifically under References Section discussion Wayne, pls post your list of the suggested split, so we can check. Wayne, it would also be much better to change the references to the SNMP documents to the new RFC341x range. We have also more or less agreed on a new new MIB boilerplate that you may want to check.... http://www.ops.ietf.org/mib-boilerplate.html although right at this moment I seem unable to access myself. Bert > > /jon > > > > > -----Original Message----- > > > From: Jon Saperia [mailto:saperia@jdscons.com] > > > Sent: donderdag 2 januari 2003 15:16 > > > To: snmpconf@snmp.com; Randy Bush; Wayne F. Tackabury > > > Cc: snmpconf@snmp.com > > > Subject: Re: snmpconf "bcp" Version 11 published > > > > > > On Monday 30 December 2002 10:27 pm, Randy Bush wrote: > > > > > -- The "references" section is now called "Informative > > > > > References". This is consistent with the notion that > this is to > > > > > be an Informational RFC, and has no particular > pronouncements on > > > > > its own. > > > > > > > > uh, to be precise, any of the references which MUST be read to > > > > understand this document are normative, not informational. > > > > > > > > randy > > > > > > Do you have a specific suggestion for changing the title of > > > the section? > > > If not, we can leave it alone or change back to just > > > 'references' as in > > > previous draft which I assume could be done by the RFC > editor if you > > > wanted. > > > > > > /jon > > > -- > > > Jon Saperia > > > > > > saperia@jdscons.com > > > Phone: 978-461-0249 > > > Fax: 617-249-0874 > > > http://www.jdscons.com/ > > -- > Jon Saperia > > saperia@jdscons.com > Phone: 978-461-0249 > Fax: 617-249-0874 > http://www.jdscons.com/ > From owner-snmpconf@seymour39.snmp.com Fri Jan 3 16:37:22 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19607 for ; Fri, 3 Jan 2003 16:37:21 -0500 (EST) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3/m.000221) id QAA19891 for snmpconf-outgoing; Fri, 3 Jan 2003 16:23:36 -0500 (EST) Message-Id: <5.1.0.14.0.20030103161426.02745548@mail.goldwiretech.com> X-Sender: wayne-pop@mail.goldwiretech.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 03 Jan 2003 16:21:35 -0500 To: snmpconf@snmp.com, Randy Bush From: "Wayne F. Tackabury" Subject: RE: snmpconf "bcp" Version 11 published In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15583DB27@nl0006exch001u.nl.l ucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com At 02:41 PM 1/3/2003 +0100, Wijnen, Bert (Bert) wrote: >Wayne, pls post your list of the suggested split, so we can check. I did that. Since I haven't heard any specific feedback, I'm going with what I last posted, *with one exception*. In carefully looking, MIBs in RFC 2011/3418 have been used in a strictly informative/demonstrative fashion, hence 3418 goes to the informative set. Did I say 3418? Oh yeah... >Wayne, it would also be much better to change the references to the >SNMP documents to the new RFC341x range. Done. >We have also more or less agreed on a new new MIB boilerplate >that you may want to check.... a) I cannot get to this site either b) Since this has already undergone last calls, conversion to Informative, and submission to IESG, and what you reference is "new new" and "more or less" agreed on, c) this is *Informative*, and not presenting any standards track MIB, d) this is consistent with the prior boilerplate e) I'd like to submit a new version today :). Therefore I'd like to punt on this particular one. I'll resubmit with these changes otherwise. Oh, and I have access to the tiac.net website again, I'll let you know when I have the new -11 up there. If you have an issue with this, let me know, well, *the next 30 minutes* would be nice. :) Regards, Wayne > http://www.ops.ietf.org/mib-boilerplate.html > >although right at this moment I seem unable to access myself. > >Bert > > > > > /jon > > > > > > > -----Original Message----- > > > > From: Jon Saperia [mailto:saperia@jdscons.com] > > > > Sent: donderdag 2 januari 2003 15:16 > > > > To: snmpconf@snmp.com; Randy Bush; Wayne F. Tackabury > > > > Cc: snmpconf@snmp.com > > > > Subject: Re: snmpconf "bcp" Version 11 published > > > > > > > > On Monday 30 December 2002 10:27 pm, Randy Bush wrote: > > > > > > -- The "references" section is now called "Informative > > > > > > References". This is consistent with the notion that > > this is to > > > > > > be an Informational RFC, and has no particular > > pronouncements on > > > > > > its own. > > > > > > > > > > uh, to be precise, any of the references which MUST be read to > > > > > understand this document are normative, not informational. > > > > > > > > > > randy > > > > > > > > Do you have a specific suggestion for changing the title of > > > > the section? > > > > If not, we can leave it alone or change back to just > > > > 'references' as in > > > > previous draft which I assume could be done by the RFC > > editor if you > > > > wanted. > > > > > > > > /jon > > > > -- > > > > Jon Saperia > > > > > > > > saperia@jdscons.com > > > > Phone: 978-461-0249 > > > > Fax: 617-249-0874 > > > > http://www.jdscons.com/ > > > > -- > > Jon Saperia > > > > saperia@jdscons.com > > Phone: 978-461-0249 > > Fax: 617-249-0874 > > http://www.jdscons.com/ > > From owner-snmpconf@seymour39.snmp.com Fri Jan 3 17:11:08 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20281 for ; Fri, 3 Jan 2003 17:11:07 -0500 (EST) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3/m.000221) id QAA20823 for snmpconf-outgoing; Fri, 3 Jan 2003 16:59:17 -0500 (EST) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15583DB9C@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: snmpconf@snmp.com Cc: wayne@goldwiretech.com Subject: RE: snmpconf "bcp" Version 11 published Date: Fri, 3 Jan 2003 22:58:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com [ dropped Randy from cc: list, I think he is on snmpconf list, otherwise he will see the result] Wayne, I did not see the split posted anywhere.... pls resend. No need to hurry either, internet-drafts is closed till Monday. You can send them an email to not publish whatever you did send already over the holiday period. Thanks, Bert > -----Original Message----- > From: Wayne F. Tackabury [mailto:wayne@goldwiretech.com] > Sent: vrijdag 3 januari 2003 22:22 > To: snmpconf@snmp.com; Randy Bush > Subject: RE: snmpconf "bcp" Version 11 published > > > At 02:41 PM 1/3/2003 +0100, Wijnen, Bert (Bert) wrote: > > >Wayne, pls post your list of the suggested split, so we can check. > > I did that. Since I haven't heard any specific feedback, I'm > going with > what I last posted, *with one exception*. In carefully > looking, MIBs in > RFC 2011/3418 have been used in a strictly informative/demonstrative > fashion, hence 3418 goes to the informative set. Did I say > 3418? Oh yeah... > > > >Wayne, it would also be much better to change the references to the > >SNMP documents to the new RFC341x range. > > Done. > > > > >We have also more or less agreed on a new new MIB boilerplate > >that you may want to check.... > > a) I cannot get to this site either > b) Since this has already undergone last calls, conversion to > Informative, > and submission to IESG, and what you reference is "new new" > and "more or > less" agreed on, > c) this is *Informative*, and not presenting any standards track MIB, > d) this is consistent with the prior boilerplate > e) I'd like to submit a new version today :). > > Therefore I'd like to punt on this particular one. > > I'll resubmit with these changes otherwise. Oh, and I have > access to the > tiac.net website again, I'll let you know when I have the new > -11 up there. > > If you have an issue with this, let me know, well, *the next > 30 minutes* > would be nice. :) > > Regards, > Wayne > > > http://www.ops.ietf.org/mib-boilerplate.html > > > >although right at this moment I seem unable to access myself. > > > >Bert > > > > > > > > /jon > > > > > > > > > -----Original Message----- > > > > > From: Jon Saperia [mailto:saperia@jdscons.com] > > > > > Sent: donderdag 2 januari 2003 15:16 > > > > > To: snmpconf@snmp.com; Randy Bush; Wayne F. Tackabury > > > > > Cc: snmpconf@snmp.com > > > > > Subject: Re: snmpconf "bcp" Version 11 published > > > > > > > > > > On Monday 30 December 2002 10:27 pm, Randy Bush wrote: > > > > > > > -- The "references" section is now called "Informative > > > > > > > References". This is consistent with the notion that > > > this is to > > > > > > > be an Informational RFC, and has no particular > > > pronouncements on > > > > > > > its own. > > > > > > > > > > > > uh, to be precise, any of the references which MUST > be read to > > > > > > understand this document are normative, not informational. > > > > > > > > > > > > randy > > > > > > > > > > Do you have a specific suggestion for changing the title of > > > > > the section? > > > > > If not, we can leave it alone or change back to just > > > > > 'references' as in > > > > > previous draft which I assume could be done by the RFC > > > editor if you > > > > > wanted. > > > > > > > > > > /jon > > > > > -- > > > > > Jon Saperia > > > > > > > > > > saperia@jdscons.com > > > > > Phone: 978-461-0249 > > > > > Fax: 617-249-0874 > > > > > http://www.jdscons.com/ > > > > > > -- > > > Jon Saperia > > > > > > saperia@jdscons.com > > > Phone: 978-461-0249 > > > Fax: 617-249-0874 > > > http://www.jdscons.com/ > > > > From owner-snmpconf@seymour39.snmp.com Fri Jan 3 17:22:57 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20532 for ; Fri, 3 Jan 2003 17:22:57 -0500 (EST) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3/m.000221) id RAA21087 for snmpconf-outgoing; Fri, 3 Jan 2003 17:10:14 -0500 (EST) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15583DB9E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: wayne@goldwiretech.com Cc: snmpconf@snmp.com Subject: RE: snmpconf Normaformational references Date: Fri, 3 Jan 2003 23:09:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Inline A lot of these references are all to the old DS SNMPv3 RFCs. We have a new range RFC341x. If you do not change them now, we will see delay later in the RFC-Editor queue when they do want to update them to the current RFCs that have obsoleted the ones you list. If you use the new boiler plate (I did send a copy to you), then maybe you do not need to use as many references. More inline Thanks, Bert > -----Original Message----- > From: Wayne F. Tackabury [mailto:wayne@goldwiretech.com] > Sent: donderdag 2 januari 2003 21:34 > To: snmpconf@snmp.com > Subject: snmpconf Normaformational references > > > Here's a proposal for breakdown of references per the most recent > thread. Let me know if this sounds about right--I'd like to > try to sneak > in another draft tomorrow to get before the i-d editor returns from > vacation, so let me know by start of business then. > > One question is whether "architecture" documents like [1] and the > applications document [14] would go into the informative > camp. My read of all advice to authors makes it sound like it > could go either way. > For STDs track documents, you cannot have normative refs to docs that are lower on the stds track. So you would normally not have a normative reference to an informational RFC. There are exceptions. > Normative: > > [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for > Describing SNMP Management Frameworks", RFC 2571, April 1999. > > [2] Rose, M., and K. McCloghrie, "Structure and Identification of Man- > agement Information for TCP/IP-based Internets", STD 16, RFC 1155, > May 1990. > > [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC > 1212, March 1991. > > [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", > RFC 1215, March 1991. > > [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., > and S. Waldbusser, "Structure of Management Information Version 2 > (SMIv2)", STD 58, RFC 2578, April 1999. > > [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., > and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC > 2579, April 1999. > > [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., > and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC > 2580, April 1999. > > [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network > Management Protocol", STD 15, RFC 1157, May 1990. > > [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduc- > tion to Community-based SNMPv2", RFC 1901, January 1996. > > [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport > Mappings for Version 2 of the Simple Network Management Protocol > (SNMPv2)", RFC 1906, January 1996. > > [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Pro- > cessing and Dispatching for the Simple Network Management Protocol > (SNMP)", RFC 2572, April 1999. > > [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for > version 3 of the Simple Network Management Protocol (SNMPv3)", RFC > 2574, April 1999. > > [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol > Operations for Version 2 of the Simple Network Management Protocol > (SNMPv2)", RFC 1905, January 1996. > > [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC > 2573, April 1999. > > [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Con- > trol Model (VACM) for the Simple Network Management Protocol > (SNMP)", RFC 2575, April 1999. > > [16] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Management > Information Base for Version 2 of the Simple Network Management > Protocol (SNMPv2)", RFC 1907, January 1996. > > [18] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to > Version 3 of the Internet-standard Network Management Framework", > RFC 2570, April 1999. > I think I would make the above (2570, or better 3410) an Informative ref > [44] McCloghrie, k., "SNMPv2 Management Information Base for the Inter- > net Protocol using SMIv2", RFC 2011, November 1996. > > Informational: > > > [17] McCloghrie, K., and Kastenholz, F., "The Interfaces Group MIB", RFC > 2863, June 2000. > > [19] Brown, C., and F. Baker, "Management Information Base for Frame > Relay DTEs Using SMIv2", RFC 2115, September 1997. > > [20] Baker, F, "Requirements for IP Version 4 Routers", RFC 1812, June > 1995. > > [21] Hawkinson, J., and T. Bates, "Guidelines for Creation, Selection, > and Registration of an Autonomous System (AS)", RFC 1930, March > 1996. > > [22] Decker, E., Langille, P., Rijsinghani, A., and K. McCloghrie, "Def- > initions of Managed Objects for Bridges", RFC 1493, July 1993. > > [23] Levi, D., and J. Schoenwaelder "Definitions of Managed Objects for > Scheduling Management Operations", RFC 2591, May 1999. > > [24] Bell, E., Smith, A., Langille, P., Rijsinghani, A., and K. > McCloghrie, "Definitions of Managed Objects for Bridges with Traf- > fic Classes, Multicast Filtering and Virtual LAN Extensions, RFC > 2674, August 1999. > > [25] Baker, F., "IP Forwarding Table MIB", RFC 2096, January 1997. > > [26] St. Johns, M., "Radio Frequency (RF) Interface Management Informa- > tion Base for MCNS/DOCSIS compliant RF interfaces", RFC 2670, > August 1999. > > [27] Baker, F., and R. Coltun, "OSPF Version 2 Management Information > Base", RFC 1850, November 1995. > > [28] Blake, S. Black, D., Carlson M., Davies E. Wang Z., Weiss W., "An > Architecture for Differentiated Services ", RFC 2475, December > 1998. > > [29] Willis, S. and J. Chu., "Definitions of Managed Objects for the > Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2", > RFC 1657, July 1994. > > [30] Waldbusser, S."Remote Network Monitoring Management Information > Base", RFC 2819, May 2000. > > [31] McCloghrie, K., and Hanson, G., "The Inverted Stack Table Extension > to the Interfaces Group MIB", RFC 2863, June 2000. > > [32] McCloghrie, K. and Bierman, A., "Entity MIB (Version 2)", RFC 2737, > December, 1999. > > [33] ITU-T,, Recommendation M.3010., PRINCIPLES FOR A TELECOMMUNICATIONS > MANAGEMENT NETWORK. February, 2000. > > [34] Waldbusser, S., Saperia, J., and Hongal, T., "Policy Based Manage- > ment MIB", Work-in-progress. > > [35] Heintz, L., "SNMP Row Operations Extensions", Work-in-progress. > This one is dead now... do you still want to reference it? > [36] Zeltserman, D., "A Practical Guide to Snmpv3 and Network Manage- > ment", Prentice Hall, 1999. > > [37] Noto, M., Spiegel, E., and Tesink, K., "Definitions of Textual Con- > ventions and OBJECT-IDENTITIES for ATM Management", RFC 2514, > February, 1999. > > [38] Kassaveri, R., and Stewart, B., "Distributed Management Expression > MIB", RFC 2982, October, 2000. > > [39] Daniele, M., Haberman, B., Routhier, S., and Schoenwaelder, J., > "Textual Conventions for Internet Network Addresses", RFC 2851, > June 2000. > > [40] St. Johns, M., "DOCSIS Cable Device MIB Cable Device Management > Information Base for DOCSIS compliant Cable Modems and > Cable Modem > Termination Systems", RFC 2669, August, 1999. > > [41] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., > Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, > J., and Wald- > busser, S., "Terminology for Policy-Based Management", work-in- > progress, July, 2001. > **note from Wayne: I think this has a RFC number now** > > [42] http://wwww.cisco.com/univercd/cc/td/product/software/ios113ed/ > 11ed_cr/secur_c/scprt/scacls.pdf. > > [43] Waldbusser, S., "Remote Network Monitoring Management Information > Base Version 2 using SMIv2", RFC 2021, January 1997. > > Regards, > Wayne > Bert From owner-snmpconf@seymour39.snmp.com Wed Jan 8 08:55:47 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19856 for ; Wed, 8 Jan 2003 08:55:46 -0500 (EST) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3/m.000221) id IAA06895 for snmpconf-outgoing; Wed, 8 Jan 2003 08:52:32 -0500 (EST) Message-Id: <200301081348.IAA19349@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: snmpconf@snmp.com From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snmpconf-bcp-11.txt Date: Wed, 08 Jan 2003 08:48:41 -0500 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Configuration Management with SNMP Working Group of the IETF. Title : Configuring Networks and Devices with SNMP Author(s) : M. MacFaden, D. Partain, J. Saperia, W. Tackabury Filename : draft-ietf-snmpconf-bcp-11.txt Pages : 85 Date : 2003-1-7 This document is written for readers interested in the Internet Standard Management Framework and its protocol, the Simple Network Management Protocol (SNMP). In particular, it offers guidance in the effective use of SNMP for configuration management. This information is relevant to vendors that build network elements, management application developers, and those that acquire and deploy this technology in their networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-bcp-11.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-snmpconf-bcp-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-snmpconf-bcp-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-7160633.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpconf-bcp-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpconf-bcp-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-7160633.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-snmpconf@seymour39.snmp.com Thu Jan 9 14:53:31 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24276 for ; Thu, 9 Jan 2003 14:53:30 -0500 (EST) Received: by seymour39.snmp.com (8.9.3/m.000221) id OAA02809 for snmpconf-outgoing; Thu, 9 Jan 2003 14:50:51 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: snmpconf Persistence definition X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 9 Jan 2003 12:50:15 -0700 Message-ID: Thread-Topic: Persistence definition Thread-Index: AcKzeQZOvxvUa4LPRu62QCDk8Vy3pQDOuYCA From: "Eduardo Cardona" To: X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by seymour39.snmp.com id OAA02805 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit Hi all, Just wonder if there is any definition of persistence related to MIBs in any RFC? "3.7 Persistent Configuration" in draft-ietf-snmpconf-bcp-10.txt is a good starting point at least to figure out whether an object needs or not a persistent reference by DESCRIPTION or storageType object. The Q came to me as "Webstern dictionary definition", sysDescr is persistent (persist, ramain the same), but not in the MIB scope, isn't it? MIB persistence (also from 3.7 cases description) I guess is more like if a value was changed/added and must be keep, then the object persist, but haven't find any good reference/glossary term about persistent in RFCs Thanks Eduardo From owner-snmpconf@seymour39.snmp.com Thu Jan 9 15:51:43 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25916 for ; Thu, 9 Jan 2003 15:51:43 -0500 (EST) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3/m.000221) id PAA03773 for snmpconf-outgoing; Thu, 9 Jan 2003 15:49:24 -0500 (EST) Message-Id: <5.1.0.14.0.20030109153127.02bcb668@mail.goldwiretech.com> X-Sender: wayne-pop@mail.goldwiretech.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 09 Jan 2003 15:41:44 -0500 To: snmpconf@snmp.com, From: "Wayne F. Tackabury" Subject: Re: snmpconf Persistence definition In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com At 12:50 PM 1/9/2003 -0700, Eduardo Cardona wrote: >MIB persistence (also from 3.7 cases description) I guess is more like >if a value was changed/added and must be keep, then the object persist, >but haven't find any good reference/glossary term about persistent in >RFCs While it doesn't even use the term "persistence", the DESCRIPTION clause for the StorageType TC describes the concept in somewhat classic terms. While it refers to "what is in RAM"/"what is in ROM", the modern terms I hear are more of the running and/or restart values for a configurable item. This doesn't answer your main question. When writing the BCP, we didn't particularly feel like defining this was in scope. We had a glossary at one point which some people liked and which might have even had this term in it (I can't recall), but others felt as though it was too controversial for us to be trying to define terms like this, and if it didn't conflict with RFC's like the Policy Terminology RFC, could drift apart from it as each document underwent revisions. Regards, Wayne From owner-snmpconf@seymour39.snmp.com Wed Jan 15 15:20:05 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08923 for ; Wed, 15 Jan 2003 15:20:05 -0500 (EST) Received: by seymour39.snmp.com (8.9.3/m.000221) id PAA27119 for snmpconf-outgoing; Wed, 15 Jan 2003 15:16:22 -0500 (EST) Message-Id: <5.1.0.14.0.20030115151207.02c7bc60@mail.goldwiretech.com> X-Sender: wayne-pop@mail.goldwiretech.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 15 Jan 2003 15:13:32 -0500 To: snmpconf@snmp.com From: "Wayne F. Tackabury" Subject: snmpconf BCP on the web is back Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com If you want to join the fray for the review of the last few nits in the BCP document, the current versions are back and accessible at http://home.tiac.net/~wayne/snmpconf/. The candidate -12, along with the changes to it, are up there. Thanks, Wayne -------- Wayne F. Tackabury Internet: wayne@goldwiretech.com Gold Wire Technology Phone: (781) 398-8819 411 Waverley Oaks Rd., Ste 304 Waltham, MA 02452 Cell: (617) 699-6156 From owner-snmpconf@seymour39.snmp.com Mon Jan 27 06:53:40 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12934 for ; Mon, 27 Jan 2003 06:53:40 -0500 (EST) Received: by seymour39.snmp.com (8.9.3/m.000221) id GAA09582 for snmpconf-outgoing; Mon, 27 Jan 2003 06:48:17 -0500 (EST) Message-Id: <200301271144.GAA12449@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: snmpconf@snmp.com From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snmpconf-bcp-12.txt Date: Mon, 27 Jan 2003 06:44:09 -0500 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Configuration Management with SNMP Working Group of the IETF. Title : Configuring Networks and Devices with SNMP Author(s) : M. MacFaden, D. Partain, J. Saperia, W. Tackabury Filename : draft-ietf-snmpconf-bcp-12.txt Pages : 86 Date : 2003-1-24 This document is written for readers interested in the Internet Standard Management Framework and its protocol, the Simple Network Management Protocol (SNMP). In particular, it offers guidance in the effective use of SNMP for configuration management. This information is relevant to vendors that build network elements, management application developers, and those that acquire and deploy this technology in their networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-bcp-12.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-snmpconf-bcp-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-snmpconf-bcp-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-24113118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpconf-bcp-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpconf-bcp-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-24113118.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-snmpconf@seymour39.snmp.com Mon Jan 27 18:56:17 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01132 for ; Mon, 27 Jan 2003 18:56:16 -0500 (EST) Received: by seymour39.snmp.com (8.9.3/m.000221) id SAA25331 for snmpconf-outgoing; Mon, 27 Jan 2003 18:54:23 -0500 (EST) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155C82FB6@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Wayne F. Tackabury" , "Snmpconf (E-mail)" Subject: snmpconf RE: BCP rev. 12 Date: Tue, 28 Jan 2003 00:53:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com This revision was done to address the NITs that needed to be fixed in order to IESG to approve publication. I think these needs have properly been addressed, and I have advised IESG to approve this doc. Thanks, Bert > -----Original Message----- > From: Wayne F. Tackabury [mailto:wayne@goldwiretech.com] > Sent: donderdag 23 januari 2003 23:33 > To: Wijnen, Bert (Bert); saperia@jdscons.com; Mike MacFaden (E-mail) > Cc: David Partain (telia) (E-mail) > Subject: BCP rev. 12 > > > Bert: > > I just posted rev. 12 of the BCP to the i-d editor. I take > it the next step in the dance is yours. > > Thanks! > > Regards, > Wayne > From owner-snmpconf@seymour39.snmp.com Mon Jan 27 18:56:20 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01145 for ; Mon, 27 Jan 2003 18:56:19 -0500 (EST) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3/m.000221) id SAA25332 for snmpconf-outgoing; Mon, 27 Jan 2003 18:54:28 -0500 (EST) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155C82FB7@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Snmpconf (E-mail)" Subject: AD review of draft-ietf-snmpconf-pm-11.txt - part 1 Date: Tue, 28 Jan 2003 00:53:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Here is a list of NITS, admin/bureucratic comments and more or less serious concerns/questions. - on the fornt page, I would not repeat the authors/editors' names under the title. - At next revision, update copyright date - the RFC-Editor does not want the abstract to be a numbered section - Section 2, we have a new MIB boilerplate since the SNMPv3 RFCs have been published as STD 62. See: http:/www.ops.ietf.org - We also have a new MIB security guidelines at the same place. You may want to check if that means some changes to your Security Considereations section. - References need to be split in Normative and Informative See http://www.rfc-editor.org/policy.html - last para on page 4 talsk about "..this document defines standard management objects" and "... in a standard form..." The attribute of STDs track is assigned external to an RFC, so you should not state/claim that this is standard in the document itself. - First list of bullets in section 3 seems to be a marketing statement. We do not need those in RFCs. - In general, I would like the authors/editors to go through the document and to properly use the terms MIB, MIB Module. I think too often then term "MIBs" is used when you really mean "MIB Modules". I noticed it at least twice in sect 5.3 - Sect 5.5.1. s/are are/are/ - Section 6 states in 3rd para: "Some examples of the features that have been removed...." Not sure it is really "have been removed" or if it is better stated as "are not used" or "are not available" or "are not inherited" or such. - Has anyone checked the EBNF specification via a syntax checker? See http://www.ietf.org/ID-nits.html section 2 6th bullet, which also points to http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt For example, I am not sure this is correct (page 18) unary_op: '+' | '-' | ' | '!' | '++' | '--' What does that single quote between the 2nd and 3rd } mean? - sect 6.2.1 I get a bit confused when you talk about 8-bit elements for a string (in UTF-8 context). Steve tried to explain, but the current text still confuses me. I think he was going to try and add some text to unconfuse me (and possibly others). - When you use EBNF, LHS, RHS and such acronyms the first time in the document, pls expand them Thisis another RFC-Editor policy. - I had some conversation with Steve about the Library functions, on hos they are split in 4 categories and which of the "reserved words" can be used when and where. Also a question on the "which categories must be supported". I believe the answer was all. Steve is going to clarify some of this. - Sect 9.1.1 starts with a ">"... ?? I saw that at a few more places - Sect 9.1.1 I see snmp-function(...[, integer mPModel, string tDomain, string tAddress, integer secModel, string secName, integer secLevel, string contextEngineID ]) It seems to me we need to be able to express the contextName for local and for remote SNMP engines? How do we do that? I think when I look further in the document, that one of the "..." arguments is probably the contextName. Might be good to explain some of that. - when I see this snmp-function(...[, integer mPModel, string tDomain, string tAddress, integer secModel, string secName, integer secLevel, string contextEngineID ]) and if I understand it correctlym then all those extra args are positional and optional, is then not the better notation: snmp-function(...[, integer mPModel [, string tDomain [, string tAddress [, integer secModel [, string secName [, integer secLevel [, string contextEngineID ]]]]]]]) - The sample that follows getVar("sysDescr.0", "", SNMPv3, "snmpUDPDomain", "192.168.1.1/161", SNMPv3, "joe", "NoAuthNoPriv"); confuses me somewhat. I think it is a getVar for sysDescr.0, in the default contextName but it seems to list a SN MPv3 secModel. I am not aware that we have such a secmodel, do we? We have a USM secModel. We also have an SNMPv1 and SNMPv2c, or even an any secModel. But not an SNMPv3 secModel. - Sect 9.1.1 also talks about TDomain. I would suggest to consider to use terms from RFc3419, which includes values for IPv6, which is something that IESG really wants these days. - bottom of page 34. Why do we allow a trailing dot if it can case strncmp() problems? - sect 9.1.3.1 The empty (zero length) string is the default context. so I guess if one omits it that one also gets the default context. Not sure if that is clear here. At least the text If 'contextName' is not present, this element's contextName will be used. Confuses me. What does that mean? This comes back in a lot of the function descriptions - Sect 9.1.3.1 and following sections So do we realize that a "programmer" of these scripts needs to speak OID lingo as opposed to descriptors? Do we really believe that that is encouraging? - Sect 9.1.3.2 The exists() function is used to verify the existence of an SNMP MIB instance. Do you mean s/MIB/MIB object/ You cannot be meaning a complete MIB instance, do you? Similar text is used in following sections too. - I guess that exists() returns an integer cause we do not have a boolean in our language, right? - Sect 9.1.3.4 Mmm... why not rename "pattern" to "searchString" ?? And is the programmer expected to use digits to express which mode to use? Or are there reserved words for that? - Sect 9.1.3.6 I wonder how rows that have multiple integers, or octet strings or such as index, how they get created? Does the last para on page 42 agree with the code fragment on the next page? Spefically, does the if createRow() call and and checking of return code and index agree with that para? Maybe I am just confused. - page 44 talks about "noSuchName or noSuchObject" - do we still want to talk about noSuchName (SNMPv1 ??) - do we not need to talk about noSuchInstance? - sect 9.1.4.1 How about error-status and error-index? - sect 9.1.4.2 I wonder if pdu should not be prefixed with &pdu ? Can this function never return an error? - sect 9.1.4.3 and 9.1.4.4 I see int readVar(integer pdu, integer varBindIndex, and I see integer snmpSend(integer reqPDU, integer reqNumVarbinds, So I wonder, do we have both int and integer as a datatype? - sect 9.1.4.5 What if you pass a non-existing pdu handle? Will it return an error? so should it be: integer readError(integer pdu, integer numVarbinds, integer &errorStatus, integer &errorIndex, integer &hasException) to show that it can return an error? The same question for some of the other functions in sect 9.1 - sect 9.2 I wonder if this is not better sect 9.1.5 ?? It is part of the SNMP library functions, no? - sect 9.2 const integer Integer = 2; So does that potentially cause confusion for people to recognize the difference between integer with lowercase i and upprecase I ?? In fact I wonder if these could not all better be prefixed with some string like SNMP or so, e.g. const integer SNMP_Integer = 2; const integer SNMP_Integer32 = 2; etc You refer to RFC1905, better to refer to RFC3416 You also refer to RFC2571, better to use RFC3411 - sect 9.3.1 I fail to see how the function returns an indication on how the object is indexed. And does the prototype function not need arguments? - sect 9.3.4 and 9.3.5 I had asked steve if the function ev() and ec() could be better named elementValue() and elementCount(). He answered that thes function will be used a lot, similar to argv and argc in C. So.. are we happy that these are such cryptic functiuon names? Is elemv() and elemc() a better compromise. I can live with ev() and ec() if the WG says it is OK. - sect 9.3.4 and 9.3.5 I wonder if it is easy to know what "this element" means. I think it is explained in sect 7... but that is quite a few pages back. - When I see things like the roleMatch function and I know that we are in a UTF-8 environment, then I think we need to include stringprep functionality as per RFC3454. In fact Patrik Faltstrom, APPS AD has confirmed that this is needed, and he has already pointed the authors to a sample. - I guess we have another set of reserved words at the end of sect 9.3.7 Maybe we need one section that lists them all, no? - sect 9.4.6 last sentence "... twice if is an expression" ??? - sect 9.4.8 I first thought that oid needed to be &oid. But the resulting OID is returned as a string (is what Steve told me). I guess the "...replace len subids in oid1.." is what confused me. OK, part 2 comes tomorrow. Bert Thanks, Bert From owner-snmpconf@seymour39.snmp.com Tue Jan 28 17:51:57 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10485 for ; Tue, 28 Jan 2003 17:51:56 -0500 (EST) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3/m.000221) id RAA23200 for snmpconf-outgoing; Tue, 28 Jan 2003 17:48:20 -0500 (EST) Message-Id: <200301282244.RAA10406@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , snmpconf@snmp.com From: The IESG Subject: snmpconf Document Action: Configuring Networks and Devices with SNMP to Informational Date: Tue, 28 Jan 2003 17:44:10 -0500 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com The IESG has approved the Internet-Draft 'Configuring Networks and Devices with SNMP' as an Informational RFC. This document is the product of the Configuration Management with SNMP Working Group. The IESG contact persons are Bert Wijnen and Randy Bush.