From owner-snmpconf@seymour39.snmp.com Tue Apr 1 00:04:19 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 AAA11987 for ; Tue, 1 Apr 2003 00:04:19 -0500 (EST) Received: by seymour39.snmp.com (8.9.3p2/m.030206) id XAA24148 for snmpconf-outgoing; Mon, 31 Mar 2003 23:59:07 -0500 (EST) Message-ID: <3E891C03.16824E50@nextbeacon.com> Date: Mon, 31 Mar 2003 20:56:35 -0800 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-13.txt References: <200303071155.GAA21881@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 Here's a summary of the changes in the last 2 revs of the PM MIB Module. Regards, Steve Updated the Framework boilerplate Updated some of the introductory text Changed "MIBs" to "MIB Modules" throughout Clarified that UTF-8 characters are sometimes stored in more than 1 octet Changed presentation of 'this element' throughout to make more clear that the term has special meaning Made clear that implementation of all library functions is mandatory even though their presentation is split up into 4 sections Fixed bugs in example of usage of nonLocalArgs Changed to usage of transportDomainUdp* from snmpUDPDomain so that an IPV6 mapping can be defined and to be more up-to-date Clarified how contextEngineID is encoded Clarified the situations where functions that use NonLocalArgs must also require the use of ContextName One of the parameters of searchColumn is an integer that takes one of 6 values. Created a set of constants so that these values may be expressed symbolically in Policy Scripts Clarified that createRow is not useful for creating rows in tables whose index doesn't contain an arbitrary integer component. Provided advice on choice of maxTries values for createRow CounterRate needs to cause an RTE if it gets a noSuchInstance Fixed interface of readVar to be consistent with writeVar by having it signal errors through a RTE. The same with readError. Split up constants for SnmpMessageProcessingModel and SnmpSecurityModel because they didn't map accurately onto the same set of constants Clarified that the string parameters to chr() and ord() may be longer than 1 octet in length. Added stringprep function and stringprep profile so that internationalized strings may be compared correctly Added size restriction to UTF8String TC Increased size of pmPolicyAdminGroup and pmElementTypeRegDescription so that multi-byte character sets don't result in strings too short to be useful pmPolicyIndex incorrectly said that it was unique within an admin group when in fact it is required to be unique amongst all policies on the box Specified that pmPolicyPrecedenceGroup and pmRoleString values must be stringprep'd by the manager before being sent so that valid comparisons of international strings may be made Changed pmPolicySchedule range from 0..65535 to 1..4294967295 Added range to pmPolicyConditionScriptIndex, pmPolicyActionScriptIndex and pmDebuggingLogIndex Changed pmPolicyDebugging, pmCapabilitiesOverrideState, pmTrackingEPStatus and pmPolicyAdminStatus enumeration to start at 1 Specified the behavior when the storageType objects are permanent Specified which objects are modifiable when the rowStatus obects are active Moved overview text in comments into the Table descriptions Added size restriction to pmRoleContextName, pmTrackingPEContextName, pmDebuggingContextName and pmTrackingEPContextName Changed size restrictions on contextEngineID objects to (SIZE (0 | 5..32)) Clarified what happens to pmDebuggingEntries upon reboot Renumbered pmConformance to pmMib 12 Updated the security considerations to use the new format Updated the references section to split between Normative references and Informational references and also to refer to the latest versions. From owner-snmpconf@seymour39.snmp.com Tue Apr 1 09:11:57 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12252 for ; Tue, 1 Apr 2003 09:11:57 -0500 (EST) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3p2/m.030206) id JAA01144 for snmpconf-outgoing; Tue, 1 Apr 2003 09:08:28 -0500 (EST) Message-Id: <200304011408.JAA01137@seymour39.snmp.com> To: snmpconf@snmp.com Subject: snmpconf quarterly list instructions mailing Date: Tue, 01 Apr 2003 09:08:23 -0500 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com The snmpconf list is for discussing the business of the Configuration Management using SNMP (snmpconf) working group of the IETF. This working group is an open forum for raising and discussing issues related to network device configuration management and SNMP. To remove yourself from the snmpconf discussion list, send a message to snmpconf-request@majordomo.snmp.com containing just the word unsubscribe in the message body (not in the subject). If you have subscribed at an address other than your email from address, send the message unsubscribe address-to-unsubscribe. An 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 Apr 3 09:03: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 JAA20176 for ; Thu, 3 Apr 2003 09:03:27 -0500 (EST) Received: by seymour39.snmp.com (8.9.3p2/m.030206) id IAA20697 for snmpconf-outgoing; Thu, 3 Apr 2003 08:57:20 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" X-Sybari-Space: 00000000 00000000 00000000 00000000 From: David Partain To: snmpconf@snmp.com Subject: Mini one-week last call on draft-ietf-snmpconf-pm-13.txt Date: Thu, 3 Apr 2003 15:56:35 +0200 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200304031556.35514.David.Partain@ericsson.com> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit Greetings, Firstly, thanks very much to Steve Waldbusser for getting draft-ietf-snmpconf-pm-13.txt out! This mail is sent to start a one-week WG last call on this document to give everyone a chance to submit comments. If you have comments on the document, please send them to this mailing list by the end of the day on Thursday, April 10. Thereafter, the document will be handed back to our Area Director to continue its journey in the IESG. If you have questions about what has changed in the document, see Steve Waldbusser's mail to the list, which is archived at http://www.snmp.com/snmpconf/mailing-list/msg01183.html Cheers, David & Jon From owner-snmpconf@seymour39.snmp.com Fri Apr 4 08:14:20 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21007 for ; Fri, 4 Apr 2003 08:14:19 -0500 (EST) Received: by seymour39.snmp.com (8.9.3p2/m.030206) id IAA23990 for snmpconf-outgoing; Fri, 4 Apr 2003 08:12:57 -0500 (EST) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501484117@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Snmpconf (E-mail)" Subject: snmpconf Reusability of Diffserv MIB Date: Fri, 4 Apr 2003 15:12:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com So I wonder if document draft-ietf-snmpconf-diffpolicy-05.txt would be of help in this case. I have not checked the details yet. Thanks, Bert -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: donderdag 3 april 2003 0:58 To: 'Wilson.Sawyer@arrisi.com'; Wijnen, Bert (Bert) Cc: ipcdn@ietf.org Subject: RE: [ipcdn] Re: Status - draft-ietf-ipcdn-subscriber-mib-10.txt Wilson and Bert, One immediate issue I found, in trying to re-use the DiffServ MIB for the DOCSIS Subscriber Management functionality, was in the structure of the Data Path table, which is the initial table for packet classification. The Data Path Table is the first lookup table in the DiffServ MIB, and it uses ifIndex and ifDirection as the initial parameters to match. Upon a match, the typical next table is the Classifier Table (although the entry may point to other Tables in the MIB). In the Subscriber Management MIB, the first lookup table is docsSubMgtCmFilterTable, which uses the particular cable modem, upstream or downstream direction (similar to ifDirection), and CM versus CPE (CPEs are behind the CMs on the subscriber home network) source/target to map to a filter-group. The filter-group points to a set of rows in the docsSubMgtPktFilterTable for packet classification. The four subscriber management filter-groups are configured through the DOCSIS 1.1/2.0 CM registration processes. The two gaps I see in DiffServ MIB functionality are: 1. The DiffServ MIB assumes that a uniform set of classifiers are applied to all traffic flowing over a particular interface, because in the general network case, one cannot differentiate traffic except by classification. The Subscriber Management MIB assumes that distinct sets of classifiers are applied to different groups of cable modems that co-exist on the same cable RF interface, because the DOCSIS registration process aids the CMTS in differentiating different CM/CPE traffic sources and sinks. Note that there can be thousands of CMs from different filter-groups co-existing on the same cable RF interface, so an operator would need to add thousands of Classifier Table entries to match on specific CM/CPE sources and sinks. 2. The Subscriber Management MIB differentiates between CM source/sink traffic and CPE source/sink traffic. The CMTS knows the difference between CMs and CPEs on the same cable RF IP subnet(s) via the DOCSIS registration process. Using the current DiffServ MIB, making distinctions between CM and CPE traffic would require many more entries in the Classifier Tables, in order to enumerate the CM source IP addresses. It looks like the DiffServ folks were looking to use more generic parameters than the ifIndex during the development of the MIB. From section 2.2 of RFC 3289: Another possible direction of abstraction is one using a concept of "roles" (often, but not always, applied to interfaces). In this case, it may be possible to re-use the object definitions in this MIB, especially the parameterization tables. The Data Path table will help in the reuse of the data path linkage tables by having the interface specific information centralized, allowing easier mechanical replacement of ifIndex by some sort of "roleIndex". This work is ongoing. I don't know how to apply this "ongoing work" to the immediate issues that are solved by the current Subscriber Management MIB. -- Rich From owner-snmpconf@seymour39.snmp.com Fri Apr 4 08:52: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 IAA21825 for ; Fri, 4 Apr 2003 08:52:22 -0500 (EST) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3p2/m.030206) id IAA25095 for snmpconf-outgoing; Fri, 4 Apr 2003 08:52:30 -0500 (EST) Date: Fri, 4 Apr 2003 15:54:57 +0200 Subject: Re: snmpconf Reusability of Diffserv MIB Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Harrie Hazewinkel , Wilson.Sawyer@arrisi.com To: snmpconf@snmp.com From: Harrie Hazewinkel In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501484117@nl0006exch001u.nl.lucent.com> Message-Id: <0548056A-66A5-11D7-8E98-0003934A5A7E@jumpy.it> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Hi, I have not check the subscriber-mib, but some question are in line. Not saying I am an expert in all areas, therefore, some of it below may sound dumb. But in idea I believe it is quit similar. Hope this helps, Harrie On Friday, April 4, 2003, at 03:12 PM, Wijnen, Bert (Bert) wrote: > So I wonder if document draft-ietf-snmpconf-diffpolicy-05.txt > would be of help in this case. I have not checked the details > yet. > > Thanks, > Bert > > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: donderdag 3 april 2003 0:58 > To: 'Wilson.Sawyer@arrisi.com'; Wijnen, Bert (Bert) > Cc: ipcdn@ietf.org > Subject: RE: [ipcdn] Re: Status - > draft-ietf-ipcdn-subscriber-mib-10.txt > > > Wilson and Bert, > > One immediate issue I found, in trying to re-use the DiffServ MIB for > the > DOCSIS Subscriber Management functionality, was in the structure of > the Data > Path table, which is the initial table for packet classification. I do not understand what you mean by 'initial' table. In the diffserv-mib it is not needed to have a classifier as the first datapath element. > > The Data Path Table is the first lookup table in the DiffServ MIB, and > it > uses ifIndex and ifDirection as the initial parameters to match. Upon a > match, the typical next table is the Classifier Table (although the > entry > may point to other Tables in the MIB). 'typical' I would say possibility. > > In the Subscriber Management MIB, the first lookup table is > docsSubMgtCmFilterTable, which uses the particular cable modem, > upstream or > downstream direction (similar to ifDirection), and CM versus CPE (CPEs > are > behind the CMs on the subscriber home network) source/target to map to > a > filter-group. The filter-group points to a set of rows in the > docsSubMgtPktFilterTable for packet classification. The four subscriber > management filter-groups are configured through the DOCSIS 1.1/2.0 CM > registration processes. A classifier in diffserv is also a set of rows in a table. So far I believe it is all similar in concept. Just a question, are only 4 filter-groups possible?? In theory, this is also possible in the diffserv-mib. The diffpolicy MIB is then a possibility to use in order to define/register such a filter or complete datapath. > The two gaps I see in DiffServ MIB functionality are: > 1. The DiffServ MIB assumes that a uniform set of classifiers are > applied to > all traffic flowing over a particular interface, because in the general > network case, one cannot differentiate traffic except by > classification. The > Subscriber Management MIB assumes that distinct sets of classifiers are > applied to different groups of cable modems that co-exist on the same > cable > RF interface, because the DOCSIS registration process aids the CMTS in > differentiating different CM/CPE traffic sources and sinks. Note that > there > can be thousands of CMs from different filter-groups co-existing on > the same > cable RF interface, so an operator would need to add thousands of > Classifier > Table entries to match on specific CM/CPE sources and sinks. I am not getting this. Do you say that since the DiffServ MIB does not group the classifier table it is not applicable in the subscriber mib?? If I understand it, the docsSubMgtCmFilterTable has just different parameters to get to a first classifier/filter, right?? If so, I do not see a major difference is usage/concept, except that the docsSubMgtCmFilterTable points to an filter defined in the docsSubMgtPktFilterTable (and is simply more restrictive). This as opposite that in diffserv a filter is not needed to be first. Correct me if I am wrong, but is the intention of the diffserv-mib is that a filter for a specific interface and direction and you want to have a single filter defined in the docsSubMgtPktFilterTable that is reused for all the subscribers. > 2. The Subscriber Management MIB differentiates between CM source/sink > traffic and CPE source/sink traffic. The CMTS knows the difference > between > CMs and CPEs on the same cable RF IP subnet(s) via the DOCSIS > registration > process. Using the current DiffServ MIB, making distinctions between > CM and > CPE traffic would require many more entries in the Classifier Tables, > in > order to enumerate the CM source IP addresses. > > It looks like the DiffServ folks were looking to use more generic > parameters > than the ifIndex during the development of the MIB. From section 2.2 > of RFC > 3289: > > Another possible direction of abstraction is one using a concept of > "roles" (often, but not always, applied to interfaces). In this > case, it may be possible to re-use the object definitions in this > MIB, especially the parameterization tables. The Data Path table > will help in the reuse of the data path linkage tables by having the > interface specific information centralized, allowing easier > mechanical replacement of ifIndex by some sort of "roleIndex". This > work is ongoing. > > I don't know how to apply this "ongoing work" to the immediate issues > that > are solved by the current Subscriber Management MIB. The more generic usage was to allow configuration templates. For that reason also many datapath element tables are not directly associated with an interface nad it direction. If I understand you correctly you want to have filters that are used, but not tightly coupled to en entities managed in the subscriber-mib. The diffpolicy-mib provides something likem this. As you may note, in the diffserv-mib also datapath elements defined in the various tables do not have to be in operational use. From owner-snmpconf@seymour39.snmp.com Fri Apr 4 13:05:45 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 NAA01450 for ; Fri, 4 Apr 2003 13:05:45 -0500 (EST) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3p2/m.030206) id NAA10780 for snmpconf-outgoing; Fri, 4 Apr 2003 13:03:22 -0500 (EST) Message-Id: <200304041802.h34I2Zk17147@gamma.isi.edu> To: IETF-Announce: ; Subject: snmpconf RFC 3512 on Configuring Networks and Devices with Simple Network Management Protocol (SNMP) Cc: rfc-editor@rfc-editor.org, snmpconf@snmp.com From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 04 Apr 2003 10:02:35 -0800 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3512 Title: Configuring Networks and Devices with Simple Network Management Protocol (SNMP) Author(s): M. MacFaden, D. Partain, J. Saperia, W. Tackabury Status: Informational Date: April 2003 Mailbox: mrm@riverstonenet.com, David.Partain@ericsson.com, saperia@jdscons.com, wayne@goldwiretech.com Pages: 83 Characters: 196529 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-snmpconf-bcp-12.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3512.txt This document is written for readers interested in the Internet Standard Management Framework and its protocol, the Simple Network Management Protocol (SNMP). In particular, it offers guidance in the effective use of SNMP for configuration management. This information is relevant to vendors that build network elements, management application developers, and those that acquire and deploy this technology in their networks. This document is a product of the Configuration Management with SNMP Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030404100101.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3512 --OtherAccess Content-Type: Message/External-body; name="rfc3512.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030404100101.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-snmpconf@seymour39.snmp.com Wed Apr 16 01:56: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 BAA23397 for ; Wed, 16 Apr 2003 01:56:06 -0400 (EDT) Received: by seymour39.snmp.com (8.9.3p2/m.030206) id BAA00692 for snmpconf-outgoing; Wed, 16 Apr 2003 01:49:11 -0400 (EDT) To: snmpconf@snmp.com Cc: "Wijnen, Bert (Bert)" Subject: Re: Mini one-week last call on draft-ietf-snmpconf-pm-13.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8732.1050472114.1@duncan.cs.utk.edu> Date: Wed, 16 Apr 2003 01:48:35 -0400 From: "David L. Partain" Message-Id: <20030416054835.8FE6114290@smtp.cs.utk.edu> X-Virus-Scanned: by amavisd-new and ClamAntivirus Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Greetings, On April 3, I wrote: > This mail is sent to start a one-week WG last call on > this document to give everyone a chance to submit comments. > If you have comments on the document, please send them to this > mailing list by the end of the day on Thursday, April 10. > Thereafter, the document will be handed back to our Area > Director to continue its journey in the IESG. The timer went off last Thursday, so the mini last call is over. To the best of my knowledge, there have been no comments, and the document now goes back into the able hands of the IESG. With kind regards, David