Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 03 Aug 2015 09:22:48 +0200

Andy Bierman <[email-masked]> writes:

> On Fri, Jul 31, 2015 at 8:37 AM, Ladislav Lhotka <[email-masked]> wrote:
>
>>
>> > On 31 Jul 2015, at 16:54, Andy Bierman <[email-masked]> wrote:
>> >
>> >
>> >
>> > On Fri, Jul 31, 2015 at 5:45 AM, Ladislav Lhotka <[email-masked]> wrote:
>> >
>> > > On 31 Jul 2015, at 14:40, Andy Bierman <[email-masked]> wrote:
>> > >
>> > >
>> > >
>> > > On Fri, Jul 31, 2015 at 1:12 AM, Ladislav Lhotka <[email-masked]>
>> wrote:
>> > > Martin Bjorklund <[email-masked]> writes:
>> > >
>> > > > Andy Bierman <[email-masked]> wrote:
>> > > >> On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund <[email-masked]>
>> wrote:
>> > > >>
>> > > >> > Andy Bierman <[email-masked]> wrote:
>> > > >> > > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund <
>> [email-masked]>
>> > > >> > wrote:
>> > > >> > >
>> > > >> > > > Andy Bierman <[email-masked]> wrote:
>> > > >> > > > > Hi,
>> > > >> > > > >
>> > > >> > > > > I understand the intent is that an implementation of NACM
>> > > >> > > > > has to understand these NACM extensions.  I agree with Lada
>> > > >> > > > > that the YANG text about MAY ignore extensions casts doubt
>> whether
>> > > >> > > > > this sort of NACM rule is enforceable or specified
>> correctly.
>> > > >> > > >
>> > > >> > > > So do you agree that it would be a good idea to clarify this
>> > > >> > > > according to Juergen's suggestion?
>> > > >> > > >
>> > > >> > > >
>> > > >> > > >
>> > > >> > > Not really.
>> > > >> > > Pretending the extension is just another description-stmt
>> > > >> > > does not really fix anything.
>> > > >> > >
>> > > >> > > A real YANG statement like config-stmt or a new statement
>> > > >> > > called ephemeral-stmt can be modified with refine-stmt
>> > > >> > > or deviate-stmt.   This can never happen for
>> > > >> > > an external statement.
>> > > >> >
>> > > >> > There are two separate issues here:
>> > > >> >
>> > > >> > 1) It seems we are in agreement that if a model uses an extension
>> > > >> >    statement, it is normative (like ietf-system's usage of
>> nacm:*).
>> > > >> >
>> > > >> >    Should we somehow clarify this in 6020bis?
>> > > >> >
>> > > >> > 2) Extensions cannot be refined or deviated.
>> > > >> >
>> > > >> >    Actually, the *syntax* rules allows things like:
>> > > >> >
>> > > >> >      deviation /x:foo {
>> > > >> >        deviate replace {
>> > > >> >          i2rs:ephemeral true;
>> > > >> >        }
>> > > >> >      }
>> > > >> >
>> > > >> >    I agree that it not clear what this means, but we could also
>> > > >> >    clarify this in 6020bis.
>> > > >> >
>> > > >> >
>> > > >>
>> > > >> But this will take even longer than just defining the statements
>> that
>> > > >> are needed for ephemeral state, so no point in doing that.
>> > > >>
>> > > >> The text in  7.18.3.2 clearly does not support the example above at
>> all.
>> > > >
>> > > > The grammar allows extensions everywhere, so the example is (as I
>> > > > wrote) syntactically valid.
>> > > >
>> > > >> Only one of the keywords listed in the table are supported.
>> > > >
>> > > > The text doesn't say so, and anyway my point was that - regardless of
>> > > > the outcome of the ephemeral dicussion - it might be a good a idea to
>> > > > clarify that extensions can be deviated as well.
>> > >
>> > > +1
>> > >
>> > >
>> > > So you are saying that a tool MAY ignore any extension, except
>> > > inside a deviation-stmt?  Then it becomes mandatory to support?
>> > >
>> > > Or do you mean:
>> > >
>> > > Yes you can put extension-stmts anywhere, but also, yes the tool
>> > > MAY ignore every single extension (everywhere, including inside a
>> > > deviation-stmt)
>> >
>> > I understood Martin’s proposal so that a device that doesn’t support an
>> extension used in modules it advertises will have to put it in a
>> “not-supported” deviation.
>> >
>> >
>> > So features are all "not-supported" by default. but extensions,
>> > which a tool MAY ignore, are all supported by default?
>>
>> I proposed to remove this “MAY ignore” text.
>>
>
>
> I do not support this change
>

