IETF Logo Mail Archive

Re: [core] [Anima] documenting SID usage in IETF specification

Carsten Bormann <cabo@tzi.org> Sat, 03 November 2018 14:34 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 DA9D21277D2 for <core@ietfa.amsl.com>; Sat, 3 Nov 2018 07:34:17 -0700 (PDT)
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] 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 U_nmXRQxQ4bH for <core@ietfa.amsl.com>; Sat, 3 Nov 2018 07:34:16 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34789124408 for <core@ietf.org>; Sat, 3 Nov 2018 07:34:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wA3EY7mL025766; Sat, 3 Nov 2018 15:34:12 +0100 (CET)
Received: from [IPv6:2001:67c:1230:105:5c53:b8bb:f5a9:e4ef] (unknown [IPv6:2001:67c:1230:105:5c53:b8bb:f5a9:e4ef]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42nLzf2BMjz1Bqf; Sat, 3 Nov 2018 15:34:05 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <1ee600960e00adc9926b87425a585d3d@bbhmail.nl>
Date: Sat, 03 Nov 2018 21:34:01 +0700
Cc: Andy Bierman <andy@yumaworks.com>, Core <core@ietf.org>
X-Mao-Original-Outgoing-Id: 562948439.888887-cde5e596bf266414edd68a1df0278923
Content-Transfer-Encoding: quoted-printable
Message-Id: <937F3F95-6B97-4773-BAC6-8BE6A3A903C3@tzi.org>
References: <17342.1536697549@localhost> <622CDA79-7BE4-4A71-BFF7-0C80F63A1556@tzi.org> <CABCOCHTrjYZmK4e+L7pj=V=sWxg97jw2AFGen2PFe7ceBrB7bg@mail.gmail.com> <50f58c78b6825ce1cdbc33ea852c3145@bbhmail.nl> <84F58F84-4637-4D65-8F86-8E86B346528F@tzi.org> <CABCOCHStLsAgVT9Lus-=A_DR+79+3vCjTuKc5aUJ-Hu099HR0g@mail.gmail.com> <f27a9a9bbfc4052d8ac86f82ccf1b4b8@bbhmail.nl> <82ECE4AE-5284-42A4-B85D-7B5B413FD858@tzi.org> <1ee600960e00adc9926b87425a585d3d@bbhmail.nl>
To: peter van der Stok <consultancy@vanderstok.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/MEJsWKZ5mtPEoq6MUv_vkRLerJU>
Subject: Re: [core] [Anima] documenting SID usage in IETF specification
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: Sat, 03 Nov 2018 14:34:18 -0000

On Nov 3, 2018, at 20:45, Peter van der Stok <stokcons@bbhmail.nl> wrote:
> 
> Hi Carsten,
> 
> there are two sides to your question:
> - How do we convince IANA to take the responsibility

That depends a lot on the scale.  There will be hundreds of modules, each potentially with hundreds of SIDs.
So we are creating a problem on the scale of IANA’s biggest registry (Private Enterprise numbers, PENs).
I’m not sure that is realistic.

> - How will they check the SID files: Like they check the content-format numbers and others

The allocation is based on mega-ranges.  What people do within their allocations should really be their business.
Only for the IETF range we may want to go into more detail, and that should be based on allocating ranges for the modules.
The only thing that needs to be checked is that all SIDs of a module are within the range allocated to the module, and that those allocations don’t overlap.

Grüße, Carsten

v2.23.0 | Report a Bug | By Email