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

["Susan Hares" <[e-mail]>]

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. 

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. 

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