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.