Minutes of the SNMPv3 Working Group
Minneapolis IETF
Friday, 19 March 1999, 9:00 AM
Minutes: - Bob Stewart, edits: - Russ Mundy


The chair, Russ Mundy called the meeting to order and began with mutual
self congratulations on the IESG approval of our core documents for Draft
Standard and the introduction document for Informational. The documents are
in the hands of the RFC Editor, waiting to be issued.

We reviewed the published agenda and made no changes. These minutes follow
that agenda.

Rob Frye gave a presentation on the coexistence document. His slides,
available from the IETF proceedings, contain the bulk of his points. The
following points received his particular emphasis or group discussion.

The major remaining issue was Counter64 behavior for SNMPv1, with the
following major points.

A general mechanism for data type extensibility is out of scope.

Rob overviewed the problem and available options.

Rob explained the editors' proposed solution but noted it had a serious
problem of requiring proper error handling in old, existing application
code.

Rob then confirmed the following points of consensus regarding an
acceptible solution:

.       It should cover multilingual systems.
.       It should cover proxy.
.       It should be for direct access or proxy. This is a strong should
        since the major difficulty is regarding proxy for an SNMPv1
        application to an SNMPv2c/SNMPv3 agent, which is considered a minor
situation.
.       Get, GetNext, and Set should operate the same direct or proxy if
        practical.
.       Notifications should operate the same direct or proxy if practical.
.       In general SNMPv1 applications can handle OPAQUE objects but do
        not drill into object contents.
.       NetworkAddress as an index is a problem but of little concern as
        the only standard MIB where it appears is a deprecated section of
        MIB II. The coexistence documenet will say that this is covered
simply by including a constant 1 as an index field in front of an OCTET
STRING network address.
.       We should not address general extensibility of data types.

During this discussion there was a suggestion from the floor (from Bob
Stewart) on how to handle the one sticky case for the preferred solution of
treating Counter64 as not in view. We then discussed that suggestion.

The problem is when an SNMPv1 application sends a GetNext request through a
proxy to an SNMPv2 or higher version agent and the proxy gets back a
Counter64. In that case the proxy must iterate the request with the agent
until it gets past the Counter64, a potentially long, messy, expensive
process.

The proposed solution is to tell network administrators who see this
problem to solve the inefficiency by defining for that application's
community a view that does not contain the Counter64, making it truly not
in view via access control, thus keeping the necessary iteration within the
agent.

In addition to this, a proxy that does iterate should push the last
subidentifier of the offending object to its maximum value to avoid useless
iterations, then re-request all data.

The editors accepted this proposal, to be added as implementation and
deployment notes. In addition the editors' proposal to return genErr was
changed to noSuchName and we decided to follow standard not-in-view
procedure and drop notifications going out as SNMPv1 but coming in with
Counter64.

We then moved on to what needs to be updated in RFCs 1905, 1906, and 1907
for them to go to full Internet Standard.

They need some clarifications and an editorial pass. They will not be open
for general changes. The goal is to go from Draft Standard to full
Standard. We need to adjust terminology similar to what was done for SMPv2.
This should be pervasive if not too painful or otherwise a front-end
paragraph.

Changes need to be clean, clear, and simple.

Randy Presuhn, Dave Perkins, and Keith McCloghrie volunteered on the spot.
Others provided a maybe, and the need is to be mentioned on the mailing
list.

The next major point was the need for an applicability statement. Russ
reported that Scott Bradner says our present documents are sufficient in
that regard. There was some sentiment that we might need something along
the line of what it means to implement SNMPv3, but we decided to wait and
see.

We then discussed wether we needed other major documents on deployment or
implementation.

- A deployment document would capture what deployment strategies and
techniques were intended and expected by the designers. It should include
the view of the operations people. We decided we couldn't do that now but
perhaps some of us could work with the early deployers.

- As to an implementation document, we noted that there are now plenty of
implementations without one and that it would be hard to find time for the
working group to develop one.  The working group consensus was that this
item should be dropped as a working group item, perhaps leaving it to The
Simple Times.

The next agenda item was the work schedule. The coexistence document will
tentatively have a new draft by 30 April. The update team for the old RFCs
will provide a sense of the problem by 26 April.

Next on the agenda was a charter update. This will be done after the update
team's report, with Russ providing an early pass to the Area Directors.

We then had an informational presentation from Ken Hornstein on his
Kerberos for SNMPv3 security research project. He indicated this was an
interesting experiment. It's a big change from SNMP's traditional
independence from other protocols but has some benefits. We decided to
revisit this approach after further research work. There was a question
about how it would apply with AgentX.

As a final note, Bob Stewart reported that Cisco is now shipping SNMPv3 in
IOS and we issued a general call for people to send product ship reports to
Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de> for inclusion on his SNMPv3
web site and for The Simple Times.