The current "MAY ignore" formulation is unclear, and it doesn't matter
whether it talks about compilers, parsers or tools.

The problem with extensions is that they can mean virtually anything –
in particular, they can change semantics of YANG or the management
protocol.

I think there are two possible approaches:

1. Treat all extensions appearing in the server's data model as
   mandatory parts of data model or protocol semantics.

2. Make extensions truly optional and irrelevant from the point of view
   of YANG language.

With #1, a client that doesn't understand all extensions the server uses
SHOULD terminate the session, because there are no means for negotiating
support for extensions one by one.

I am afraid this could have disastrous consequences for
interoperability: we would have silos where servers only work with
clients of the same provenience.

#2 is what RELAX NG does: elements and attributes from foreign
namespaces are allowed in a schema but they cannot affect the notion of
RELAX NG validity because the specification of the validation procedure
says: "Foreign attributes and elements are removed."

With #2, protocols such as I2RS can still define their extensions
provided that

- there is some way for making sure that both the server and client
  understands it,

- it doesn't affect servers and clients of other protocols, so they may
  safely ignore it.

I would personally vote for #2, but then the NACM stuff or the
"annotation" statement really cannot be extensions.

Lada

>
>
>>
>> > A server would be required to identify and remember all
>> > extensions used?  And what about nested extensions:
>> >
>> >     acme:foo test1 {
>> >        acme:foo2 test2;
>> >     }
>> >
>>
>> Yes.
>>
>> > The server would be required to completely parse all extensions,
>> > and not skip over them? Just to list them as deviations?
>> >
>> > I think extensions should be like features and the server should
>> > advertise them if they are supported.
>>
>> My idea was that all extensions has to be supported, and those that aren’t
>> will be declared as not-supported in deviations.
>>
>>
> I do not support this change.
> Extensions are used to define external statements
> which are, in fact, not part of the YANG language.
> (hence the name "external")
>
> IMO it is a mistake to try to make them part of YANG and
> YANG conformance.
>
>
>
>> >
>> > I don't agree that "external-stmt" should be under YANG conformance
>> > at all.  That is why MAY skip over is in the text.  A tool that
>> > understands the extension is purely optional.
>> >
>>
>> But then we run into problems if extensions change semantics on the server
>> side, as with nacm.
>>
>>
>
> Some people have asked if they can just support the NACM extensions
> and not the NACM module. A: no. Only the NACM module is required
> to understand these extensions.  They do not affect the
> syntax or semantics of the tagged objects at all.
> They only affect access control for those objects.
> IMO the NACM extensions should be real YANG statements,
> and then the concepts of 'default-deny-write' and 'default-deny-all'
> could be implemented without NACM.
>
>
>
> Lada
>>
>
> Andy
>
>
>>
>> >
>> > Lada
>> >
>> >
>> > Andy
>> >
>> > >
>> > >
>> > >
>> > > Lada
>> > >
>> > > Andy
>> > >
>> > >
>> > > >
>> > > > /martin
>> > > >
>> > > >>
>> > > >>
>> > > >>    The substatement's keyword MUST match a corresponding
>> > > >>    keyword in the target node, and the argument's string MUST be
>> equal
>> > > >>    to the corresponding keyword's argument string in the target
>> node.
>> > > >>
>> > > >>                        The deviates's Substatements
>> > > >>
>> > > >>                  +--------------+---------+-------------+
>> > > >>                  | substatement | section | cardinality |
>> > > >>                  +--------------+---------+-------------+
>> > > >>                  | config       | 7.19.1  | 0..1        |
>> > > >>                  | default      | 7.6.4   | 0..1        |
>> > > >>                  | mandatory    | 7.6.5   | 0..1        |
>> > > >>                  | max-elements | 7.7.4   | 0..1        |
>> > > >>                  | min-elements | 7.7.3   | 0..1        |
>> > > >>                  | must         | 7.5.3   | 0..n        |
>> > > >>                  | type         | 7.4     | 0..1        |
>> > > >>                  | unique       | 7.8.3   | 0..n        |
>> > > >>                  | units        | 7.3.3   | 0..1        |
>> > > >>                  +--------------+---------+-------------+
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >> > > IMO ephemeral data support needs to be a real statement
>> > > >> > > that can be used with refine-stmt and  deviate-stmt.
>> > > >> > > It is a real property of a data node.
>> > > >> >
>> > > >> > Note: it is still not clear that such a statement (base or
>> extension)
>> > > >> > is needed at all.
>> > > >> >
>> > > >> >
>> > > >>
>> > > >> Maybe not to you, but according to the I2RS ephemeral requirements,
>> > > >> it is needed, so unless you have a better plan, this is the default.
>> > > >>
>> > > >> Explain how ephemeral state can be identified within a data node.
>> > > >> It must be possible to use groupings to define such data nodes.
>> > > >> If must be possible to refine these groupings.
>> > > >> It must be possible for a vendor to write deviation statements.
>> > > >> All YANG tools must recognize the ephemeral data property.
>> > > >> It should not be isolated to a particular YANG module, which would
>> > > >> create a dependency in all future YANG modules.
>> > > >>
>> > > >>
>> > > >> Andy
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >> >
>> > > >> > /martin
>> > > >> >
>> > >
>> > > --
>> > > 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 3 Aug 2015 10:18:14 +0200

