This is only a rough draft - Megan 04/09/92 Minutes of the IETF SNMP over a Multi-protocol Internet (mpsnmp) Working Group March 18 1992, San Diego CA Mailing list general discussion: snmp-foo@thumper.bellcore.com to subscribe: snmp-foo-request@thumper.bellcore.com archive: thumper.bellcore.com:pub/snmp-foo/archive Chair Ted Brunner tob@thumper.bellcore.com Meeting Notes: The meeting started by considering the working group charter. It had not been sent out over the ietf mailing list, nor made available for anonymous ftp prior to the first meeting of the Working Group. It was read aloud (enough paper copies were available for about half the participants) and accepted as written. The charter names three transport domains (OSI, Appletalk, and XNS/IPX) over which SNMP can be carried, and tasks the working group (among other things) with developing suitable encapsulation techniques. Questions were raised as to the appropriateness of considering other transport domains. In particular running SNMP over SNA was brought up as an interesting candidate for consideration. The working group decided it did not have the necessary expertise to pursue such an undertaking and it was dropped. Running SNMP directly over Ethernet was suggested and also dropped. There is already an RFC that deals with such a case (rfc1089). Running SNMP over TCP was suggested. Here the sense of the Working Group was that this was outside the scope of the charter. The charter speaks of environments where the recommended method for exchanging SNMP messages (UDP/IP) is not available. It does not speak of changing the recommended method of communicating SNMP messages. The rational for choosing UDP/IP rather that TCP/IP is expressed in rfc1270. The informational RFC (rfc1298) entitled "SNMP over IPX," was considered first. SNMP encapsulation in this case is relatively straightforward, and all of the relevant points addressed by rfc1298 were discussed. o It is recommended that the minimum maximum packet size supported by the SNMP/IPX agent be raised to 546 - the limit under IPX. o Two sockets are assigned: for get-next/sets and for traps. o The agent address field in the trap pdu is left as 0.0.0.0 and the agent identified by the source address in the IPX header. o The IPX addresses will be represented by an OCTET STRING. o An OBJECT DISCRIPTOR is defined for the ipx transport domain. The working group identified a small omission. An OBJECT IDENTIFIER for an initial party ID was added to the rfc. With this change, and assuming customary time for consideration of internet-drafts and no further controversy, the working group expressed its intention to propose this rfc for promotion to "proposed standard." A show of hands was made of companies who had implemented or had some inclination of implementing to this standard. Present were Synoptics, Spider, MicroComm and Shiva. The working group next considered the internet draft (draft-ietf-appleip-snmp-00.txt) entitled "SNMP over AppleTalk." SNMP encapsulation in this case was a little less straightforward. All the relevant issues raised by the draft were discussed. o Appletalk (DDP) datagrams contain 0 to 586 octets of data. The WG recommended that the SNMP agent increase its minimum maximum packet size to 586. o DDP Socket numbers and protocol types are assigned to SNMP requests, responses and traps. o In Appletalk, network elements advertize themselves using the Name Binding Protocol (NBP) which dynamically binds names to addresses. A NBP type is assigned to SNMP agents (to receive requests), and SNMP managers (to receive traps). o The agent address field in the trap PDU is left as 0.0.0.0. In Appletalk the name advertized by the NBP is unique and constant, but the address is not. So the agent inserts its name (object and zone) in the VarBind list of the trap PDU. o Names are represented as OCTET STRINGs. o There is discussion of some implications for robust service with this use of names and the NBP to identify managers and agents. Caching is suggested. The WG expressed possible implementation concerns at the maximum name length of 96 bytes. The WG observed that this reliance on NBP is succeptible to denial of service attacks, but this is not a *further* security hole to SNMP. The WG recommended that "SNMP Security Widgets" be added to this draft: Transport Domain OIDs and Default Party. With these changes, and assuming customary time for consideration of internet-drafts and no further controversy, the working group expressed its intention to propose this internet-draft for promotion to "proposed standard." Again a show of hands was made of companies who had implemented or had some inclination of implementing to this standard. Present were Apple, Novell and Shiva. Mentioned but not present were Cayman, Neon, Interconn(spell? sorry.) etc. Next the WG discussed the experimental RFC (rfc1283) "SNMP over OSI." o Three transport mappings are included: Connectionless Transport (CLTS), Connection Oriented Transport (COTS) over TP4 and over TP0 with X.25. o In OSI, locally meaningful "selectors" are used where IP uses "well known ports." T-selectors for request/response and for trap are specified. o An address representation convention known as string encoding is adopted from rfc1278. The WG agreed (with the author) to drop this convention. o The trap pdu specifies a network address, following the syntax defined in the CLNP mib (rfc1238). The WG observed that this convention is not the same as that of the previous two documents considered. It was recommended (by the author) that this document be changed to be consistent: the network address be left as 0.0.0.0. The WG also observed that the "SNMP Security Widgets" were not defined here. It was recommended that they be included. The WG also observed that two transport selectors are needed, one for CLTS carried over connectionless network service, and one for CLTS carried over connection oriented network service [sic]. Further discussion evolved around the COTS, with the concern being that the description was too vague. It was also observed that COTS is a painful way to support SNMP - and a full description would likewise be painful. A poll was taken of implementation experience: one implementation under BSD. It was suggested by the WG that CLTS is the architecturally appropriate way to support SNMP (see rfc1270), and that COTS should be dropped from the document. Other contributing factors being implementation costs of COTS compared to CLTS, and interoperability issues with COTS compared with CLTS. The suggestion was carried. Further discussion concerned whether this WG had the authority to make this recommendation. An informal sounding was taken of individuals present with some knowledge of other OSI efforts. A general agreement seemed to be that though CLTS was the better approach, but there was potential conflict with some efforts which concentrated solely on COTS (predominately over X.25.) The Area Director for OSI Integration suggested that this WG did have the authority to set such a standard, and should seize the moment to deliver the best solution. He also offered to check with the NOOP group, which is developing OSI technology for use in the Internet, to get their reaction (expected to be positive.) With these changes, and assuming customary time for consideration of internet-drafts and no further controversy, the working group expressed its intention to propose this rfc for promotion to "proposed standard." Finally the WG suggested that a short how-to RFC be generated to describe the checklist of issues to consider in specifying an encapsulation of SNMP. These issues are: o Connectionless mode mapping o Choosing addresses and sockets o packet size o trap pdu network address (0.0.0.0) o transport address representation (OCTET STRING) o "security widgets" - transport Domain OID, Default Party o identify reliance on other "servers" o check implementation experience Two volunteers came forward to help write this RFC. Another was identified as potentially being interested given his experience with related RFCs.