Subject: Re: [Lime] [Rtg-yang-coord] Relationship between config, oper etc for a feature

From: Tom Taylor <[email-masked]>
Date: Wed, 12 Nov 2014 15:54:09 -0500

I think LIME has something like this in their charter. Note the 
cross-posting.

Tom Taylor

On 12/11/2014 3:41 PM, Matt Hartley (mhartley) wrote:
> When designing YANG models, it's possible to organize them so that a single tree for a feature contains all the elements related to that feature (config, oper, etc), or so that config, oper, etc are collected into separate trees. Or, to put it another way: you can have everything related to a feature in one place, or everything related to config in one place, but not both.
>
> So we can do this:
>
> +--rw feature
>      +--rw foo
>          +--rw foo-cfg
>          +--ro foo-oper
>      +--rw bar
>          +--rw bar-cfg
>          +--ro bar-oper
>
> Or this:
>
> +--rw feature
>      +--rw feature-cfg
>          +--rw foo-cfg
>          +--rw bar-cfg
>      +--ro feature-oper
>          +--ro foo-oper
>          +--ro bar-oper
>
> The same applies to notifications and rpcs.
>
> Are there any global recommendations that one approach be favoured over the other? Is there any push to be consistent between protocols in the routing area? Or is this up to individual WGs or document authors to do whatever they think is most appropriate for the YANG model they're designing?
>
> Cheers
>
> Matt
>
> _______________________________________________
> Rtg-yang-coord mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 12 Nov 2014 13:07:05 -0800

Hi,

I guess I misunderstood feature to mean YANG feature rather than
application feature.
IMO separate config and state is expensive (duplicates instance
scaffolding, creates
inconsistencies due to instance creation differences, more complicated
retrieval filters).

If the state can exist independently of the config, then separate
config and state trees
are needed.  If not, then the added complexity does not buy you anything.

Andy

On Wed, Nov 12, 2014 at 12:54 PM, Tom Taylor <[email-masked]> wrote:
>> When designing YANG models, it's possible to organize them so that a
>> single tree for a feature contains all the elements related to that feature
>> (config, oper, etc), or so that config, oper, etc are collected into
>> separate trees. Or, to put it another way: you can have everything related
>> to a feature in one place, or everything related to config in one place, but
>> not both.
>>
>> So we can do this:
>>
>> +--rw feature
>>      +--rw foo
>>          +--rw foo-cfg
>>          +--ro foo-oper
>>      +--rw bar
>>          +--rw bar-cfg
>>          +--ro bar-oper
>>
>> Or this:
>>
>> +--rw feature
>>      +--rw feature-cfg
>>          +--rw foo-cfg
>>          +--rw bar-cfg
>>      +--ro feature-oper
>>          +--ro foo-oper
>>          +--ro bar-oper
>>
>> Are there any global recommendations that one approach be favoured over
>> the other? Is there any push to be consistent between protocols in the
>> routing area? Or is this up to individual WGs or document authors to do
>> whatever they think is most appropriate for the YANG model they're
>> designing?
>>
>> Cheers
>>
>> Matt
>>