Subject: [netmod] system created list entries

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

Forking off a new thread since Y12 doesn't look like it will be applicable to this issue.

>From the Y12 thread:
-       JS: It would be a statement that simply tells the client that they should read the list to find pre-populated entries.
-       MJB: I am not sure what you mean with "pre-populated".

I wasn't sure what term to use here but the main use case I see is for lists that are described in the data model (in the YANG modules) and have an entry that is automatically created by the system at startup time.

Other entries may be created by the user later, and the user needs to be able to delete the system created entries (and make that persistent in a startup datastore so that after a subsequent bootup the system entry is deleted).

I don't think these are "defaults" as defaults are described in RFC6020.   I was thinking it would make sense for them to be considered as part of the contents of the datastore but I'm stumped on how to keep them deleted.

Another possible solution is to treat these system created items as operational data and have items in the config model to suppress them but that forces the creation of a lot of new config items (and anticipation of what the system might want to automatically pre-populate/create).

Jason

---

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

Hi,

I don't see the problem; if I understand your description this works
fine today.

When the system starts up initially, nothing prevents it from
initializing its config db w/ factory defaults.

When a client connects, it can get-config to discover the initial db.
The client can delete/create/modify the db as usual.  The initial data
is not special.

/martin

"Sterne, Jason (Jason)" <[email-masked]> wrote:
> -       JS: It would be a statement that simply tells the client that they
> -       should read the list to find pre-populated entries.
> I wasn't sure what term to use here but the main use case I see is for
> lists that are described in the data model (in the YANG modules) and
> have an entry that is automatically created by the system at startup
> time.
> 
> Other entries may be created by the user later, and the user needs to
> be able to delete the system created entries (and make that persistent
> in a startup datastore so that after a subsequent bootup the system
> entry is deleted).
> 
> I don't think these are "defaults" as defaults are described in
> RFC6020.  I was thinking it would make sense for them to be considered
> as part of the contents of the datastore but I'm stumped on how to
> keep them deleted.
> 
> Another possible solution is to treat these system created items as
> operational data and have items in the config model to suppress them
> but that forces the creation of a lot of new config items (and
> anticipation of what the system might want to automatically
> pre-populate/create).
> 
> Jason
> 
> 
>

---

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

I'm good with your explanation that a system can just create list entries in the config datastore and a client should do a get-config to discover them.   The client can then delete those entries - no problem so far.

A deletion simply causes an absence of that list entry in the datastore.   A <get-config> would simply not have that item in the list - again no problem so far.

But now I want that deletion to be persistent (i.e. that entry should not exist after the next bootup).  If we take an example of a system that has a running and a startup datastore, and we perform a copy-config from running->startup, then the startup ds doesn't contain that list entry.   At the next reboot the system will happily create that entry again.

Maybe this is just an implementation specific issue that is outside the scope of netconf & yang but if anyone has a solution that fits in with netconf/yang that would be useful.

Jason

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Friday, September 19, 2014 2:52 PM
To: Sterne, Jason (Jason)
Cc: [email-masked]
Subject: Re: [netmod] system created list entries

Hi,

I don't see the problem; if I understand your description this works fine today.

When the system starts up initially, nothing prevents it from initializing its config db w/ factory defaults.

When a client connects, it can get-config to discover the initial db.
The client can delete/create/modify the db as usual.  The initial data is not special.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Sep 2014 10:34:20 +0200

> Maybe this is just an implementation specific issue that is outside the scope of netconf & yang but if anyone has a solution that fits in with netconf/yang that would be useful.

Are you saying that the system ignores the fact that a list entry got
explicitly deleted? In that case, I think this likely more a
shortcoming of a particular implementation.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Per Hedeland <[email-masked]>
Date: Mon, 22 Sep 2014 12:53:10 +0200

> shortcoming of a particular implementation.

I believe Jason is just not looking far enough "outside" of
netconf/yang... On a system with startup and running, such "factory
default" config must be part of the *initial* *startup* contents -
i.e. it cannot be created as part of the startup -> running copy that
occurs at *every* reboot.

--Per Hedeland

---

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

Hi guys,

This isn't as simple as a system just ignoring a deletion.  It is about how that deletion would look in a <get-config>.  An absence of the entry doesn't tell the client that the system created entry is being explicitly suppressed/deleted (and an absence can't represent the explicit delete/suppression that in theory should be shown in a startup ds).

Let me walk through an example in a bit more detail:

## (A) system model

list foo {
    key "entry"
    leaf entry {
        type string;
    }
}

## (B) initial <get-config> result from the <running> ds on a newly booted system contains an entry that is populated by the system at startup time

<data>
    <foo>
        <entry>system-created-1</entry>
    </foo>
</data>

## (C) user does an <edit-config> to add a new foo entry ' client-created-1'.   Results of a <get-config> now look like this:

<data>
    <foo>
        <entry>system-created-1</entry>
    </foo>
    <foo>
        <entry>client-created-1</entry>
    </foo>
</data>

## (D) user deletes the entry 'system-created-1'.   Results of a <get-config> look like this:

<data>
    <foo>
        <entry>client-created-1</entry>
    </foo>
</data>

## (E) now a <copy-config> from <running> to <startup>.  Does a <get-config> of the <startup> return the same as what we see in (D) above ?    If so - what tells the system during the next startup to actually suppress 'system-created-1' ?

A simple absence of system-created-1 from the <startup> ds can't really cause the deletion of that entry IMO.   A completely empty <startup> ds should have the system come up with the 'system-created-1' entry configured.

Maybe the only solution is an implementation specific item in the startup ds that says to explicitly delete 'system-created-1' but I was looking for any way to model/show this in NETCONF/YANG.

Regards,
Jason

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, September 22, 2014 4:34 AM
To: Sterne, Jason (Jason)
Cc: Martin Bjorklund; [email-masked]
Subject: Re: [netmod] system created list entries

> Maybe this is just an implementation specific issue that is outside the scope of netconf & yang but if anyone has a solution that fits in with netconf/yang that would be useful.

Are you saying that the system ignores the fact that a list entry got explicitly deleted? In that case, I think this likely more a shortcoming of a particular implementation.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Sep 2014 15:52:21 +0200

On Mon, Sep 22, 2014 at 01:25:57PM +0000, Sterne, Jason (Jason) wrote:
> ## (E) now a <copy-config> from <running> to <startup>.  Does a <get-config> of the <startup> return the same as what we see in (D) above ?

I hope so.

> If so - what tells the system during the next startup to actually suppress 'system-created-1' ?
> 

Exactly. The startup config is not empty anymore so that system should
not auto-populate it anymore.

> Maybe the only solution is an implementation specific item in the startup ds that says to explicitly delete 'system-created-1' but I was looking for any way to model/show this in NETCONF/YANG.

Some CLIs work in the way you describe where the deletion of always
automatically generated stuff is part of the explicit config. This is
not how I think NETCONF/YANG works.

Things can be even a bit more tricky to implement since
auto-population of entries may be needed for hot pluggable components
even if there is already some other config. So the condition is not
just config empty yes/no but relevant config empty yes/no or you would
have to keep track whether auto-population has already been carried
out. But for sure, blindly always auto-populating on every restart
seems to be a bit too simplistic.

/js