IETF Logo Mail Archive

Re: [core] progressing ietf-core-yang-cbor and ietf-core-sid

Carsten Bormann <cabo@tzi.org> Thu, 16 January 2020 17:47 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D837120861 for <core@ietfa.amsl.com>; Thu, 16 Jan 2020 09:47:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StbG8f01tUSj for <core@ietfa.amsl.com>; Thu, 16 Jan 2020 09:47:22 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA49120071 for <core@ietf.org>; Thu, 16 Jan 2020 09:47:22 -0800 (PST)
Received: from client-0160.vpn.uni-bremen.de (client-0160.vpn.uni-bremen.de [134.102.107.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47zBV027x6zyRy; Thu, 16 Jan 2020 18:47:20 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CABCOCHRXH4AqYh6y9wVtCdA8T01sG7tAXmhzwzAk3QV9OjLonA@mail.gmail.com>
Date: Thu, 16 Jan 2020 18:47:19 +0100
Cc: Ivaylo Petrov <ivaylo@ackl.io>, Core <core@ietf.org>, Alexander Pelov <alexander@ackl.io>
X-Mao-Original-Outgoing-Id: 600889639.290224-5cae1b8d232acb504856dbdf0d76dbd8
Content-Transfer-Encoding: quoted-printable
Message-Id: <5C3B4919-5513-4342-888D-998A11366D36@tzi.org>
References: <29380.1565102380@localhost> <BL0PR06MB50428065032ECC2AB3345F619AD70@BL0PR06MB5042.namprd06.prod.outlook.com> <7505.1565633977@localhost> <BL0PR06MB50424C618A704460E4A8F8D99AA90@BL0PR06MB5042.namprd06.prod.outlook.com> <18990.1577231446@localhost> <CAJFkdRyWOfCb4U09rEJ-ZMR3GUuk-rmQ+f3Fs164Mxs8qkeVuw@mail.gmail.com> <22612.1578626081@localhost> <CAJFkdRztFUxdGcdvtTgB=9c-e_BwDAgLTmVPJ+OB8-dgs1sGog@mail.gmail.com> <15754.1578789013@localhost> <CAJFkdRy_3pC37ZxzhTmzqRgWjwDvEFTuhu5Z8+_ktaJgoeOGfg@mail.gmail.com> <6025.1578939111@localhost> <F67A7C80-0955-4836-9B84-66CB52AB6FD9@tzi.org> <26398.1579112884@localhost> <0805B57C-3DCB-4601-976C-2D51CE812312@tzi.org> <14603.1579125396@localhost> <CFF6555D-85EF-42CB-B773-17116F9CC554@tzi.org> <18568.1579133839@localhost> <CABCOCHRJ6-YUSn=MXGMtJT5tK3m9uR3U1K2xYd2UgW2MYkv6ig@mail.gmail.com> <CAJFkdRy8tDbYnnyr-mCer-Bip6s7pcXyGQPmo+nO8zRavSTm1w@mail.gmail.com> <CABCOCHRXH4AqYh6y9wVtCdA8T01sG7tAXmhzwzAk3QV9OjLonA@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/_FtRbagTiWm7xr25idAEXoPtuwI>
Subject: Re: [core] progressing ietf-core-yang-cbor and ietf-core-sid
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jan 2020 17:47:28 -0000

On 2020-01-16, at 13:50, Andy Bierman <andy@yumaworks.com> wrote:
> 
> There is a significant amount of metadata needed to generate a SID file,
> starting with all the previous YANG revisions or SID files, and when/if
> the SID files have been reset vs. updated with preserved numbers.

Well, specifically, the current YANG module and the previous SID file; not the entire history of the universe.

The need for the previous SID file means that there needs to be a single lineage; SID files cannot be independently progressed.  This calls for central entity (or a blockchain :-).
What we need to define unambiguously is who that entity is.
One we are at the IANA, the Designated Expert (DE) can play this role.
But we need to define the process leading up to this.
(Yes, that process will evolve, and we probably also need to allow exceptions.
But there must be strong guide rails that work for the vast majority of cases.)

Adding a version number to the SID file could indeed help with accidents/disasters.
But it could also lead to people thinking they can get away with concurrent lineages; thinking that version numbers will fix any fallout.
That would be a disaster on its own, most likely leading to permanent universe splits.
So I’m not so sure we want to open that Pandora’s box.

Grüße, Carsten

v2.23.0 | Report a Bug | By Email