> in particular, they can change semantics of YANG or the management

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.

> "annotation" statement really cannot be extensions.

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 think the NACM extensions are just fine as
they are. I do not see anything broken about them.

/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/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 3 Aug 2015 11:05:01 +0200

> On 03 Aug 2015, at 10:18, Juergen Schoenwaelder <[email-masked]> wrote:
> 

6020(bis) is silent about the effects a description or extension can have - I think there should be relatively strict limits. I agree with Jernej that descriptions or extensions should not be allowed to change YANG semantics.

We had a discussion before about defining new XPath functions via extensions. Doing it via descriptions is equally inacceptable for me.

Lada

---

From: Jernej Tuljak <[email-masked]>
Date: Mon, 3 Aug 2015 11:06:41 +0200

> 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.

> description statements.

I still disagree that description statements should be more powerful 
than any other YANG statement.

> I think the NACM extensions are just fine as

I agree. Both NACM extensions and "annotation" are examples of what the 
best practice for extension usage should be. Standardize first, then 
use. I don't mind implementing something (in a generic client) that was 
widely agreed to be useful. There are cases like this for other 
languages. EXSLT for XSLT, for example. In time, extensions should 
become proper YANG keywords.

FWIW, I prefer #2, since that is how I always understood YANG 
extensions. Don't mind #1 for standard extensions only.

Jernej

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 3 Aug 2015 11:19:09 +0200

> 6020(bis) is silent about the effects a description or extension can have - I think there should be relatively strict limits. I agree with Jernej that descriptions or extensions should not be allow…

How do you define 'change YANG semantics'?

Some of the core typedefs have semantics defined in description
statements that go beyond what can be expressed using YANG's type
restriction statements. This has >20 years of history of being useful
so lets make sure we do not loose any of that because of a fear that
things may be misused.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 3 Aug 2015 11:25:01 +0200

> normative, if this would be the case.

