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

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Wed, 12 Nov 2014 20:41:07 +0000

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 12 Nov 2014 12:50:02 -0800

Hi,

YANG features provide a conformance mechanism, not any data structure
organization.
Any node that contains an "if-feature foo;" statement is optional, and
not supported
unless the server advertises the 'foo' feature.  These if-feature
stmts can appear in
any data definition, even in other modules.

Andy

On Wed, Nov 12, 2014 at 12:41 PM, Matt Hartley (mhartley)
<[email-masked]> wrote:
> _______________________________________________
> Rtg-yang-coord mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord

---

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 12 Nov 2014 22:06:27 +0100 (CET)

"Matt Hartley (mhartley)" <[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

The question to ask is can 'foo-oper' ever exist w/o explcit
configuration of 'foo'?  If it can, you will need separate trees.  An
example is the ietf-interface model, where interfaces can exist w/o
being explicitly configured.

> The same applies to notifications and rpcs.

notifications and rpcs are defined at the top-level in the module, and
hence this does not apply to them.

/martin

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

---

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

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Wed, 12 Nov 2014 23:48:49 +0000

Thanks, Martin - that answers the question :)

Cheers

Matt

> > 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 question to ask is can 'foo-oper' ever exist w/o explcit configuration
> of 'foo'?  If it can, you will need separate trees.  An example is the
> ietf-interface model, where interfaces can exist w/o being explicitly
> configured.
> 
> > 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
> >

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 12 Nov 2014 13:56:46 -1000

> being explicitly configured.

Another question to ask is whether a configured value of a certain parameter must always be the one that the system really uses, or whether it can be changed through other channels (e.g. network protocols). In the latter case you need separate nodes for the configured and state value.

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C