IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 15 January 2020 21:56 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 18B3D1209CB for <core@ietfa.amsl.com>; Wed, 15 Jan 2020 13:56:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 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] 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 zdkcx0R6YD5z for <core@ietfa.amsl.com>; Wed, 15 Jan 2020 13:56:41 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FEDC1209C9 for <core@ietf.org>; Wed, 15 Jan 2020 13:56:40 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9E21D3897D; Wed, 15 Jan 2020 16:56:09 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 79134124A; Wed, 15 Jan 2020 16:56:36 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Carsten Bormann <cabo@tzi.org>
cc: core@ietf.org
In-Reply-To: <0805B57C-3DCB-4601-976C-2D51CE812312@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>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 15 Jan 2020 16:56:36 -0500
Message-ID: <14603.1579125396@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/HXrN-s5un_kDgKNALFRccDjT5MM>
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: Wed, 15 Jan 2020 21:56:43 -0000

Carsten Bormann <cabo@tzi.org> wrote:
    >> You use --update-sid-file normally to allocate SID values from a YANG
    >> file.  It keeps track not to re-use elements after the leaf is
    >> deleted, and makes sure to re-use numbers when the leaf has not
    >> changed.  Deleting and then adding a leaf with the *same name* should
    >> wind up with the SID being reused.

    > So when the development of a standard is completed, we hand IANA a SID
    > file with dead SIDs in it?  Or how do we maintain the memory of those
    > dead SIDs?  Are there boundaries through which a SID file can go that
    > does remove dead SIDs?

Yes, if we evolved the design during WG processing, then we could well have
dead SIDs.  We could, at WGLC or IESG approval, edit the SID file and mark
them as useable again.
(If there were no running code, we could reset the SID file entirely at that point)
The SID file maintains the memory of the dead values for only as long as we
want it to.

    >> The SID file is some JSON.  Here is an example:
    >> https://github.com/anima-wg/constrained-voucher/blob/master/ietf-constrained-voucher-request%402019-09-01.sid

    > Yes.  The file format is fine, the question is whether we give enough
    > guidance on how to handle the evolution of “the” SID file for a YANG
    > module.

Thus, I think, a need to get early IANA review of the details.

    > I think Andy Bierman has reminded us often enough that this is hard to
    > get right.  Sorry for playing a bad copy of Andy today.

    > Grüße, Carsten

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email