On Mon, Sep 18, 2017 at 9:21 AM, Juergen Schoenwaelder <
[email protected]> wrote:
> On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
> >
> > > No. I do not agree that the MUST in RFC 7950 can be removed.
> > > I do not agree the architecture should update YANG at all.
> > OK.
>
> I am with Andy here. <running> has always had the requirement to be
> valid and we are not supposed to change that. Mechanisms for inactive
> configuration or templating must be designed to be backwards compatible
> I think.
>
>
I have been trying to think of a way that an enterprise-wide flag day
upgrade is not required,
but no luck so far. As Phil pointed out, if 1 client is using disabled
nodes,
unaware clients clients might end up deleting them if disabled nodes
are just omitted from <get-config> responses. (e.g., replace operation).
A client has no requirement to maintain attributes sent with server
responses
(unlike the server for <rpc> -> <rpc-reply>), so returning the disabled
nodes
to an unaware client is no solution either.
It looks to me that an operator has to make sure all apps that alter
configuration
are aware of the disabled nodes.
IMO a standard attribute should be defined using RFC 7952:
md:annotation enabled {
type boolean;
description "...";
}
Even if the server supports vendor-specific attributes, it has to report
this attribute as well.
The default is enabled, so only disabled nodes need this attribute.
Standard configuration can wait. Standard reporting should not wait.
Since clients can ignore YANG extensions, a new version of YANG will be
needed eventually,
but at least this allows 3rd party clients to recognize disabled nodes from
any vendor.
/js
>
>
Andy
> --
> Juergen Schoenwaelder Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
