FW: Status of the WG

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.
 
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.
 
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?
 
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.
 
dbh
 
 -----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]]
>>
>> So... not much (if anything) seems to be happening.
>>