From owner-snmpconf@seymour39.snmp.com Wed Oct 1 09:23: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 JAA11609 for ; Wed, 1 Oct 2003 09:23:07 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3p2-20030922/m.030206) id JAA00248 for snmpconf-outgoing; Wed, 1 Oct 2003 09:16:46 -0400 (EDT) Message-Id: <200310011306.JAA29411@seymour39.snmp.com> To: snmpconf@snmp.com Subject: snmpconf quarterly list instructions mailing Date: Wed, 01 Oct 2003 09:06:43 -0400 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. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** From owner-snmpconf@seymour39.snmp.com Thu Oct 2 10:21:51 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 KAA21688 for ; Thu, 2 Oct 2003 10:21:50 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3p2-20030922/m.030206) id KAA14022 for snmpconf-outgoing; Thu, 2 Oct 2003 10:10:54 -0400 (EDT) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC3F5@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Snmpconf (E-mail)" Subject: FW: AD review of: draft-ietf-snmpconf-diffpolicy-07.txt Date: Thu, 2 Oct 2003 15:32:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Is it just me who missed an announcement, or has no follow up occured? WHy can we not keep momentum once we're moving? Thanks, Bert -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: donderdag 28 augustus 2003 1:22 To: snmpconf@snmp.com Subject: AD review of: draft-ietf-snmpconf-diffpolicy-07.txt We're getting close. Still afe nits. - sect 2, first para seems to end with an incomplete sentence? - sect 3 refers to RFC3512 as a BCP. Well, fist of all it is not good to talk too much about the maturity level of documents inside an RFC. that maturity level is an external label, that may change over the lifetime of an RFC. But in any case, way back when we decided to make RFC3512 an Informational RFC, and that is what it is. - You have kept the PM-MIB as a normative reference. Based on the text, that still seems to make sense... but.. this means that this doc will be depending on the PM-MIB to be approved as PS as well. So if I bring this one ot IESG, and if we approve it, then it will hang in RFC-Editor queue till PM-MIB is ready for RFC as well. I can accept the way it is... just let me know if that is indeed what you wanted/intended. - Security section. So do I understand there is no sensitivity to reading any of the objects in this MIB? If such is the case, it might be good to state so. Now you only talk about write access. - If you're gonna rev once more anyway, then diffServConfigId OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..116)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique id for the per-hop-behavior policy. The range of up to 116 octets is chosen to stay within the SMI limit of 128 subidentifiers in an object identifier." ::= { diffServConfigEntry 1 } s/SMI/SNMP/, cause the SMI does not limit it, it is the SNMP PDU that does not allow for more than 128 subids in an OID in a varBind. I should have seen this last time. - StorageType, I stated: But in any event, you need to say something about write access for permanent entries. See the StorageTypeTC in RFC2579 I see nothing about it. What I mean is some text in DESCRIPTION clause aka: Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. if such is indeed the case. - I do not see that you addressed: 11. RowStatus Need to say which (if any) objects can be changed while a row is active. See RowStatus TC in RFC2579 It may be as simple as All writable objects in this row may be modified at any time. If such is indeed the case. Bert From owner-snmpconf@seymour39.snmp.com Thu Oct 2 10:50:09 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 KAA22984 for ; Thu, 2 Oct 2003 10:50:06 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3p2-20030922/m.030206) id KAA16235 for snmpconf-outgoing; Thu, 2 Oct 2003 10:46:48 -0400 (EDT) Date: Thu, 2 Oct 2003 16:43:30 +0200 Subject: Re: FW: AD review of: draft-ietf-snmpconf-diffpolicy-07.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Harrie Hazewinkel To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155028EC3F5@nl0006exch001u.nl.lucent.com> Message-Id: X-Mailer: Apple Mail (2.552) Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit On Thursday, October 2, 2003, at 03:32 PM, Wijnen, Bert (Bert) wrote: > Is it just me who missed an announcement, or has no follow up occured? > WHy can we not keep momentum once we're moving? I went through your comments and this was my reply. I wanted to discuss it first with my co-editor, but not had a response yet. David P?? Although, I have an nroff version I do not seem to have a proper template to generate the internet-draft (which my co-editor always did). So there was no new draft. I have put up the last information/version at http://www.lisanza.net/snmpconf/ Sorry for the delay. See more details below. Harrie > > Thanks, > Bert > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: donderdag 28 augustus 2003 1:22 > To: snmpconf@snmp.com > Subject: AD review of: draft-ietf-snmpconf-diffpolicy-07.txt > > > We're getting close. Still afe nits. > > - sect 2, first para seems to end with an incomplete sentence? Correct. It should have said: "Without the Policy-based Management MIB module a management application must emulated its behavior by doing equivalent SNMP operations by means of manager/agent communication." > > - sect 3 refers to RFC3512 as a BCP. Well, fist of all it is not > good to talk too much about the maturity level of documents > inside an RFC. that maturity level is an external label, > that may change over the lifetime of an RFC. > But in any case, way back when we decided to make RFC3512 an > Informational RFC, and that is what it is. OK, I took out the BCP reference and change the reference with the RFC. > > - You have kept the PM-MIB as a normative reference. My fault, thought I changed it. > Based on the > text, that still seems to make sense... but.. this means that this > doc will be depending on the PM-MIB to be approved as PS as well. > So if I bring this one ot IESG, and if we approve it, then it will > hang in RFC-Editor queue till PM-MIB is ready for RFC as well. > I can accept the way it is... just let me know if that is indeed > what you wanted/intended. If I understand the 'rules' correctly of standard level, I agree. The problem is that the draft wants to address the usage of the PM-MIB, however, one could use it without the PM-MIB. This is provided as an example. But since it describes things of the PM-MIB it indeed depends on it. If this is the case I am not sure how to work around this. If others have ideas, I would like to hear them. > - Security section. So do I understand there is no sensitivity to > reading any of the objects in this MIB? If such is the case, it > might be good to state so. Now you only talk about write access. You understood that correctly, my view is there are no values in this MIB module for templates. One could only retrieve the info like "there is a template". I have added this: "There is no sensitivity in reading any of the objects, while it only provide information like "there is a template". This is due to the fact that the managed objects that compose the template are in the DIFFSERV-MIB. For more detail is refered to [RFC3289]." Is this OK?? And if others think differently, please speak up. > > - If you're gonna rev once more anyway, then > diffServConfigId OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE(1..116)) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A unique id for the per-hop-behavior policy. The range > of up to 116 octets is chosen to stay within the SMI > limit of 128 subidentifiers in an object identifier." > ::= { diffServConfigEntry 1 } > s/SMI/SNMP/, cause the SMI does not limit it, it is the SNMP PDU > that does not allow for more than 128 subids in an OID in a > varBind. I should have seen this last time. I leave as is, after reading list comments (from Jeff and Bert). > > - StorageType, I stated: > But in any event, you need to say something about write > access for permanent entries. See the StorageTypeTC in RFC2579 > I see nothing about it. What I mean is some text in DESCRIPTION > clause aka: > Conceptual rows having the value 'permanent' need not > allow write-access to any columnar objects in the row. > if such is indeed the case. I thought I addressed it with the extra text and the storage type TC itself. Anyway, I added now: "Rows that have a storage type of 'permanent' do not need to allow write-access to any of its columnar objects." > > - I do not see that you addressed: > 11. RowStatus > Need to say which (if any) objects can be changed while a > row is active. See RowStatus TC in RFC2579 > It may be as simple as > All writable objects in this row may be modified at > any time. > If such is indeed the case. Yes. I have added: "All writable objects in this row may be modified at any time." From owner-snmpconf@seymour39.snmp.com Fri Oct 3 09:01: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 JAA05246 for ; Fri, 3 Oct 2003 09:01:06 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3p2-20030922/m.030206) id IAA28306 for snmpconf-outgoing; Fri, 3 Oct 2003 08:56:15 -0400 (EDT) From: "David Partain (LM/EAB)" Organization: Ericsson AB To: snmpconf@snmp.com Subject: Re: FW: AD review of: draft-ietf-snmpconf-diffpolicy-07.txt Date: Fri, 3 Oct 2003 08:18:00 +0200 User-Agent: KMail/1.5.4 References: <7D5D48D2CAA3D84C813F5B154F43B155028EC3F5@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155028EC3F5@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310030818.00914.david.partain@ericsson.com> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit On Thursday 02 October 2003 15.32, Wijnen, Bert (Bert) wrote: > Is it just me who missed an announcement, or has no follow up occured? > WHy can we not keep momentum once we're moving? Hi all, This is _entirely_ my fault, and I'll work today to get the latest out. Watch an I-D repository near you. Cheers, David From owner-snmpconf@seymour39.snmp.com Fri Oct 3 09:10:16 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 JAA05410 for ; Fri, 3 Oct 2003 09:10:15 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3p2-20030922/m.030206) id JAA29003 for snmpconf-outgoing; Fri, 3 Oct 2003 09:05:54 -0400 (EDT) From: "David Partain (LM/EAB)" Organization: Ericsson AB To: snmpconf@snmp.com Subject: submitted draft-ietf-snmpconf-diffpolicy-08.txt Date: Fri, 3 Oct 2003 14:47:27 +0200 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310031447.27589.david.partain@ericsson.com> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Greetings, I have now submitted draft-ietf-snmpconf-diffpolicy-08.txt to the I-D people. This update reflects changes after Bert's AD review. The I-D should appear soon. The changes are in the diff below. I've removed all of the administrivia stuff (-07 to -08 and so on). Also not reflected in the diff is moving the reference to the PM MIB from normative to informational references. It's not a diff you can feed into patch, so don't try. Cheers, Harrie and David @@ -77,7 +77,7 @@ Abstract This memo describes a MIB module that provides a conceptual layer - between high-level "network-wide" policy definitions that affect + between high-level "network-wide" policy definitions that effect configuration of the Differentiated Services (diffserv) subsystem and the instance-specific information that would include such details as the parameters for all the queues associated with each interface in a @@ -209,7 +210,8 @@ used in combination with the Policy-based Management MIB module [PMMIBDR], but that is not a requirement. Without the Policy-based Management MIB module, a management application must emulate behavior - provided by the Policy-based Management MIB using equivalent + provided by the Policy-based Management MIB using equivalent "low- + level" SNMP operations in normal manager/agent communication. Together, this memo and [RFC3289] and [PMMIBDR] represent an instance of an integrated architecture for both device-specific and network- @@ -245,12 +246,13 @@ It is assumed that the reader is familiar with Differentiated Services ([RFC2474] and [RFC2475]), the Policy-based Management MIB - ([PMMIBDR]) and the BCP entitled "Configuring Networks and Devices - With SNMP" ([RFC3512]). These documents include all of the necessary - terminology for understanding this memo. [RFC3512] also provides an - example MIB module which may help in understanding the relationship - between DIFFSERV-CONFIG-MIB and the Differentiated Services MIB in - [RFC3289]. + ([PMMIBDR]) and "Configuring Networks and Devices With SNMP" + ([RFC3512]). These documents include all of the necessary + terminology for understanding this memo. Note, though, that use of + the MIB module in this memo does not require the use of [PMMIBDR]. + [RFC3512] also provides an example MIB module which may help in + understanding the relationship between DIFFSERV-CONFIG-MIB and the + Differentiated Services MIB in [RFC3289]. 4. Relationship to other MIBs @@ -269,7 +271,8 @@ of elements on a particular device, a table for representing the capabilities of a device with respect to policy management, a table for referencing elements affected by a policy, as well as other - infrastructure. + infrastructure. There is no requirement that [PMMIBDR] be used in + conjunction with the MIB module defined in this memo. See [PMMIBDR] for a full description of the policy-based configuration framework it provides. @@ -491,7 +495,8 @@ stream. Then, with the policy-based configuration concept as defined in this document and in [PMMIBDR], a traffic marking configuration will be applied. The example will walk the reader through all of the - steps involved in this process. + steps involved in this process. Again, the use of [PMMIBDR] is + simply as an example and is not required. NOTE WELL: For brevity and clarity, the example does not always show the complete entry (row) of a table. The only objects shown @@ -1216,7 +1217,9 @@ may differ. It may very well be that the agent is not capable of detecting such changes and therefore, the management application should verify the correct - configuration after a reboot." + configuration after a reboot. Rows with a StorageType + of 'permanent' do not need to allow write access to + any of the columnar objects in that row." DEFVAL { nonVolatile } ::= { diffServConfigEntry 6 } @@ -1226,23 +1229,24 @@ STATUS current DESCRIPTION "RowStatus object used for creation and deletion of - rows in this table." - DEFVAL { notInService } - ::= { diffServConfigEntry 7 } + rows in this table. All writable objects in this row + may be modified at any time." + DEFVAL { notInService } + ::= { diffServConfigEntry 7 } @@ -1313,24 +1373,34 @@ In addition, the managed objects of the DIFFSERV-MIB are also security sensitive, since unauthorized changes may cause configuration changes. For more detail, refer to [RFC3289]. + Allowing read access to objects in this MIB module is generally not + considered sensitive, as read access only provides information that a + template exists. This is due to the fact that the managed objects + that actually instantiate the template are in the DIFFSERV-MIB + [RFC3289]. However, in environments where the template description + (diffServConfigDescr) or owner (diffServConfigOwner) is considered + sensitive information, appropriate access control should be exercised + for these objects. + SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), there is no control as to who on the secure network is allowed to From owner-snmpconf@seymour39.snmp.com Fri Oct 3 16:44:21 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 QAA27281 for ; Fri, 3 Oct 2003 16:44:20 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3p2-20030922/m.030206) id QAA21128 for snmpconf-outgoing; Fri, 3 Oct 2003 16:38:08 -0400 (EDT) Message-Id: <200310032025.QAA25438@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-diffpolicy-08.txt Date: Fri, 03 Oct 2003 16:25:41 -0400 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 : The Differentiated Services Configuration MIB Author(s) : H. Hazewinkel, D. Partain Filename : draft-ietf-snmpconf-diffpolicy-08.txt Pages : 28 Date : 2003-10-3 This memo describes a MIB module that provides a conceptual layer between high-level 'network-wide' policy definitions that affect configuration of the Differentiated Services (diffserv) subsystem and the instance-specific information that would include such details as the parameters for all the queues associated with each interface in a system. This essentially provides an interface for configuring differentiated services at a conceptually higher layer than that of the Differentiated Services MIB. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-diffpolicy-08.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-diffpolicy-08.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-diffpolicy-08.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-10-3164049.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpconf-diffpolicy-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpconf-diffpolicy-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-3164049.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-snmpconf@seymour39.snmp.com Fri Oct 3 16:44:32 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 QAA27336 for ; Fri, 3 Oct 2003 16:44:31 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3p2-20030922/m.030206) id QAA21098 for snmpconf-outgoing; Fri, 3 Oct 2003 16:37:53 -0400 (EDT) Message-Id: <200310032025.QAA25385@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-pm-14.txt Date: Fri, 03 Oct 2003 16:25:05 -0400 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 : Policy Based Management MIB Author(s) : S. Waldbusser, J. Saperia, T. Hongal Filename : draft-ietf-snmpconf-pm-14.txt Pages : 128 Date : 2003-10-3 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP- based internets. In particular, this MIB defines objects that enable policy-based monitoring and management of SNMP infrastructures as well as a scripting language and a script execution environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-pm-14.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-pm-14.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-pm-14.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-10-3164032.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpconf-pm-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpconf-pm-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-3164032.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-snmpconf@seymour39.snmp.com Wed Oct 8 15:33:09 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 PAA05652 for ; Wed, 8 Oct 2003 15:33:09 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3p2-20030922/m.030206) id PAA12006 for snmpconf-outgoing; Wed, 8 Oct 2003 15:26:22 -0400 (EDT) X-test-idtracker: no To: IETF-Announce :; Cc: snmpconf@snmp.com From: The IESG Subject: snmpconf Last Call: 'The Differentiated Services Configuration MIB' to Proposed Standard Message-Id: Date: Wed, 08 Oct 2003 15:18:01 -0400 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com The IESG has received a request from the Configuration Management with SNMP WG to consider the following document: - 'The Differentiated Services Configuration MIB ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-10-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-diffpolicy-08.txt From owner-snmpconf@seymour39.snmp.com Thu Oct 9 10:15: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 KAA21737 for ; Thu, 9 Oct 2003 10:15:21 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3p2-20030922/m.030206) id KAA11688 for snmpconf-outgoing; Thu, 9 Oct 2003 10:10:36 -0400 (EDT) Message-ID: <3F84CDB8.90BE0731@nextbeacon.com> Date: Wed, 08 Oct 2003 19:53:44 -0700 From: Steve Waldbusser X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: I-D ACTION:draft-ietf-snmpconf-pm-14.txt References: <200310032025.QAA25385@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Diffs: The -14 draft of the PM MIB was published. The changes are in two main categories: 1. Fixes to issues brought up by Bert's AD-Review: - Updated references - Cleaned up instructions on how credential delegation works including adding usage examples - Changed name of UTF8String TC to PmUTF8String to avoid conflicts - Added warning text to tables where combinations of indexes could result in instance names longer than 128 subids. - Expanded security considerations section with information about specifically which objects may have security concerns when written. - Added an IANA considerations section 2. Patrik Falstrom did a review of the document to ensure that the document was consistent with regards to internationalization. Patrik had a few concerns that things *weren't* consistent which basicly boiled down to the fact that while 'Strings' are defined to be UTF-8, comparison operations on them treat them as 8-bit characters even if they happen to contain multi-byte characters. We agreed the best remedy to this would be not to pretend that Strings (and operations on Strings) are UTF-8, but to define them as sequences of octets and then create an International String function library that contains functions that manipulate Strings that may contain multi-byte characters. The full set of changes were: - Define String as a sequence of octets and make sure all existing functions are defined correctly for single-byte ascii characters - Create a function library for International Strings that contains Stringprep and other functions for multi-byte characters. (See this function library for the details) - Updated the stringprep profile to perform normalization Thanks to Bert and Patrik for the very thorough reviews! Steve Internet-Drafts@ietf.org wrote: > 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 : Policy Based Management MIB > Author(s) : S. Waldbusser, J. Saperia, T. Hongal > Filename : draft-ietf-snmpconf-pm-14.txt > Pages : 128 > Date : 2003-10-3 > > This memo defines a portion of the Management Information Base > (MIB) for use with network management protocols in TCP/IP- > based internets. In particular, this MIB defines objects that > enable policy-based monitoring and management of SNMP > infrastructures as well as a scripting language and a script > execution environment. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-pm-14.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-pm-14.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-pm-14.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. > > ------------------------------------------------------------------------ > Content-Type: text/plain > Content-ID: <2003-10-3164032.I-D@ietf.org> From owner-snmpconf@seymour39.snmp.com Mon Oct 13 09:33: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 JAA04187 for ; Mon, 13 Oct 2003 09:33:29 -0400 (EDT) Received: by seymour39.snmp.com (8.9.3p2-20030922/m.030206) id JAA06084 for snmpconf-outgoing; Mon, 13 Oct 2003 09:27:53 -0400 (EDT) X-test-idtracker: no To: IETF-Announce :; Cc: snmpconf@snmp.com From: The IESG Subject: snmpconf Last Call: 'The Differentiated Services Configuration MIB' to Proposed Standard Message-Id: Date: Wed, 08 Oct 2003 15:18:01 -0400 X-AIMC-AUTH: (null) X-AIMC-MAILFROM: owner-ietf-announce@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: iesg-secretary@ietf.org Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com The IESG has received a request from the Configuration Management with SNMP WG to consider the following document: - 'The Differentiated Services Configuration MIB ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-10-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-diffpolicy-08.txt From owner-snmpconf@seymour39.snmp.com Fri Oct 17 10:18:09 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 KAA04171 for ; Fri, 17 Oct 2003 10:18:09 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3p2-20030922/m.030206) id KAA05719 for snmpconf-outgoing; Fri, 17 Oct 2003 10:12:48 -0400 (EDT) From: "David Partain (LI/EAB)" Organization: Ericsson AB To: snmpconf@snmp.com Subject: snmpconf Status of our work Date: Fri, 17 Oct 2003 14:27:13 +0200 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200310171427.13417.david.partain@ericsson.com> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit Greetings all, The two final SNMPCONF documents have been published, with appropriate changelogs published here. draft-ietf-snmpconf-diffpolicy-08.txt: There is an ongoing IETF last call on this document. draft-ietf-snmpconf-pm-14.txt: Published following AD review. We believe that this revision covered the remaining outstanding issues, but there it may be that Patrik Fältström will have additional comments about internationalization. If you have comments about these documents, please speak up quickly. Now is the right time... David and Jon From owner-snmpconf@seymour39.snmp.com Fri Oct 17 10:42:28 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 KAA04911 for ; Fri, 17 Oct 2003 10:42:27 -0400 (EDT) Received: by seymour39.snmp.com (8.9.3p2-20030922/m.030206) id KAA08295 for snmpconf-outgoing; Fri, 17 Oct 2003 10:40:01 -0400 (EDT) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502B42C51@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Snmpconf (E-mail)" Subject: FW: AD review: draft-ietf-snmpconf-pm-14.txt Date: Fri, 17 Oct 2003 16:35:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by seymour39.snmp.com id KAA07814 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit FYI on the Internationalization stuff Thanks, Bert -----Original Message----- From: Patrik Fältström [mailto:paf@cisco.com] Sent: dinsdag 14 oktober 2003 22:19 To: Wijnen, Bert (Bert) Subject: Re: AD review: draft-ietf-snmpconf-pm-14.txt This is excellent! I.e. draft-ietf-snmpconf-pm-14.txt paf On 14 okt 2003, at 13.28, Wijnen, Bert (Bert) wrote: >> draft-ietf-snmpconf-pm From owner-snmpconf@seymour39.snmp.com Fri Oct 17 11:23:56 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 LAA06112 for ; Fri, 17 Oct 2003 11:23:55 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3p2-20030922/m.030206) id LAA10774 for snmpconf-outgoing; Fri, 17 Oct 2003 11:20:49 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: snmpconf Status of our work Date: Fri, 17 Oct 2003 10:52:03 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA01139189@NHROCMBX1.ets.enterasys.com> Thread-Topic: snmpconf Status of our work Thread-Index: AcOUuUWSeYkQA5FzS4yub+muxfMT0gAAQfeQ From: "Harrington, David" To: X-OriginalArrivalTime: 17 Oct 2003 14:52:03.0189 (UTC) FILETIME=[39DB8250:01C394BE] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.0 X-pstn-levels: (C:83.3688 M:99.4056 P:95.9108 R:95.9108 S:73.3543 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by seymour39.snmp.com id KAA09362 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit Hi, I continue to believe that the scripting language used to specify policies should be separated from the MIBs that coordinate the advertisement and coordination of policies. In the MIDCOM WG, we could use many of the features described in snmpconf, such as advertised capabilities, policy groups, precedence, override, etc. Convincing the WG to adopt those features is made much harder by the requirement to be non-conformant to the only defined compliance, which requires support for the snmpconf scripting language. It might be possible to simply add lesser compliance levels, but the dependencies on the scripting language in the design of the mib probably need to be reduced to enable easier reuse of the non-scripting portions of the design possible. As the representative for a vendor, I can say that I will not go to my engineering department and recommend this protocol because I don't believe the snmpconf scripting is something I believe will solve more problems than it raises. I do not believe a freeform scripted language approach is application friendly; it strikes me about as application-friendly as HTML web pages that manipulate SNMP objects. I hate to throw out the baby with the bathwater however. I believe the snmpconf work contains many mib constructs that could be useful if it weren't for the required scripting. If we made these useable with other policy-specification approaches, they could be very useful. I believe the snmpconf-pm document should be broken up into at least two documents. That would allow vendors and other WGs to adopt some aspects of snmpconf without adopting it all. dbh > -----Original Message----- > From: David Partain (LI/EAB) [mailto:david.partain@ericsson.com] > Sent: Friday, October 17, 2003 8:27 AM > To: snmpconf@snmp.com > Subject: snmpconf Status of our work > > > Greetings all, > > The two final SNMPCONF documents have been published, with > appropriate changelogs published here. > > draft-ietf-snmpconf-diffpolicy-08.txt: There is an ongoing > IETF last call on this document. > > draft-ietf-snmpconf-pm-14.txt: Published following AD review. > We believe that this revision covered the remaining outstanding > issues, but there it may be that Patrik Fältström will have > additional comments about internationalization. > > If you have comments about these documents, please speak up > quickly. Now is the right time... > > David and Jon > > From owner-snmpconf@seymour39.snmp.com Tue Oct 21 09:09:32 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 JAA16322 for ; Tue, 21 Oct 2003 09:09:31 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3p2-20030922/m.030206) id JAA21821 for snmpconf-outgoing; Tue, 21 Oct 2003 09:04:09 -0400 (EDT) From: "David Partain (LI/EAB)" Organization: Ericsson AB To: snmpconf@snmp.com Subject: Re: snmpconf Status of our work Date: Tue, 21 Oct 2003 13:07:26 +0200 User-Agent: KMail/1.5.4 References: <6D745637A7E0F94DA070743C55CDA9BA01139189@NHROCMBX1.ets.enterasys.com> In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA01139189@NHROCMBX1.ets.enterasys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310211307.26213.david.partain@ericsson.com> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Hi all, On Friday 17 October 2003 16.52, Harrington, David wrote: > I continue to believe that the scripting language used to specify policies > should be separated from the MIBs that coordinate the advertisement and > coordination of policies. [rest deleted] Thanks for the mail and the comments. It seems very late in the game to be suggesting a split in the architecture of the document. This would definitely be a very major change at a time when our only remaining milestone is to close the working group. While there may be reasons to consider a split of the MIB constructs and the scripting language, it would require a significant effort to accomplish this. Our preference would be to get the document published as is to allow vendors who are interested in implementing the work to do so. Should we indeed discover wide support for a looser coupling between scripting and the MIB module, we should clearly address that in future work in a rejuvenated SNMPCONF or in some other working group. I hope that seems reasonable... Cheers, David Partain From owner-snmpconf@seymour39.snmp.com Tue Oct 21 12:47:07 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 MAA26001 for ; Tue, 21 Oct 2003 12:47:06 -0400 (EDT) Received: by seymour39.snmp.com (8.9.3p2-20030922/m.030206) id MAA06185 for snmpconf-outgoing; Tue, 21 Oct 2003 12:42:08 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: snmpconf Status of our work Date: Tue, 21 Oct 2003 12:10:11 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA01139277@NHROCMBX1.ets.enterasys.com> Thread-Topic: snmpconf Status of our work Thread-Index: AcOX1FBTxIPqpphsSKCWBWBGOes4pwAFlsRg From: "Harrington, David" To: X-OriginalArrivalTime: 21 Oct 2003 16:10:12.0083 (UTC) FILETIME=[CE4EF430:01C397ED] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.0 X-pstn-levels: (C:91.3934 M:99.4056 P:95.9108 R:95.9108 S:79.8563 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by seymour39.snmp.com id MAA03727 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit Hi, I won't challenge the advancement of the document, but will respond to your response. To suggest that this suggestion is "late in the process" is a bit misleading. I have been requesting the split of the snmpconf functionality for approximately three years, so we could reuse existing mib module functionality where possible, especially in terms of scripting support, and so that other working groups could more easily reuse some of the work being done in snmpconf. I think it is too bad when "late in the process" is used to justify pushing through work that is technically not as well-designed for reusability as it should be for an industry standard. You comment that it would take a significant effort to do the split. It will require even more effort to split it later, since that would almost certainly require re-rooting the tree, which of course requires obsoleting and renaming descriptors and reassigning OIDs. Time-to-market is certainly a reality to consider, but what vendors do you know are just waiting to implement this specification once it reaches PS? I haven't heard anybody even mention implementing snmpconf in the past year or so. The only places I have seen snmpconf mentioned is in MIDCOM, where they have largely rejected using it because it is too heavyweight, especially with the snmpconf scripting. If the document were split into the script language, script execution support, and policy support, the MIDCOM WG (and probably others) would be much more likely to utilize some of the snmpconf functionality. My $.02 and now I'll shut up, dbh > -----Original Message----- > From: David Partain (LI/EAB) [mailto:david.partain@ericsson.com] > Sent: Tuesday, October 21, 2003 7:07 AM > To: snmpconf@snmp.com > Subject: Re: snmpconf Status of our work > > > Hi all, > > On Friday 17 October 2003 16.52, Harrington, David wrote: > > I continue to believe that the scripting language used to > specify policies > > should be separated from the MIBs that coordinate the > advertisement and > > coordination of policies. > [rest deleted] > > Thanks for the mail and the comments. > > It seems very late in the game to be suggesting a split in > the architecture of the document. This would definitely be a > very major change at a time when our only remaining milestone > is to close the working group. > > While there may be reasons to consider a split of the MIB > constructs and the scripting language, it would require a > significant effort to accomplish this. Our preference would > be to get the document published as is to allow vendors who are > interested in implementing the work to do so. Should we indeed > discover wide support for a looser coupling between scripting > and the MIB module, we should clearly address that in future > work in a rejuvenated SNMPCONF or in some other working group. > > I hope that seems reasonable... > > Cheers, > > David Partain > > From owner-snmpconf@seymour39.snmp.com Thu Oct 23 13:58:42 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 NAA09285 for ; Thu, 23 Oct 2003 13:58:41 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3p2-20030922/m.030206) id NAA19065 for snmpconf-outgoing; Thu, 23 Oct 2003 13:52:39 -0400 (EDT) To: snmpconf@snmp.com Subject: Re: snmpconf Status of our work References: <6D745637A7E0F94DA070743C55CDA9BA01139277@NHROCMBX1.ets.enterasys.com> From: Wes Hardaker Organization: Sparta Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEXotKX87e8eDA4GAQbQgmlzNycHAwizYkruzul2AAACaUlEQVR4nFXUTW/jIBAGYFI56jWutuq1S9b2dddW6dWtQFxbq4jzwq73Glmg+fv7DiT9QJGS+GEGhiER67TWEQ5CtOeh21ZcIIbmOPq5QvMZYlyV6u+/gsJLTSrGIL/CxEPxQuPAcP0JYlQsq3x5B3UJmUaEyB6yZ+CQ+pwXCzKsbXtbIhg4KtZypPz+AVGtlxH69c87qAqRY6Rc5QUmZMGeAj+TfVjjUwE1lflKys5JGXpM+V0hltqCJ0qL7Plkft4wRM6lxi5p3Wyy7O7fB8TgtdZivxy5rvAB6wSYhbA9vn+GOCaOEGJRPO2mHgk+q1Chyf0Up3AG0NjhOXI19ogEFziq6M+ZtN3kUZ13NW4qUCprC3CW668C06M5jihON1Vsjq8F1CPJB8LINNeQfscwxUEvAwM5Xghvsq2pBr3hnKhbDIrMS3cBRDx70uS9JW2dy667gM0AbZFFmyvn3GOBGB8wG9kppaSNz357LaCmUdtSny5LU9qeCrglvJmyH20TwkjnXQE0usscIWayCWZJ7OpZ4QbUVGRnhuTub3cMYRk99oSplDIfibzfn0FyXyk7z8XThuvC0P/dGCwee7O8aZJBmh0vPixy0NrYhDaR02aR3W0BbyT6h23OB5Hzybj+DOm5w6XCOZG13p5Oh/bursJVh9S+bBiFnPCDuntpcTH080AO+7GlW1i3bRphBM04dZ2dI6yMLjmGFqnIok/cB1YU8sJAACTeuHOd5+lumQHfDM6KyLqEm4aWkkcc1m4PqBewZxBZOg44lT+aJiexDteewboiVhxAjSHxQwhiYJEdCR6tMN1/uckirDRNbsgAAAAASUVORK5CYII= Date: Thu, 23 Oct 2003 09:03:17 -0700 In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA01139277@NHROCMBX1.ets.enterasys.com> (David Harrington's message of "Tue, 21 Oct 2003 12:10:11 -0400") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >>>>> On Tue, 21 Oct 2003 12:10:11 -0400, "Harrington, David" said: David> To suggest that this suggestion is "late in the process" is a bit David> misleading. I have been requesting the split of the snmpconf David> functionality for approximately three years, so we could reuse existing David> mib module functionality where possible, especially in terms of David> scripting support, and so that other working groups could more easily David> reuse some of the work being done in snmpconf. As have I. I also made comments a long time ago that the MIB should have other-language support (specifically, I think I mentioned that it was unlikely the language would come out perfect the first time and that a completely new language might be needed in the future, without deleting support the old at the same time). So, I have to agree with David that "late in the process" is a bit misleading. Though, the WG did make the decision a long time ago to not follow these opinions, and David is just restating old advise. It doesn't make it more likely it'll be followed at this point though... -- Wes Hardaker Sparta From owner-snmpconf@seymour39.snmp.com Fri Oct 24 09:08: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 JAA29052 for ; Fri, 24 Oct 2003 09:08:59 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3p2-20030922/m.030206) id JAA02915 for snmpconf-outgoing; Fri, 24 Oct 2003 09:05:10 -0400 (EDT) From: "David Partain (LI/EAB)" Organization: Ericsson AB To: snmpconf@snmp.com, Wes Hardaker Subject: Re: snmpconf Status of our work Date: Fri, 24 Oct 2003 08:29:00 +0200 User-Agent: KMail/1.5.4 References: <6D745637A7E0F94DA070743C55CDA9BA01139277@NHROCMBX1.ets.enterasys.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310240829.00506.david.partain@ericsson.com> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Hi David and Wes, On Thursday 23 October 2003 18.03, Wes Hardaker wrote: > >>>>> On Tue, 21 Oct 2003 12:10:11 -0400, "Harrington, David" > >>>>> said: > > David> To suggest that this suggestion is "late in the process" is a bit > David> misleading. I have been requesting the split of the snmpconf > David> functionality for approximately three years, so we could reuse existing > David> mib module functionality where possible, especially in terms of > David> scripting support, and so that other working groups could more easily > David> reuse some of the work being done in snmpconf. > > As have I. I also made comments a long time ago that the MIB should > have other-language support (specifically, I think I mentioned that it > was unlikely the language would come out perfect the first time and > that a completely new language might be needed in the future, without > deleting support the old at the same time). > > So, I have to agree with David There are _too_ many Davids :-) > that "late in the process" is a bit > misleading. Though, the WG did make the decision a long time ago to > not follow these opinions, and David But a _different_ David this time. :-) > is just restating old advise. It > doesn't make it more likely it'll be followed at this point though... I was going to respond to David H. earlier but travel got in the way... You are both correct that David H. has brought this up before. I realized that I had misspoke previously. Whoops! My apologies for failing to remember. David has certainly stated his opinion about a split before. Wes is also correct that the WG has previously decided at that time not to do so. Cheers, David