Re: [netmod] instance data new backward compatibility text

Balázs Lengyel <> Mon, 25 March 2019 23:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 48DE4120150 for <>; Mon, 25 Mar 2019 16:02:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 3.036
X-Spam-Level: ***
X-Spam-Status: No, score=3.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DJmc3d23YlCH for <>; Mon, 25 Mar 2019 16:01:58 -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 8CBE5120152 for <>; Mon, 25 Mar 2019 16:01:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=85+7mP4FQQjzBmwzzE0EtLnm2CA+DMpPYtjoY6j6xng=; b=TR6puID8urVXn3D2Wtrh3TgDpNRQ9KwMa25PpQGErB7Q8fNz97sKVwn74BlqA+pGb6gSs6rDiriBGUzA7lDTA16JdZgSl7MWq1Vj9PMLK61uoGalUfwgsjg47Ew0CnI1UTXAB0IoEEjqXxRmlpVgQy9g0lqIgoHFy/RdVu+XkGg=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.11; Mon, 25 Mar 2019 23:01:52 +0000
Received: from ([fe80::39a5:6b6d:a86f:721c]) by ([fe80::39a5:6b6d:a86f:721c%2]) with mapi id 15.20.1730.013; Mon, 25 Mar 2019 23:01:52 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= <>
To: "" <>
Thread-Topic: [netmod] instance data new backward compatibility text
Thread-Index: AQHU41YNtfrF2XOMeUSipLaMZQVy/KYc6gWAgAAMugA=
Date: Mon, 25 Mar 2019 23:01:52 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
x-clientproxiedby: HE1P190CA0002.EURP190.PROD.OUTLOOK.COM (2603:10a6:3:bc::12) To (2603:10a6:209:31::16)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3abd2840-1a5b-4349-00cc-08d6b175deb2
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:AM6PR07MB5075;
x-ms-traffictypediagnostic: AM6PR07MB5075:
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 0987ACA2E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(136003)(366004)(346002)(396003)(199004)(189003)(6486002)(1730700003)(8936002)(14454004)(478600001)(3846002)(85182001)(66574012)(65826007)(31686004)(316002)(52116002)(105586002)(71190400001)(99286004)(25786009)(58126008)(14444005)(256004)(5660300002)(76176011)(85202003)(97736004)(2906002)(106356001)(36756003)(5640700003)(53936002)(7736002)(6436002)(2616005)(11346002)(186003)(6512007)(31696002)(386003)(68736007)(236005)(54896002)(446003)(71200400001)(476003)(6506007)(64126003)(26005)(86362001)(2351001)(6116002)(65956001)(65806001)(66066001)(81156014)(2501003)(229853002)(8676002)(102836004)(81166006)(486006)(6346003)(99936001)(6246003)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB5075;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is );
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: k+pncpVwZxigEH2ynCAd12bexhSwiFUBxwMy6uZUNUWcSRzDOXa9EHTu1ClbKGnKKH3pZ1ki/wT2Ohm5NTxHcLy0/6Os0Fg5Ev3rwmNHSCklLVzDz4qL/rZuJGVF/6lNgMWLJorkAUnv7x6zkBE8ZjYy/qgSaKhcOwzJJIuWwRkhLOn/A25bH1aOxtqkKJXaX7mZDCzjtOKa2AQVtjknFs9k5sH7qZZYB2LLTFWZRr9mT7tFHVtLSF5zCjqOgh+pZABBm4wZG7J1VIzLC6GPI07aG39RLx3+y0oGNJO31VVhZK1gunA67YoNgKODT4+VOE/Hr0DiW0JVTw8z54zOv53vvDcEk5/VtN6yqGTU57Njlek6PZqoFU8iKq6/2LDiCL4KBUOlkQjTi1AdZP4jc3Kzs9LZ3HcDTBlGX5dZlOY=
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050105080601090402000805"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3abd2840-1a5b-4349-00cc-08d6b175deb2
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2019 23:01:52.7042 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5075
Archived-At: <>
Subject: Re: [netmod] instance data new backward compatibility text
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Mar 2019 23:02:01 -0000

Hello Jurgen,

I don't think these rules are Ericsson specific. In some of our most important use-cases (UC1, UC2, UC6) changing the keys would lead to problems.

UC1: If you document server capabilities using ietf-yang-library the name of the module sets may be/should be meaningful. It might be used by the NMS to compare the capabilities of different versions of the YANG server; changing keys without a reason will mislead the NMS into assuming the server capabilities changed..

UC2: Preloading default configuration data. E.g.  If you change the identifier of NACM ruleset, then during upgrade it might be loaded again as the server can not detect, that this is the same ruleset that is already in the datastore.

UC6:  Storing diagnostics data. If you change the keys used in diagnostic data, comparing values before and after the key change will be difficult.

And yes as we were using instance data for the last then years, we did have a lot of problem with people changing the keys without considering compatibility effects.
I agree that this is not always a problem, so I only used SHOULD  (and not MUST) in the text.

regards Balazs

On 2019. 03. 25. 23:16, Juergen Schoenwaelder wrote:
On Mon, Mar 25, 2019 at 09:59:43PM +0000, Balázs Lengyel wrote:
Hello Jurgen,

You are right that this is important mostly for instance data prepared as a
design/implementation activity; while not relevant for data coming from the
I will add it.

However in the first case it is vital!

For config files, and also for file documenting server capabilities we have
had MANY problems with people changing the key values/identities of list
They think it is a nice idea to provide better, more meaningful key values;
however the NMS designers use these key values to detect changes; also
during an upgrade process if a default configuration file is loaded again
with slightly changed key values, then e.g. access control rules become

The conditions under which it is meaningful to change keys and when it
is not appropriate are very application specific.  You may have
specific use cases at Ericsson where you want internal regulations but
I do not think this leads to meaningful rules outside your specific
application scenario.


Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: