IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 16 January 2020 00:17 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 63F87120891 for <core@ietfa.amsl.com>; Wed, 15 Jan 2020 16:17:23 -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 BkTnszgTnlp1 for <core@ietfa.amsl.com>; Wed, 15 Jan 2020 16:17:21 -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 19EDC12008F for <core@ietf.org>; Wed, 15 Jan 2020 16:17:20 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0EC813897D; Wed, 15 Jan 2020 19:16:53 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 00EC9124A; Wed, 15 Jan 2020 19:17:19 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Carsten Bormann <cabo@tzi.org>
cc: core@ietf.org
In-Reply-To: <CFF6555D-85EF-42CB-B773-17116F9CC554@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>
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 19:17:19 -0500
Message-ID: <18568.1579133839@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/BeDee8wfWfwfDuzM_PkI6GVIOus>
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 00:17:23 -0000

Carsten Bormann <cabo@tzi.org> wrote:
    >> 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.

    > This paragraph is exactly reflecting my nightmares about this.  We
    > could do a lot of things, if we wanted to.  What are our unambiguous,
    > not-to-be-missed instructions that make this fool-proof?

We will screw up, but the fools are often brilliant in their ability to get
around fool-proofing :-)

    > I would expect that we get rid of dead SIDs about as often as we revoke
    > TCP port number assignments, i.e., essentially never.  But this
    > requires getting around the cognitive dissonance of just having
    > “wasted” a SID value (*): With very strongly worded instructions, I’d
    > assume.

    > Grüße, Carsten

    > (*) (Note that there are way more SIDs than there are TCP ports.)

The time when we are most likely to create dead SID values is during the
development of running code between WG Adoption and WGLC.
I think it is reasonable thing to decide, with some communication among
implementers to reset/re-allocate.

Revisions to the YANG which deprecate leafs and therefore create deprecated
SID values are different: deployed code might still be using them.
(If we are revising published YANG, then certainly can never reset the SID process!)

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

v2.23.0 | Report a Bug | By Email