Re: [netmod] operational knobs

[Andy Bierman <andy at netconfcentral.com>]

Jon Saperia wrote:
> Randy,
> 
> Good points.
> 
> In the context of the current conversation, this history argues for
> getting as much of NETCONF/YANG correct the first time.  I mean not only
> for the immediate application to which the protocol and language will be
> put, but also, where people want it to go.
> 

I disagree.
We have a lot of theory, but not 1 config=true
object in any I-D or RFC.  We have a description-stmt
for a reason.

It is much easier for a WG to reach consensus
on advanced features if there is common experience
based on well-known data models in use.

There also needs to be a YANG Doctors eventually, like MIB Doctors,
so sufficient review resources are available throughout the
IETF YANG data modeling experience.  This is a far more effective
process than working forever on YANG 1.0, because we know it
is not perfect.


> To the degree NETCONF/YANG are successful, it will be difficult to
> change them to make adjustments/corrections that the WG chooses to punt
> now.

But now we have capabilities and a <hello> message.
Incremental additions are part of the plan.


> 
> /jon

Andy

> On Nov 1, 2009, at 11:02 AM, Randy Presuhn wrote:
> 
>> 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
>>
>> _______________________________________________
>> netmod mailing list
>> netmod at ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> 
> _______________________________________________
> netmod mailing list
> netmod at ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>