Subject: [nmrg] Would you please so kind give me a answer?
From: "qr su" <[email-masked]>
To: [email-masked]
Date: Sat, 30 Oct 1999 20:24:01 CST

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

Date: Fri, 29 Oct 1999 18:30:56 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [nmrg] NMRG meeting Washington (46th IETF)
Sender: [email-masked]

>>>>> 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
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Tue, 26 Oct 1999 17:00:58 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Keith McCloghrie <[email-masked]>, Andy Bierman <[email-masked]>, David Levi <[email-masked]>, David Perkins <[email-masked]>, Randy Presuhn <[email-masked]>, David Harrington <[email-masked]>, Jeff Case <[email-masked]>, "Shawn A. Routhier" <[email-masked]>
CC: Network Management Research Group <[email-masked]>
Subject: [nmrg] NMRG meeting Washington (46th IETF)
Sender: [email-masked]

This is an invitation to join the next meeting of the IRTF Network
Management Research Group (NMRG) <URL:http://www.irtf.org/> 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
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Tue, 26 Oct 1999 10:23:57 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] next NMRG meeting in Washington
Sender: [email-masked]

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
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Mon, 25 Oct 1999 21:46:20 +0200
From: Aiko Pras <[email-masked]>
To: "[email-masked]" <[email-masked]>
CC: Aiko Pras <[email-masked]>
Subject: [nmrg] Draft minutes of the IRTF-NMRG meeting
Sender: [email-masked]

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.

Date: Fri, 22 Oct 1999 16:03:54 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: Network Management Research Group <[email-masked]>
Subject: [nmrg] draft-irtf-nmrg-smi-ops-00.txt
Sender: [email-masked]

Please post the attached document as Internet Draft
<draft-irtf-nmrg-smi-ops-00.txt>. 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

                    <draft-irtf-nmrg-smi-ops-00.txt>

                          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: [email-masked]

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]

Date: Fri, 22 Oct 1999 16:03:11 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: Network Management Research Group <[email-masked]>
Subject: [nmrg] draft-irtf-nmrg-snmp-ops-00.txt
Sender: [email-masked]

Please post the attached document as Internet Draft
<draft-irtf-nmrg-snmp-ops-00.txt>. 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

                   <draft-irtf-nmrg-snmp-ops-00.txt>

                          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: [email-masked]

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", <draft-
               irtf-nmrg-smi-ops-00.txt>, 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]

Date: Wed, 13 Oct 1999 19:20:10 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] our meeting this week (more details)
Sender: [email-masked]

>>>>> 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:

<URL:http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/1999/zurich/>.

This page has a link to a DSOM page which explains how you get from
the airport to the ETH:

<URL:http://www.tik.ee.ethz.ch/dsom99/location.html>

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Wed, 13 Oct 99 17:33:02 DST
From: "Bert Wijnen" <[email-masked]>
To: [email-masked], [email-masked]
Subject: [nmrg] our meeting this week (more details)
Sender: [email-masked]

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

Date: Wed, 13 Oct 1999 14:03:40 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] our meeting this week (more details)
Sender: [email-masked]

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
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Wed, 13 Oct 1999 14:01:44 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] our meeting this week
Sender: [email-masked]

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
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>