> On 06 Aug 2015, at 13:03, Andy Bierman <a...@yumaworks.com> wrote: > > > > On Thu, Aug 6, 2015 at 12:43 AM, Ladislav Lhotka <lho...@nic.cz> wrote: > Andy Bierman <a...@yumaworks.com> writes: > > > On Mon, Aug 3, 2015 at 11:58 AM, Ladislav Lhotka <lho...@nic.cz> wrote: > > > >> > >> > On 03 Aug 2015, at 18:01, Andy Bierman <a...@yumaworks.com> wrote: > >> > > >> > > >> > > >> > On Mon, Aug 3, 2015 at 7:48 AM, Ladislav Lhotka <lho...@nic.cz> wrote: > >> > > >> > > On 03 Aug 2015, at 16:41, Andy Bierman <a...@yumaworks.com> wrote: > >> > > > >> > > > >> > > > >> > > On Mon, Aug 3, 2015 at 2:25 AM, Juergen Schoenwaelder < > >> j.schoenwael...@jacobs-university.de> wrote: > >> > > On Mon, Aug 03, 2015 at 11:06:41AM +0200, Jernej Tuljak wrote: > >> > > > Juergen Schoenwaelder je 3.8.2015 ob 10:18 napisal: > >> > > > >Any description statement in principle can do this. We trust that > >> sane > >> > > > >data model writers won't do bad things. And if they do, we hope that > >> > > > >people will not implement and deploy bad things. > >> > > > > >> > > > Why not simply make this impossible by ensuring that description > >> > > > statements cannot change what has already been agreed upon in RFC6020 > >> > > > (aka YANG semantics)? I would have no problem with descriptions being > >> > > > normative, if this would be the case. > >> > > > >> > > You need to define way more clearly what 'YANG semantics' means. > >> > > > >> > > > >> > > > >> > > Agreed. The description-stmt is normative. > >> > > It defines implementation requirements for a data node. > >> > > It is not used to override other YANG statements. > >> > > However, if the description says "child foo must be > >> > > greater than the value of bar" that is just as normative > >> > > as a must-stmt that says the same thing. > >> > > > >> > > > >> > > > >I continue to see extension statements as reusable and (in > >> principle) > >> > > > >machine readable fragments of description statements. From this > >> > > > >perspective, it seems odd to make a difference between extensions > >> and > >> > > > >description statements. > >> > > > > >> > > > I still disagree that description statements should be more powerful > >> > > > than any other YANG statement. > >> > > > >> > > What does 'powerful' mean? Time that someone writes concrete text so > >> > > we can have a more constructive discussion. > >> > > > >> > > > >> > > A YANG description-stmt cannot override the syntax and semantics of > >> other YANG > >> > > statements. But is is mandatory and it is normative. > >> > > >> > It’s not only about overriding. For example, it wouldn’t be good to > >> introduce a new data node type though an extension. > >> > > >> > > >> > But isn't that exactly what you are proposing by making ephemeral data > >> > an extension instead of part of YANG? > >> > >> It depends on how it would be defined and used. If it is an extension, > >> NETCONF/RESTCONF clients either shouldn’t see it at all, or they should be > >> able to ignore it. > >> > >> > > >> > None of the existing text covers the validation rules for ephemeral data. > >> > Nothing is needed for config=true nodes in the ephemeral datastore, > >> > but ephemeral-only data needs to be identified. > >> > >> I think it still has to be clarified how ephemeral data interact with > >> normal config data. Normal semantic validation of config=true data doesn’t > >> make much sense to me if some parameters may be overriden by ephemeral > >> values. > >> > >> > > > > I agree that suitable solutions have been discussed off-line, > > and the slides from Jeff do not specify how validation would work. > > This is part of the month of work left to do. > > > > IMO the running datastore and ephemeral datastore have different > > validation procedures: > > > > Running: > > config=true validation > > same as now; no impact from ephemeral datastore > > validation done at edit-time > > I think there has to be an impact - validation of running has to take > into account ephemeral values as long as they are what's operationally > used. > > > > > This is completely wrong. > Config nodes cannot refer to non-config nodes for validation. > Consider the moment when the device boots, and there is > no ephemeral data. Any validation of the startup config > that depends on ephemeral data will fail.
If there is no ephemeral data, then config data is what counts. However, if some config parameters may be overriden by ephemeral values, then a separate validation of running is not sufficient - it may be in conflict with ephemeral data. I guess the purpose of semantic rules and validation is to make sure the parameters that the device uses, no matter where they come from, are correct. > > The running config must be self-consistent. > It never ever relies on ephemeral or operational data > for validation. Ephemeral data is a configuration, too. > > > For example, take IPv6 RA parameters valid-lifetime and > preferred-lifetime as defined in ietf-ipv6-unicast-routing. A must > constraint is there to ensure that > > preferred-lifetime <= valid-lifetime > > Now, assume their values in running are p and v, respectively, but an > I2RS client sets an ephemeral value of valid-lifetime to v' where > > v' < v > > If a NETCONF client changes value of preferred-lifetime to p' where > > v' < p' <= v > > then the constraint in running is satisfied but the values p' and v' > appearing in RA Prefix Information sent by the device violate RFC 4861. > > How is this supposed to be resolved? > > > Setting the ephemeral value has to be valid in the ephermal datastore. > That is a separate datastore and validated differently. > See paragraph "Ephemeral' below. > Perhaps the "panes of glass" concept has not been explained to you? Of course it was. You didn’t answer my question though, so let me expand my example into the following scenario: 1. The device boots, values of valid-lifetime and preferred-lifetime in running are initialized from startup to v and p, respectively, where p < v. The device sends RAs with there values, everything’s OK. 2. I2RS sets the ephemeral value of valid-lifetime to v’ where p < v’ < v. The device now sends RAs with p and v’, which is still OK. 3. A NETCONF client attempts to change preferred-lifetime in running to p’ where v’ < p’ <= v. Should this edit be rejected? On one hand, running continues to be perfectly valid, but on the other hand RAs with values of p’ and v’ are broken. Lada > > > > Lada > > > Andy > > > > > > Ephemeral: > > config=true validation done with ephemeral data first, > > then running datastore if no matching ephemeral data > > (panes of glass) ; validation done at edit-time > > > > config=ephemeral validation done with ephemeral data > > and operational state; config=true MUST NOT appear > > in any ephemeral data node constraint expressions.; > > validation done at edit-time; not clear if additional validation > > needed whenever any relevant operational state changes. > > (Implementation detail how quickly server checks?) > > > > > > > > Lada > >> > >> > > > > Andy > > > > > >> > > >> > Validation rules are needed for ephemeral data. > >> > Whether this is part of a protocol spec or YANG needs to be decided. > >> > > >> > > >> > > >> > Lada > >> > > >> > > >> > Andy > >> > > >> > > > >> > > > >> > > > >> > > > >> > > /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/> > >> > > > >> > > >> > -- > >> > Ladislav Lhotka, CZ.NIC Labs > >> > PGP Key ID: E74E8C0C > >> > > >> > > >> > > >> > > >> > > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> > >> > >> > >> > >> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
