Re: [netmod] operational knobs
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [netmod] operational knobs



Hi -

> From: "Phil Shafer" <phil at juniper.net>
> To: "Joel M. Halpern" <jmh at joelhalpern.com>
> Cc: "NETMOD Working Group" <netmod at ietf.org>
> Sent: Sunday, November 01, 2009 9:01 AM
> Subject: Re: [netmod] operational knobs
...
> I've always been curious why new verbs weren't added to SNMP
> instead of this kludge.  Poking bytes into control registers
> clearly wasn't the example to follow and the distaste for it
> seems universal, but I've never grok'd why verbs like CREATE,
> DELETE, LOCK, CHANGE, PRE-CREATE, DISABLE, &etc weren't made.
...

Adding them would have been a change to the protocol's grammar,
which would have been a non-starter for several reasons:

   -  re-starting the clock at "Proposed Standard" each time one of
      these was added would have been politically unpalatable (CMIP
      was a full IS, and, since it already had verbs for Create, Delete, etc.,
      adding these to SNMP would also have been seen as an admission
      of inadequacy)

   - changing the grammar would have adversely affected the deployed base
      of management systems and agents, as well as the various vendors'
      development tools, and would have invalidated the interoperability suites,
      bake-offs, and test events.  The ability to work with generic "dumb" MIB
      browsers was demanded by users.

    - by the time SMP, Secure SNMP, SNMPv2, SNMPv2*, etc, started appearing,
      access control models were being formulated in terms of object identifiers.
      If an "Action" facility were to be added, we'd have had to formulate the policies
      in ways similar to how VACM processes notifications, which would severly
      constrain how people could formulate actions.  (Not that that would have been
      a bad thing)

FWIW the CMIP experience, while it did establish that having distinct verbs for
Create and Delete was a Good Thing, and had provisions for synchronization
built into the object model and the protocol, also demonstrated that a generic
Action facility, while useful, needed to be used *Very* carefully.  Like netconf RPCs,
it provided the ability to shovel around rather arbitrary syntax.  Mating this with
fine-grained access control expressed in terms of the object model is
hard.  Later discussions of "we wish we had" in CMIP-land supported limiting
the payload to things that would look like variable bindings, rather than arbitrary
ASN.1, to ease matching up the bits and pieces of actions with the objects'
data models.

Randy


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.