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

[Ladislav Lhotka <[e-mail]>]

Andy Bierman <[e-mail]> writes:

> On Mon, Aug 3, 2015 at 11:58 AM, Ladislav Lhotka <[e-mail]> wrote:
>
>>
>> > On 03 Aug 2015, at 18:01, Andy Bierman <[e-mail]> wrote:
>> >
>> >
>> >
>> > On Mon, Aug 3, 2015 at 7:48 AM, Ladislav Lhotka <[e-mail]> wrote:
>> >
>> > > On 03 Aug 2015, at 16:41, Andy Bierman <[e-mail]> wrote:
>> > >
>> > >
>> > >
>> > > On Mon, Aug 3, 2015 at 2:25 AM, Juergen Schoenwaelder <
>> [e-mail]> 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.

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

>
> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>> > > Fax:   [phone]         <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