InfoMagic Standards 1993 July/Disc.iso/inet/ietf/mpsnmp/92mar.min

Text File | 1993-02-17 | 8.0 KB | 172 lines

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:    [e-mail]
    to subscribe:    [e-mail]
    archive:    thumper.bellcore.com:pub/snmp-foo/archive

Chair
    Ted Brunner        [e-mail]


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.