[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 09:44:25AM -0700, Andy Bierman wrote:

It's less work to define data models for use with the netconf
protocol than it is to redefine the netconf protocol functionality.

I do not believe this to be true. Implementation wise, I actually do
not see much of a difference. My SNMP experience tells me that adding
new PDUs is actually not a big deal - implementing the semantics is
where you have to spend time. And having to check whether the data
elements you received make since is about the same work as checking
whether a PDU that you received makes sense.

<soap>
  Once upon a time, people believed that the addition of create/delete
  operations to SNMP would add a huge amount of complexity and so we
  got RowStatus which I assume every implementor who has gone through
  the 8K description clause has falled into deep love with.
</soap>

While I do not have a strong opinion, I do have a preference for a
_simple_ subscription mechanism as part of the protocol since I
believe having special verbs will make it more likely that management
apps get to actually use the feature. The argument is clearly on the
irrational side of things how I believe many human programmers work -
they usually tend prefer verbs over data structures and even purely
declarative approaches.


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.

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.

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.


/js


Andy



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