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

Peter van der Stok <stokcons@bbhmail.nl> Mon, 05 November 2018 04:38 UTC

Return-Path: <stokcons@bbhmail.nl>
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 DD9911298C5 for <core@ietfa.amsl.com>; Sun, 4 Nov 2018 20:38:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 ie36uSpp7eMx for <core@ietfa.amsl.com>; Sun, 4 Nov 2018 20:38:08 -0800 (PST)
Received: from smtprelay.hostedemail.com (smtprelay0040.hostedemail.com [216.40.44.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 641CC128CF2 for <core@ietf.org>; Sun, 4 Nov 2018 20:38:08 -0800 (PST)
Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay02.hostedemail.com (Postfix) with ESMTP id 1B95A3C48E; Mon, 5 Nov 2018 04:38:07 +0000 (UTC)
X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C
X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:41:72:152:355:379:582:599:800:960:962:967:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1535:1543:1575:1588:1589:1592:1594:1711:1730:1776:1792:2068:2069:2198:2199:2525:2527:2528:2553:2559:2564:2682:2685:2693:2741:2827:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3354:3622:3846:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4118:4250:4321:5007:6117:6119:6261:6298:6657:6659:6678:7860:7875:7903:8603:8985:9025:9177:10004:10400:10848:11232:11658:11783:11914:12043:12663:12740:12895:13071:13139:13149:13160:13161:13229:13230:13972:14093:14096:14180:14181:14347:14721:14819:21060:21063:21080:21433:21451:21625:21811:30029:30030:30034:30041:30054:30070:30090, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF
X-HE-Tag: coat13_63eb750bb9845
X-Filterd-Recvd-Size: 7551
Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf15.hostedemail.com (Postfix) with ESMTPA; Mon, 5 Nov 2018 04:38:06 +0000 (UTC)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_0c1d29f98b43511672db49438f76d2df"
Date: Mon, 05 Nov 2018 11:38:06 +0700
From: Peter van der Stok <stokcons@bbhmail.nl>
To: Carsten Bormann <cabo@tzi.org>
Cc: peter van der Stok <consultancy@vanderstok.org>, Andy Bierman <andy@yumaworks.com>, Core <core@ietf.org>
Organization: vanderstok consultancy
Reply-To: consultancy@vanderstok.org
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <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> <937F3F95-6B97-4773-BAC6-8BE6A3A903C3@tzi.org>
Message-ID: <67ddf8fa801586ca3452e331e93252c9@bbhmail.nl>
X-Sender: stokcons@bbhmail.nl
User-Agent: Roundcube Webmail/1.2.7
X-Originating-IP: [31.133.136.157]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/ihclxY4Hd6Tht6jjRENnt7yleHA>
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: Mon, 05 Nov 2018 04:38:11 -0000

Hi Carsten,

My proposal for the handling of SIDs is the following:

During the development of a YANG module described in an Internet draft,
the allocation of SIDs is handled by the comi.space facility.
A range is allocated to the module in the non-RFC range; during the
development of the draft, the range can be changed and the allocation to
individual YANG names can be changed.

Once the draft is accepted to become RFC, the following actions should
be taken:
- The SID range for every module in the future RFC is allocated from the
RFC range. (This means changing the SID values)
- The contents of the SID files (one per module) are included in the
RFC.
- IANA registers the module names, RFC number, and the SID range
allocations.
- IANA registers the YANG name to SID map for every module in the RFC.

we could ask IANA to provide an extension to YANG parameter registry
https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml

It contains presently a YANG module registry. (as specified in RFC6020,
section 14.1)
Suggestion to create next to yang module registry a sid module registry.
Currently, IANA makes a version of the yang module available, so
maintaining a sid file should be possible as well (IMO)

Comments will be appreciated,

Peter 

Carsten Bormann schreef op 2018-11-03 21:34:

> 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