Re: [netmod] OpsState and Schema-Mount

["Acee Lindem (acee)" <[e-mail]>]

On 8/4/16, 6:52 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)"
<[e-mail]> wrote:

>
>
>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)" <[e-mail] on behalf of
>> [e-mail]> wrote:
>>
>>>
>>> On 03/08/2016 07:49, Ladislav Lhotka wrote:
>>>>> On 02 Aug 2016, at 18:35, Balazs Lengyel
>>>>><[e-mail]>
>>>>> 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.


Then I see no YANG language barriers in collapsing config and state trees
- the model root just needs to be “config true”.

Thanks,
Acee 



>
>Thanks,
>Rob
>
>
>>
>> Thanks,
>> Acee
>>
>>
>>
>>
>>> Rob
>>>
>>>
>>>> Lada
>>>>
>>>>> regards Balazs
>>>>>
>>>>> -- 
>>>>> Balazs Lengyel                       Ericsson Hungary Ltd.
>>>>> Senior Specialist
>>>>> Mobile: [phone]              email:
>>>>>[e-mail]
>>>>>
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>>>
>>>>
>>>>
>>>>
>>>> .
>>>>
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>