Re: [netmod] YANG 1.1 Y12 (initialized-by-system)

["Sterne, Jason (Jason)" <[e-mail]>]

Hi guys,

I can't immediately see how initialized-by-system is more complicated or unclear than its use with a leaf-list but I may be missing something.  It would be a statement that simply tells the client that they should read the list to find pre-populated entries.

WRT Martin's comment when I mentioned a system created 'admin' user and 'system' interface: 

   "This is already possible today.  Most systems come with some kind of factory default config.  When a client connects the very first time, it cannot assume that the config is empty."

That is true but doesn't the same argument hold for the use of initialized-by-system for leafs and leaf-lists ?  You don't *need* initialized-by-system for leafs, leaf-lists or lists but it is useful to know what areas might have pre-populated config.

I agree the system-controlled interfaces in RFC 7223 are a bit different than this initialized-by-system concept in Y12.   System-controlled (RFC 7223) is simply operational data (not part of the config ds).

There is also a need to handle items that are initialized by the system but are also considered part of the config datastore.   Some of these items can be deleted by the operator (e.g. for security they don't want the pre-populated 'admin' user). 

Deletion of these entries can be done with an <edit-config> operation='delete' but things get a little difficult when you support a startup datastore.   When you delete the pre-initialized "admin" user in the running config, and then copy the running config to the startup config, how do you indicate in the startup config that the router should remove the "admin" user during startup ?  I can't see how to model that with netconf/yang (i.e. what would a <get-config> of that list look like for the "admin" user ?   Absence of the user would not suppress the user during bootup).

Some more comments below.

Regards,
Jason

-----Original Message-----
From: Ladislav Lhotka [mailto:[e-mail]] 
Sent: Wednesday, September 10, 2014 4:33 AM
To: Balazs Lengyel
Cc: Martin Björklund; Sterne, Jason (Jason); [e-mail]
Subject: Re: [netmod] YANG 1.1 Y12 (initialized-by-system)


On 10 Sep 2014, at 10:02, Balazs Lengyel <[e-mail]> wrote:

> Hello,
> IMHO initialized by system would be just as useful for lists  as well.
> 
> In Ericsson a big number of lists (managed objects) are created by the system. It is usually forbidden to remove these system created lists, but sometimes allowed.

If it is forbidden, then it really looks like system-controlled list entries:

http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-15#section-4.1

I think that letting the system (perhaps on behalf of other protocols like DHCP or HNCP) write to NETCONF datastores should not be considered normal. What if the datastore is locked when the write is supposed to happen?

[>>JS] I don't think of it as a "NETCONF datastore".   It is the system datastore and NETCONF is one protocol used to access and change it.    Other interfaces may also change it (SNMP, CLI).   Some interfaces like DHCP may affect behavior of the node and have saved state that isn't considered "config" and in that case it wouldn't be in the datastore (but may be in some ephemeral ds).   I don't think we should get too deep into ephemeral datastores in this email thread but going back to the original point -> the system may need to write to the config datastore (especially during system initialization).

That's also why I think we need to develop the concept of a separate operational datastore. The system could write there anytime without interfering with NETCONF datastores.

[>>JS] Are you thinking the operator could do an <edit-config> on that "operational" datastore ?   There may be a need to allow an operator to delete some of these system initialized objects.

> We also have such items under user created lists: if the user creates the upper level list, then the system will automatically create the lower level ones.
> E.g. HW can be detected by the system and the relevant list-entries created, while some leafs for the HW will be user settable.

All this is covered by system-controlled list entries.
[>>JS] Agreed if the entries can't be deleted or modified by an operator

> 
> Why doesn't this apply to candidate?

Actually, yes. If the system writes something only into running, then the client who happens to be editing candidate may not be able to perform commit anymore due to restricted access to the system-written data.

Lada

> regards Balazs
> 
> 
> On 2014-09-09 22:40, Martin Bjorklund wrote:
>>> Was there any previous discussion about having the 
>>> initialized-by-system concept somehow applying to lists (i.e. 
>>> indicating that the system might initialize some list instances/entries)?
>> IIRC everyone agreed that this was not needed.  Unclear use cases, 
>> and unclear how it would work.
>> 
>> /martin
> 
> -- 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> ECN: 831 7320                        Tel: [phone]
> Mobile: [phone]              email: [e-mail]
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

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