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
- [core] documenting SID usage in IETF specification Michael Richardson
- Re: [core] [Anima] documenting SID usage in IETF … Carsten Bormann
- Re: [core] [Anima] documenting SID usage in IETF … Michael Richardson
- Re: [core] [Anima] documenting SID usage in IETF … Andy Bierman
- Re: [core] [Anima] documenting SID usage in IETF … Peter van der Stok
- Re: [core] [Anima] documenting SID usage in IETF … Carsten Bormann
- Re: [core] [Anima] documenting SID usage in IETF … Andy Bierman
- Re: [core] [Anima] documenting SID usage in IETF … Michael Richardson
- Re: [core] [Anima] documenting SID usage in IETF … Michael Richardson
- Re: [core] [Anima] documenting SID usage in IETF … Carsten Bormann
- Re: [core] [Anima] documenting SID usage in IETF … Andy Bierman
- Re: [core] [Anima] documenting SID usage in IETF … Michael Richardson
- Re: [core] [Anima] documenting SID usage in IETF … Andy Bierman
- Re: [core] [Anima] documenting SID usage in IETF … Peter van der Stok
- Re: [core] [Anima] documenting SID usage in IETF … Carsten Bormann
- Re: [core] [Anima] documenting SID usage in IETF … Peter van der Stok
- Re: [core] [Anima] documenting SID usage in IETF … Carsten Bormann
- Re: [core] [Anima] documenting SID usage in IETF … Peter van der Stok