Subject: Re: [netmod] tconfig

From: David Partain <[email-masked]>
Date: Tue, 1 Sep 2009 13:27:19 +0200

Hi,

I've just read through this thread.  It's talked about "transient config" and 
is now morphing into a discussionabout deviations.  

I haven't, though, seen any concrete suggestions about textual changes that 
people want.  I'd like to close this thread, please, unless accompanied by 
suggestions for changes.

Thanks.

David

On Monday 31 August 2009 21.52.25 Andy Bierman wrote:
> Ladislav Lhotka wrote:
> > Andy Bierman píše v Po 31. 08. 2009 v 09:45 -0700:
> >>>> An alternative could be to work on a more generic solution, but I
> >>>> think this requires protocol support (<get-operational> or something),
> >>>> and modelling support.  But I don't think this is a must-have for YANG
> >>>> 1.0.  We don't even know what such a solution would look like, so if
> >>>> anything, we could encourage people to work on the problem, using
> >>>> NETCONF and YANG extensions.
> >>>
> >>> I agree, and from my point of view current YANG is OK as a
> >>> domain-specific XML schema language - we can decide whether a given
> >>> configuration is valid according to a data model, whether two
> >>> configurations are equivalent given the set of declared defaults etc.
> >>
> >> I also agree, but only if the definition of a default is confined
> >> to the YANG default-stmt value, for all YANG modules advertised
> >> in the module capabilities.
> >
> > Absolutely, and with-defaults draft should include YANG-specific
> > normative text.
>
> yes, but I am not sure how deviations work with this definition
> of a default.
>
> I think there are only 2 implementations that include deviation-stmt
> at this time, and we both implemented deviations as a patch.
> Once the run-time schema tree is patched, does this count as the
> new contract, including defaults?
>
> That's what I was afraid of when I objected to deviations
> so strongly in the first place.
>
> standard says:
>
>    leaf foo {
>      type string;
>    }
>
> If the deviations add/replace/delete a default, does
> that count as the new default, or does that count as
> a server-created instance with a non-default value?
> The deviations were not supposed to allow the contract
> to be altered, just identify the ways the server
> is non-compliant.
>
> The schema language is the component that adds
> semantics to the standard syntax.  We are making a big
> departure from SNMP robustness principles by requiring
> a client to have a complete and accurate set of schema
> definitions and deviations, just to obtain a complete set of
> operational data values from a particular server.
>
> A human or a dumb 'MIB walker' could make use of the complete
> output, especially in XML, because the object hierarchy is
> clearly identified and (except for binary) the built-in content
> is all readable.  This definition of 'all' includes YANG defaults.
>
> I am also concerned that vendors will not advertise the
> critical deviation modules for standard modules, because
> that (by definition) means the vendor does not comply with
> the standard.  The deviations for the vendor's own YANG modules
> will be quite rare in comparison, since they have total
> ownership of that content.
>
> I am also concerned about the fact that revision statements
> are purely optional to use (outside of standard modules).
> Then, if the vendor changes a default over time, the client
> has no clue which leaf-stmt to pick to decide if
> a missing leaf has a default, and its true value.
>
> (Still want to stake your job on those default-stmt values. operators?)
>
> > Lada
>
> Andy
>
> >> As long as every leaf instance is retrievable by the client somehow,
> >> then the current draft is fine.  I can accept that the configuration
> >> is just the leaf instances that do not have the YANG default-stmt
> >> value.  If the current value of every leaf instance is retrievable
> >> on every NETCONF server, then it is OK if the description statements
> >> are needed to correlate the leaf instances.
> >>
> >> Asking the server to deduce the value of any current leaf instance
> >> value is the only non-starter still floating around at this time.
> >>
> >>> Lada
> >>>
> >>>> /martin
> >>
> >> Andy