Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id OAA19484 for nmrg-outgoing; Sat, 30 Oct 1999 14:33:00 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id OAA19473 for ; Sat, 30 Oct 1999 14:32:58 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id OAA00269; Sat, 30 Oct 1999 14:32:58 +0200 Message-Id: <199910301232.OAA00269@henkell.ibr.cs.tu-bs.de> From: "qr su" To: nmrg@ibr.cs.tu-bs.de Subject: [nmrg] Would you please so kind give me a answer? Date: Sat, 30 Oct 1999 20:24:01 CST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Dear Professor, If the langusge XML will become useful, what is the SNMP's future? Thank you for your kindness. With best regards, Sincerely yours, Q. R. Su A student of Nanjing University China ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id SAA13206 for nmrg-outgoing; Fri, 29 Oct 1999 18:36:13 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id SAA12942; Fri, 29 Oct 1999 18:30:59 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id SAA25436; Fri, 29 Oct 1999 18:30:56 +0200 Date: Fri, 29 Oct 1999 18:30:56 +0200 Message-Id: <199910291630.SAA25436@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: kzm@cisco.com, abierman@cisco.com, dlevi@nortelnetworks.com, dperkins@snmpinfo.com, rpresuhn@dorothy.peer.com, dbh@cabletron.com, case@snmp.com, sar@epilogue.com, saperia@mediaone.net, nmrg@ibr.cs.tu-bs.de In-reply-to: <199910261500.RAA06436@henkell.ibr.cs.tu-bs.de> (message from Juergen Schoenwaelder on Tue, 26 Oct 1999 17:00:58 +0200) Subject: Re: [nmrg] NMRG meeting Washington (46th IETF) References: <199910261500.RAA06436@henkell.ibr.cs.tu-bs.de> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> Juergen Schoenwaelder writes: me> This is an invitation to join the next meeting of the IRTF me> Network Management Research Group (NMRG) in Washington DC. [...] me> The meeting is tentatively scheduled for Sunday 7th November me> 1999 after the IETF reception in Washington DC. Please let me me> know ASAP whether you are able to attend the meeting so that me> we can continue our arrangements. So far I have received positive feedback from the following people: Dave Harrington Dave Perkins Dave Levi Jeff Case Jon Saperia Keith McCloghrie Bert Wijnen Juergen Schoenwaelder Wes Hardacker (arrives later) For those of you who did not respond yet, please do so ASAP so that we can plan ahead. I will distribute more details about the location and the starting time later. So please stay tuned. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA24527 for nmrg-outgoing; Tue, 26 Oct 1999 17:10:43 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA23938; Tue, 26 Oct 1999 17:01:15 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA06436; Tue, 26 Oct 1999 17:00:58 +0200 Date: Tue, 26 Oct 1999 17:00:58 +0200 Message-Id: <199910261500.RAA06436@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Keith McCloghrie , Andy Bierman , David Levi , David Perkins , Randy Presuhn , David Harrington , Jeff Case , "Shawn A. Routhier" CC: Network Management Research Group Subject: [nmrg] NMRG meeting Washington (46th IETF) Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk This is an invitation to join the next meeting of the IRTF Network Management Research Group (NMRG) in Washington DC. The list of invited people who are (not yet?) member of the NMRG already shows that this meeting will be different from previous NMRG meetings. In fact, this meeting is being organized in cooperation between the NMRG and the ADs of the OPS area within the IETF. We want to keep the size of the meeting reasonably small in order to make progress. Nevertheless, if you feel that any other person who can make contributions is missing from the list of invitees, please let us know, so we can consider inviting him/her. The purpose of the meeting is to bring a small group of people together and to discuss some pressing SNMP related issues in order to prepare recommendations that can be presented and further discussed at the OPS open area meeting (scheduled for Tuesday, 13:00-15:15). A particular goal of this meeting is to figure out how we can align work items between IETF and IRTF groups and how to proceed on some pressing problems such as missing core data types in SMIv2/SNMPvX. The meeting is tentatively scheduled for Sunday 7th November 1999 after the IETF reception in Washington DC. Please let me know ASAP whether you are able to attend the meeting so that we can continue our arrangements. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id KAA26670 for nmrg-outgoing; Tue, 26 Oct 1999 10:23:58 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id KAA26665 for ; Tue, 26 Oct 1999 10:23:57 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id KAA24182; Tue, 26 Oct 1999 10:23:57 +0200 Date: Tue, 26 Oct 1999 10:23:57 +0200 Message-Id: <199910260823.KAA24182@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Network Management Research Group Subject: [nmrg] next NMRG meeting in Washington Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Many thanks to Aiko for getting the minutes out. The final line in the minutes says: > Next meeting > ------------ > Before 22 October we will decide if the next meeting will be in > Washington or not. There will be an NMRG meeting in Washington during the IETF week. The exact date and location is still being worked on. This meeting will be slightly different from previous meetings since we will invite people who are active in several IETF network management working groups. The high-level goal of this meeting is to figure out how we can align work items between IETF and IRTF groups and how to proceed on some pressing problems such as missing core datatypes in SMIv2/SNMP that are also addressed by some of the NMRG work being done. You will soon hear more about this meeting. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id VAA13917 for nmrg-outgoing; Mon, 25 Oct 1999 21:46:30 +0200 (MET DST) Received: from prodnet.civ.utwente.nl (prodnet.civ.utwente.nl [130.89.1.19]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id VAA13908 for ; Mon, 25 Oct 1999 21:46:27 +0200 (MET DST) Received: from ctit.utwente.nl (ut197003.inbel.utwente.nl [130.89.197.3]) by prodnet.civ.utwente.nl (8.9.3/MQT) with ESMTP id VAA28338; Mon, 25 Oct 1999 21:46:25 +0200 (METDST) Message-ID: <3814B38C.87AC4EEC@ctit.utwente.nl> Date: Mon, 25 Oct 1999 21:46:20 +0200 From: Aiko Pras X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "nmrg@ibr.cs.tu-bs.de" CC: Aiko Pras Subject: [nmrg] Draft minutes of the IRTF-NMRG meeting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Minutes of the 4th IRTF Network Management Research group (NMRG) meeting Date: 14-15 October 1999 Location: Zurich Participants: Raouf Boutaba, Luca Deri, Jean-Philippe Martin-Flatin, Aiko Pras (minutes), Juergen Schoenwaelder, Ron Sprenkels, Frank Strauss, Dave Thaler, Bert Wijnen SNMP over TCP ------------- There were some suggestions to clarify pieces of text within the Internet Draft. Juergen promised to update the text, and send an new version out soon. Status of current implementations: - Juergen: manager and agent part, based on CMU-Linux. This software will be shipped with the next distribution of the Linux CMU SNMP agent - Luca: manager part, based on UCD 3.x - Ron: UTwente (Bert Helthuis) implemented manager and agent part, based on UCD 3.x - Via email Wes Hardekker promised to implement it in UCD version 4. It was decided to have pointers to these implementations from the IRTF-NMRG page. Juergen will take care of maintaining this page; the pointers must be send to Juergen by the various implementors. SNMP compression ---------------- The status was briefly discussed. The current Internet Draft needs to be extended somewhat and include text explaining why alternative techniques were not chosen. Also some text should be added to explain when a manager / command generator should retrieve the MIB variables that identify the compression algorithm and threshold. We checked with Bert Wijnen where we can get PDU tags from and we decided that we will allocate tags from the top of the tag number space downwords. Juergen will update the Internet Draft. There is a preliminary implementation of SNMP compression by Eric Schoenfelder; this implementation may need to be updated after the Draft has been updated / completed. After the new Internet Draft becomes available, the University of Twente expects to build an implementation too. GET-SUBTREE ----------- Linked responses: in the past we discussed three different approaches for the responses of the GET-SUBTREE: 1) use only one new tag for all responses. All responses, except the last, use a new error code which indicates that there is no error, but there will be a next response. The last response uses the traditional values for the error fields. Note that for cases where only a single response is sent back, this behavior is the behavior we know from currently existing operations. 2) use two different tags for responses, one tag for the last response and one for the other earlier responses to the request. You do not do anything new with the error codes. 3) use two different tags for responses. This time, however, the last response does not contain any data; it is just an indication that there is no data to be returned. This approach may be useful in case, some time in the future, we will add a new operation which needs linked replies too. After discussing these three approaches, we have a preference for the first approach. The syntax of GET-SUBTREE request was discussed. The request may include more than one OID. We also think the non-repeaters field should be there, since this will be useful for things like SysUptime and allows to re-use Get-Bulk code. There was a discussion on the order in which variables can be returned, and the fact that "strange" responses can be returned in case the request contains OIDs belonging to different tables. The discussion gave some more insight into the semantics of the GET-SUBTREE; it appeared that we had different, slightly conflicting goals in mind: at one side we wanted to have efficient transfer of bulk data, at the other side we wanted to make it easier for managers to retain the semantics of tables as much as possible. We decided to update the draft and add more reasoning; Juergen will take care of this. GET-SUBTREE-MIB --------------- Dave explained the basic idea of his GET-SUBTREE-MIB contribution from 17 July. The interesting idea of his contribution is that you can retrieve bulk data without changing the SNMP protocol; this would allow easy acceptance of this approach within the IETF. There was some discussion on architectural integrity (the command responder and notification originator need to be tightly coupled, as well as the command generator and notification responder). There was also a discussion on security (you perform a SET, which requires other community strings than GETs). Dave promised to add more reasoning (advantages and disadvantages) to the text of the GET-SUBTREE-MIB, and submit it as Internet Draft. SMIng ----- We started with a discussion on politics, the relation between SMIng and CIM, the directions into which vendors go, etc. A design decision behind SMIng is to be upwards compatible with SMIv2; you can automatically translate from SMIv2 into SMIng and back without losing any information. There are two issues related to SMIng. First it allows you to change the syntax of existing MIBs and get rid of ASN.1; this has the advantage that defining and reading MIBs becomes easier and tools become more efficient. Second it allows you to use new data types, which do not exist in SMIv2. We discussed that there is a difference between an SMI, and the protocol that transports management data. There was a feeling that it is important to document the mapping between possible new data types, and the way you transfer these data types over the wire. Bert asked about the relationship between the recent work on "SMIv2 Operations", and SMIng. It was decided that, for the time being, "Operation-Types for SMIv2" should not (yet) be part of the SMIng core, but should be seen as an extension (documented separately). We concluded that this IRTF group should look at SMI issues; some people expressed more interest into the direction of CIM and others of SMIng. An interesting work item might therefore be the mapping between CIM and SMIv2 / SMIng. Dave will try to find if there is already material on that. Operation-Types for SMIv2 ------------------------- We started the discussion by giving the motivation behind this proposal, which is the work on policies within the IETF. First the status of the discussions within the IETF on policies is presented. Currently the IETF distinguishes between a policy manager, repository, PDP and PEP. There are many people within the IETF who believe communication between policy manager and repository, as well as PDP and repository, should be based on LDAP. How communication between a policy manager and a PDP should look like is not yet determined. Regarding the communication between PDPs and PEPs, there are currently two approaches: COPS and PIBs, versus SNMP and MIBs. Juergen's proposal, "Operation-Types for SMIv2", focusses on the interaction between PDP and PEP and can be seen as an attempt to extend SNMP and MIBs to obtain the same functionality as you would have with COPS and PIBs. After a discussion whether we would like to investigate this approach further and whether this approach can also be used to solve the needs of the COPS / PIBs community, we had some more technical discussion. One of the things we discussed was how parameters and results should be exchanged; do we want that every parameter and every result has an OID, or not. It was noted that the approach is very similar to RPC, and resembles the proposal made by Luca at our first meeting at Lausanne. However, the "Operation-Types for SMIv2" approach is more general and can, for example, also be used as alternative for "Get-Subtree". There was a general feeling that the "Operation-Types for SMIv2" approach is interesting and should be further investigated. Next meeting ------------ Before 22 October we will decide if the next meeting will be in Washington or not. Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id QAA14545 for nmrg-outgoing; Fri, 22 Oct 1999 16:04:01 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id QAA14530; Fri, 22 Oct 1999 16:03:54 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id QAA29441; Fri, 22 Oct 1999 16:03:54 +0200 Date: Fri, 22 Oct 1999 16:03:54 +0200 Message-Id: <199910221403.QAA29441@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: internet-drafts@ietf.org CC: Network Management Research Group Subject: [nmrg] draft-irtf-nmrg-smi-ops-00.txt Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Please post the attached document as Internet Draft . This document is hereby approved by the NMRG chair. Network Working Group J. Schoenwaelder Internet-Draft TU Braunschweig Expires April 2000 22. October 1999 Operation-Types for SMIv2 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this document is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This document defines an extension for the SMIv2 which allows to define operations. Operations can among other things be used to define install/remove operations on conceptual MIB tables. This can result in simpler and more efficient implementations of configuration management systems. Warning This document has not been written in order to specify a solution. Instead, this document has been written to stimulate (controversial) discussions within the NMRG (and elsewhere). Schoenwaelder [Page 1] Internet-Draft Operation-Types for SMIv2 October 1999 Table of Contents 1 Introduction ................................................. 3 2 Definitions .................................................. 4 3 Mapping of the OPERATION-TYPE macro .......................... 5 3.1 Mapping of the ARGUMENTS clause ............................ 6 3.2 Mapping of the ERRORS clause ............................... 6 3.3 Mapping of the RESULTS clause .............................. 6 3.4 Mapping of the CREATES clause .............................. 6 3.5 Mapping of the DELETES clause .............................. 7 3.6 Mapping of the STATUS clause ............................... 7 3.7 Mapping of the DESCRIPTION clause .......................... 7 3.8 Mapping of the REFERENCE clause ............................ 7 3.9 Mapping of the OPERATION-TYPE value ........................ 8 3.10 Usage Examples ............................................ 9 4 Revising Operation Type Definitions .......................... 10 5 Open Issues .................................................. 11 6 Security Considerations ...................................... 12 7 Authors' Address ............................................. 12 8 References ................................................... 12 9 Full Copyright Statement ..................................... 13 Schoenwaelder [Page 2] Internet-Draft Operation-Types for SMIv2 October 1999 1. Introduction Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using an adapted subset of OSI's Abstract Syntax Notation One, ASN.1 (1988) [ASN1], termed the Structure of Management Information (SMI) [RFC2578]. When designing a MIB module, it is often useful to define operations on collections of related objects. Operations go beyond what is available with normal read and write access to individual objects: - Operations have a defined name which makes it easier to communicate complex operations on MIB objects. - Operations have well defined input and output parameters with ordering constraints which reduces variability and simplifies implementations. - Operations can raise operation specific errors during their invocation. - Operations define whether they create or delete rows in conceptual tables. - The defined signatures of operations allow to implement tools that generate APIs and stub procedures for command responder as well as command generator applications. Operations can be defined on arbitrary collections of objects. However, it is expected that operations will normally be defined only on closely related objects (e.g. objects contained in a single conceptual row) since this simplifies implementation in extensible agent environments. Schoenwaelder [Page 3] Internet-Draft Operation-Types for SMIv2 October 1999 2. Definitions SNMPv2-OPS DEFINITIONS ::= BEGIN IMPORTS ObjectName FROM SNMPv2-SMI; OPERATION-TYPE MACRO ::= BEGIN TYPE NOTATION ::= ArgumentsPart ErrorsPart ResultsPart CreatesPart DeletesPart "STATUS" Status "DESCRIPTION" Text ReferPart VALUE NOTATION ::= value(VALUE ObjectName) ArgumentsPart ::= "ARGUMENTS" "{" Parameters "}" | empty ErrorsPart ::= "ERRORS" "{" NamedNumbers "}" -- INTEGER enumerations | empty ResultsPart ::= "RESULTS" "{" Parameters "}" | empty CreatesPart ::= "CREATES" "{" Rows "}" | empty DeletesPart ::= "DELETES" "{" Rows "}" | empty Parameters ::= Parameter | Parameters "," Parameter Parameter ::= identifier Syntax Syntax ::= type Schoenwaelder [Page 4] Internet-Draft Operation-Types for SMIv2 October 1999 | "BITS" "{" NamedBits "}" NamedBits ::= NamedBit | NamedBits "," NamedBit NamedBit ::= identifier "(" number ")" -- number is nonnegative NamedNumbers ::= NamedNumber | NamedNumbers "," NamedNumber NamedNumber ::= identifier "(" number ")" Rows ::= Row | Rows "," Row Row ::= value(ObjectName) Status ::= "current" | "deprecated" | "obsolete" ReferPart ::= "REFERENCE" Text | empty -- a character string as defined in [RFC2578] Text ::= value(IA5String) END END 3. Mapping of the OPERATION-TYPE macro The OPERATION-TYPE macro is used to define an operation. An operation has a defined signature which consists of the operation name, the types and names of the arguments, the types and names of the results and the operation specific errors that can occur while invoking the operation. Operations can create or delete rows in conceptual tables. The optional CREATES and DELETES clauses of the OPERATION-TYPE macro identify the tables in which rows are created or deleted. It should be noted that the expansion of the OPERATION-TYPE macro is something which conceptually happens during implementation and not during run- time. Schoenwaelder [Page 5] Internet-Draft Operation-Types for SMIv2 October 1999 3.1. Mapping of the ARGUMENTS clause The ARGUMENTS clause, which need not be present, defines an ordered sequence of the types and names that form the arguments of the operation. The operation's DESCRIPTION clause must specify the information/meaning conveyed by each argument listed in the ARGUMENTS clause. The name of an argument must consist of one or more letters or digits, and its initial character must be a lower-case letter. Argument names must be unique across all arguments and results defined in a single invocation of an OPERATION-TYPE macro. 3.2. Mapping of the ERRORS clause The ERRORS clause, which need not be present, defines the operation specific errors that can occur while invoking the operation. Errors are represented as integer-valued named-number enumerations. Note that although it is recommended that error values start at 1 and be numbered contiguously, any valid value for an INTEGER in the range (1 to 2147483647 decimal) is allowed for an error value and, further, error values need not be contiguously assigned. The no error case does not need to be enumerated. A label for a named-number enumeration within the ERRORS clause must consist of one or more letters or digits, up to a maximum of 64 characters, and the initial character must be a lower-case letter. (However, labels longer than 32 characters are not recommended.) Note that hyphens are not allowed. 3.3. Mapping of the RESULTS clause The RESULTS clause, which need not be present, defines an ordered sequence of the types and names that form the results of the operation. The operation's DESCRIPTION clause must specify the information/meaning conveyed by each result listed in the RESULTS clause. The name of a result parameter must consist of one or more letters or digits, and its initial character must be a lower-case letter. Result names must be unique across all arguments and results defined in a single invocation of an OPERATION-TYPE macro. 3.4. Mapping of the CREATES clause The CREATES clause, which need not be present, defines the conceptual table rows that will be created by invoking the operation. Rows are Schoenwaelder [Page 6] Internet-Draft Operation-Types for SMIv2 October 1999 identified by the descriptor which refers to a conceptual row, i.e. has a syntax which resolves to a SEQUENCE containing columnar objects. The operation's DESCRIPTION clause must specify how an implementation determines the instance identifier(s) of the row(s) created by the operation. 3.5. Mapping of the DELETES clause The DELETES clause, which need not be present, defines the conceptual table rows that will be deleted by invoking the operation. Rows are identified by the descriptor which refers to a conceptual row, i.e. has a syntax which resolves to a SEQUENCE containing columnar objects. The operation's DESCRIPTION clause must specify how an implementation determines the instance identifier(s) of the row(s) deleted by the operation. 3.6. Mapping of the STATUS clause The STATUS clause, which must be present, indicates whether this definition is current or historic. The value "current" means that the definition is current and valid. The value "obsolete" means the definition is obsolete and should not be implemented and/or can be removed if previously implemented. While the value "deprecated" also indicates an obsolete definition, it permits new/continued implementation in order to foster interoperability with older/existing implementations. 3.7. Mapping of the DESCRIPTION clause The DESCRIPTION clause, which must be present, contains a textual definition of the operation type which provides all semantic definitions necessary for implementation and use, and should embody any information which would otherwise be communicated in any ASN.1 commentary annotations associated with the object. 3.8. Mapping of the REFERENCE clause The REFERENCE clause, which need not be present, contains a textual cross-reference to some other document, either another information module or some other document which provides additional information relevant to this definition. Schoenwaelder [Page 7] Internet-Draft Operation-Types for SMIv2 October 1999 3.9. Mapping of the OPERATION-TYPE value The value of an invocation of the OPERATION-TYPE macro is the name of the operation type, which is an OBJECT IDENTIFIER, an administratively assigned name. Schoenwaelder [Page 8] Internet-Draft Operation-Types for SMIv2 October 1999 3.10. Usage Examples The first example shows an operation which creates or allocates a new entry in the vacmSecurityToGroupTable [RFC2575]. vacmCreateSTGEntry OPERATION-TYPE ARGUMENTS { securityModel SnmpSecurityModel (1..2147483647), securityName SnmpAdminString (SIZE(1..32)), groupName SnmpAdminString (SIZE(1..32)), storageType StorageType { volatile(2), nonVolatile(3) } } ERRORS { rowAlreadyExists(1) } CREATES { vacmSecurityToGroupEntry } DESCRIPTION "This operation installs and activates a new entry in the vacmSecurityToGroupTable. The new entry is identified by the securityModel and securityName parameters. Implementations that do not support the creation of new rows but which have permanent rows that are currently notInService are expected to allocate and activate one of these notInService rows. The value of the storageType parameter is ignored in this case. The rowAlreadyExists(1) error is returned if the row identified by securityModel and securityName already exists." ::= { vacmOperations 1 } The second example shows the definition of an operation that can be used to remove a row from the vacmSecurityToGroupTable. vacmRemoveSTGEntry OPERATION-TYPE ARGUMENTS { securityModel SnmpSecurityModel (1..2147483647), securityName SnmpAdminString (SIZE(1..32)) } ERRORS { rowDoesNotExist(1), readOnlyStorageType(2) } DELETES { vacmSecurityToGroupEntry } DESCRIPTION "This operation removes an entry identified by the securityModel and securityName parameters from the vacmSecurityToGroupTable. Entries which can not be removed (e.g. the value Schoenwaelder [Page 9] Internet-Draft Operation-Types for SMIv2 October 1999 of vacmSecurityToGroupStorageType is permanent) will be disabled by changing the RowStatus column vacmSecurityToGroupStatus to notInService. The rowDoesNotExist(1) error is returned if the row identified by the securityModel and securityName parameters does not exist. The readOnlyStorageType(2) error is returned if the row cannot be removed or disabled since it is stored in ROM." ::= { vacmOperations 2 } The third example shows the definition of an operation which deletes zero or more entries from the vacmSecurityToGroupTable. The argument of the operation contains a pattern which is matched against all vacmGroupName instances. vacmRemoveSTGEntryByGroupName OPERATION-TYPE ARGUMENTS { pattern SnmpAdminString (SIZE(1..32)) } RESULTS { numberRemoved Unsigned32 } DELETES { vacmSecurityToGroupEntry } DESCRIPTION "This operation removes all entries from the vacmSecurityToGroupTable where the vacmGroupName matches the pattern parameter. The comparison is an exact match where each byte must match exactly (no wildcarding). Entries that can not be removed (e.g. the value of vacmSecurityToGroupStorageType is permanent) will be disabled by changing the RowStatus column vacmSecurityToGroupStatus to notInService. Entries that can not be disabled (e.g. the value of vacmSecurityToGroupStorageType is readOnly) will be ignored. The operation returns the number of entries that were actually removed from or disabled in the vacmSecurityToGroupTable." ::= { vacmOperations 3 } 4. Revising Operation Type Definitions An operation definition may be revised in any of the following ways: (1) The ERRORS clause may have new enumerations added. Schoenwaelder [Page 10] Internet-Draft Operation-Types for SMIv2 October 1999 (2) A STATUS clause value of "current" may be revised as "deprecated" or "obsolete". Similarly, a STATUS clause value of "deprecated" may be revised as "obsolete". When making such a change, the DESCRIPTION clause should be updated to explain the rationale. (3) A REFERENCE clause may be added or updated. (4) Clarifications and additional information may be included in the DESCRIPTION clause. (5) Entirely new operations may be defined, named with previously unassigned OBJECT IDENTIFIER values. Otherwise, if the semantics of any previously defined operation are changed (i.e., if a non-editorial change is made to any clause other than those specifically allowed above), then the OBJECT IDENTIFIER value associated with that operation must also be changed. Note that changing the descriptor associated with an existing operation is considered a semantic change, as these strings may be used in fielded implementations and APIs derived from the operation type definition. 5. Open Issues 1. The current version supports three different ways to define a parameter. There are valid reasons for all three alternatives. First, there is a need to have input parameters for operations that do not exactly match an existing object. It would be a burdon to require that all parameters be defined as objects since many would end up with a write-only access (which does not exist) anyway. Second, there is a need to refer to types that are implicitely defined as part of an object definition. A good example is ifAdminStatus, which is an implicitly defined enumeration without a proper name. Third, it is necessary to assign names to parameters in order to solve problems when a single type of implicit type shows up in a arguments or result clause more than once. 2. It is currently not allowed to return vectors as a result. There are several issues to consider in this case. The most important reason to allow vectors is that you can have an operation which itself returns a sequence of operations to recreate the current Schoenwaelder [Page 11] Internet-Draft Operation-Types for SMIv2 October 1999 state. But the details how this would work are not yet fully worked out. 6. Security Considerations This document defines the means to define operations on collections of MIB objects. The definition of operations has no direct security impact on the Internet. 7. Authors' Address Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531 391-3283 EMail: schoenw@ibr.cs.tu-bs.de 8. References [ASN1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, December, 1987 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999 Schoenwaelder [Page 12] Internet-Draft Operation-Types for SMIv2 October 1999 9. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Schoenwaelder [Page 13] Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id QAA14504 for nmrg-outgoing; Fri, 22 Oct 1999 16:03:17 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id QAA14496; Fri, 22 Oct 1999 16:03:11 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id QAA29401; Fri, 22 Oct 1999 16:03:11 +0200 Date: Fri, 22 Oct 1999 16:03:11 +0200 Message-Id: <199910221403.QAA29401@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: internet-drafts@ietf.org CC: Network Management Research Group Subject: [nmrg] draft-irtf-nmrg-snmp-ops-00.txt Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Please post the attached document as Internet Draft . This document is hereby approved by the NMRG chair. Network Working Group J. Schoenwaelder Internet-Draft TU Braunschweig Expires April 2000 22. October 1999 SNMP Protocol Operations for Invoking Operations Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this document is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This document defines additional protocol operations for the Simple Network Management Protocol (SNMP) that support more efficient configuration management via SNMP. The CallRequest and CallResponse PDUs add an RPC style operation invocation mechanism to SNMP. The CompoundRequest and CompoundResponse PDUs add a mechanism to send multiple SNMP operations in a single SNMP message. Warning This document has not been written in order to specify a solution. Instead, this document has been written to stimulate (controversial) discussions within the NMRG (and elsewhere). Schoenwaelder [Page 1] Internet-Draft SNMP Protocol Operations for Operations October 1999 Table of Contents 1 Introduction ................................................. 3 2 Definitions .................................................. 4 3 PDU Processing ............................................... 7 4 Usage Examples ............................................... 7 5 Open Issues .................................................. 7 6 Security Considerations ...................................... 7 7 Authors' Address ............................................. 8 8 References ................................................... 8 9 Full Copyright Statement ..................................... 9 Schoenwaelder [Page 2] Internet-Draft SNMP Protocol Operations for Operations October 1999 1. Introduction The Simple Network Management Protocol (SNMP) is successfully used for tasks such as statistics gathering, status monitoring, topology discovery or event generation/distribution. All these application areas have in common that they mainly require read access to network elements. SNMP has been less successful as a network control protocol that is actually used to configure and exercise control over network elements. One often cited reason for the limited usage as a network configuration or control protocol is the lack of security mechanism in the widely deployed SNMP protocol version 1 (SNMPv1). Recent work on SNMP version 3 (SNMPv3) adds strong message security and access control mechanisms to SNMP. Work on SNMPv3 also adds remote administration MIBs that allow to configure the configuration parameters associated with an SNMP engine. Another reason for the limited success of SNMP as a network configuration or control protocol are the properties of the SNMP SetRequest protocol operation: (1) The SetRequest operation allows a command generator to build arbitrary complex operations that are hard to handle correctly on a command responder. (2) The SetRequest operation does not impose an ordering in the varbind list nor does it impose an ordering in the processing of the varbind list. (3) The SetRequest operation does not return result values upon successful completion of the operation. (4) The SetRequest operation does not return set request specific error codes. (5) It is generally hard to implement and complex operations as side effects on write operations to simple types variables. (6) The message size constraints results of the underlying transports for SNMP messages have lead to MIBs where complex write operations may be realized by a sequence of less complex write operations (dribble mode). (7) The dribble mode add complexity since SNMP allows concurrent access to a command responder from multiple SNMP command generators. This leads to additional complexity (e.g. spin locks) in order to serialize concurrent attempts to perform complex write operations. Schoenwaelder [Page 3] Internet-Draft SNMP Protocol Operations for Operations October 1999 This document defines two new protocol operations (CallRequest and CallResponse) that add an RPC style operation invocation mechanism to SNMP. Operations are formally defined using an SMIv2 extension and identified by an object identifier [SMIv2OPS]. Operations take a sequence of arguments and return either a sequence of results, an operation specific error code or a generic protocol error code. Two additional protocol operations (CompoundRequest and CompoundResponse) can be used to bind multiple SNMP operations together and to process them in a single SNMP message. This can be used to bind several related operations into a single transaction and reduces the overall message and security processing overhead. 2. Definitions SNMP-OPS-PDU DEFINITIONS ::= BEGIN IMPORTS ObjectSyntax FROM SNMPv2-SMI GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, Response-PDU, SetRequest-PDU, InformRequest-PDU, SNMPv2-Trap-PDU, Report-PDU, max-bindings FROM SNMPv2-PDU; max-pdus INTEGER ::= 2147483647 PDUs ::= CHOICE { get-request GetRequest-PDU, get-next-request GetNextRequest-PDU, get-bulk-request GetBulkRequest-PDU, response Response-PDU, set-request SetRequest-PDU, inform-request InformRequest-PDU, Schoenwaelder [Page 4] Internet-Draft SNMP Protocol Operations for Operations October 1999 snmpV2-trap SNMPv2-Trap-PDU, report Report-PDU, call-request CallRequest-PDU, call-response CallResponse-PDU } CallRequest-PDU ::= [42] IMPLICIT OPS-PDU CallResponse-PDU ::= [43] IMPLICIT OPS-PDU CompoundRequest-PDU ::= [44] IMPLICIT COMP-PDU CompoundResponse-PDU ::= [45] IMPLICIT COMP-PDU OPS-PDU ::= SEQUENCE { request-id INTEGER (-2147483648..2147483647), error-status INTEGER { noError(0), tooBig(1), noSuchName(2), -- for proxy compatibility badValue(3), -- for proxy compatibility readOnly(4), -- for proxy compatibility genErr(5), noAccess(6), wrongType(7), wrongLength(8), wrongEncoding(9), wrongValue(10), noCreation(11), inconsistentValue(12), resourceUnavailable(13), commitFailed(14), undoFailed(15), authorizationError(16), notWritable(17), inconsistentName(18), noErrorMoreFollows(19) }, Schoenwaelder [Page 5] Internet-Draft SNMP Protocol Operations for Operations October 1999 error-index INTEGER (0..max-bindings), -- or sequence number values ValueList } ValueList ::= SEQUENCE (SIZE (0..max-bindings)) OF ObjectSyntax COMP-PDU ::= SEQUENCE { request-id INTEGER (-2147483648..2147483647), error-status INTEGER { noError(0), tooBig(1), noSuchName(2), -- for proxy compatibility badValue(3), -- for proxy compatibility readOnly(4), -- for proxy compatibility genErr(5), noAccess(6), wrongType(7), wrongLength(8), wrongEncoding(9), wrongValue(10), noCreation(11), inconsistentValue(12), resourceUnavailable(13), commitFailed(14), undoFailed(15), authorizationError(16), notWritable(17), inconsistentName(18), noErrorMoreFollows(19) }, error-index INTEGER (0..max-pdus), -- or sequence number pdus PduList } PduList ::= SEQUENCE (SIZE (0..max-pdus)) OF PDUs END Schoenwaelder [Page 6] Internet-Draft SNMP Protocol Operations for Operations October 1999 3. PDU Processing TBD 4. Usage Examples 5. Open Issues 1. need to support linked Return-PDUs, similar to linked Response- PDUs: where to allocate the missing bit? 2. error-status indicates whether values in response contains results, exceptions or arguments 3. error-status and error-index are most likely not used in a COMP-PDU (other than having a sequence number in there). 4. where to encode the operation name (OID)? 5. what to do about access control? for which objects do you call isAccessAllowed()? 6. allow a compound PDU within a compound PDU? 7. what about a GetConfig-PDU? 6. Security Considerations This document defines new SNMP protocol operations to invoke operations on collections of MIB objects and to combine multiple SNMP operations into a single SNMP message. Message security is not affected by these new protocol operations. Message security therefore depends on the security model used by the message format. Compound SNMP operations are processed as if they were send in a sequence of separate messages. Thus, access control is still subject of the access control processing of the protocol operations contained in a compound SNMP operation. Operations that invoke operations on collections of MIB objects rely on the access control for the MIB objects. (TBD) Schoenwaelder [Page 7] Internet-Draft SNMP Protocol Operations for Operations October 1999 7. Authors' Address Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531 391-3283 EMail: schoenw@ibr.cs.tu-bs.de 8. References [ASN1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, December, 1987 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996 [SMIv2OPS] J. Schoenwaelder, "Operation-Types for SMIv2", , October 1999 Schoenwaelder [Page 8] Internet-Draft SNMP Protocol Operations for Operations October 1999 9. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Schoenwaelder [Page 9] Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id TAA11567 for nmrg-outgoing; Wed, 13 Oct 1999 19:27:03 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id TAA11039; Wed, 13 Oct 1999 19:20:11 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id TAA15215; Wed, 13 Oct 1999 19:20:10 +0200 Date: Wed, 13 Oct 1999 19:20:10 +0200 Message-Id: <199910131720.TAA15215@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: WIJNEN@vnet.ibm.com CC: nmrg@ibr.cs.tu-bs.de In-reply-to: <199910131533.LAA24038@southrelay03.raleigh.ibm.com> (WIJNEN@vnet.ibm.com) Subject: Re: [nmrg] our meeting this week (more details) References: <199910131533.LAA24038@southrelay03.raleigh.ibm.com> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> Bert Wijnen writes: Bert> How far (how long by train/bus/taxi) is it from the airport? Bert> Any travel directions will be appreciated. See: . This page has a link to a DSOM page which explains how you get from the airport to the ETH: /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA03880 for nmrg-outgoing; Wed, 13 Oct 1999 17:34:10 +0200 (MET DST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA03875 for ; Wed, 13 Oct 1999 17:34:07 +0200 (MET DST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.99.132.206]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA488532 for ; Wed, 13 Oct 1999 11:33:22 -0400 Received: from BLDVMA.boulder.ibm.com (bldvma.boulder.ibm.com [9.99.64.30]) by westrelay03.boulder.ibm.com (8.8.8m2/NCO v2.05) with SMTP id JAA70306 for ; Wed, 13 Oct 1999 09:33:57 -0600 Message-Id: <199910131533.JAA70306@westrelay03.boulder.ibm.com> Received: by BLDVMA.boulder.ibm.com (IBM VM SMTP Level 310) via spool with SMTP id 5431 ; Wed, 13 Oct 1999 09:32:56 MDT Date: Wed, 13 Oct 99 17:33:02 DST From: "Bert Wijnen" To: schoenw@ibr.cs.tu-bs.de, nmrg@ibr.cs.tu-bs.de Subject: [nmrg] our meeting this week (more details) Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Ref: Your note of Wed, 13 Oct 1999 14:03:40 +0200 Subject: Re: [nmrg] our meeting this week (more details) How far (how long by train/bus/taxi) is it from the airport? Any travel directions will be appreciated. Thanks, Bert Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id OAA18733 for nmrg-outgoing; Wed, 13 Oct 1999 14:03:42 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id OAA18724; Wed, 13 Oct 1999 14:03:40 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id OAA09735; Wed, 13 Oct 1999 14:03:40 +0200 Date: Wed, 13 Oct 1999 14:03:40 +0200 Message-Id: <199910131203.OAA09735@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Network Management Research Group Subject: [nmrg] our meeting this week (more details) Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk I forgot the most important detail: The meeting will be help in room at the following address: Electrical Engineerings Building (ETZ and ETF Building) Room H 91 Gloriastrae 35 CH-8092 Zuerich /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id OAA18611 for nmrg-outgoing; Wed, 13 Oct 1999 14:01:46 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id OAA18603; Wed, 13 Oct 1999 14:01:44 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id OAA09732; Wed, 13 Oct 1999 14:01:44 +0200 Date: Wed, 13 Oct 1999 14:01:44 +0200 Message-Id: <199910131201.OAA09732@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Network Management Research Group Subject: [nmrg] our meeting this week Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Here are the latest details about our meeting on Thursday/Friday. We (the people that are already in Zurich) decided that we will start on Thursday after lunch (about 1:00 pm). Dave Thaler will arrive in Zurich around 11:30 am so I guess he will be at the meeting from the beginning. On Friday, we will start at 9:00 am so that we can get some work done. I failed to come up with updated documents on the bulk retrieval specs right before the meeting. The reason for that is that I am doing some other work (see the URLs below). I would like to spend some time on these documents on Friday. So if you have a chance to look at it before our meeting (while traveling), that would be fine. The URLs are: http://www.ibr.cs.tu-bs.de/~schoenw/draft-schoenw-smi-ops-00.txt http://www.ibr.cs.tu-bs.de/~schoenw/draft-schoenw-snmp-ops-00.txt Note that these documents are purely experimental and they may be rubbish. I hope to find out during our meeting. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936