IETF Logo Mail Archive

Re: [core] [Ext] Re: Lars Eggert's Discuss on draft-ietf-core-sid-22: (with DISCUSS and COMMENT)

Carsten Bormann <cabo@tzi.org> Fri, 27 October 2023 18:57 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 E46D6C151064; Fri, 27 Oct 2023 11:57:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AT9wL3N8ugbA; Fri, 27 Oct 2023 11:57:42 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [134.102.50.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74227C14CE4D; Fri, 27 Oct 2023 11:57:37 -0700 (PDT)
Received: from eduroam-pool10-182.wlan.uni-bremen.de (eduroam-pool10-182.wlan.uni-bremen.de [134.102.90.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4SHBk66wyCzDCd4; Fri, 27 Oct 2023 20:57:34 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <F8CED175-BD91-46FA-8505-07DF5D4BFABD@iana.org>
Date: Fri, 27 Oct 2023 20:57:31 +0200
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Lars Eggert <lars@eggert.org>, The IESG <iesg@ietf.org>, "draft-ietf-core-sid@ietf.org" <draft-ietf-core-sid@ietf.org>, "core-chairs@ietf.org" <core-chairs@ietf.org>, "core@ietf.org" <core@ietf.org>
X-Mao-Original-Outgoing-Id: 720125851.4593281-2e3b5827d12559cb23561df6589492b3
Content-Transfer-Encoding: quoted-printable
Message-Id: <80E3607A-2FD3-4856-8BFF-C638221CDC7D@tzi.org>
References: <169832632311.59761.11389369756506251047@ietfa.amsl.com> <19859.1698357456@localhost> <F8CED175-BD91-46FA-8505-07DF5D4BFABD@iana.org>
To: Amanda Baber <amanda.baber@iana.org>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/NVf0XbC9vAaO5EC60dFIiEaMIF8>
Subject: Re: [core] [Ext] Re: Lars Eggert's Discuss on draft-ietf-core-sid-22: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 27 Oct 2023 18:57:46 -0000

Hi Amanda,

On 2023-10-27, at 20:11, Amanda Baber <amanda.baber@iana.org> wrote:
> 
> 
>    IANA can ask itself for more space.
>    There are some advantages to everyone to keep everyone below 2^32.
>    Although it's not large, since most entries are delta-encoded.
> 
> [AB] IANA could ask for more space from the Mega-Range registry, given that it's an Expert Review space, but it would take an RFC to add it to the IETF YANG SID Range and set registration procedures for it. We would prefer not to manage a separate registry w/internally-declared registration procedures ourselves, and have no mechanisms for designating experts, handling appeals, etc.

I am pretty sure that the YANG community would watch any depletion process very intently and create another RFC well before the 1000000 SIDs are consumed (assuming that RFCs are still being made when the depletion finally happens, which may be centuries from now).

I am maybe a bit more concerned about the 0..59999 range set aside for the RFC Required space running out, which could happen within a decade or so.  So maybe we should indeed increase the cushion a bit there.

I made a PR:
https://github.com/core-wg/yang-cbor/pull/163

Grüße, Carsten

v2.23.0 | Report a Bug | By Email