Re: request for extension

[Daniel Mahoney <[e-mail]>]

I'd like to make four points:

1) Requirements;
2) Flexibility breeds complexity;
3) Credibility;
4) Bottom Line.

Requirements
------------
On Jun 19,  8:32pm, Keith McCloghrie wrote:
> Subject: A request for an extension
> Bob & Deirdre -
>
> The current SNMPv2 administrative framework seeks to accomplish several
> goals:
>
>     (1) support for accessing management information (contexts) held
> 	both locally (views) and remotely (proxy)
>
>     (2) authentication, message integrity, limited replay protection,
> 	and, optionally privacy, all supported by strong cryptography
>
>     (3) support for both symmetric and asymmetric cryptographic
> 	approaches
>
>     (4) support for access control and authorization based on
> 	administrative policy and management information
>
>     (5) remote diagnostics of SNMP entities (the SNMPv2 mib and error
> 	reports)
>
>     (6) remote configuration of SNMP entities (the party mib)
>                  .
>                  .
>                  .
>                  .
>-- End of excerpt from Keith McCloghrie

It is further stated that:
On Jun 19,  8:32pm, Keith McCloghrie wrote:
>     (1) The three of us are given until June 30th to produce a set of
> 	internet-drafts, based on the ideas in Glenn's draft, which
> 	achieve goals (1), (2), (4), and (5).
>
> 	Although (6) is an important feature, in keeping with Glenn's draft,
> 	we will defer (6) for a later standardization effort, perhaps the
> 	upcoming  "distman" working group.
>
>-- End of excerpt from Keith McCloghrie

I believe that 6 is too important to Network Management Systems to be
deferred and that the current direction of the "distman" working group has
nothing to do with remote configuration.  I felt this feature was a major step
forward to truly managing networks giving customers the ability to configure
users' access to network devices remotely.  Without this, the customer is often
reduced to sneakernet when user access needs to be configured.

Flexibility breeds Complexity
-----------------------------

Admittedly, the current admin model is perceived to be complex, but that is the
nature of the beast.  To achieve the original requirements necessiates a model
such as the one currently in the drafts.  It IS the place of the NMS to create
value-added solutions to complex problems.  It is NOT the job of the standards
group to solve the complexity of administering the currently proposed
administration model. In the case of SPECTRUM, Cabletron's NMS entry, we have a
security system in place and plan on leveraging the existence of this system to
simplify the viewed complexity of the current admin model.

Credibility
-----------

It is my feeling that making such drastic changes this late in the games will
further damage the already weakened credibility of the SnmpV2 Working Group.

Bottom Line
-----------

If you haven't gathered from my above comments, I'm against any further changes
to the RFCs.  I believe that the current RFCs work and work well.  Let's push
ahead with what we got.


DOM II

-- 
--------------------------------------------------------------------------------
Daniel Mahoney
Cabletron Systems Inc.
Project Leader, Spectrum Protocols Group
-------------------------------------------------------------------------------