On 8/4/16, 6:52 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email protected]> 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)" <[email protected] on behalf of >> [email protected]> wrote: >> >>> >>> On 03/08/2016 07:49, Ladislav Lhotka wrote: >>>>> On 02 Aug 2016, at 18:35, Balazs Lengyel >>>>><[email protected]> >>>>> 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: +36-70-330-7909 email: >>>>>[email protected] >>>>> >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>> >>>> >>>> >>>> >>>> . >>>> >>> _______________________________________________ >>> netmod mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
