On Sat, Sep 16, 2017 at 3:14 AM, Juergen Schoenwaelder <
[email protected]> wrote:
> On Sat, Sep 16, 2017 at 02:56:45AM -0700, Andy Bierman wrote:
>
> > Either way, the new YANG rules seem half-baked and not ready
> > for standardization.
>
> OK. Then please tell us where you see problems. The usage of must vs
> MUST does not seem to be the issue.
>
>
sec 4.4:
Validation is performed on the contents of <intended>.
Does this mean validation is not done on <running>?
The draft does not say. If so, then this seems to break all
existing clients that validate <running>. Standard operations
such as <commit> or <edit-config> with :writable-running capability work
this way.
What happens if a client does validation on <running>? It now can fail even
though RFC 7950, sec. 8.1 says:
*The running configuration datastore MUST always be valid.*
The motivation is clear in the RD draft, sec 4.3:
The running configuration datastore (<running>) holds the complete
current configuration on the device. It may include inactive
configuration or template-mechanism-oriented configuration that
require further expansion.
This forces a client to accept unspecified proprietary inactive
configuration and proprietary templates
that apparently are not subject to YANG validation.
Currently there are no standard mechanisms defined that affect
<intended> so that it would have different contents than <running>,
but this architecture allows for such mechanisms to be defined.
This is a significant change in the NETCONF/RESTCONF standards which is
completely unrelated to operational state. The client MUST understand
unspecified
proprietary differences between <running> and <intentional>. The client
can now
assume that <running> is always valid, but this draft breaks that.
IMO, only the <operational> datastore work is standards-ready.
Andy
/js
>
> --
> 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
