[nmrg] Draft minutes of the IRTF-NMRG meeting

[Aiko Pras <[e-mail]>]

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.