From owner-snmpconf@seymour39.SNMP.COM Sat Aug 5 08:56:42 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20999 for ; Sat, 5 Aug 2000 08:56:42 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id IAA24490 for snmpconf-outgoing; Sat, 5 Aug 2000 08:37:06 -0400 (EDT) Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB088C73BB@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: snmpconf@snmp.com, ietf@ietf.org Subject: snmpconf Found: a vaio ethernet cable Date: Sat, 5 Aug 2000 14:36:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com At the SNMPCONF seession on Firday Morning (Aug 4th) in South Room 2, in the last row of chairs, close to the door, we found such a cable. I have handed it to the IETF secretariat, so if you lost it contact them. Bert From owner-snmpconf@seymour39.SNMP.COM Mon Aug 7 11:09:32 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08365 for ; Mon, 7 Aug 2000 11:09:32 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id KAA02357 for snmpconf-outgoing; Mon, 7 Aug 2000 10:48:22 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 07 Aug 2000 10:49:44 -0400 Subject: snmpconf Summary of SNMPCONF Working Group Meeting From: Jon Saperia To: Bert Wijnen , Randy Bush , snmpconf , , Jon Saperia Message-ID: Mime-version: 1.0 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 The following is the required one paragraph summary of the SNMPCONF Working Group Meetings at the 48th IETF. The SNMPCONF working group met twice during the week and was attended by close to 200 people. On Tuesday there was a brief review of the agenda for the two working group sessions as well and a reminder and discussion about the interim meeting to be held immediately following the IETF. The rest of the Tuesday session included a presentation on the work that we are doing and the status of the three documents by Jon Saperia. Mike MacFaden lead a discussion on the Best Current Practices Document and several of the recommendations for general configuration. Jon followed with a few points on the sections of the BCP relating to policy and management software. We began a discussion lead by Steve Waldbusser of the items previously published to the working group which was continued in the Friday morning meeting. We reviewed issues related to the policy execution environment and the policy expression language. Part of the time on Friday was also used to discuss logistics for the interim meeting and talk about plans for future meetings. David Harrington Jon Saperia From owner-snmpconf@seymour39.SNMP.COM Mon Aug 7 11:58:45 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09450 for ; Mon, 7 Aug 2000 11:58:44 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA03923 for snmpconf-outgoing; Mon, 7 Aug 2000 11:42:24 -0400 (EDT) Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB08932858@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: snmpconf , Jon Saperia Cc: Randy Bush Subject: snmpconf RE: Summary of SNMPCONF Working Group Meeting Date: Mon, 7 Aug 2000 17:41:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Thanks Jon and Dave Bert From owner-snmpconf@seymour39.SNMP.COM Mon Aug 7 15:32:02 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16669 for ; Mon, 7 Aug 2000 15:32:01 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA12768 for snmpconf-outgoing; Mon, 7 Aug 2000 15:18:11 -0400 (EDT) Message-Id: <200008071918.PAA12761@seymour39.SNMP.COM> to: snmpconf@snmp.com Subject: snmpconf diffserv-mib Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Mon, 07 Aug 2000 15:18:09 -0400 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit [the following message bounced due to an address change] From: Harrie Hazewinkel Organization: Covalent technologies X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kwok Ho Chan CC: Fred Baker , diffserv@ietf.org, "Chan, Kwok-Ho" , Andrew Smith , snmpconf Subject: diffserv-mib References: <4.3.2.7.2.20000803154659.038d5340@127.0.0.1> <200008041440.KAA18190@pobox.engeast.BayNetworks.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, During the SNMPCONF interim meeting on friday I made a picture of how the structure of the DIFFSERV-MIB and the DIFFPOLICY-MIB. Kwok as editor of the diffserv mib and others were interested in having the pictures. They are now available at: http://public.covalent.net/ Here you find 2 pictures. 1) diffserv-mib.gif that represents the structure of pointers and links within the diffserv-mib. 2) the diffpolicy-mib.gif that would represent a possible setup of the diff-serv mib for configuration. With respect to the diff-policy-mib this will change a lot especially since the indexing (which was broken) of the diffserv-mib will be changed in the next release. Hope this is useful for the diffserv-mib editors as well the diff-policy-mib. NOTE: it is possible that I made errors. Harrie 0- Harrie Hazewinkel ---------------------------------------0 mailto:harrie@covalent.net phone:+1-415-536-5221 0-----------------------------------------------------------0 From owner-snmpconf@seymour39.SNMP.COM Tue Aug 8 09:45:38 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27121 for ; Tue, 8 Aug 2000 09:45:37 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA14676 for snmpconf-outgoing; Tue, 8 Aug 2000 09:25:35 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Tue, 08 Aug 2000 09:27:03 -0400 Subject: snmpconf Re: ipsec-cfg MIB From: Jon Saperia To: Ricky Charlet , ipsec-policy , snmpconf Message-ID: In-Reply-To: <398F1983.18C40730@redcreek.com> Mime-version: 1.0 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 on 08/07/2000 4:18 PM, Ricky Charlet at rcharlet@redcreek.com wrote: > Our work will conform to the IPsec Policy Model document as it morphs > its way toward standard (draft-ietf-ipsp-config-policy-model-01.txt). We > will also have assistance from the SNMP-CONF folks to help us conform to > best current practices and philosophies of SNMP-CONF. I spoke with a few > representatives in that community and got enthusiastic response. Hi, I have forwarded this to the SNMPCONF WG list as well since they are of course interested. I brought this issue up at our interim meeting this weekend and you are correct, there are people who are very interested in working with you on this task. I will ask one of them to make contact. /jon From owner-snmpconf@seymour39.SNMP.COM Tue Aug 8 15:41:43 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25857 for ; Tue, 8 Aug 2000 15:41:42 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA27483 for snmpconf-outgoing; Tue, 8 Aug 2000 15:19:13 -0400 (EDT) Message-ID: <39904F4F.60166184@redcreek.com> Date: Tue, 08 Aug 2000 12:19:59 -0600 From: Ricky Charlet Organization: Redcreek Communications X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: David Waitzman CC: ipsec-policy , snmpconf Subject: snmpconf Re: ipsec-cfg MIB References: <398F1983.18C40730@redcreek.com> <39902733.FD091245@bbn.com> <39902F4E.419347F1@redcreek.com> <39904198.2B7BD379@bbn.com> 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 David Waitzman wrote: > > I wrote: > > > The MIBs have some 4096 octet strings. Does this conform with the > > > current BCP for SNMP? I would have thought a much clumsier split of > > > the objects into >  > Ricky Charlet wrote: > > I'm very glad of your comment that we should focus on conforming to BPC > > of SNMPCONF as we develop the IPsec Policy MIB. But I have to admit that > > I can't pace your acronym 'MMS'. Could you explain further please? > > I was using "BCP" as in its generic sense of "Best Current Practice", > not referring to a particular draft. > > "MMS" means maximum message size, and limits the packet size, so if the > MMS is assumed to be 1500 or so octets, then a 4096 octet variable can't > ever fit. Early SNMPv1 assumed for safety an MMS of 484 bytes (a > minimum value that all managers/agents needed to work with)! RFC1351 > may have the first explicit definition of the term in SNMP space. > > He also wrote: > > The large majority of the octect strings are our "common names" (look > > at the Textual Convention we defined. These are used as indicies to all > > the tables. The reasons that we create these octet strings has to do > > with our managment software and its capabilities rather than any SNMP > > BPC. > > I understand. > > And he also wrote: > > That mib is a work for future Redcreek devices. I'd be glad to answer > > questions about it but not on this list. This discussion will have to be > > about the IETF work on a new IPsec Policy MIB. > > That means that you don't (yet) have proof by deployment that the MIB > works. That's quite ok and is just a useful data point if people > reading the MIB think they see problems of the form "how can this > possibly work"? > > -david Ah ha, Now I'm getting what you are talking about. Those 4K byte MIB objects are intended to hold certificates which have an undetermined maximum size. I think that you are proposing that overly large objects with unclear maximum sizes like these be downloaded to the device as a series of smaller blocks. I think the idea has merit. And I would be intersted in what folks in the SNMPCONF space have to say about a BCP when sending down very large objects to divices. Therefore, I am cross posting this to snmpconf@snmp.com -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-snmpconf@seymour39.SNMP.COM Sun Aug 13 18:00:18 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13299 for ; Sun, 13 Aug 2000 18:00:17 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA20318 for snmpconf-outgoing; Sun, 13 Aug 2000 17:36:13 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Sun, 13 Aug 2000 17:36:34 -0400 Subject: snmpconf Re: ipsec-cfg MIB From: Jon Saperia To: Ricky Charlet , David Waitzman , Mike MacFaden , Jon Saperia CC: ipsec-policy , snmpconf Message-ID: In-Reply-To: <39904F4F.60166184@redcreek.com> Mime-version: 1.0 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 on 08/08/2000 2:19 PM, Ricky Charlet at rcharlet@redcreek.com wrote: > Ah ha, Now I'm getting what you are talking about. Those 4K byte MIB > objects are intended to hold certificates which have an undetermined > maximum size. I think that you are proposing that overly large objects > with unclear maximum sizes like these be downloaded to the device as a > series of smaller blocks. I think the idea has merit. And I would be > intersted in what folks in the SNMPCONF space have to say about a BCP > when sending down very large objects to divices. Therefore, I am cross > posting this to snmpconf@snmp.com I have now caught up on this thread. Beyond IPSec MIB Module questions and a IPSec Policy MIB Module, the question raised above is a general one. I have copied Mike MacFaden who is my co-author on the SNMCONF BCP. This discussion points to a deficiency in the BCP in that we do not discuss the issue of single data elements that are potentially larger than a single PDU. We discuss in terms of MIB design and manager/agent interactions multi-PDU transactions - more work needs to be done here as well. Specific suggestions for how to best deal with this with the current architecture are welcome. /jon From owner-snmpconf@seymour39.SNMP.COM Mon Aug 14 14:54:34 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17119 for ; Mon, 14 Aug 2000 14:54:34 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id NAA01529 for snmpconf-outgoing; Mon, 14 Aug 2000 13:21:49 -0400 (EDT) Message-Id: <4.3.2.7.1.20000814095859.034da6f8@mordor> X-Sender: mrm@mordor X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Aug 2000 10:23:37 -0700 To: Jon Saperia , Ricky Charlet , David Waitzman , Jon Saperia From: Michael MacFaden Subject: snmpconf Re: ipsec-cfg MIB Cc: ipsec-policy , snmpconf In-Reply-To: References: <39904F4F.60166184@redcreek.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 Hi, So four courses of action come to mind and there are probably others/combinations. Have all of them been discussed besides #3? Choice 1: Use the universal type "octet string" Pro: Simple to understand, follows requirement of not making mgmt itself more difficult than technology being managed. Con: Any PDU carrying this object will exceed MTU, bad performance results Certificate size is implicitly bounded at 65535 bytes per rfc 2578 pg 6 Choice 2: Use a form of indirection, abstract the certs in the mib Pro: Follows the first bcp - use the "correct level of abstraction" Certificates are not artificially limited in size Con: Problem of actually getting the certificate transferred not solved. Choice 3: Break Certificate into smaller chunks How done: A table could list the certs, and operations can move a cert into a distribution table that would then have major and minor index and some discussion on how to break apart/glue the certs into rows. Pro: Certificates are not artificially limited in size Con: Manipulating certificates becomes painful, and scaling to large number of certs will be difficult. Choice 4: Punt and wait for bulk transfer to be resolved in some future SNMP wg pro: A standard and non painful way of transferring arbitrarily large objects exists won't be a problem to migrate to. con: Certs handled in non-standard way until such a standard exists Regards, Mike MacFaden www.riverstonenet.com At 05:36 PM 8/13/2000 -0400, Jon Saperia wrote: >Now I'm getting what you are talking about. Those 4K byte MIB > > objects are intended to hold certificates which have an undetermined > > maximum size. I think that you are proposing that overly large objects > > with unclear maximum sizes like these be downloaded to the device as a > > series of smaller blocks. I think the idea has merit. And I would be > > intersted in what folks in the SNMPCONF space have to say about a BCP > > when sending down very large objects to divices. Therefore, I am cross > > posting this to snmpconf@snmp.com > >I have now caught up on this thread. Beyond IPSec MIB Module questions and a >IPSec Policy MIB Module, the question raised above is a general one. I have >copied Mike MacFaden who is my co-author on the SNMCONF BCP. This discussion >points to a deficiency in the BCP in that we do not discuss the issue of >single data elements that are potentially larger than a single PDU. We >discuss in terms of MIB design and manager/agent interactions multi-PDU >transactions - more work needs to be done here as well. > >Specific suggestions for how to best deal with this with the current >architecture are welcome. From owner-snmpconf@seymour39.SNMP.COM Mon Aug 14 14:54:36 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17129 for ; Mon, 14 Aug 2000 14:54:35 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id OAA03655 for snmpconf-outgoing; Mon, 14 Aug 2000 14:30:03 -0400 (EDT) From: remoore@us.ibm.com X-Lotus-FromDomain: IBMUS To: Michael MacFaden cc: Jon Saperia , Ricky Charlet , David Waitzman , ipsec-policy , snmpconf Message-ID: <8525693B.00658A69.00@d54mta02.raleigh.ibm.com> Date: Mon, 14 Aug 2000 14:29:39 -0400 Subject: snmpconf Re: ipsec-cfg MIB Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com > Choice 3: Break Certificate into smaller chunks It's several years old, but we did a chop-and-glue implementation for SNA/MS Alerts that was easy to define and implement, and has worked just fine. The MIB modules we used are available at the following URL, which you'll have to reassemble manually: ftp://ftp.networking.ibm.com/pub/standards/aiw/ snasnmp/alertmgr.mib-modules.txt The only problem we've had with this function is explaining to people why they can't configure an ordinary SNMP manager to do something useful with these traps. The reason is that once you've glued the pieces back together at the manager, you've got a complete SNA/MS Alert, which requires a specialized application to understand it. You'll have the same problem if you glue a cert back together, but I think that in this case people will expect it to require a special application to interpret the cert. Anyway, all I wanted to focus on now was the chopping and gluing. Note that the way we did it was to define a doubly indexed table with one accessible column. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com From owner-snmpconf@seymour39.SNMP.COM Fri Aug 18 04:07:51 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24935 for ; Fri, 18 Aug 2000 04:07:50 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id DAA15578 for snmpconf-outgoing; Fri, 18 Aug 2000 03:48:06 -0400 (EDT) From: "Andrea Westerinen" To: "Snmpconf@Snmp. Com" Subject: snmpconf Policy Terminology Draft Date: Fri, 18 Aug 2000 00:51:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit The Policy Framework WG has created an I-D to try to disambiguate policy terminology across all IETF Work Groups. This draft is located at: http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-00.txt In creating the draft, the team tried to look across all RFCs and WGs to gain an understanding of policy and its applicability, and consolidate definitions. At the Pittsburgh Policy Framework session, it was recommended that this draft be forwarded to all work groups where it may be applicable. (If you receive multiple copies, my apologies.) Please look the draft over, and if you have feedback, please reply to me and/or to the policy mail list (policy@raleigh.ibm.com). Some questions to be considered are ... Are there definitions that should be updated? Are there additional terms that should be defined? For the current terms in the draft, please try to use these terms consistently. Our goal is to take this draft through the standards process and have it serve a function similar to RFC2828. Thanks. Andrea Westerinen Policy Terminology Draft Editor From owner-snmpconf@seymour39.SNMP.COM Thu Aug 24 16:04:44 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23303 for ; Thu, 24 Aug 2000 16:04:43 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA10057 for snmpconf-outgoing; Thu, 24 Aug 2000 15:36:51 -0400 (EDT) From: Dale Francisco Message-Id: <200008241935.MAA24812@itech-view2.cisco.com> Subject: Minutes from the IETF-48 snmpconf meetings To: proceedings@ietf.org, snmpconf@snmp.com Date: Thu, 24 Aug 2000 12:35:44 -0700 (PDT) Cc: moulton@snmp.com, saperia@mediaone.net, dbh@enterasys.com, dfrancis@cisco.com (Dale Francisco) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 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 Minutes from the meetings of the snmpconf WG at IETF-48 will go out (at the latest) the morning of Friday, Aug 25. I apologize for the delay. Regards, Dale --- /// Dale Francisco IOS Network Management Protocols \\\ Cisco Systems dfrancis@cisco.com /// 170 W Tasman Dr SJCM/2 voice: (408) 527-9787 \\\ San Jose CA 95134-1714 USA fax: (408) 527-2477 From owner-snmpconf@seymour39.SNMP.COM Mon Aug 28 10:48:44 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11337 for ; Mon, 28 Aug 2000 10:48:43 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id KAA15096 for snmpconf-outgoing; Mon, 28 Aug 2000 10:22:19 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 28 Aug 2000 10:24:29 -0400 Subject: snmpconf Comments on the draft-ietf-policy-terminology-00.txt document From: Jon Saperia To: , snmpconf Message-ID: Mime-version: 1.0 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 Here are some comments on the recent draft. Sorry for the cross posting. I know that some on the SNMPCONF WG list are not on the policy list. On Page 3: > - "M" identifies various mechanisms to create or convey policy- > related information in a network. For example, COPS and an > "Information Model" are two mechanisms for communicating and > describing policy-related data. Perhaps we need another term. Mechanism has come to be used in the context of a technology used to realize a particular policy in a policy domain. An example would be RED or WRED in DiffServ of BGP Policy in the Routing Policy domain. In addition, there are several places in the document (see also page 7) that would benefit from a clearer expansion of the terms that are currently in use in terms of levels of abstraction. At present 4 levels of abstraction have been defined and are now in common use in the SNMPCONF documents. They are: 1. Domain Specific. 2. Mechanism Specific 3. Implementation Specific 4. Instance Specific Rather than quote the entirety of these terms, here are the reference IDs: draft-ietf-snmpconf-diffpolicy-02.txt draft-ietf-snmpconf-bcp-02.txt Additional background information is found in: draft-saperia-policysnmp-00.txt I believe that community will be well served by a common set of terms as they relate to these levels of abstraction. On Page 4 > Common Open Policy System (COPS) I have no issue with the inclusion of this specific mechanism and components of its architecture such as PDPs and PEPs. To the extent that we choose to define such technologies in this document, we should also define the SNMP-based ones as well and it based documents - those references are pretty well known. With regard to SNMPCONF specific items this document should also include items such as: Policy MIB Module Mechanism and Implementation Specific MIB Modules Policy Management Application (see above references) Also on Page 4 > configuration I found this paragraph a bit confusing. The telco industry uses configuration to refer to parameters that 'are set at the factory' and are not generally changeable by the customer. Provisioning refers to those parameters that are customer changeable. I think there is a useful concept in the paragraph which points to user or provisioning system(s) setting of object values versus those that are dynamic or run time. The best example I can give is in the routing are where a set of BGP or OSPF configuration values are set by the user, but the routing information is continuously changing while the system is running. On Page 5. > Directory Enabled Networks (DEN) My issue is not the inclusion or definition. I would like for us to have generic terms that are not dependent on the DMTF as well. For example what shall we call the general data model that is not LDAP specific? Since this is an IETF document, I think we should not only reference the work that the document is based on, but the technology over which we have change control and will use, perhaps in addition to other technologies. On pages 7, 9, 11 and 12: Terms such as policy condition, policy action, policy rule, role and role combination. I assume this document will be revised to reflect discussions that came out of the IETF meeting to resolve term conflicts that Andrea and Steve Waldbusser and others have had. I have not seen documentation of these discussions and look forward to those clarifications. Page 9 > Policy Information Base (PIB) Same comment as before. No issue with definition, we just need to add the SNMP counterparts. Page 10 > policy server I do have an issue with this definition. It states: > (P) A marketing term whose definition is imprecise. Originally, > [R2753] referenced a "policy server." As the RFC evolved, this > term became more precise and known as the Policy Decision Point > (PDP). Today, the term is used in marketing and other > literature to refer specifically to a PDP, or for any entity > that uses/services policy. In the SNMPCONF work we have been using policy application for some time since PDP and PEP have a very specific and sometimes different set of behaviors than SNMP. Also on Page 10. > PolicyRepository I feel this should be a generic term since many people will store the information cited in systems and formats not common to PCIM or CIM. These comments aside. The document is a good start and will be quite helpful. /jon From owner-snmpconf@seymour39.SNMP.COM Tue Aug 29 18:56:09 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02311 for ; Tue, 29 Aug 2000 18:56:08 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id SAA18192 for snmpconf-outgoing; Tue, 29 Aug 2000 18:40:21 -0400 (EDT) From: Dale Francisco Message-Id: <200008292239.PAA21497@itech-view2.cisco.com> Subject: snmpconf Meeting minutes and slides from IETF-48 To: snmpconf@snmp.com Date: Tue, 29 Aug 2000 15:39:45 -0700 (PDT) Cc: dfrancis@cisco.com (Dale Francisco) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 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 A little late, but I've finally forwarded to the IETF the meeting minutes and slides from the Tuesday and Friday morning meetings at IETF-48. In two subsequent e-mails, I'll send the minutes to the list. Steve Moulton at SNMP Research has kindly offered to make the slides available on their website later this week. Dale From owner-snmpconf@seymour39.SNMP.COM Tue Aug 29 18:56:12 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02321 for ; Tue, 29 Aug 2000 18:56:11 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id SAA18257 for snmpconf-outgoing; Tue, 29 Aug 2000 18:42:34 -0400 (EDT) From: Dale Francisco Message-Id: <200008292241.PAA22471@itech-view2.cisco.com> Subject: IETF 48 Pittsburgh snmpconf Tue 0900 1 Aug 2000 To: snmpconf@snmp.com Date: Tue, 29 Aug 2000 15:41:59 -0700 (PDT) Cc: dfrancis@cisco.com (Dale Francisco) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 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 IETF 48 Pittsburgh snmpconf Tue 0900 1 Aug 2000 Reported by Dale Francisco (dfrancis@cisco.com), Rob Frye (rfrye@longsys.com), and Steve Moulton (moulton@snmp.com). Summary ======= The bulk of the Tuesday morning meeting was devoted to Jon Saperia's presentation "Configuration Management with SNMP: SNMPCONF WG Status" (see also accompanying slides), and discussion of the topics he raised. Then Mike MacFaden and Jon discussed the BCP doc "Configuring Networks and Devices with SNMP" (draft-ietf-snmpconf-bcp-02.txt). Finally, Steve Waldbusser began his presentation on "Policy Processing Questions" originally scheduled to begin at the Friday meeting. Attributions ============ Andrea == Andrea Westerinen andreaw@cisco.com Andy == Andy Bierman abierman@cisco.com Case == Jeff Case case@snmp.com Dan == Dan Romascanu dromasca@lucent.com Harrington == Dave Harrington dbh@enterasys.com Jon == Jon Saperia saperia@mediaone.net Juergen == Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de> Mike == Mike MacFaden mrm@riverstonenet.com Partain == Dave Partain David.Partain@ericsson.com Randy == Randy Presuhn Randy_Presuhn@bmc.com Shai == Shai Herzog herzog@iphighway.com Steve == Steve Waldbusser waldbusser@nextbeacon.com Jon Saperia began his presentation with an agenda: - Review of charter, goals, and work items. - Policy management with SNMP: Goals, Terms and Operational Model - Policy-based Management MIB Module: quick status and work items. - DiffServ Policy MIB Module: quick status and work items. Jon went on to discuss the wg charter, goals and work items. The overall goal is to improve the utility of SNMP as a configuration management framework. In support of this goal, the wg will add MIB objects to support policy-based provisioning concepts. Work items include: - Best Current Practices document for configuration using SNMP and for documenting policy-based work - Policy Management MIB module - DiffServ Policy MIB module Jon argued that it made sense to use a common framework (SNMP) for all management activities, in order to achieve benefits of efficiency and scale, and to leverage existing knowledge and software. There will also be operational benefits from integration of configuration data with other data such as that from performance and fault monitoring. The wg approach will involve adding MIB modules at different levels of abstraction. Jon proposed defining those levels as: Domain: A domain is a general area of technology such as service quality or security. Services, or service level agreements, may span several domains, each of them potentially including many policies. Generally people will not discuss these domains in the abstract. They will most often use technology or application-specific examples. Examples include IPSec and Differentiated Services. Mechanism: A mechanism is a management technology over a domain--the dials that you turn to affect a domain. Comprises standard MIB modules. Implementation: Vendors may define implementation-specific parameters to augment a standard set of mechanism-specific parameters. These vendor-specific extensions are described in private (enterprise) MIB modules. Instance--The low-level details; the actual parameter values associated with particular instances of a managed element. It is useful to have _all_ of these levels represented. Jon proceeded to define terminology for policy-based management using SNMP: Policy-based management: The practice of applying management operations globally on all managed objects that share certain attributes. Policy: The association of a boolean filter that selects objects with an operation to be performed on those objects. Expressed as: if (policyFilter) then (policyAction). Filter: A boolean expression that determines if an object is a member of a set of objects upon which an action is to be performed. Action: An operation performed on a set of objects (efficiency gain--don't set individual instances). Role: An abstract characteristic assigned to an element that expresses a notion such as political, financial, legal, or geographical association; a way of identifying who gets a particular QoS, for example. Element: A uniquely addressable entity on a managed device. Jon described the inputs to managers (slide #9, Policy Management with SNMP: Operational Model--Applications): Roles, schedules (only want something to be true at certain times), filters (for a particular policy, select only these elements), and actions (mechanism and implementation-specific info). Managed elements include capabilities, capacity info, utilization, and other state info. For example: The House Lighting MIB module. A table might have light intensity and other parameters for every light in house. Next level of abstraction: Mechanism specific: House lighting Policy MIB module Next level: Policy based Mgmt MIB module (communicates w/ other modules as needed) Note: The standard, low-level management framework is unchanged. Policy mgmt is just an overlay. Jon then gave the current status of the Policy-Based Mgmt MIB module: draft-ietf-snmpconf-02 published in July. Modifications to capabilities table - pointer to mechanism- and technology-specific modules - support for implementations with restricted capabilities (how does a system tell the world it supports WRED, or security, but with exceptions?). General functional questions: - policy precedence - notifications (if there's a config change, should tell system) - policy override mechanisms Execution environment (scheduling) Policy expression issues (versioning, extensibility) Architectural relationship w/ other docs e.g., interaction w/ mechanism- and implementation-specific modules Conflict resolution Jon then gave status on the DiffServ Policy MIB module: draft-ietf-snmpconf-diffpolicy-02.txt, published in June. Work items: - Ongoing sync with QoS device model - Ongoing sync with DiffServ MIB - Expansion of how module relates to other MIB modules - Better usage examples - Integration of state, other info Then followed discussion on Jon's presentation: Partain: In slide 10 ("Policy Management with SNMP: Agents", using the House Lighting MIB example) I'd like to restate the terminology to see if I understand it. The "House Lighting MIB module" is the nuts and bolts--what we SNMP IETF people love. The "House Lighting Policy MIB module" is a template for operations (e.g. vacation lighting policy). The "Policy Based Management MIB module" sets up filters/mechanisms (a role might be "edge light"). Dan: I have a question about the different definition of "role" (different from PIB/COPS). I better understand the COPS one. Jon: We talked about this: a role can be an arbitrarily assigned attribute of an element. Dan: Other definition: A role is a selector for policy rules that determines the applicability of a policy to a network element. Jon: My sense is that they don't mean exactly the same thing. Andrea: Why don't we work together and come up with a better word? "Role" means function in COPS world. Steve: They really are different things. In COPS, a role is the entire selector for whether policy applies to a particular element. In snmpconf, we draw on many variables (e.g. ifAdminStatus) for selection; "roles" are "special", high-level notions only known by humans. Maybe we need another word. Shai: "Role" is a problematic usage. COPS already has this well-defined. No reason to twist an existing term. Jon: Someone will contact Andrea to work with her on syncing terminology. Next, Mike MacFaden discussed the BCP document "Configuring Networks and Devices with SNMP" (draft-ietf-snmpconf-bcp-02.txt). The goals are to: - Document what we already know - Document BCPs in the use of SNMP as a configuration tool, and correct misperceptions about SNMP-based configuration and policy. Illustrate the practices through examples. - Highlight application and MIB module design choices to produce efficient and effective configuration mgmt systems. - Update general knowledge of SNMP-based mgmt to the year 2000. The intended audience is network vendors and people who design and deploy MIBs. Some MIB design guidelines: Distinguish row creation from activation; need to make explicit the effect a change has on the stability of a system under configuration. Newer MIBs often provide objects to turn all or some features off. Turning off is better than removing. Design in ability to save the active config easily. It's nice to have clear separation of config variables from others. One idea is to use MIB design convention of groupings. What do I have to save from a MIB in order to capture active config? A BCP would state how to partition the config info. Don't use OCTET-STRINGs to aggregate multiple objects. Does this conflict with PortList TC? No...that's a good example of efficient containerization. Specify an upper limit on the number of traps that can be sent in response to a given event. The effects of configuration can generate an inordinate number of notification events. E.g., when an FR link is set admin down, don't need to send down traps on each DLCI. Provide user controls to avoid cascading notifications due to hierarchies. When possible, specify a notification equivalent to the layer being configured. Provide a mechanism that can control lower layer notifications e.g., ifLinkUpDownEnable. (Otherwise things could get bad in policy changes, where you change lots of things at once.) Provide user controls to avoid a flood of notifications due to parallel notifications, e.g., a line card w/ 400 IFs goes down--just need one trap for the "containing" object. Persistence of config objects should be well specified. Consider using StorageType TC as opposed to using DESCRIPTIONS. e.g., disman schedule MIB. Alternate approach: defining static config tables. Design w/ multiple managers in mind (provide appropriate locking mechanisms, such as spinlock, ownerstring). Define read-write objs at "right" level of abstraction. Too many instances to configure may mean abstracting the mgmt interface. A lot of MIBs have too many details--if I have to config 1000 rows to put ACLs on my router, I probably won't use SNMP. Randy: Providing individual controls on generation of notifications at the MIB level interacts with the Notification Log MIB and access control in 2575, seems like it invites a multi-manager problem. Discussion: Jon: One clarification: Wrt notifications, you want to create them at the appropriate level of abstraction. Some things shouldn't be notifiable (e.g. queue depth change). Try to decide where does it make sense to have a notification, then choose level. Jon Saperia then continued with discussion of the BCP doc. More recommendations include: Management software: Make SET PDUs as efficient as possible by grouping as many varbinds as makes sense. Take advantage of AGENT-CAPS if available. Make config ops as parallel as possible (support concurrent Sets as makes sense). Use notifications to relate changed configuration to one or more mgmt stations. (ability to timestamp, rollback, etc.) Policy management: Provide implementation-specific MIB objects if instance-specific vendor extensions have been made. Policy mgmt apps should determine the time-keeping abilities of managed systems. E.g., could either have the mgmt app send down policy at particular times, or have devices that know what time it is turn policy on at particular time. A notification should be sent when a policy override occurs. Overrides may be necessary, but when allowed, need to let mgr know. Q: On making sets as large as possible: You need to know more about the device before you can know if an entire Set of varbinds will work together. So sometimes conservative policy is best. Harrington: If you send large SET packets, you can tie up bandwidth (v1) figuring out what went wrong. Perkins: Business logic is duplicated in the mgr app as well as agent. If I decide to change rules, I need to update in two places. It's been proposed over the past 10 years that SETS could return an app-level error, so that business logic could be done in agent. Agent might return "can't do this op because of constraints X,Y,Z". Jon: Agent error reporting for config ops would be useful. Perkins: Access control is very fine-grained in SNMP. It's hard to relate from a user point of view what I need to config in VACM to perform high-level operations. Q: You say it's necessary to notify when config changes or when there's a policy override. Are they really different? Jon: Not every element in a system is necessarily under policy control. So if something isn't under policy control, you need to send config change trap. Secondly, the policy override is meant to keep the policy mgmt system informed about things it thinks it controls being temporarily removed from its control. Q: About throttling notifications. Would be nice to have mgrs subscribe to different sets of traps. More flexibility. Juergen: Need better specifications in MIB docs. Procedures for app writers on proper sequence of SET ops. So really need better documentation in MIB. Perkins: I support that, I typically advise that the table DESCRIPTION tells meta-level info (e.g. if you have this many slots, you have this many rows), ROW description gives entry-specific info. Andy: One of the big problems with SETs is arbitrary and incomplete rows that you need to handle. (E.g., many set requests for different rows in 11 different tables, all bundled in one SET PDU). We could get rid of a lot of this complexity. BCP touched on rowStatus and how many items in a PDU. We really should address this in the SMI. Randy: Regarding complex SET requests--the infamous "as if" simultaneous requirement in the protocol is the root cause. Andy: About the House lighting MIB and House lighting Policy MIB...why not just add a table to the House Lighting MIB? House lighting MIB could have templates. Not clear how there's a reduction of work in having two MIBs. You still need to have perfect knowledge of the low-level MIB to do the Policy MIB. As there was time remaining, the wg moved on to Friday agenda items, with a presentation on "Policy Processing Questions" by Steve Waldbusser: 1) An agent that gets a bad policy should do the right thing, where the right thing is TBD. A bad policy is one that has a syntax error or that creates a processing error. The right thing is terminate immediately. 2) Expression examples would be helpful (the new draft is OK in this). 3) How do we handle syntax errors? Harrington: Need clarification: syntax errors at processing time vs load time. Andy: Delay of syntax error returns goes against SNMP approaches to have SNMP agent reply about success/failure of SETs immediately - Can a management station step through an expression statement to find errors? No. - An agent can't reasonably go through every code path in a script to look for potential errors & return such at SET time. - To the extent that these are described in BNF, the agent should be able to verify that they adhere to the language (BNF) syntax without evaluating correctness. - Is there value in doing the check at SET time? Limited value. - Protecting the agent from overruns is different from other types of checking of valid operations. 4) How do we handle run time exceptions? How many errors are OK in a policy? (0?) 5) How to deal with partial failures and notifications thereof? 6) Different types of exceptions, e.g. divide-by-zero or system failures--how to handle different error severities? Juergen: What is the relationship of this work to the disman Script and Expression MIBs? Steve: They are different to address different (though similar) problems Case: There are strong similarities between disman and this work. Randy: Why are there scripts? Steve: Network operators are comfortable with the use of scripts. 7) What is the role of the management application in evaluating expressions? 8) What type of error reporting from agents is required? The meeting adjourned for further discussion on Friday. From owner-snmpconf@seymour39.SNMP.COM Tue Aug 29 19:01:19 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02451 for ; Tue, 29 Aug 2000 19:01:18 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id SAA18333 for snmpconf-outgoing; Tue, 29 Aug 2000 18:45:06 -0400 (EDT) From: Dale Francisco Message-Id: <200008292244.PAA23934@itech-view2.cisco.com> Subject: IETF 48 Pittsburgh snmpconf Fri 1130 4 Aug 2000 To: snmpconf@snmp.com Date: Tue, 29 Aug 2000 15:44:31 -0700 (PDT) Cc: dfrancis@cisco.com (Dale Francisco) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 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 IETF 48 Pittsburgh snmpconf Fri 1130 4 Aug 2000 Reported by Dale Francisco (dfrancis@cisco.com) and Steve Moulton (moulton@snmp.com). Summary ======= Continued with Steve Waldbusser's presentation, in the section "Policy Processing Questions". We resumed discussion at question (9). After completing this section, we moved on to "Execution Environment Questions", then "Language Related Questions". The questions that generated the most discussion were on how to select instances in filters (Policy Processing questions 21-23 below), and whether the language and the accessor functions should be extensible (Language Related question 4 below). We decided that the next interim meeting would be in Knoxville, TN, hosted by SNMP Research. Attributions ============ Andy == Andy Bierman abierman@cisco.com Bert == Bert Wijnen bwijnen@lucent.com Case == Jeff Case case@snmp.com Harrington == Dave Harrington dbh@enterasys.com Joel == Joel Halpern joel@omniplex.mcquillan.com Jon == Jon Saperia saperia@mediaone.net Partain == Dave Partain David.Partain@ericsson.com Randy == Randy Presuhn Randy_Presuhn@bmc.com Steve == Steve Waldbusser waldbusser@nextbeacon.com Policy Processing Questions =========================== 9) Is it a requirement that we support UTF8 in our accessor functions? Randy Presuhn will work with Steve on this. 10) Do we want to feed values from filters into policy action? E.g., suppose there's filtering on interfaces, and say I/Fs 1, 2, fail, but I/F 3 succeeds...should there be any state variables that linger from the earlier, failed processing? And after we get a return value do we want to fire an action, and if so with a param other than true/false? Andy: Suppose I go through RMON control table where ifIndex is a columnar value, not an index...how would I pass this into an action? Steve: The same way the filter got it. 11) Is the constraint of left and right useful (cleavage into two scripts, filter and action)? Jon: One of the compelling reasons for keeping them separate is it may be handy to do the eval on left side at a different time than eval on right side, especially if one or the other is computationally complex. Left decides what policy applies to. Steve: Another advantage is code reuse. E.g., imagine an icon for "select all enet I/Fs", drag to left, "turn off all I/Fs", drag to right. Also, Policy group supports this split. 12) Do we need both action and filter or would one do? What are the interactions allowed? This just restates questions 10 and 11. There was no further discussion on this. 13) Need to address the question of the syntax of an identifier, what is the proper syntax of ifType.$1--what is the structure including wildcarding? Steve: Does anyone want a different syntax? I'd like to prove what we're doing is inefficient before changing it. Joel: How do we handle wildcarding on multiple indices? Will they each get a wildcard? Steve: They should, the design isn't finished yet. 14) What are implications of wildcarding and implications in both directions in the role tables? Steve: I can't remember what this one meant. Joel: Larger issue: We're trying to build a solution, but what if there are base attributes that are used by both alternatives [snmpconf and rap]. "Role" is particularly problematic. I would like to have one table where roles are dealt with, i.e., not different than what rap group is doing. Steve: In a offline activity, we're working with rap to either resolve the identity or come up with different names. Joel: It'd be nice if were easy to factor out the simple cases of role use. Steve: What we called assertions...as we go through usage examples, we may find it'll be difficult for a manager to look at a filter and know whether it should be downloaded to a system...but you do know what roles and capabilities are on a system. "Assertion" is a term for pulling some terms of a filter out that would allow a mgmt station to know it didn't need to download a particular policy. Case: Wildcarding has been used in two places. One associated with roles, one with identifiers. Item #14 really isn't about roles, it's about identifiers. With roles: How do you do roles and role combinations? #14 is suppose you had a table that's not the ifTable that has two indexes, and you want to wildcard over one and hold the other constant. Another person asked what is the balance between complexity and functionality (is wildcarding too expensive?). Jon: I'm keeping a list of side topics such as assertions and roles for Saturday afternoon. 15) How big should an expression be allowed to be? Steve: No larger than necessary [laughter]. Most filters will be 1 or 2 or 3 lines, so I picked something very high (65k). Jon: I think that's fine for now. We can express local limitations using the CAPS file if desired. So different vendors with different memory constraints can restrict as necessary. 16) Not possible to download all policies everywhere. Must subset what to send, so must handle two errors: download superfluous policy, fail to download needed policy. Steve: Two cases: (1) False positive (superfluous download)...filter never executes on that system. False negative would have operational impact (didn't download something that was needed...if it had been, it would have executed). Assertions will make it easier to decide what to download, but haven't heard an idea of how to prevent false negatives. Case: This is more something that should be observed than something we need to worry about. Just need to alert the readers. This really isn't an open issue. Randy: I agree with what Jeff just said, also feel that we need to be careful about saying whether or not it's a problem. If we try to determine whether a filter could ever be true, it gets messy, possibly even not computable with a sufficiently powerful filter language. 17) How do we detect and how to standardize error handling? Steve: No text yet on notifications of errors (not necessarily SNMP notifications, but even just error counting variables)...will investigate further. Randy: Should look at history of script and expression MIBs...this is a deceptively devilish problem. This has some things in common with both of them. 18) Estimate the # of policies we need to handle. We need the architecture to scale up and down--what attribs needed to meet the goals? Jon: Start collecting usage scenarios, need a base level understanding of how many expressions are out there, how large they'd be, accessor functions. Anyone who has experience in this area please get in touch with Steve...any volunteers? [No response.] 19) Where to start the policy evaluation? Steve: That is, is the role the first thing to evaluate in order to reduce computation? (Move role comparison to front of filter to short-circuit evaluation). Should this be in the form of a recommendation? Role table and element table help bound the problem. Jon: Even as we get more examples, we may want to modify Rules for Filter writers. What is the general sequence of events that a policy mgr takes to get a policy properly executing..."This is how the system works start to finish." Case: All of these questions are subitems of "What does the execution environment look like?". 19-24 are all related. 20) How often to eval filter and when? Steve: Don't want to leave this completely up to agent. Need to specify on a policy-by-policy basis. Straw proposal: 2 new objects, filterMaxLatency, actionMaxLatency. Not the time between when a policy executes on I/F 7 and I/F 8, but on the same I/F. Agent is free to execute filters and actions in any order. Harrington: On ordering, if I write an action that has Sets, is that not guaranteed order? Steve: No, within an action, order of execution is assured. Harrington: Just for sanity's sake, should we add language saying that agent is ultimate arbiter of timing? Randy: Language that can be stolen from Expression MIB. 21) Is the iterator inside or outside the filter statement? Steve: E.g., should the expression have a for-loop that would iterate through interfaces? I think it's a bad idea. How to find instances quickly is something that the execution environment should provide. Harrington: I think it may be clearer for people to be allowed to write iterators. Steve: It may take some mindset change to think in terms of policy rather than iterators. 22) Is one iterator sufficient or do we need nested iterators? [same as 21]. 23) How do we select instances? Steve: Execution environment hands elements to filter. That's how we know what "this" element is. Jon: I think we'd had discussions where it was the method that was used to select from all possible objects... Steve: Right, this was the element type registration table. A way for mgmt station to download to agent what elements it wants under policy control. Agent doesn't know (out of the box) whether policies are executed on I/Fs, circuits, whatevers. This table provides the OID of say, right up to ifIndex. The agent conceptually does a walk of that OID, comes up with a hit for every I/F instance. Jon: One thing that isn't covered is shortlived instances. Steve: This table is just a way to describe to the system things it doesn't understand. It would be difficult to create a standard set of element types. Shouldn't confuse conceptual algorithm with how agent implements it. Text allows for builtin element types, so e.g. for ifIndex, it already knows how to handle objects in this table. I.e., not a polling arch. Randy: Just know the base OID doesn't give you the info to get to indices..they're not self-describing. Steve: This system treats the OIDs opaquely. Treats suffixes opaquely as well, whether one subid or many. Suppose FR circuit table, 1.111, 1.112, 5.317 (ifIndex, DLCI). $1==1, $2==111. Randy: Isn't it then possible to derive from the filter expression itself the contents of this table? Steve: Yes, sigh. It's not artificial intelligence, but it's close. Randy: At expression download time, you look for the OIDs that this filter expression cares about, that gives you the element types that the table needs. If the filter expression needs to know how the indexes are composed, then the filter is required to know what the element name is. If ifOperStatus is in the filter exp, then you know ifTable is an element type. Steve: Doesn't that make your brain hurt? We haven't discussed expressions that effect things that contain things that they work on (e.g., touching the parent ifIndex of an FR circuit). Randy: Is the type table necessary to evaluate the filter expressions? If there's sufficient info in the filter itself, than the type table is superfluous. You need a way of specifying the iteration context per filter--if you have that, the table is superfluous. If there's always a (type==something), the table is superfluous. Steve: I'll take an action item to see if I can get comfortable with it. Randy: I think that since all your expressions have a "type==something", that says something about the structure of the filters. Steve: Autoregistering element types by inspection of policy filters (especially if there's a mandatory "type==something"). 24) What do we want for role--iterators...how many, where? [No comments.] Execution Environment Questions =============================== 1) What are the implementation target environment requirements for the work? Steve: E.g., what's the size of 'int'? Don't want people to have to check ints with sizeof() every time they use them. Still not entirely defined...please send notes to mailing list when you find things like this. 2) What are minimal requirements for systems that participate in policy configuration? Steve: E.g., date and time? Jon: I wanted to ask...I think we want elements to execute on internal schedules, but do we want to allow a model of operation where the managed device says "I don't have date and time, so you have to do it for me"? Randy: I think it's a deployment decision on whether time is local or distributed. Jon: Architecturally we shouldn't add a constraint. 3) Would like a clearer definition of what "this element" is. [No comments.] 4) What's the scheduling environment? [No comments.] Language Related Questions ========================== 1) Language for expressions: Do we want to use an existing one? Do we want to create a new one? Steve: We've been given a directive that we're not allowed to define a new language. The IESG will look askance if we do so. So instead, let's subset an existing language. There's a BNF in the doc that shows a subset of ANSI C. The BNF doesn't fully describe the syntax. Normative reference to ANSI C. Would subset of C or subset of PERL be better? What we have is such a restricted subset of C that I think it's also PERL [laughter]. There is no normative ref for PERL, and the PERL5 to PERL6 is a huge non-backward-compatible change, so I think C really is the right choice. Case: Primary difference between having two identical grammars (subset of C / subset of PERL) is marketing. You're concerned that it's true, and we're talking about marketing. Joel: I think we need this level of complexity, but I think we need to spell out exactly why we need this level of richness. Steve: I agree. We'll come up with a list of examples, learn and realize what's only achievable through this langauage, then write down rationale. Randy: There's a rather PERL-like script language that BMC has used for years that has a normative ref in an ISO standard. SMSL is the name...one of the language for ISO command sequencer stuff. May or may not be useful, but thought I should mention it. 2) Temp variables? Garbage collection? [No comments] 3) Is UTF8 required? Randy: Anything outside the 7-bit range gets entered as multiple "\" escaped sequences if we're using subset of C. Case: We have to be sensitive to internationalization issues, it has to be UTF8, other schemes wouldn't be good. If we decided to support C except for UTF8, I don't think the IESG would shoot us down. So let's just do good engineering and it'll work out. Joel: IESG mandate is that we shall internationalize. We need to know how to put UTF8 strings in expressions, but _not_ in variable names. Randy: there are languages that allow UTF8 variable names, and in some dev environments that's useful. Steve: Randy and I already have action item to fix this. 4) Extensibility of language and accessor functions without revisiting the standard? Current doc says no subsetting, no extensions. Randy: I agree with that for the language. In the library it gets trickier. We dealt with that in the Script MIB (extending accessor functions). Steve: Regardless of what we say, vendors will extend accessor functions. Case: You want consistency across the system. But there are two issues here: product differentiation, and spec evolution. We should be cautious in terms of blocking spec evolution. One way to allow evolution is a standardized system for extension. So as we find useful improvements, we can upgrade easily. I think it's also true that vendors will make non-standard extensions, but I think we can contain the damage by specifying how such extensions are made. It might be as simple as having an app level err code that is returned to indicate you didn't have a particular accessor function available. I don't think we should say "no extensibility". Randy: You want to be able to interrogate a system to discover the language level supported and accessor functions supported, so you don't have to wait for a runtime error to find out that a policy wasn't the right version for a device. Steve: Do we need to do anything explicitly? Partain: There are going to be extensions. We should make it possible to do in a standards based way. Andy: I think the draft currently says only the specified accessor functions are allowed...that's a mistake...I think there needs to be an accessor registry. Steve: The high level goal is to manage a network as a whole, not a device. The network will include devices from many vendors. If we have subsetting and extensibility, it gets hard to manage. Andy: Capabilities grow over time, and we can't ignore it. If I'm managing a class of devices and I know it has the extension, then I want to use it. A CAPS table, read-only. Steve: I don't want to allow subsetting of this very minimal set of accessors. Case: Unlikely we'll resolve this today. Two separate issues: Language extensibility, accessor extensibility (Andy was just referring to accessor extensibility). I'm uncomfortable with waiting until the first extension comes along to figure out how to allow for extensibility. Andy is correct that the difference between extensions and subsets...they're really the same problem from an interoperability point of view. We need to design something that will evolve gracefully over time. Bert: Are we struggling over whether we need the absolutely minimal set of accessors? I think we need a minimal subset of accessors available, even if there's a registry. [end of discussion] From owner-snmpconf@seymour39.SNMP.COM Wed Aug 30 11:44:04 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02689 for ; Wed, 30 Aug 2000 11:44:03 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id LAA19490 for snmpconf-outgoing; Wed, 30 Aug 2000 11:23:48 -0400 (EDT) Message-Id: <200008301523.LAA28598@aix43.snmp.com> to: snmpconf@snmp.com Subject: snmpconf IETF48 Minutes and Slides Date: Wed, 30 Aug 2000 11:23:44 -0400 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com The minutes and slides from IETF48 have been placed in anonymous FTP at ftp://www.snmp.com/pub/snmpconf/ietf48 These are the minutes as submitted to the working group, and are not in the final form for IETF submission. Final form minutes will be made available when they are, uh, available. The minutes will also be made available via majordomo when they are submitted to the IETF. Many thanks to Dale Francisco for putting the minutes in final form. The minutes from the interim meeting in Pittsburgh are still being worked on, and should be posted to the working group by the end of the week. --- Steve Moulton SNMP Research, Inc moulton@snmp.com From owner-snmpconf@seymour39.SNMP.COM Thu Aug 31 09:36:19 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05874 for ; Thu, 31 Aug 2000 09:36:19 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA22771 for snmpconf-outgoing; Thu, 31 Aug 2000 09:17:15 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 31 Aug 2000 09:19:39 -0400 Subject: Re: snmpconf Meeting minutes and slides from IETF-48 From: Jon Saperia To: , Steve Moulton CC: Dale Francisco Message-ID: In-Reply-To: <200008292239.PAA21497@itech-view2.cisco.com> Mime-version: 1.0 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 on 08/29/2000 6:39 PM, Dale Francisco at dfrancis@cisco.com wrote: > A little late, but I've finally forwarded to the > IETF the meeting minutes and slides from the > Tuesday and Friday morning meetings at IETF-48. > Dale and Steve, Thanks very much for this detailed set of notes. It will greatly help those who were not at the meeting and focus discussion in the coming weeks. A read of the minutes reveals that many of the issues that came up previously were discussed at the meeting. Some were resolved while others require additional work. I hope that we can get additional items resolved in advance of the next revision of our documents. Dale has/will re-forwarded the slides and notes to the minutes@ietf.org people for future reference. Steve Moulton sent a note the other day to the list for the interim location until they are published via the regular IETF page: > The minutes and slides from IETF48 have been placed in anonymous > FTP at > > ftp://www.snmp.com/pub/snmpconf/ietf48 Thanks again /jon P.S. - due out soon are the notes from the interim meeting that followed the IETF. From owner-snmpconf@seymour39.SNMP.COM Thu Aug 31 10:13:17 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06325 for ; Thu, 31 Aug 2000 10:13:16 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA23981 for snmpconf-outgoing; Thu, 31 Aug 2000 09:56:07 -0400 (EDT) Message-Id: <4.1.20000831092655.00a803c0@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 31 Aug 2000 09:53:48 -0400 To: Jon Saperia , , snmpconf From: John Schnizlein Subject: snmpconf on "configuration" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com At 10:24 AM 08/28/2000 -0400, Jon Saperia wrote: >... The telco industry uses configuration to refer to parameters >that 'are set at the factory' and are not generally changeable >by the customer. Provisioning refers to those parameters that >are customer changeable. The Internet industry seems to use "configuration" to mean changable parameters, as in the Dynamic Host Configuration Protocol [RFC 2131]. The BOF announced with Policy Terminology was called Configuration Management (excerpt below). The WG you co-chair is called Configuration Management with SNMP (snmpconf). My impression is that there is a rough consensus that we would be better served using this word as in the Internet context rather than in the "telco industry" you cite. My dictionary (American Heritage) defines provisioning as supplying with provisions, and a provision as that which is supplied. It defines configuration as the arrangement of the parts or elements of something. This distinction does not reflect 'set at the factory'. John At 11:24 PM 10/27/1999 +0000, Bert Wijnen wrote: >There will be two BOFs that may be of interest to readers of this >mailing list. > > Configuration Management Bof > Policy Terminology BOF > From owner-snmpconf@seymour39.SNMP.COM Thu Aug 31 10:22:48 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06540 for ; Thu, 31 Aug 2000 10:22:48 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id KAA24222 for snmpconf-outgoing; Thu, 31 Aug 2000 10:06:42 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 31 Aug 2000 10:09:03 -0400 Subject: snmpconf Re: on "configuration" From: Jon Saperia To: John Schnizlein , , snmpconf Message-ID: In-Reply-To: <4.1.20000831092655.00a803c0@diablo.cisco.com> Mime-version: 1.0 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 on 08/31/2000 9:53 AM, John Schnizlein at jschnizl@cisco.com wrote: > The Internet industry seems to use "configuration" to mean > changable parameters, as in the Dynamic Host Configuration Protocol > [RFC 2131]. The BOF announced with Policy Terminology was called > Configuration Management (excerpt below). The WG you co-chair is > called Configuration Management with SNMP (snmpconf). Yes, thank you I am aware of that. > > My impression is that there is a rough consensus that we would be > better served using this word as in the Internet context rather than > in the "telco industry" you cite. The reason I suggested it is that as we are all aware, the IETF has not published much yet in this area. I have learned that the telco folks have a lot to contribute to this discussion - though I am not a telco person. The IETF does from time to time use terms and definitions from other organizations (CIM comes to mind). I believe the distinction is a useful one. /jon From owner-snmpconf@seymour39.SNMP.COM Thu Aug 31 13:50:12 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10549 for ; Thu, 31 Aug 2000 13:50:11 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA29106 for snmpconf-outgoing; Thu, 31 Aug 2000 13:31:10 -0400 (EDT) Message-ID: <39AE9600.4DCF1FD6@enterasys.com> Date: Thu, 31 Aug 2000 13:29:36 -0400 From: David Harrington Organization: Enterasys Networks X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "snmpconf@snmp.com" Subject: snmpconf well, back to work 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 Hi all, Now that the meeting minutes are being posted, I guess we should get back to work. It has been a rather pleasant opportunity to relax for the past month. 1) The next interim meeting is coming up. We need to finalize those plans. Jeff, is SNMP Research still willing to host this in Knoxville, as discussed in Pittsburgh? if so, can you confirm the dates, so people can begin planning? Thanks. 2) Jon Saperia has published an individual submission that provides a nice description of the philosophy of the SNMPCONF approach. In Pittsburgh, we discussed adopting this document as a work item of the working group. We need to verify consensus of the WG to adopt this work item. If nobody has any strong objections before September 16, I will consider it WG consensus that we accept the work item. 3) We need to plan the agenda for the next interim. The authors' bulleted lists worked especially well for identifying issues to be resolved. We need to verify WG consensus on Pittsburgh proposed solutions for the bulleted items. Could the authors publish the lists again, and describe potential agreements reached in Pittsburgh, and identify which items still have no potential agreement after Pittsburgh? If anybody has any topics they want on the agenda, please speak up. Thanks, dbh -- --- David Harrington Network Management Standards Architect dbh@enterasys.com Office of the CTO +1 603 337 2614 - voice Enterasys Networks +1 603 332 1524 - fax Rochester NH, USA From owner-snmpconf@seymour39.SNMP.COM Thu Aug 31 13:53:27 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10611 for ; Thu, 31 Aug 2000 13:53:27 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA29199 for snmpconf-outgoing; Thu, 31 Aug 2000 13:36:01 -0400 (EDT) Message-Id: <200008311735.NAA20262@aix43.snmp.com> X-Mailer: exmh version 2.1.2 06/08/2000 To: snmpconf@snmp.com Subject: Re: snmpconf well, back to work In-Reply-To: Message from David Harrington of "Thu, 31 Aug 2000 13:29:36 EDT." <39AE9600.4DCF1FD6@enterasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 31 Aug 2000 13:35:58 -0400 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com On Thursday, August 31 2000, David Harrington wrote: > 2) Jon Saperia has published an individual submission that provides a > nice description of the philosophy of the SNMPCONF approach. In > Pittsburgh, we discussed adopting this document as a work item of the > working group. We need to verify consensus of the WG to adopt this work > item. > > If nobody has any strong objections before September 16, I will consider > it WG consensus that we accept the work item. I am in favor of including this as a work item. - Steve --- Steve Moulton SNMP Research, Inc voice: +1 865 573 1434 Sr Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 moulton@snmp.com Knoxville, TN 37920-9716 USA http://www.snmp.com From owner-snmpconf@seymour39.SNMP.COM Thu Aug 31 17:35:20 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13301 for ; Thu, 31 Aug 2000 17:35:19 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA04455 for snmpconf-outgoing; Thu, 31 Aug 2000 17:18:26 -0400 (EDT) Message-Id: <200008312118.RAA11262@aix43.snmp.com> to: snmpconf@snmp.com Subject: snmpconf slides from working group interim meeting in Pittsburgh Date: Thu, 31 Aug 2000 17:18:23 -0400 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com I am finishing the working group interim meeting notes, and find that I am missing slides. If you have slides you used in your presentation, please send them to me so that I can refer to them to correct potential errors, and submit them to the IETF. Thank you. - Steve --- Steve Moulton SNMP Research, Inc voice: +1 865 573 1434 Sr Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 moulton@snmp.com Knoxville, TN 37920-9716 USA http://www.snmp.com