Re: comments on draft-ietf-netconf-notification-01.txt

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

I really agree with Juergen on this issue.

One thing that I would like to remind the readers about is
the following about creates.....

Consider a create operation. In some cases, the instance
of the item being created has a semantic meaning and
in other cases the instance is arbitrary. In other management
protocols, a create operation returns the instance of
the item being created. In the SNMP protocol, since
the designers did not provide "reliability", the result
of an operation could be lost. If the operation was
"create", then an instance could be created, but lost
when the result message was lost. Thus, to add a
create operation, the SNMP protocol would have to be
made "reliable". This is much harder, given the
installed base, than just adding a new verb.


On Wed, 3 May 2006, Juergen Schoenwaelder wrote:
> On Wed, May 03, 2006 at 12:38:35PM -0700, Andy Bierman wrote:
>  
> > There is always engineering trade-offs to consider.
> > 
> > I agree it will always be simpler on the NMS for
> > a particular task to use a specialized API that moves
> > complexity to the agent.  It is not simpler on the agent
> > to add new specialized code than it is to reuse existing code.
> 
> I am not convinced that using a verb instead of a data model makes any
> difference implementation wise on the agent. I accept that your
> experience might be different from mine so we do not have to agree on
> this.
>  
> > This approach doesn't scale well.
> > By the time you define 5 or 10 specialized RPCs for each
> > possible feature, you have 5000 special RPCs
> > and no reusable code.
> 
> My background is work on DISMAN MIBs and I can assure you that the
> fact that we had to cast every disman operation into gets/sets on a
> data model did not make things simpler. In fact, it requires some
> engineering efforts to cast out verbs from many data models that can
> be provided as a library to be used by applications. In some MIBs, I
> started to write down procedures how the various knobs should be used
> to implement a verb. Here is also a quote from RFC 3535:
> 
>    -  Several standardized MIB modules lack a description of high-level
>       procedures.  It is often not obvious from reading the MIB modules
>       how certain high-level tasks are accomplished, which leads to
>       several different ways to achieve the same goal, which increases
>       costs and hinders interoperability.
> 
> I also note that CLIs tend to have lots of verbs and even though you
> might not like this approach, they have at least been successful.
> Note that I am not arguing we should open up pandora's box and add
> verbs for everything (e.g. "shutdown interface" vs. "set interface
> status down"). But we should also not fall into the other extreme
> where we strictly stick to a fixed set of verbs just for purity
> reasons or not very detailed claims of "increased complexity".
> 
> > We explicitly designed a protocol to provide
> > a small set of powerful standard operations which can
> > manipulate any arbitrary data model.
> > IMO, it is better to stick with this architecture
> > than ignore it and start on a path of specialized RPCs.
> 
> I thought we would have learned from SNMP's history and the success of
> CLIs and that we would be a bit more flexible this time around and
> take some of the irrational factors of humans also into account when
> we design things.
> 
> Anyway, I think I stated my preference wrt. notification subscriptions
> and if I am just a small minority who has some unusal implementation
> experiences, I am fine to accept a more data driven approach (means I
> will not object against it).
> 
> /js
Regards,
/david t. perkins


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>