Re: [YANG] new pyang errors

Juergen Schoenwaelder píše v St 23. 01. 2008 v 09:41 +0100:
> On Wed, Jan 23, 2008 at 09:25:56AM +0100, Ladislav Lhotka wrote:
> 
> > > a) ssh is not going to do that for me anytime soon
> > 
> > It's important that raw ssh works in principle but let's face it -
> > reading and typing NETCONF XML stuff via stdin/stdout is only for
> > masochists.
> 
> Perhaps real operators are masochists. Seriously, the amount of
> existing scripting code using CLI interfaces is huge. This is not
> going to go away.

Yes, but scripts connected via stdin to ssh are something different. You
can then set up a pipeline with a filter that suppresses (or fills in in
the opposite direction) the default values - but these could be your
default values that needn't necessarily be the same defaults the device
uses.

> 
> > > b) only the device really knows what has been touched
> > 
> > I'd like to make sure that my configurations work - as much as possible
> > - even after the device has been replaced by another brand.
> 
> There is no contradiction between these two statements so I guess you
> agree with my statement. ;-)

Well, if you only have a diff against factory default configuration of
device A and device B has a different one ...

> 
> > > c) configuration will always be to some extend proprietary; so your
> > >    app needs to understand all the proprietary stuff of all your devices
> > 
> > I don't agree - the whole NETCONF then wouldn't make much sense. That
> > "some extent" must be rather minor IMO.
> 
> It is an illusion to believe that all router vendors will ship exactly
> the same feature set. Whether the proprietary configuration knobs will
> be 1% or 100% we don't know - but it will exist.

If two devices advertise the same DM then I can assume they both have
the knobs that are present in the DM - perhaps others as well. The
simpler the DM is, the more likely it is that different vendors accept
it. That's why I'd like to remove all constraints that can be handled in
a different way, even if it means more data on the wire.

> 
> > > d) SNMP failed badly in this space, partly because of b) and c)
> > 
> > Avoiding hidden assumptions cannot make the situation worse, only
> > better.
> 
> I am not sure which hidden assumptions you have in mind.

That configuration parameters in the device have certain values even
though you haven't seen them.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

_______________________________________________
YANG mailing list
YANG@ietf.org
https://www1.ietf.org/mailman/listinfo/yang