RE: Status of the WG

As I said, we really need to decide whether we believe SNMPv3 is worth =
the effort to help get it deployed. If not, we should declare it =
Historic, pick an alternative, and move on.=20

dbh

-----Original Message-----
From: Andy Bierman [mailto:[email protected]]
Sent: Thursday, February 13, 2003 5:43 PM
To: Harrington, David
Cc: Durham, David; Wijnen, Bert (Bert); Sming (E-mail); Randy Bush =
(E-mail); [email protected]
Subject: RE: Status of the WG


At 05:15 PM 2/13/2003 -0500, Harrington, David wrote:
>Hi,
>
>I have a slightly different viewpoint.
>
>Both eos and sming are developing add-ons to SNMPv3. And I think SNMPv3 =
is the problem. SNMPv3 is incomplete, and the things it needs are not =
new mib syntax or compressed PDUs or TCP support. What it needs is some =
guidance about how to deploy it, and how to migrate a network, and =
network management tools, from SNMPv1 to SNMPv3.
>
>SNMPv3, as currently defined, is difficult to deploy. There is no =
standardized initial key distribution mechanism, only an experimental =
Diffie-Hellman approach. There is no integration with centralized key =
management and authorization, such as RADIUS; one approach exists for =
Kerberos, but that has been labeled experimental, and Kerberos does not =
seem to be in wide commercial use. There has been no official work to =
standardized the widely desired AES support. There has been no work to =
guide operators/vendors how to provide support for VACM views, given the =
design of existing mibs. There has been no work to guide mib writers how =
to write VACM-friendly mibs. There has been no work to define an =
easier-to-deploy access control model.
>
>The five leading network/systems management frameworks - HPOV, BMC =
Patrol, CA-Unicenter, Tivoli TME, and Spectrum - offer little support =
for SNMPv3 messaging, and no support for managing the elements of SNMPv3 =
such as users, views, and groups. Best-of-breed application vendors such =
as Concord Communications and Micromuse do not offer SNMPv3 support. =
Equipment vendors have provided support for SNMPv3 in their devices, but =
even their own applications, such as CiscoWorks, hide the details of the =
underlying SNMPv3 systems, and do not take advantage of the power of =
SNMPv3 concepts.
>
>No SNMP applications have been developed to manage SNMPv3 key =
distribution in-band between multiple agents and multiple applications. =
I have seen no applications to provide an easy graphical way to define =
and distribute VACM views.
>
>There are a number of applications that do policy-based management, =
including assigning roles to users, but they have not been integrated =
with SNMPv3 users and groups. Different operators often manage different =
aspects of networks, such as routing or security, but no standards have =
been developed to define policy-based division of labor for Network =
Management protocols.
>
>No standards have been defined for integrating the security models of =
SNMPv3 and CLI and web-based management. Securing one interface but not =
the others makes no sense. No work has been done to define how one =
should distribute SNMPv3 keys in CLI command scripts.

I'm not that interested in discussing how to make small incremental
changes to SNMPv3 to make it more deployable.  For those interested
in SNMPv3, this seems like a meaningful endeavor, and nothing seems
to be preventing such an effort.  One may ask why the EOS WG is not
addressing these issues (but ask on the EOS mailing list).

>
>EOS and SMING are interesting research projects, but they aren't very =
practical because they depend on a protocol and a security design that =
nobody can deploy reasonably. Before EOS and SMING become truly =
relevant, we need to help the industry get SNMPv3 deployed.

I disagree.  I don't see how changes to the data description language
affect security design.  I don't see the advancements that have been
suggested for SMIng as a research project.  These data modeling
features are well understood in both concept and practice.  One
can already derive these features from XML, and I suspect those
who want better data modeling will move to XML.

>
>We really need to decide whether we believe SNMPv3 is worth the effort =
to help get it deployed. If not, we should declare it Historic, pick an =
alternative, and move on. If we want it to be accepted, then we need to =
help the industry understand how to deploy it. So far, we have simply =
chosen to not get involved. If we don't believe it's worth the work, why =
should operators and vendors believe it's worth the work?

IMO, SNMPv3 does not meet many operator requirements and it does
not meet many vendor requirements either.  It seems pretty clear
that most people have made up their mind about SNMP, and no amount
of tinkering is going to change their opinions.

>
>I propose we deactivate EOS and SMING, and combine our efforts in an =
SNMPv3 deployment WG. This would be a good opportunity to have the =
network management experts and the operations experts work together to =
develop some recommended practices and the necessary missing pieces to =
make SNMPv3 a deployable secure network management protocol.

This does not address the high level issue of what to do in
the IETF about NM standards.  I don't buy the premise that if
we keep waiting long enough, the world will embrace SNMP, especially
for configuration management. There have been several I-Ds written,
detailing why SNMP is incompatible with operator and vendor
requirements.  The IETF is not serving community needs by
forcing people to use SNMPv3 and SMIv2.  There is a major disconnect
here which needs to be addressed.

>
>dbh

Andy


>
> -----Original Message-----
>From: Andy Bierman [mailto:[email protected]]
>Sent: Thursday, February 13, 2003 4:06 PM
>To: Durham, David
>Cc: Wijnen, Bert (Bert); Sming (E-mail); Randy Bush (E-mail)
>Subject: RE: Status of the WG
>At 09:39 AM 2/13/2003 -0800, Durham, David wrote:
>>The silence is deafening, and says it all. It seems that while most =
are
>>in agreement that SMI is seriously antiquated, convoluted, and =
requires
>>several maintenance fixes, there is very little (apparently zero now)
>>interest in fixing it and improving it. It would seem people are
>>satisfied with SNMP being regulated to a legacy systems management
>>interface.
>>
>>There is the realization that up-to-date data modeling languages are
>>already widely used and available (e.g. XMLSchema), and that the IETF
>>should not be engaged in the task of inventing yet another =
idiosyncratic
>>data modeling language... Particularly given that it will seriously
>>languish behind those that are commonly available today.
>>
>>Looking at the ROI on this effort, there are those who are asking why
>>not just adopt what is already available and stop beating a dead horse
>>in the hopes it will rise.
>
>I agree with this assessment.  It would be a large development
>effort to move from SMIv2 to any new syntax.  The key question
>is how much benefit will be realized by making a particular change.
>
>While I still believe there is enough benefit in the data modeling
>features of SMI-DS to make it worthwhile, I no longer believe that
>SNMP vendors and customers are willing to incur any significant cost
>to get this benefit.  I think the resources devoted to SNMP
>development are diminishing quickly (as expected for a legacy
>technology), and developers and customers believe SMIv2 is
>good enough, for the amount of effort they are willing to
>invest in SNMP.
>
>The cost/benefit ratio for SMIv2.1 seems worthwhile.  The
>need for HC data types has been known since (at least) 1992.
>Mandatory maintenance of SMIv2 is something that should already
>be done, so better late than never.
>
>Keep in mind that the decision to abandon SMIv3 (and EOS)
>sends a clear message to vendors and customers that SNMP
>technology has reached its peak. What we have now is
>as good as its ever going to get.  Those that are happy
>with SNMPv3/SMIv2 will continue to use it.  Those looking
>for something better will accelerate their efforts to
>transition to something else.
>
>
>
>>-Dave
>
>Andy
>
>
>
>
>
>>> -----Original Message-----
>>> From: Wijnen, Bert (Bert) =
[<mailto:[email protected]>mailto:[email protected]]
>>>
>>> So... not much (if anything) seems to be happening.
>>>
>