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

"Sterne, Jason (Nokia - CA/Ottawa)" <> Mon, 23 October 2017 23:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF4FA13AB3E for <>; Mon, 23 Oct 2017 16:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gPBdueqbhvcd for <>; Mon, 23 Oct 2017 16:46:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 25FA513A6D5 for <>; Mon, 23 Oct 2017 16:46:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wGfs5IwZ0IkaC1rQyzZML/Gv2/A/gy7hdVty4DRqPBU=; b=oMg/D/VYU59OE4g5pzcda4YpijlmEO6K6mx+GW9nJaWjO05nH35OupDzDnkQi/bZ4EBmkZ3dgRqWmMW3VlwlGyXwKcruBw9FmGix/QY7eSKXBwv3bybfXc3AIeNQ8tIquO0jR04QgK4wtfas6tRMnH6vZpwKOsrnHm3TmiMpsX4=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id; Mon, 23 Oct 2017 23:46:17 +0000
Received: from ([fe80::746c:4eb1:1f6a:9527]) by ([fe80::746c:4eb1:1f6a:9527%14]) with mapi id 15.20.0178.003; Mon, 23 Oct 2017 23:46:17 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" <>
To: Martin Bjorklund <>
CC: "" <>
Thread-Topic: [netmod] leafref to lists that contain system-controlled entries
Thread-Index: AdNETq1mxw6yfiPkS3eq6pji6usdqwB/ST6AAYLPhLA=
Date: Mon, 23 Oct 2017 23:46:16 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1121; 6:W0WS9c5BRnH0RtVwiQwOZPkLKALwkIrt8ON1qpqmAspI3c5cKhCg6WPBQ6+r9mWwYWeZu89bs1Huz07JQiXaRRyzPj0rkc++x5M5PZ+e3OxvIPdJnvobBOgcn2b+VtNL3FAggXDGKzN6+3DpNSMvqDosyN5Q7LQrR424+IVNR/RWRxt+d8gxpJnjzlXZxXkw4xtEDiOIGro5eXSG2m627VDeLxpfv0R9xwbB17+aeFJvF2ZKHnXVlw5RXrJIPKEWHcij7/ra9KQLlT3aKwiBBS3B524PmMUE4yZaL4sxNUQWRlOuRkO6gGwnhMbZ3K9d5KbEzlcS8FbB90Py/6U3OycxOc9q3cpjHDwomoK+EfA=; 5:om4nipazJfYin5Yd5vD+tDpTDyQ2AuqCujdFEWJ9bP6RIqo54Lu48Bmw5rRuxlTdkmymRmOJU/yE7MEuJmIcxaU6TBRZHnD5B9jBFjbg/aLnpTxXR3Q1lYsJtVi+ucR0qDdBHYMYUGINlhCAgqeQH3SqT9tS9aO9VspoDLCMsso=; 24:bPZdzY3N5Z0OSAQRhFmmC0uBtiSjOWnWVX9MfZnOQQYKTy+yV6zNm56HHMUWdwFW05PZw5Gj4lORY6vkI0LPul8sUBFNIOq/u2+QFXL6fYU=; 7:FIB/IJnmxc2T4XEtjFlp1T8pUlDZQ2Y7bevPRIYBnCU9Y3F0uEZ0hwv6mDC5IjLhmVoCX8QxYEg0hOzIdHJ1uUvJHhvLAT6EWIngv6qEAYA2rjhuwKi57hi0FIMK2z2otEAv0lNW5dNjGwg6mbtEw8ZouG2gLHRn85LQh/MQ5W78arASEjJnG8F7a3VuqNWQOP9BUXsbDZLiUpPEUlGGqne3Qwh04Ej1iSUxp8+YWnV2xOMmY0cohViyoLJKuADF
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: f4e7f2bd-2bbf-468c-79e8-08d51a7040ef
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:AM3PR07MB1121;
x-ms-traffictypediagnostic: AM3PR07MB1121:
x-exchange-antispam-report-test: UriScan:(82608151540597);
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231020)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1121; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1121;
x-forefront-prvs: 046985391D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(13464003)(24454002)(199003)(189002)(6436002)(66066001)(5660300001)(14454004)(316002)(2906002)(3660700001)(5250100002)(478600001)(4326008)(53546010)(99286003)(189998001)(55016002)(9686003)(6246003)(86362001)(53936002)(6506006)(3280700002)(229853002)(2900100001)(76176999)(74316002)(97736004)(7736002)(50986999)(305945005)(54356999)(81156014)(102836003)(81166006)(33656002)(8676002)(101416001)(7696004)(2950100002)(8936002)(25786009)(3846002)(6116002)(105586002)(6916009)(106356001)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB1121;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f4e7f2bd-2bbf-468c-79e8-08d51a7040ef
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2017 23:46:16.9951 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1121
Archived-At: <>
Subject: Re: [netmod] leafref to lists that contain system-controlled entries
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Oct 2017 23:46:23 -0000

Thanks Martin.  Pls see below.

> -----Original Message-----
> From: Martin Bjorklund []
> Sent: Monday, October 16, 2017 2:56
> To: Sterne, Jason (Nokia - CA/Ottawa) <>
> Cc:
> Subject: Re: [netmod] leafref to lists that contain system-controlled entries
> "Sterne, Jason (Nokia - CA/Ottawa)" <> wrote:
> >
> > 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