[netmod] Generic DS concept WAS:RE: [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

Hi All,

I started this thread for a discussion on the Intended Status of the Revised
DS Draft.
I think the discussion on technical issues of the DS concept can be
discussed on one maillist.

I call the new thread "Generic DS concept".

Cheers,
Mehmet

-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka
Sent: Wednesday, January 11, 2017 4:37 PM
To: Robert Wilton <rwilton@cisco.com>
Cc: Netconf <netconf@ietf.org>; NetMod WG <netmod@ietf.org>
Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the
Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

> On 11 Jan 2017, at 16:18, Robert Wilton <rwilton@cisco.com> wrote:
> 
> 
> 
> On 11/01/2017 14:48, Ladislav Lhotka wrote:
>>> On 11 Jan 2017, at 15:18, Robert Wilton <rwilton@cisco.com> wrote:
>>> 
>>> Hi,
>>> 
>>> On 11/01/2017 13:05, Ladislav Lhotka wrote:
>>>>> On 11 Jan 2017, at 13:53, Martin Bjorklund <mbj@tail-f.com> wrote:
>>>>> 
>>>>> Ladislav Lhotka <lhotka@nic.cz> wrote:
>>> <snip>
>>>>>> Show me a single YANG data node definition that's duplicate in my 
>>>>>> concept above. But then maybe I didn't explain it properly.
>>>>> The interface's "type" leaf.  With the new operational-state 
>>>>> datastore, /interfaces/interface/type in operational-state and 
>>>>> /interfaces-state/interface/type are duplicate.
>>>> As I said, ietf-interfaces-state state would consist of augments
containing extra state nodes (i.e. those that are not in configuration). So
"type" won't be there.
>>> I think that this effectively just achieves the same thing that the
"config: true|false" statement indicates in a combined config/state tree.
>>> 
>>> Personally, I think that a file of augmentations is probably going to be
harder to read than having the config and state schema in one tree in one
file.
>> Possibly we could also use schema mount. On the other hand, it doesn't
enforce the use of operational-state datastore. A simple device like a
WiFi-controlled electric socket could easily use just ietf-interfaces-config
(and ietf-ip-config), i.e. no state data.
>> 
>> Another example I am dealing with now is OpenWRT: with some effort, it
would be possible to translate our nice configuration data into UCI files
without touching the OpenWRT system itself. On the other hand, serving state
data according to our YANG modules is a non-starter.
> Isn't the proper answer here to generate deviations to remove the state
leaves that won't be implemented.

This is of course possible but deviations are generally frowned upon, so why
not use the modularity features for making it a little more flexible? I know
some people will now say that without state data it is no proper network
management but, speaking pragmatically, automated configuration would be a
big boon by itself.

> 
>> 
>>> The models may also be slightly more inconvenient to use because the
state tree leaves would presumably be in a different namespace from the
configuration?
>>> 
>> Yes, but I don't think it is a big problem - even for human readers.
> I'm not sure.  I think that you might end up with a variation of the
OpenConfig models, and based on experience I would say that those models are
hard to read if they haven't been compiled first to expand the groupings and
reveal the actual structure.

One thing that makes modules really hard to read are augments, and we
already have them all over the place. It's a trade-off between readability
and modularity.

Lada

> 
> Rob
> 
> 
>> 
>>> If you wanted this file level split then using submodules would allow
for separate config/state files but still be managed as a single combined
module.
>> But it means you have to implement both.
>> 
>> Lada
>> 
>>> Rob
>>> 
>>> 
>>>>>> Note also that you slightly misinterpreted my statement that you
>>>>>> cited:
>>>>>> 
>>>>>> I believe both the protocols and YANG can work with any set of 
>>>>>> datastores [...]
>>>>>> 
>>>>>> I didn't say that there cannot be *modules* that are somehow 
>>>>>> designed for a particular datastore model - I meant YANG the
language.
>>>>> Ok.  Yes, you're right, but then we'd probably need some new 
>>>>> statement in each module that tells which meta-model the YANG 
>>>>> module is written for.
>>>> I would prefer to have it as state data, basically separate YANG
libraries for configuration datastores and operational-state.
>>> 
>>>> Lada
>>>> 
>>>>> /martin
>>>>> 
>>>>> 
>>>>>> Lada
>>>>>> 
>>>>>>> /martin
>>>>>>> 
>>>>>>> 
>>>>>>>> Am I completely misguided here? If not, then I don't see where 
>>>>>>>> the new modules refer to any particular datastore model. Yes, 
>>>>>>>> they do reflect that there is configuration and state data, but 
>>>>>>>> we don't want to get rid of this distinction, right?
>>>>>>>> 
>>>>>>>> Lada
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> /martin
>>>>>>>> --
>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>>>> --
>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Netconf mailing list
>>>> Netconf@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>> .
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>> 
>> 
>> 
>> 
>> 
>> .

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

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod