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

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Tue, 9 Sep 2014 19:39:49 +0000

Hi all,

I see in the issues list that initialized-by-system is intended to be applicable to leafs and leaf-lists.

Can someone give an example of how that might look for a leaf-list ?   Is it just to indicate that there may be a system initialized member of the leaf-list ?

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) ?   For example -> the network element (server) may automatically add an interface called "system" or a user called "admin" during startup.    The initialized-by-system could perhaps be indicated at the list level to at least indicate that there may be system initialized list entries (i.e. to prompt the client to <get-config> to see them).

I'm also interested in the note that says "A similar issue: passwd of type crypt-hash.".   I'd like to see what the intended use case is behind that sentence (I'm hoping it might help me with an issue we have that sounds similar).

Regards,
Jason

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 09 Sep 2014 22:40:05 +0200 (CEST)

Hi,

"Sterne, Jason (Jason)" <[email-masked]> wrote:
> Can someone give an example of how that might look for a leaf-list ?  Is it
> just to indicate that there may be a system initialized member of the leaf-list
> ?

Right; when the parent node is created, the system initializes one or
more members of the leaf-list.

> 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.

> For example -> the network element
> (server) may automatically add an interface called "system" or a user called
> "admin" during startup.

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.

> The initialized-by-system could perhaps be indicated
> at the list level to at least indicate that there may be system initialized
> list entries (i.e. to prompt the client to <get-config> to see them).
> 
> I'm also interested in the note that says "A similar issue: passwd of type
> crypt-hash.".  I'd like to see what the intended use case is behind that
> sentence (I'm hoping it might help me with an issue we have that sounds
> similar).

If a clear-text value is written to a node of type crypt-hash, the
server calculates the hash and stores the hash value instead of the
clear text value.  This is not the same as initialized-by system, but
similar.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Sep 2014 07:26:22 +0200

> it cannot assume that the config is empty.

I think the first part is more about system-controlled interfaces (see RFC 7223, sec. 1.1) - that is, the “system” interface would be initialized in operational state but won’t initially appear in configuration.

Lada

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

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

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 10 Sep 2014 10:02:44 +0200

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.
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.

Why doesn't this apply to candidate?
regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Sep 2014 10:32:35 +0200

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

> 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?

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.

> 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.

> 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

---

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Thu, 18 Sep 2014 21:08:25 +0000

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:[email-masked]] 
Sent: Wednesday, September 10, 2014 4:33 AM
To: Balazs Lengyel
Cc: Martin Björklund; Sterne, Jason (Jason); [email-masked]
Subject: Re: [netmod] YANG 1.1 Y12 (initialized-by-system)

[>>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.

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

Lada

>>> 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
> 
> --

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 19 Sep 2014 14:17:26 -0400 (EDT)

"Sterne, Jason (Jason)" <[email-masked]> wrote:
> 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.

I am not sure what you mean with "pre-populated".

>    "This is already possible today.  Most systems come with some kind of
>    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 ? 

initialized-by-system is not used to mark factory defaults.  It is
used to tell the server that when its parent node is created, the
system will provide a value unless set by the client.

> You don't *need*
> initialized-by-system for leafs, leaf-lists or lists

Correct.

> 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).

This goes outside the scope of the proposed initialized-by-system.
IMO this should be solved with access control, rather than special
treatment in the code.

/martin

---

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Fri, 19 Sep 2014 18:37:04 +0000

Thx Martin.   Pls see below.
Jason

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Friday, September 19, 2014 2:17 PM
To: Sterne, Jason (Jason)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [netmod] YANG 1.1 Y12 (initialized-by-system)

> initialized-by-system for leafs and leaf-lists ?

initialized-by-system is not used to mark factory defaults.  It is used to tell the server that when its parent node is created, the system will provide a value unless set by the client.

[>>JS] Thx.  I didn't realize that was the primary use case but I can see how that makes sense.   That is a bit different than what I'm looking for but I was hoping this initialized-by-system could somehow help.   I'm not so convinced now (especially to handle operator deletion of those system entries).    I will start a separate thread for it.

Correct.

[>>JS] Considering your use case I think maybe there is a case where it is needed -> for mandatory leafs that may get initialized by the system.   The 'type' leaf in the ietf-interfaces is one that confused me (if it is mandatory how can a client know it can create an interface without specifying a value for it ?).

This goes outside the scope of the proposed initialized-by-system.
IMO this should be solved with access control, rather than special treatment in the code.

/martin

---

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Mon, 22 Sep 2014 22:02:47 +0000

Starting a new thread for this clear-text vs hash issue (mentioned in Y12).

In some cases there is a need for an operator to be able to enter a clear-text value but can never read it back as clear text (only as a hash).  

If the operator can configure a clear-text value, but can only read back a hashed value, are the write and the read really to/from the same leaf in the datastore ?

Maybe some new attribute of a leaf that indicates you won't read back what you wrote ?

There may also be a need in some cases to allow the hashed value to be entered (i.e. copying from one place to another without knowing the underlying clear-text value).   What semantics could we use in the <edit-config> to say we are writing a hashed value (so don't re-hash) ?

I'm assuming this issue is outside the scope of Yang 1.1 (i.e. won't be solved as part of Y12) but I'm still interested in any thoughts on solving this at some point. 

Jason

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Tuesday, September 09, 2014 4:40 PM
To: Sterne, Jason (Jason)
Cc: [email-masked]
Subject: Re: [netmod] YANG 1.1 Y12 (initialized-by-system)

Hi,

"Sterne, Jason (Jason)" <[email-masked]> wrote:
> Can someone give an example of how that might look for a leaf-list ?  
> Is it just to indicate that there may be a system initialized member 
> of the leaf-list ?

Right; when the parent node is created, the system initializes one or more members of the leaf-list.

> 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.

> (server) may automatically add an interface called "system" or a user 
> called "admin" during startup.

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.

> The initialized-by-system could perhaps be indicated at the list level 
> to at least indicate that there may be system initialized list entries 
> (i.e. to prompt the client to <get-config> to see them).
> 
> I'm also interested in the note that says "A similar issue: passwd of 
> type crypt-hash.".  I'd like to see what the intended use case is 
> behind that sentence (I'm hoping it might help me with an issue we 
> have that sounds similar).

If a clear-text value is written to a node of type crypt-hash, the server calculates the hash and stores the hash value instead of the clear text value.  This is not the same as initialized-by system, but similar.

/martin