[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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".



Here is my concern.

We have zero standard data models now.
We have zero specialized RPCs now.

The notifications draft completely ignores all
of the write/save/reload operations in the protocol
and reinvents them with specialized RPCs instead.
Except they are under-specified and contradict
the protocol standard in some places (e.g., saying
NV-storage is optional).

I think a combined approach would be acceptable:

1) Define a data model for all the parameters that control/monitor
   the notification subscription, so that it can also be used by the
   agent without any manager subscription.  I.e., a table indexed by
   a name string containing one 'row' per parameter set.  A separate
   table for reusable filters is also needed.

   A notification target table is also needed which is completely
   independent of the session-subscription API.  Parameters such
   as the notification receiver address, user name, and user credentials
   need to be included to configure a traditional notification
   generation application.

2) Use standard operations such as <edit-config> to manipulate
   all notification parameters, even for changing profiles in use.
   <create-subscription> and all other special RPCs go away.

3) A new special RPC <start-notifications> is used
   for a manager to start receiving notifications.
   There is no subscription ID because there is only one
   stream of notifications on this session, which can be changed
   by editing the configuration.

   The <stop-notifications> RPC is used to tell the agent to
   cease notification generation for the session.

4) There is no real need for <suspend> and <resume> because
   the parameters passed in <start-notifications> are trivial.

5) mixed-mode vs. endless-RPC is very problematic.
   I could live with mixed-mode, but I don't want
   the WG coming back next year asking for a lot
   of complicated hacks to deal with the horrible
   operational characteristics of mixed-mode.
   The answer will be "don't mix operations and notifications
   if you are not prepared to deal with the delays or the lost
   notifications."



Andy






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




--
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/>