IETF Logo Mail Archive

Re: [Yot] contents of SID registration authority

peter van der Stok <stokcons@xs4all.nl> Mon, 19 February 2018 10:27 UTC

Return-Path: <stokcons@xs4all.nl>
X-Original-To: yot@ietfa.amsl.com
Delivered-To: yot@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE52126D05 for <yot@ietfa.amsl.com>; Mon, 19 Feb 2018 02:27:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 smRwree_LgHg for <yot@ietfa.amsl.com>; Mon, 19 Feb 2018 02:27:55 -0800 (PST)
Received: from lb2-smtp-cloud8.xs4all.net (lb2-smtp-cloud8.xs4all.net [194.109.24.25]) (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 BB5D6126CF9 for <yot@ietf.org>; Mon, 19 Feb 2018 02:27:54 -0800 (PST)
Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:212]) by smtp-cloud8.xs4all.net with ESMTPA id nifoeOsyTar0wnifoeNUZh; Mon, 19 Feb 2018 11:27:52 +0100
Received: from AMontpellier-654-1-73-22.w90-0.abo.wanadoo.fr ([90.0.168.22]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 19 Feb 2018 11:27:52 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Mon, 19 Feb 2018 11:27:52 +0100
From: peter van der Stok <stokcons@xs4all.nl>
To: Michel Veillette <Michel.Veillette@trilliantinc.com>
Cc: consultancy@vanderstok.org, yot@ietf.org, Michael Richardson <mcr@sandelman.ca>
Organization: vanderstok consultancy
Reply-To: consultancy@vanderstok.org
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <BN6PR06MB2308EFDDD226631D7ED514B6FEF40@BN6PR06MB2308.namprd06.prod.outlook.com>
References: <792b282a276d738ddfaf519668a008a4@xs4all.nl> <BN6PR06MB2308A232AF7F2382F2344EDEFEF50@BN6PR06MB2308.namprd06.prod.outlook.com> <dababb77f3473da4817b8e85eefc8347@xs4all.nl> <BN6PR06MB2308EFDDD226631D7ED514B6FEF40@BN6PR06MB2308.namprd06.prod.outlook.com>
Message-ID: <232f180f1c728b1a614cca4ae3a6b3ac@xs4all.nl>
X-Sender: stokcons@xs4all.nl
User-Agent: XS4ALL Webmail
X-CMAE-Envelope: MS4wfP+kb3vqxSjITXNZO0WwfDElYEceaKTeKVhW7rPrMA9zEUcLOjfyJzkMXaMDF626S5RwhAi4gxziytAIEg6eaqCrgkla3pjAy4rtAPmD5OT6JrIF5VB3 DJ3b8+sVNY+xE6VDosNb5utOWmjh6s2TPapo2vT10Pqa9/JL8vpNHO6dShK0LCepcxRJByTDz3+cxfp2dtjW5Zd60UZMcpZLfjH95pTc4Ci0VRgDO6N6VCS6 psSpYjQIH7MIAJxE+cyOks3v9FHCkSno4e0UNIDuJqhDR/MuRBxOttG7Zut4S3FT
Archived-At: <https://mailarchive.ietf.org/arch/msg/yot/tvzJucllwJxkZ2XfoN3r7sAc7D8>
Subject: Re: [Yot] contents of SID registration authority
X-BeenThere: yot@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Yang of Things <yot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yot>, <mailto:yot-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yot/>
List-Post: <mailto:yot@ietf.org>
List-Help: <mailto:yot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yot>, <mailto:yot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Feb 2018 10:27:56 -0000

Hi Michel,

I read the core-sid draft, and saw that indeed there is a IANA registry 
called "SID mega-range" and another called
"YANG module assignment".
That simplifies things. Good.
some text enhancements below:

>> 
>>    o  The range of 1000 to 59,999 is reserved for YANG modules defined
>>       in RFCs.  The IANA policy for future additions to the "SID 
>> mega-range" sub-
>>       registry is "RFC required" [RFC5226].
All RFC-based YANG modules SHOULD allocate SID values and register them 
in "SID mega-range" registry.
          It is required to register the associated ".yang" and ".sid"
>>       files in the "YANG module assignment" registry.  The allocation 
>> within this
>>       range is done prior to the RFC publication but should not be 
>> done
>>       prior to the working group adoption.
>> 

Question:
Suppose after WG adoption SID are allocated in the IETF range. During 
the draft development the number of required SIDS changes radically and 
a new allocation is required.

How is that going to be handled? Will there be holes in the allocated 
SID value range?

Greetings,

Peter

v2.23.0 | Report a Bug | By Email