> On 06 Aug 2015, at 17:31, Andy Bierman <a...@yumaworks.com> wrote: > > > > On Thu, Aug 6, 2015 at 5:50 AM, Ladislav Lhotka <lho...@nic.cz> wrote: > > > 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. > > > > > If an edit would cause the datastore to be invalid, > then it has to be rejected. > > > > > > > > > > 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. > > It needs to be in a separate datastore so it can be > validated separately from the running config. > > > > > > > > > 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. > > > > This type of corner case has been discussed. > The ephemeral state needs to over-write enough of > the running config to be self-consistent.
Hmm, so such values become suddenly persistent? And what if running is locked when this over-write is attempted? Will such chagnes be propagated to candidate? This looks like a lot of wizardry that tries to hack ephemeral state on top of the existing NETCONF architecture. Lada > > > In any case it is OK to set the running config value to > something that will not be used at the moment. I2RS > will prevent the running config value of p from being used. > The ephemeral config has priority over the running config. > > > Lada > > Andy > > > > > > > > > > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
