Minutes of SNMPv3 Working Group
Munich IETF - August 1997
We had two meeting slots. Both were well-attended, over-packed in a
too-small, too-hot room.
11 August
Area Co-director Mike O'Dell expressed his appreciation for what he called
a remarkable level of sustained intellectual exercise.
Chair Russ Mundy briefly presented the agenda that had previously been
published on the mailing list. He emphasized that we would have no
tutorial, gave us a quick look at an overall diagram from the architecture
document then proceeded with discussion of issues led by an editor for each
document.
Architecture - Dave Harrington
Dave presented the issues list and his reading of apparent consensus,
soliciting any strong disagreement from the assembled working group.
There was some objection that Application Service Interfaces (ASIs) look
too much like Application Programming Interfaces (APIs). This was
dismissed as too late in the process to try to change directions.
A discussion on the length of the engine ID resulted in some clarifications
and consensus that it is a variable length value with a maximum of 32 bytes.
There was considerable discussion on the use of strings as indexes for
tables of direct interest to humans. The following points were made.
. An objection was raised to the overhead of a string in every
varbind, along with skepticism that people will directly
configure such information.
. Names offer better consistency. .
. That is not necessarily true. Small, numeric indexes with a
descriptor string are functionally equivalent and more efficient.
. Use of a string doesn't guarantee semantics. Application writers
must inspect string contents. Can we depend on this?
. Such enforcement is an administrative procedure.
. Existing experience with small integer indexes indicates that
using names relieves users by spending some machine resources,
and you can force the use of short names if necessary.
. A textual description is not trustworthy either.
. The major issue is message overhead.
. This is not a frequent operation.
. How about adding a number to go with the name.
. Objector is willing to drop the issue.
. Conclusion: We made no change.
We then discussed the use of UTF8 for some time with the following points
being made.
. Some people want a general UTF8 replacement for DisplayString.
. AdminString is not that as it is more restricted.
. UTF8 is not a panacea.
. Is this problem bigger than management needs? People are
picking up UTF8 in other places. Research will be provided.
. We need our solution now.
. Adding DisplayString-like carriage control is unnecessarily
complex.
. That was added to DisplayString due to demonstrated need.
. Applications must handle carriage control and non-printing
characters anyway. How do restrictions help?
. The problem is garbage restriction versus end-to-end recognition
of character meanings.
. What if we simply say that carriage-return/linefeed represents
the canonical end of line and make other restrictions simply
suggestions.
. What we're discussing is a DisplayString replacement. AdminString
is for restricted use and has no carriage control and no leading
or trailing white space.
. Conclusion: We won't try to do anything more general now.
We discussed Report PDUs with the following points being made.
. All Report PDUs are noAuth/noPriv except NotInTimeWindow which is
auth/noPriv.
. We need to allow other security models to have other definitions.
. Changing this would not be an easy edit.
. Let the requester of the Report send it specification for level
of security.
. Such a fix would require multiple changes to say what happens if
the report can't be sent that way.
. The issue is an architectural layer violation.
. What if the security module could specify but not application
modules?
. That information is not available.
. What if we say noAuth/noPriv is the default and pass differing
desires in status information?
. Conclusion: Agreed to last suggestion.
The question was asked if it is OK that the USM is bound to v3. There was
violent agreement that we would be better off to stick closer to v3 and
this isn't the only place.
We discussed whether an OID or an enumeration is better for identifying the
security protocol. The following points were made.
. Using OIDs you can't find the inclusive list, can't figure out
what a value means, and can't reuse existing values, Use of OIDs
here is not appropriate.
. Let's simplify this by deleting the column from the table.
. Doing that will require a change in how we recognize protocols.
. We can use a new model number for new protocols and simply say it
is similar to an older one.
. We need to support changes of protocol.
. A single column is better than separate tables.
. Add the model as an index and delete the column.
. That's more complex.
. Determining what protocols are supported is a problem.
. The conversation became emotional and pointed.
. We deferred the issue until later.
An objection to passing parameters that have unchangeable values was
answered that this is to provide placeholders for future flexibility
although the detail does create some burden.
There is no distinguished value that can be used as a wildcard for a
contextEngineID. The solution to this is implementation-specific, such as
using a flag. This explanation will be added as implementer's notes in the
specification for PDU types and contextEngineID in the Register and
Unregister ASIs.
We discussed the need to add a PDU version in the ASI. The following
points were made.
. This is not a good solution to the problem of supporting multiple
versions. A better solution would be disjoint PDU function codes
for different versions.
. Behind this suggestion is a desire to change the PDU function
codes on the wire.
. Even if v3 has different types we will have to distinguish v1
and v2c.
. We deferred this issue to the discussion of Message Processing.
A suggestion was made and strongly supported to make the architecture
explicitly v3.
. The chair ruled the support was not strong enough for such a
drastic change.
. The present architecture is not general enough. .
. It is flexible enough, up to a point.
. The ASIs do not accomplish the flexibility they should.
. The chair informed us that due to IESG input we need to change
MD5 to HMAC and doing so may improve functional separation as
long as such improvement is not too disruptive.
We returned to the issue of OID versus enumeration for security protocol
identification.
. Some people want time to consider the issue of OID versus
enumeration versus removing it.
. The chair ruled that we should leave it as it is (OID), note
the objection, and reexamine our position if it comes up again.
We discussed the need for an overview/roadmap document. The following
points were made.
. We shouldn't make any changes in the present architecture
document.
. We need the overview document.
. Conclusion: If the overview appears soon and we like it,
duplicate overview text will be removed from architecture.
. Conclusion: Doing the overview is OK. We'll see if we like it
when we have it in hand.
We debated whether "should" is too strong or too weak regarding the
architecture's list of security threats. We decided to leave it as is.
We debated whether an agent should have MIB objects to say the length of
AdminStrings it supports. The following points were made.
. Strong support was expressed since agents can limit the length of
these strings.
. That should be covered by AGENT-CAPABILITIES.
. It's not since managers don't have or use that information.
. Without this information writing applications is too hard. Past
experience indicates we will have limited agents and will need
this information.
. AGENT-CAPABILITIES does supply this information. Applications
should use that.
. Experience says AGENT-CAPABILITIES isn't trustworthy.
. The agent should return an error to say too big. Such objects
as this are not good.
. These objects could indicate no new entries allowed by indicating
maximum length of zero.
. What is the proper error return? There isn't one for index too
long. All we have is inconsistentName.
. We should go back to integer indexes.
. Using integers is just too hard for people.
. There are other places this could apply. Why do it here and not
there?
. We should do it for the most important structures.
. We deferred this issue due to being 45 minutes over time and one
document behind.
To ensure that we could finish our business in the one meeting we had left
the chair established midnight the next day as the deadline to publish to
the mailing list those issues that must be addressed in the second meeting.
A Web site for those was volunteered.
Since Dave Perkins had many issues the chair asked for his key issues to
help understand what was left. They were:
. There are problems with the use of message ID versus request ID.
. Use of engine ID is unclear for transient versus persistent
applications.
. Is access control required or not?
The first meeting was adjourned.
13 August
Due to the painfully slow progress at the last meeting the chair revised
the procedure for this meeting to speed progress. He presented the
following categories, in priority order:
1. Will NOT function.
2. Prevents doing secure Sets.
3. Won't support v2 SMI.
4. Other.
All issues must be categorized and will be handled in priority order until
the top three categories are empty and we run out of time.
We went through the issues submitted on the mailing list and had the
submitters categorize their own issues. We had category 1-3 issues from
Perkins, Case, and McCloghrie as follows:
Document Issues
Applications 8
USM 5
ACM 3
MP 4
Architecture 1
Total 21
All were category 1.
We then proceeded with the issues, by document.
MP
Problems with message ID space uniqueness among systems were judged
editorial, to be fixed by the editor.
The v3 message format was changed to create a HeaderData sequence. When
parsing for previous versions this causes an ASN.1 parser error instead of
a version mismatch. After a small amount of discussion we deferred the
issue for further consideration.
The destination contextEngineID can not be discovered if Reports are
optional. This is not a problem since Reports are not optional.
Reports can not be optional. They're not.
Applications
What happens if the Report receiver ????? This is fixed by retrying when a
Report is received.
A group Inform should not be satisfied by a single ACK. This is an
optimization, working as intended. If each destination must ACK, don't
make them a group.
Some Informs do not synchronize clocks. We deferred this.
Another issue was the same as the group Inform issue.
Proxy needs processing for maximum message sizes. This will be fixed.
Proxy sends notifications to multiple targets. This will be clarified as a
feature.
Some proxy TAddress processing can't happen. This will be fixed.
USM
We need the ability to use source address as input to authorization
processing. This was relegated to "other."
We need a MIB table for clock information. This is not broken so we won't
fix it.
There is bad logic in section 3.1 step 6. No there isn't.
Section 3.2 step 7 part b step 1 is broken. This will be reconsidered for
unclear wording.
Section 3.2 step 7 part b step 2 needs an added case. This is part of the
previous issue.
ACM
Some issues were dismissed by their presenter.
The algorithm in the DESCRIPTION for acmAccessTable is too complex and
loses some good cases. Changing this is a major issue, requiring an index
change. The way it is was the best we could find for the present indexing
and is believed to operate properly even if somewhat complex.
The chair ruled that the final issue didn't meet the criteria for further
discussion.
Applications
The snmpTargetAccessSpinLock process is too burdensome, overly complex,
causing retrieval of all entries. Juergen's "tag" solution fixes this. We
deferred discussion of that solution until later. There was also a comment
that RowStatus should be sufficient without a spin lock.
An issue that a command generator should not accept mismatched responses
was judged editorial.
Architecture
The engine ID value generation algorithm doesn't work for multiple engines
on the same system. We deferred this for later.
We returned to the deferred issues.
MP - HeaderData issue.
The desire is to put the version back where it was in the message format.
It will be fixed that way if the change is clean and obvious.
This was done to make the architecture cleaner. It was observed that
message format and architecture need not be so closely bound and that this
issue is touched somewhat by the pending change from MD5 to HMAC.
Applications - Inform clock synchronization.
If sender is slower than the receiver and the difference in clocks is too
great, manual synchronization is required. This is a burdensome exception.
This was changed from a fully automatic operation due to security
considerations. The consensus was that the fully automatic synchronization
was strongly preferred. The chair was requested to discuss this issue with
appropriate security folk to determine if the fully automatic clock
syncronization could be used in all situations. Based on discussions
subsequent to the meeting, the chair determined that to be the case, i.e.,
fully automatic clock synchronization should be used in all situations.
Architecture - engine ID algorithm.
Multiple engines following the algorithm on the same system will end up
with the same ID. The suggested algorithms are thus dangerous in some
common situations.
A warning will be added, explaining the problem and stating that the
algorithms suggested do not solve it.
Applications - spin lock problem.
The proposed solution is to change the indexing and add tags to use for
selecting targets. Each target has a set of tags. Targets are selected by
listing the tags of interest.
This could be helpful for Distributed Management.
Further discussion was deferred to the mailing list.
We then discussed the overall readiness of the four documents other than
Security which will be changing to HMAC. The following points were made.
. The applications document needs another working group last call.
. Mostly the documents are very close to sufficient for submission
for Proposed Status. The Area Co-director reinforced the
statement that "Proposed" means ready to do implementation, not
locked in stone or perfect or finished.
. Working group and IETF last call can't overlap.
. IPng coverage needs to be added.
. The area co-director stated that IPv6 may be included only if it
is trivial to do so.
. DEADLINE: New documents will be available by 15 September.
. An explicit list of changes will be provided.
. Remaining issues may be answered by referring to previous
consensus rather than discussing them again.
. DEADLINE: The chair preferred a 1-week last call but after
discussion we decided on a 2-week last call, the last two weeks
of September.
. After the September working group last call we're ready for IESG
submission and IETF last call.
We discussed the need for a roadmap/overview. We decided it would be
helpful but must not slow down or be referenced by the other documents.
Editors are to be identified.
The meeting was adjourned.
Respectfully submitted,
Bob Stewart