You need to define way more clearly what 'YANG semantics' means.

> than any other YANG statement.

What does 'powerful' mean? Time that someone writes concrete text so
we can have a more constructive discussion.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 3 Aug 2015 11:57:18 +0200

> On 03 Aug 2015, at 11:19, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> How do you define 'change YANG semantics’?

Anything that changes YANG language as defined in the spec of the corresponding version.  

> so lets make sure we do not loose any of that because of a fear that

Typedefs like counter32 are just instructions for server developers about the internal semantics of a parameter in state data. It has no relevance to the data model as a client-server contract.

It’s OK to state a semantic rule for a given data model in a description, if it can't be done via “must” expression, or specify how to select a default value for a leaf, things like that. On the other hand, for example, saying in a description of a config list that a key isn’t required for that list must not be allowed. Doing the same with an extension would not be better.

Lada

---

From: Jernej Tuljak <[email-masked]>
Date: Mon, 3 Aug 2015 11:59:36 +0200

> You need to define way more clearly what 'YANG semantics' means.

In terminology used by you, when you were explaining your view of 
descriptions and extensions:

All we do is agreeing on certain constructs to be generally useful and
so we can write shortcuts that have well defined meanings. This is why
we have a language and do not write everything in prose. It is more
compact and more efficit.

Those shortcuts.

> we can have a more constructive discussion.

The power to change previously agreed upon meaning of a YANG language 
construct. The power to turn an arbitrary leaf into a container by mere 
mention of it in what is defined as a textual description for humans.

Jernej

---

From: Andy Bierman <[email-masked]>
Date: Mon, 3 Aug 2015 07:41:29 -0700

> 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.

> 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.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 3 Aug 2015 16:48:49 +0200

> On 03 Aug 2015, at 16:41, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Mon, Aug 3, 2015 at 2:25 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> A YANG description-stmt cannot override the syntax and semantics of other YANG

It’s not only about overriding. For example, it wouldn’t be good to introduce a new data node type though an extension.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 3 Aug 2015 09:01:29 -0700

On Mon, Aug 3, 2015 at 7:48 AM, Ladislav Lhotka <[email-masked]> wrote:

> 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?

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.

Validation rules are needed for ephemeral data.
Whether this is part of a protocol spec or YANG needs to be decided.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 3 Aug 2015 20:58:40 +0200

> On 03 Aug 2015, at 18:01, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

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.

> 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. 

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 3 Aug 2015 12:16:34 -0700

On Mon, Aug 3, 2015 at 11:58 AM, Ladislav Lhotka <[email-masked]> wrote:

> 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.
>
> >
> 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

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 06 Aug 2015 09:43:26 +0200

>    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.

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?

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 6 Aug 2015 04:03:02 -0700

> into account ephemeral values as long as they are what's operationally

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.

The running config must be self-consistent.
It never ever relies on ephemeral or operational data
for validation.

> 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?

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 6 Aug 2015 14:50:04 +0200

> On 06 Aug 2015, at 13:03, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

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.

> It never ever relies on ephemeral or operational data

Ephemeral data is a configuration, too.

> 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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 6 Aug 2015 08:31:31 -0700

On Thu, Aug 6, 2015 at 5:50 AM, Ladislav Lhotka <[email-masked]> wrote:

> > >> > > > >Any description statement in principle can do this. We trust
> that
> > >> sane
> > >> > > > >perspective, it seems odd to make a difference between
> extensions
> > >> and
> > >> > > > >description statements.
> > >> > > >
> > >> > > A YANG description-stmt cannot override the syntax and semantics
> of
> > >> other YANG

If an edit would cause the datastore to be invalid,
then it has to be rejected.

> 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.
>
> >

It needs to be in a separate datastore so it can be
validated separately from the running config.

> 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.

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

> > >> > > Fax:   +49 421 200 3103         <http://www.jacobs-university.de/
> >
> > >> > >
> > >> >
> > >> > --

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 6 Aug 2015 17:40:45 +0200

