Minutes
SNMPv3 Working Group
Recorded by Jeff Case
47th IETF
Adelaide Australia
Wednesday March 29, 2000
Welcome by Russ Mundy.
Introduction of new co-chair, David Harrington, Enterasys.
Agenda Bashing -- no changes from agenda published on mailing list.
Acknowledgement of Published RFC Updates.
The publication of two documents since the 46th IETF was announced:
Coexistence and transition document (RFC 2776), Proposed Standard.
Diffie-Helman USM Key Management extensions (RFC 2786), Experimental.
The next topic was the discussion of updated versions of RFCs 1905-1907 in
the interest of advancing them from Draft to Full Standard status.
Randy Presuhn made a presentation on the very few remaining open issues
with respect to the drafts which had been issued before the meeting:
draft-ietf-snmpv3-update-mib-01.txt
draft-ietf-snmpv3-update-transmap-01.txt
draft-ietf-snmpv3-update-proto-01.txt
RFC 1905 bis: there are no known outstanding open issues
RFC 1906 bis: there are two related open issues related to rfc1157 domain
The issue can be researched by looking at
ftp://amethyst.bmc.com/pub/snmpv3/Update567/rfc1906/issue1906-06.html
The -01 document leaves the text largely unchanged. However, there were at
least two comments on the mailing list that the text should be made more
clear or the rfc1157 domain should be deprecated.
None of the people who raised objections to the text found in the -01
draft were present and the objections were posted after most of those
present at the meeting had left home, both of which made discussion
somewhat difficult.
Keith McCloghrie encouraged the group to come to some closure at the
meeting. Randy Bush said that we could not make any final decisions
today -- that everything must be decided on the list.
The group did take a straw-man vote among those present to get a
sense of the working group. There was no objection to advancing the
text as published in the -01 draft.
The final decision on this issue was deferred to the mailing list.
RFC 1907 bis: there is one set of related open issues related to the
internationalization of character strings and UTF-8, specifically related
to the MIB objects sysDescr, sysName, sysContact, and sysORDescr.
The issue can be researched by looking at
ftp://amethyst.bmc.com/pub/snmpv3/Update567/rfc1907/issue1907-18.html
Jeff Case argued against the change, reiterating what he had posted
to the list. He suggested that we have 3 basic choices (really 2):
1) leave these objects as they are in RFC 1907, but create
additional objects that contain localized variations
of objects such as sysName and sysContact, etc
2) make the changes as proposed in the -01 draft
3) do neither -- but expect to get the document thrown back
in our faces when it reaches the IESG -- not recommended
Jeff stated his strong preference for option (1) and explained
why he thought that options (2) and (3) were unworkable.
Bert Wijnen pointed out the need for this change as proposed in the
-01 draft (He spoke in favor of option 2). Bert said we have made
similar changes before (Entity MIB).
Randy Presuhn stated his preference for the text in the -01 draft (He spoke
in favor of option 1).
Mike St. Johns: This violates the SMI. Use duplicate objects. (He
spoke in favor of option 1).
Ran Atkinson: Use duplicate objects. (He spoke in favor of option 1).
Participants were encouraged make sure their positions had been
posted to the mailing list.
A suggestion was made to take a straw poll.
After much time and flagellating, we got through the poll.
Q1: Retain DisplayString object semantics as found in RFC 1907
(i.e., part of option 1)
sense of the room is yes
Q2: Create new UTF objects in parallel
(i.e., part of option 1)
(the question did not distinguish between in parallel in the
same draft or in a separate draft)
sense of the room is yes
Q3: Deprecate existing objects
consensus is no
Q4: Change semantics on objects to UTF8
(i.e., part of option 2)
sense of the room is no
It was again observed the the Entity MIB WG has already acted in a
way that too the opposite approach to the above conclusions.
Bert observed that we cannot add objects to the MIB and advance. Others
observed that the information module containing the new objects need not
be in the same document.
The consensus of the room was for option 1, but based on Randy Bush's
earlier input, we were unable to come to a conclusion. Correspondingly,
the issue was deferred to the list for the final decision.
The next topic was SNMPv3 Deployment Reports
Russ Mundy, co-chair reported on four sets of deployment experience
he has become aware of.
Small testbed at NAI labs
Verio - Carl Kalbfleish
SNMP Research
MG-Soft Reports Significant v3 Product Sales to "Users"
He called on Carl Kalbfleish, Verio, who reported on the limited work
done to date in his test lab environment.
Others were invited to make reports of their experiences.
Ran Atkinson reported on the DOCSIS cable modem standard.
Testing is happening in the lab against cable modem products.
Testing is occuring with agent products built using products from two
of the leading toolkit vendors.
One vendor indicated that he knows of others in the room that have SNMPv3
successfully implemented (and deployed) but continue to be shy about coming
forward and reporting on it. It is somewhat unknown why these people do
not want to make their reports public.
Deployment experience should be sent to snmpv3@lists.tislabs.com or
Russ Mundy or Dave Harrington.
It was suggested that people may want to be on the lookout for a large
United States Postal Service (USPS) Request for Proposals (RFP) which
is rumored to contain a large SNMPv3 component.
The next topic was SNMPv3 Q & A Document Discussion: David Harrington
Dave Harrington had proposed on the list that we create a question and
answer document.
So far, he has received only a few comments on the proposal.
The purpose of the Internet Draft would be to cover the following:
Frequently Asked Questions
What does SNMPv3 Do?
Alternatives to SNMPv3
Implementation Concerns
Deployment Concerns
Recommended Practices
This document would be similar in some ways to the document from the
IAB on the case for IPv6.
He wants to be try to answer some of the questions people ask when they
go to deploy or implement SNMPv3.
Costs/Benefits. Feasibility Analysis. Resource Planning.
Resure[sic]/Integration Studies. Buy/Develop Decision.
How does SNMPv3 benefit my customer? What features can I
sell my customer?
Alternatives. Why not SNMPv2c, Ipsec, WEBM…
Implementation concerns – code space, etc
Deployment concerns. How hard is it to manage? More operators?
Interoperability.
Co-existence with other management v1, v2c, cli, radius, cops,
cmip, tmn
Recommended Practices. Once there is a view based control
mechanism? How do you use it? Routing configuration verses
sysContact. Security Parameters.
A/C statements, sysORTable (to determine the capabilities of
devices). As release notes
See Dave's presentation slides for additional detailed subpoints -- sorry,
but we were unable to keep up here.
Dave is looking for looking for volunteers to each write small portions
of the document.
The next topic was Promoting SNMPv3
New/Updated Implementations were discussed. SNMPv3 is now shipping
in RedHat Linux and FreeBSD.
Find information on Juergen's Web site:
http://www.ibr.cs.tu-bs.de/projects/snmpv3
There is an interest in identifying organizations requiring and
buying SNMPv3 and other promotional ideas.
IWL has offered to host additional interoperability testing if there
is sufficient interest.
Bert (with AD hat on): promotional activities that smack of
marketing should happen outside the IETF.
Randy Presuhn: should document the experience with WinSNMP and
snmp++ to support SNMPv3. There was some question about how complete
those works are.
Dave Perkins: is getting questions from cable modem customers about
how to use SNMPv3. He has SNMPv3, but has not turned it on, because
he does not have sufficient printed information.
Straw poll: do we want to do interoperability testing? No strong
support. Steve Waldbusser: thinks that we are past the time where
interoperability testing is either necessary or useful -- may
be counterproductive by sending the wrong message -- indicating
the technology is less mature than it is.
Bert: sees no need for interoperability testing for promotion.
Randy Bush sees no strong need for additional interoperability testing.
The next topic was Discussion of Related Items
Several potential additional Working Group items were identified and
discussed. One question articulated by Co-chair Mundy is:
What additional information and specifications that would
encourage greater deployment and use of SNMPv3?
Several additional security components were discussed in this light:
Diffie-Helman USM Key Management extensions on standards track
Triple-DES protection from disclosure
Kerberos
There was no strong interest at this time in bringing new work into
the Working Group with respect to additional security modules
Jeff Case suggested that it might reduce barriers to adoption and
deployment if we invite an expert speaker to come to a future
meeting and present tutorial information on the impact of recent
changes in export control regulations.
Next, there was an attempt to gauge interest in new work items to be
considered either in this Working Group, or a new one. A large number
of possible work items were presented:
Recommended Practices
Views for Common MIB Objects
read-only versus read-write
routing configuration versus sysContact
Security Parameters (USM, VACM)
Usefulness of A/C Statement
Management Extensions for SNMPv3 Applications
Bulk Transfer
OID Compression
Operations on PDUs
New (High Capacity) Datatypes
New SMI
Complete Information Modeling
Moving topics from ongoing IRTF work to new IETF work
A total of eleven work areas were presented. A straw poll was taken
on several of these topics.
bulk transfer
sense of the room was in favor of looking at working on it
OID compression
sense of the room was in favor of looking at working on it
operations and pdus
sense of the room was in favor of looking at working on it
The room became somewhat restless, in part, because attendees were
being asked to take a position on questions they did not fully
understand.
At this point, Ran observed that we need to stop enhancing, fixing,
and extending and leave things stable so the market can catch up.
Randy Bush responded: we cannot remain static -- we have had pressure
for some changes building for some time ... therefore we must pick the
items for our future work lists *_very_* carefully.
The opinions were expressed that our next work items need to
incorporate management features, not merely more security
address long-standing issues
produce solutions compatible with snmpv3
be clearly focused projects
At this point David Harrington got his laptop working again which
allowed him to project his presentation.
Proposed Phase 1
efficient data transfer
bulk transfer
improved table retrieval
OID compression / suppression
Proposed Phase 2
new data types and operators
need to the understand problem
Proposed Phase N
Non engineering ready
Focus not well understood
Not sure which wg should handle these
May be IRTF efforts
There was no attempt to propose that all work be done here.
Projects that should be reviewed in other places including
DISMAN
Remote intelligence
Standardized script language: DISMAN or SNMPCONF
The meeting concluded when we ran out of time at 5:30 pm.
Respectfully submitted,
Jeff Case
(Thanks also to Carl Kalbfleisch who provided a second set of notes which
helped in the "hurried" places.)