Finished Projects
Network Security
SNMP - Advisory Team Charter
Advisory team has been formed to analyze the existing SNMP security specifications (USEC and SNMPv2*). The Security and Administrative Framework Evolution for SNMP Advisory Team will produce a white paper by November 1 that identifies area of similarities and differences between the two existing proposals. For the areas of differences the team will attempt to identify a recommended solution.
The purpose of the team is to provide input to the NM community. The intention is to activate a working group at the next IETF (12/96) to identify a specification for supporting security for SNMP.
Russ Mundy, TIS, is chairing the team. Members include:
- David Harrington (Cabletron)
- David Levy (SNMP Research)
- John Linn (Openvision)
- Jeff Johnson (Cisco)
- Shawn Routhier (Epilogue)
- Glenn Waters (Nortel)
- Bert Wijnen (IBM)
Project Plan for the Security and Administrative Framework Evolution for SNMP Advisory Team.
Purpose
This project plan explains what we will deliver, when we expect to
deliver it, how we intend to work to achieve it, what guidelines we will
use to decide technical issues, and how others may help us accomplish
the work.
Our Proposed Schedule and Deliverables
Aug 26 - Team formation announced Sep 30 - status update Nov 1 - white
paper to be published to the snmpv2 list. This is one month prior to the
December IETF meeting.
It is our plan to generate a white paper, not reference implementations. No intermediate publications are planned. We will post a status report in late September.
Contents of the White Paper
Commonalities of the proposals that can be merged. We will identify the
pieces that are in agreement, so the WG can try to finalize those
points.
Differences between the proposals
We will identify divergent designs, their pros and cons, and the
requirements which drove the alternate designs.
Our Proposed Solutions
We will suggest some solutions to the divergent designs, including our
rationale for the solution.
Rationale
In the rationale for the solution proposals, we will include, as
appropriate and as time permits, a qualitative cost/benefit analysis,
and an analysis of the tradeoffs of functionality, footprint,
modularity, cross-table consistency checking, and MIB design. Where
there is not unanimous support for a solution, we will provide a
dissenting rationale.
The Process
We intend to document the process so the WG can understand how we
reached our recommendations. The team is composed of a balance of USEC
and SNMPv2* contributors, plus a number of neutral parties from outside
the SNMPv2 WG.
Although the NMAD is not part of the team, nor a member of the team's mailing list the NMAD will be given status updates. Our companies have committed us to 10-20 hours per week for this task.
We plan to use a private mailing list for our discussions. We think this will be most effective, and the exclusionary effect is mitigated by the fact that we are only providing a white paper, not completed proposals.
Consensus is a nebulous indicator of agreement. We will strive for unanimous "consensus" within the team, using counted votes to determine our level of consensus and need for more discussion. We will report the final voting counts in the white paper for areas of disagreement within the team.
We will identify the set of documents we used for comparison. All documents used will be the most current, publicly available version.
We will assign topic numbers to each issue, to enabled focused subsequent discussion by the working group.
We will assign topics to team members, who will prepare a summary of the issue plus a solution proposal on which to vote. Any member opposed to the initial proposal may prepare an alternate proposal if they desire. Then the team discusses the proposals and votes.
Votes will be YES (accept), NO (needs more discussion), ABSTAIN (don't agree but won't block or propose alternate), or VETO (don't agree, want this discussed by a full working group).
Team members may consult with non-team members as needed.
Our Basic Guidelines
We are analyzing only existing SNMP Security solutions. We may consider
new elements to these solutions in identifying the Team's proposals.
Analysis should:
- be completed by the assigned deadline
- include a summary of purpose
- concentrate on technical issues.
- include comment on both approaches to the topic.
- not include brand new proposals
- include discussion from the snmpv2 list, possibly as an appendix to the analysis.
- Address manager, midlevel manager, and agent issues.
- include comments on the requirements being addressed
- include comments on the importance of the requirements for managers,
- mid-level-managers, and agents.
- include a statement of any clear preference from the author.
- if there are related topics, they should be identified. If one impacts the other, the potential
- impact should be mentioned, but a full analysis should not be done, since this may
- duplicate the other analysis. The implications of the interaction may be suggested as an additional topic.
- if there are related topics, dependency directions should be identified, i.e. they each can
- stand alone, they are mutually dependent, only one depends on the other.
- whether the topic may be a candidate for deferral.
- if the topic is a candidate for deferral, what requirements must be met to ensure that it can
- be integrated later.
We will try to make it possible for minimal implementations to provide limited functionality in a minimal footprint, while making it possible for fuller implementations to offer more functionality at the cost of a larger footprint.
We will try hard to find one approach that is a viable solution which can be done in one implementation. If differences in approaches cannot be resolved within our limited time, then we will try to enable both approaches rather than forcing one approach, and let the market decide. We consider this a worst case scenario and intend to have none of this if possible.
When two valid non-interoperable approaches meet different requirements, we may recommend entities negotiate interoperability.
We will summarize issues for which there was no recommended solution alternative, a brief description of why, & a rough indication of priority of the issue.