IETF Logo Mail Archive

Re: [Yot] contents of SID registration authority

peter van der Stok <stokcons@xs4all.nl> Tue, 20 February 2018 08:12 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 EB7CC1243F3 for <yot@ietfa.amsl.com>; Tue, 20 Feb 2018 00:12:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 zYUFneMCcc_o for <yot@ietfa.amsl.com>; Tue, 20 Feb 2018 00:12:13 -0800 (PST)
Received: from lb2-smtp-cloud9.xs4all.net (lb2-smtp-cloud9.xs4all.net [194.109.24.26]) (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 0C3DB124239 for <yot@ietf.org>; Tue, 20 Feb 2018 00:12:12 -0800 (PST)
Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:216]) by smtp-cloud9.xs4all.net with ESMTPA id o31zeGpDooWCOo31zej3bw; Tue, 20 Feb 2018 09:12:10 +0100
Received: from AMontpellier-654-1-186-134.w92-145.abo.wanadoo.fr ([92.145.165.134]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 20 Feb 2018 09:12:07 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Tue, 20 Feb 2018 09:12:07 +0100
From: peter van der Stok <stokcons@xs4all.nl>
To: Michel Veillette <Michel.Veillette@trilliant.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: <BN6PR06MB23087FF6C2A7A67AA57523B19AC80@BN6PR06MB2308.namprd06.prod.outlook.com>
References: <792b282a276d738ddfaf519668a008a4@xs4all.nl> <BN6PR06MB2308A232AF7F2382F2344EDEFEF50@BN6PR06MB2308.namprd06.prod.outlook.com> <dababb77f3473da4817b8e85eefc8347@xs4all.nl> <BN6PR06MB2308EFDDD226631D7ED514B6FEF40@BN6PR06MB2308.namprd06.prod.outlook.com> <232f180f1c728b1a614cca4ae3a6b3ac@xs4all.nl> <BN6PR06MB23087FF6C2A7A67AA57523B19AC80@BN6PR06MB2308.namprd06.prod.outlook.com>
Message-ID: <8eb1d49832a5583452431192260843ce@xs4all.nl>
X-Sender: stokcons@xs4all.nl
User-Agent: XS4ALL Webmail
X-CMAE-Envelope: MS4wfCdCroV7ke5dyr1kGlqMkIGZGKl6lXKfUY8qL+zR9wPSx91bbgrKx1WeXNnCv9C1NjdAtu7lSV3DQPQTyAf8nwPb+JiEkVOgTQvTYULOAtxD25TizuWC bfZ5s+5NTa+TMBpE7248QDe0I1Zos3TPOHinebqUQNxarYzdJFOetCoVspMJ8vTweJw2qhp+lXxgKTnDGsvsCqgcmhSCSpkEfrpWWpPdfb4XFv4fX62iFGFF Uz+BhETOu27bN5PySflOSoM7SI0Af5Vux5wGgb3r2nyzwICjXvdiQgB5y6SIys/U
Archived-At: <https://mailarchive.ietf.org/arch/msg/yot/ik9E59e0bUiw3sEw33tToeMDYBw>
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: Tue, 20 Feb 2018 08:12:16 -0000

Hi Michel,

My suggestion is the following:

Assign a pool of provisional ietf SIDs. When working on a WG draft, 
these can be used.
Once transfer to RFC starts; return the provisional SIDs and allocated 
definite ietf SIDs.

Peter


Michel Veillette schreef op 2018-02-19 22:20:
> About "During the draft development the number of required SIDS
> changes radically and a new allocation is required."
> 
> During the development, the authors have two options.
> 
> 1) Stay backward compatible by updating the previous .sid file.
>    In this case, previously assigned SIDs are preserved.
>    Data nodes can be deprecated but not deleted as mandated by RFC7950
> section 11.
>    "Obsolete definitions MUST NOT be removed from published modules"
> 
> 2) Restarting from scratch by generating a brand new .sid file.
>     In this case, a completely new set of SIDs is generated.
> 
> Regards,
> Michel
> 
> -----Original Message-----
> From: peter van der Stok [mailto:stokcons@xs4all.nl]
> Sent: Monday, February 19, 2018 5:28 AM
> To: Michel Veillette <Michel.Veillette@trilliant.com>
> Cc: consultancy@vanderstok.org; yot@ietf.org; Michael Richardson
> <mcr@sandelman.ca>
> Subject: Re: contents of SID registration authority
> 
> 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