more on de-coupling

[Bobby Krupczak <rdk@krupczak.org>]

Hi!

I had privately replied to Andy's challenge but figured that my
comments were probably just as apropos to the group.

>Please explain which information model specific details are part
>of the protocol.  All of the protocol operations are generic
>and apply to any type of device, not just routers.  

My reading of the draft, leads me to believe it is very cisco-centric.
(However, it may be because I know you and know you're from Cisco
. . .)  Its been a while since I've configured routers, and while most
routers have some sort of running vs standby config, the concepts
embedded in this set of drafts do seem to mirror cisco-style
configuration awefully closely.  

If someone on the list from some non-cisco network-gear company would
comment, that would be awesome.  My ascend P75 (OK, I'm dating myself)
didnt exactly have a running vs. candidate-config, and many of the
smaller router boxes you can now buy hide any of this via those
dreaded web-interfaces.  However, I suspect underneath they dont have
this.  If this WG only focuses data models on the larger more complex
routers, would this be a mistake?

Non-routers (e.g. workstations, etc.) dont necessarily have a
running-config vs candidate config either.  In fact, their "config" is
so much more elaborately complex as to not fit this model very well.
Firewalls, dhcp servers, and other "network" devices may also be
troublesome to this model.

>Also remember
>that the charter of this WG focuses on network configuration,
>not every possible aspect of network management.

Very true and I am glad you bring that back up so as to re-remind me.
I think it would be a shame, for those of us looking to move beyond
SNMP, to have to re-invent an XML based protocol and framework that is
sooooo close to the netconf but just different enough to foster
confusion.  However, the WG does have its charter and its water under
the bridge (Hi Randy Bush?!)

I could go on and on but I think the SBC guys' comments are very to
the point.  My point really in replying was to add some small level of
support to them.

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