Re: [netmod] leafref to lists that contain system-controlled entries

["Sterne, Jason (Nokia - CA/Ottawa)" <[e-mail]>]

Thanks Martin.  Pls see below.
Jason

> -----Original Message-----
> From: Martin Bjorklund [mailto:[e-mail]]
> Sent: Monday, October 16, 2017 2:56
> To: Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [netmod] leafref to lists that contain system-controlled entries
> 
> "Sterne, Jason (Nokia - CA/Ottawa)" <[e-mail]> wrote:
...snip...
> >
> > Another approach could be to actually have those system created
> > entries show up in running/candidate.  That would ensure that
> > references to those entries are valid.
> 
> This works if the "system created entries" behave just like any other entry,
> i.e., a client (with proper access rigths) can modify and delete them.

[>>JTS] I think there are 2 classes of these "system created entries":
1) deletable entries
2) non-deletable entries

For deletable entries we had old discussions about those a few years ago on the list where it was proposed these are modelled as "default startup datastore" entries (i.e. instantiated by the system at startup time if there is no startup datastore present).  They can then be deleted or modified by a client (and then a subsequent startup would not have those entries).

I'm more concerned here with non-deletable entries.  The entries themselves would always be present (or perhaps only be present if some other part of the config is actually referencing them).   Some types of entrie may be modifiable (i.e. their leafs or other descendants can be changed) and some may not be modifiable.

My responses below are based on non-deletable entries.

> 
> If this is not the case, the next question is what happens if the client creates
> its own entry with the same name as a system created entry?  Is this illegal,
> or will the user created entry override the system created entry?

[>>JTS] I think creation of an entry by a client would just be silently accepted (and wouldn't affect what a client sees in a <get-config> since it was already present).  Similarly a deletion of an entry would be silently accepted but the entry would still be there in a <get-config> response.
As mentioned above, some entries may have modifiable leafs and descendants.  Some may not (would return an error if attempting to set the value of a leaf/descendant).

> 
> Another question to think about is what happpens with user config that
> refers to such a system created entry if a new software image is loaded
> where the system created entry is no longer present?

[>>JTS] A few options:
1) only use this for entries that are never really expected to be obsoleted (which may actually be a pretty likely case from what I've seen of these types of entries)
2) have the startup config/datastore contain these entries (so they would be created as explicit user entries if they don't exist as system created in the future)
3) have upgrade code that accepts references to "old" entries and auto-convert them to some new entry (assuming one exists)

> 
> 
> /martin