Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt)

[Andy Bierman <ietf@andybierman.com>]

Phil Shafer wrote:
> Andy Bierman writes:
> > If they want to conform to the standard "notification" capability,
> > then they will do everything that is specified, including
> > implementing the tiny standard data model in the spec.
>
> For netconf to be widely accepted we need to minimize the price of
> implementation, leveraging existing software features and configuration.
>
> For example, JUNOS configures its syslog logging under the "system
> syslog" statement, where a set of files (and remote destinations)
> are configured.  Using the mechanism in the draft, I can expose
> these files as streams for netconf clients with fairly low
> implementation costs.
>
> If the cost of implementing netconf is moving every config statement
> to a new hierarchy and reimplement all software to fit this new
> netconf world, then netconf is going nowhere.

This doesn't make a lot of sense.
You are okay with standard parameters for syslog delivery
when they are passed in a special RPC, but if those standard
parameters are moved to a data model, suddenly you can't
map your proprietary mechanism to the standard anymore.
If you could handle the burden of standard parameters
passed in a special RPC, then you can handle the burden
if they are passed in a existing RPC.

Remember that those existing RPCs represent the minimal
conformance level for a netconf agent.  An implementation MUST
advertise the base capability, which includes all the
operations we have been discussing.  Any other capabilities
MUST be in addition to the base capability.  So it is
not a burden for a conforming netconf agent or manager
to use the base operations, since they are never optional.

As for the need for standard data models at all...
It doesn't really matter from a standards POV what any particular
vendor has implemented for configuration.  What matters is
that an NMS developer can code to the standard, and it works.

We are not chartered to produce standard data models for the
entire IETF -- just the NETCONF protocol (just as the SNMP WG
developed standard MIBs for the management of the SNMP protocol itself.)

The bar has been raised in this WG.
We are going to eat our own recipe.
We are going to provide fully configurable features
for the NETCONF protocol.  It may be okay for other WGs
to say "leave configuration to the vendors, that is not our focus",
but not this WG.  Standards based configuration is our focus.
(Not syslog delivery, BTW.)





> Thanks,
>  Phil


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