Re: Separation of protocol and information model

[Bobby Krupczak <rdk@krupczak.org>]

Hi!

>I think there's a division between what the configuration can contain
>and how it can be manipulated.  What I'd like to see is a protocol that
>can take a chunk of opaque configuration and load it only a router, with
>the maximum degree of reliability, recoverability, and transactionality
>available in the device's software.

>The content is the device's data model, which netconf is avoiding.
>The management is what we're trying to solve.  I can make fairly
>simple xslt scripts to turn a generic definition of what I want a vpn
>to look like into a set of configurations for each involved device
>(and to make it vendor/product/release specific).  I just need
>a simple and robust mechanism for loading those deltas onto devices.
>
>At the same time, I want an extensible mechanism so that applications
>can take advantage of features like candidate configuration, rollback,
>locking, named configurations, etc.  And I want something open to
>future extensions so that the Next Great Idea (tm) can be added
>incrementally to both devices and applications.  When my
>time-travel-based pre-corrective measure project comes to fruition, I
>want to be able to see it get used without having to travel back to
>now and add it to this spec. ;^)

I'm having a difficult time seeing how the working group can really
pull this off and come up with something that really benefits the
Internet community.  That is, is the resulting standardized protocol
really worth it.  W/o tackling (e.g. standardizing on) some of the
data-model (not necessarily in the protocol but in accompanying docs),
is this effort worthwhile?  It almost seems to be like standardizing
on SNMP w/o any standard-mibs.  While the ability to have
private-enterprise mibs was a key to SNMP's success, not having
standard MIBs would have surely killed it.  In essence, the Internet
Management Framework community was specifying what it meant to manage
a device and in term, it was specifying what and how devices should
handle management information.

At this point, these comments are probably not terribly helpful to the
working group as the charter, focus, and specs are already underway.

I'll probably have to partially re-invent the wheel as I'm really look
for a bit broader and deeper replacement for SNMP.

Thanks,

Bobby


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