Re: [I2rs-proto-dt] couple YANG details

[Andy Bierman <[e-mail]>]

On Fri, Oct 23, 2015 at 1:41 PM, Susan Hares <[e-mail]> wrote:

> Jeff and Andy:
>
> I agree with Jeff.  I2RS should not create new constraints for anything
> under a configuration data tree.   (Jeff see the BGP suggestions below).
>
> What about the I2RS protocol data modules?  I think these data modules have
> their own constraints.  Is this true.
>
>

No -- currently there is no way to tell that the constraints apply to I2RS.

So the YANG constraints apply to the running datastore.
The config=true nodes make up the running datastore.
The ephemeral datastore contents and the ephemeral-stmt
values are ignored for this validation.

There is no YANG constraint enforcement in the ephemeral datastore at all.
Only the YANG "type" statement is enforced, and even then,
leafrefs with "require-instance true" are treated as if they were
"require-instance false".

All servers should do validation the same way or the client will not know
what to expect.




> Sue
>
> Examples from BGP:
>
> 1) if you create an ephemeral BGP peer, then it should have the same
> constraints and other peers.
>



> b) If you create a BGP cost community, then it should have the same
> constraints as other cost communities.
>
>


But the YANG statements only apply to the running datastore.
What does "same constraints" mean here?


Andy



> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Friday, October 23, 2015 11:18 AM
> To: Andy Bierman
> Cc: Susan Hares; [e-mail]
> Subject: Re: [I2rs-proto-dt] couple YANG details
>
> On Wed, Oct 21, 2015 at 02:45:56PM -0700, Andy Bierman wrote:
> > 1) module-level "ephemeral" flag
> > Since the data node flag applies to the entire subtree, it should be
> > simple enough to just require each top-level data node to declare
> > 'ephemeral true' if needed.
> > There are usually 1 - 2 top-level data nodes per module so this is not
> > a burden.  Checking 2 places is too complicated and they can conflict.
>
> As long as we permit ephemeral true in nodes other than the top one, I
> think
> that's good.  We want to permit data models to be published that have
> non-ephemeral components with some ephemeral without requiring an ephemeral
> augmentation module just for the ephemeral properties.
>
> > 2) groupings wrt/ edit overlap
> >
> > YANG already has a way to say what sub-nodes must be present
> > (mandatory=true, min-elements>0).
> > Is this good enough for I2RS?  Can the requirements for the ephemeral
> > version be different than the persistent version, wrt/ mandatory &
> > min-elements?
>
> If I'm parsing this correctly, I think that's fine.  We want to avoid
> introducing additional constraints in ephemeral modules, but shouldn't
> perturb the requirements for persistent config state.  Since ephemeral
> state
> can only go underneath the persistent stuff when they mix, min-elements
> should be tied to requirements for the persistent nodes; the ephemeral
> nodes
> may contribute, but shouldn't count against the min, ideally.
>
> -- Jeff
>
>