> On 06 Aug 2015, at 17:31, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 6 Aug 2015 08:46:39 -0700

On Thu, Aug 6, 2015 at 8:40 AM, Ladislav Lhotka <[email-masked]> wrote:

> > > >> > > A YANG description-stmt cannot override the syntax and
> semantics of
> > > >> other YANG
> > 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
> 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?
>
>

no -- the ephemeral datastore can contain config=true nodes.
If the ephemeral data had both p and v, then the running config
values are not used and not relevant.  Tho running config values
get used if the ephemeral values are removed.

It is quite easy for an operator to mess up by over-riding configured
values.  YANG validation is going to
be slow so probably will be avoided.
Only "operator clue" can prevent this sharp knife
from killing the network.

This looks like a lot of wizardry that tries to hack ephemeral state on top
> of the existing NETCONF architecture.
>
> Lada
>
>
Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 Aug 2015 17:53:25 +0200

> 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.

So far, validation concerns a configuration data store, no more and no
less. Expanding this to something different will be a major change how
the curent protocol and its implementations work.

> 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 h…

The running config is valid. I think it is today an implementation
issue how any conflicts with other dynamic information are resolved
(e.g., whether the running config in this case overwrites or deletes
the now broken ephemeral value or whether the NC server signals a
runtime error while processing the edit-config - which would not be a
validation error).

We currently understand what a valid configuration datastore
means. This is goodness and we should work hard to preserve this.

When we add ephemeral configuration datastores, it is not clear what
it means for them to be valid or whether we also have to think in
addition in terms of validation of the resulting 'merged
datastore'. Some people also wanted to allow references from ephemeral
configuration data to operational state data, which adds another
dimension of complexity to the picture.

All I can say at this point in time is that the precise semantics of
validation of ephemeral data are rather unclear to me. And there may
also be a risk to define validation semantics that at the end nobody
will implement fully because it does not scale (e.g., because it
requires to monitor significant amounts of operational state to detect
changes that trigger re-validation).

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 Aug 2015 18:03:06 +0200

> get used if the ephemeral values are removed.

If the ephemeral datastore uses the same data model as the
configuration datastores, you will mostly likely only be able to have
_both_ p and v in the ephemeral datastore.

It is likely goodness to keep certain restrictions alive instead of
allowing arbitrary selective overwrites.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 6 Aug 2015 09:21:47 -0700

> allowing arbitrary selective overwrites.
It is up to the operator to make sure of these things.
It might be possible to come up with YANG statements
to help, but might not be worth the effort.

I agree that config=true datastore validation needs to be preserved.

The ephemeral datastore has different "default" rules than other datastores.
Normally, a missing node is either a YANG default or nothing.
In the ephemeral datastore, a missing node is first the corresponding
node in the running config, and then the YANG default if nothing
in running to match.  I think these validation rules would work for
config=true nodes in the ephemeral daatstore.

Validation of config=ephemeral nodes in the ephemeral datastore
is still a bit unclear.  I have asked some routing experts for examples
of ephemeral data that needs to reference operational state.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 07 Aug 2015 14:26:32 +0200

> changes that trigger re-validation).

RFC 6241 says that running datastore contains "the complete
configuration currently active on the device". However, ephemeral
datastore is also designed to contain active (non-persistent)
configuration, and I understand it can sometimes override running so
that certain parameters in running become inactive. In other words, the
ephemeral datastore competes with running for providing active
configuration to the device. I think there have to be rules for merging
configurations from running and ephemeral, and producing configuration
that's really active on the device.

To this end, the openconfig idea of intended versus applied
configuration might be useful. We would in fact have

- running = configuration intended by NETCONF,

- ephemeral = configuration intended by I2RS,

- applied = active configuration, result of merging/arbitrating running
  and ephemeral

The intended configurations may be validated separately but it is the
applied configuration whose validity really matters.

This approach could also be generalised - an additional management
interface would just contribute its own intended configuration.

Lada