Re: [netmod] operational knobs
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [netmod] operational knobs
> -----Original Message-----
> From: netmod-bounces at ietf.org
> [mailto:netmod-bounces at ietf.org] On Behalf Of Randy Presuhn
> Sent: Tuesday, November 03, 2009 6:38 PM
> To: NETMOD Working Group
> Subject: Re: [netmod] operational knobs
>
> Hi -
>
> > From: "Andy Bierman" <andy at netconfcentral.com>
> > To: "Phil Shafer" <phil at juniper.net>
> > Cc: "NETMOD Working Group" <netmod at ietf.org>
> > Sent: Tuesday, November 03, 2009 10:26 AM
> > Subject: Re: [netmod] operational knobs
> ...
> > IMO, new verbs and nested data structures in notifications are the
> > best parts of YANG.
>
> Initially, we thought the same thing about these capabilities in CMIP.
> Implementation and deployment experience demonstrated that
> they came at a high cost, though in areas that netconf hasn't
> really started to dig into.
>
What changed in the two decades dramatically is the cost of the
resources needed for implementation on a network device. As an
implementer at that time I can bare direct witness that the principal
reason we adopted SNMP at that point in time was simply that it was
implementable in network devices (hubs, bridges, routers) while CMIP was
not.
> > The config database may
> > turn out to be a 'legacy' concept, and complex verbs may replace
> > get/set operations on an XML tree someday.
>
> If that's the case, then you may as well discard the whole
> notion that configuration management is about bringing a
> system to a reasonably known state.
I would agree. I do not see yet how interoperable management is possible
without a config database shared between different vendors of devices
and applications but maybe it's just that I am not imaginative enough.
Dan
>
> Randy
>
> _______________________________________________
> netmod mailing list
> netmod at ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.