Re: [netmod] OpsState and Schema-Mount

On 03/08/2016 19:37, Acee Lindem (acee) wrote:
>
> On 8/3/16, 5:02 AM, "netmod on behalf of Robert Wilton -X (rwilton -
> ENSOFT LIMITED at Cisco)" <netmod-bounces@ietf.org on behalf of
> rwilton@cisco.com> wrote:
>
>>
>> On 03/08/2016 07:49, Ladislav Lhotka wrote:
>>>> On 02 Aug 2016, at 18:35, Balazs Lengyel <balazs.lengyel@ericsson.com>
>>>> wrote:
>>>>
>>>> Hello,
>>>> If we allow foo and foo-state for opstate, mounting models atop such a
>>>> multi rooted yang module will be fun.
>>>> mount modB-config-part onto modA-config-part
>>>> mount modB-state-part onto modA-state-part
>>>> One mount becomes two and you have to maintain parallel mounts
>>>> otherwise you are mounting half modules.
>>> This is already happenning with augments. It means some work but
>>> nothing terribly complex.
>>>
>>>> Actually the problem is not caused by opstate, but rather by
>>>> multi-rooted models. but avoiding foo-state would make life easier once
>>>> more.
>>> We already agreed that some items (such as RIBs) are "true" state which
>>> don't have direct counterparts in configuration. If we don't have
>>> foo-state, where are these supposed to be placed?
>> One choice is that they could just be placed under foo, where foo is a
>> config false leaf.
> While there is a NETCONF/RESTCONF incompatibility with config-false data
> nodes under config-true data nodes, there is no problem with the reverse -
> correct?
You are allowed config false nodes under config true, but not config 
true nodes under config false.

I had assumed in the example above that there wasn't already a config 
true "foo" to put them under, so to reconsider my answer:

In draft-ietf-netmod-routing-cfg "routing" is a top level container that 
is nominally config true.  But it is also a non presence container, so 
it would be allowed to put the config false RIB nodes directly under the 
"routing" container.  Given that "routing" is an NP container, its 
existence (e.g. to report the RIB) doesn't imply that routing has been 
configured.

In fact (given the recent discussion on the NETCONF alias), it is 
questionable what a "config" true NP container actually means.  I 
suspect that really it just ends up being a filter as to what type of 
child nodes are allowed.  I.e. if the NP container is config=true, then 
child nodes can be config true or config false. Conversely, if the NP 
container is config false then any child nodes must also be config false.

Thanks,
Rob

>
> Thanks,
> Acee
>
>
>
>
>> Rob
>>
>>
>>> Lada
>>>
>>>> regards Balazs
>>>>
>>>> -- 
>>>> Balazs Lengyel                       Ericsson Hungary Ltd.
>>>> Senior Specialist
>>>> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>>>>
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>
>>>
>>>
>>>
>>> .
>>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod