[core] SID files and IANA

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 25 July 2019 02:42 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 380181200DB for <core@ietfa.amsl.com>; Wed, 24 Jul 2019 19:42:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id VFU7jYY9eBv9 for <core@ietfa.amsl.com>; Wed, 24 Jul 2019 19:42:02 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E886D120090 for <core@ietf.org>; Wed, 24 Jul 2019 19:42:01 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [IPv6:2001:67c:370:128:6e88:14ff:fe34:93bc]) by relay.sandelman.ca (Postfix) with ESMTPS id 06AB31F44B; Thu, 25 Jul 2019 02:42:00 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 0356C1B00; Wed, 24 Jul 2019 22:42:22 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: core@ietf.org
cc: michelle.cotton@icann.org
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Wed, 24 Jul 2019 22:42:22 -0400
Message-ID: <16149.1564022542@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/h1p-vpANdyv9X2HF-CFmSX1cpQc>
Subject: [core] SID files and IANA
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: Thu, 25 Jul 2019 02:42:04 -0000

{Michelle told me to CC her, but I'm not sure if this is the email she wanted
me to use}

As https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/
and https://datatracker.ietf.org/doc/draft-ietf-core-sid/

approach WGLC, Panos, Peter and I have been wondering in our editing of

we have struggled a bit with the SID generation process.

draft-ietf-core-sid says:
6.4.1.  Structure

   Each entry in this registry must include:

   o  The YANG module name.  This module name must be present in the
      "Name" column of the "YANG Module Names" registry.

   o  A link to the associated ".yang" file.  This file link must be
      present in the "File" column of the "YANG Module Names" registry.

   o  The link to the ".sid" file which defines the allocation.

   o  The number of actually allocated SIDs in the ".sid" file.

   The ".sid" file is stored by IANA.

It is this the last part that I think is not well enough defined.
1) How does the file get to IANA?  Is it published in the RFC
   along with the initial YANG module?    This clearly only
   works for YANG modules that come to IANA via RFC, and the SID
   IANA Considerations makes it clear that SIDs will be allocated
   via a hierarchial process of mega-ranges.

2) Does the sid file need some kind of advisory locking process,
   such that only a single internet-draft effort can update things
   to make bis versions of YANG modules.

3) What is the process going to be to generate SID allocations for
   existing YANG modules that IANA already has?

4) Clearly we need to get sid.py upstreamed to pyang, and I expect to
   take another stab at doing this, but we need to take this process
   into account into when IANA is ready to take allocations.

5) https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-voucher/
   got two 50 SID ranges from comi.space, in the 1,000,000->2,000,000 space.
   We'd ask for an early registration, but we can't until the registry
      is created
   a) I'd like to know if we are going to allowed to keep this allocation,
      and if not, I'd like to know now please.

   b) can we go into the 6.3.3 initial registry?  Either with the
      current allocation, or with a new allocation.

   c) time is pretty important here...

Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-