IETF Logo Mail Archive

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

Carsten Bormann <cabo@tzi.org> Wed, 15 January 2020 23:04 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 7EA72120639 for <core@ietfa.amsl.com>; Wed, 15 Jan 2020 15:04:42 -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 IJjkoe4B2Xex for <core@ietfa.amsl.com>; Wed, 15 Jan 2020 15:04:40 -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 6ABE7120110 for <core@ietf.org>; Wed, 15 Jan 2020 15:04:40 -0800 (PST)
Received: from [192.168.217.119] (p548DC4D8.dip0.t-ipconnect.de [84.141.196.216]) (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 47yjZZ6QQkz16H8; Thu, 16 Jan 2020 00:04:38 +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: <14603.1579125396@localhost>
Date: Thu, 16 Jan 2020 00:04:38 +0100
Cc: core@ietf.org
X-Mao-Original-Outgoing-Id: 600822278.361071-5c5beb9024d8c4a37a9f3e0918d6dd74
Content-Transfer-Encoding: quoted-printable
Message-Id: <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>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/dvdCYUlwNLAKfdRIyXLWuQ5STJI>
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 23:04:42 -0000

On 2020-01-15, at 22:56, Michael Richardson <mcr+ietf@sandelman.ca> 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?

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.)

v2.23.0 | Report a Bug | By Email