[core] documenting SID usage in IETF specification

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 11 September 2018 20:25 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 CDFAC130E05; Tue, 11 Sep 2018 13:25:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 xSDuui4nMEO0; Tue, 11 Sep 2018 13:25:50 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D7A5130DC5; Tue, 11 Sep 2018 13:25:50 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B8A3E20090; Tue, 11 Sep 2018 16:44:44 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 9EBFD82; Tue, 11 Sep 2018 16:25:49 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9BA3C7C; Tue, 11 Sep 2018 16:25:49 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: core@ietf.org
cc: anima@ietf.org
Reply-to: core@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Tue, 11 Sep 2018 16:25:49 -0400
Message-ID: <17342.1536697549@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/481KsoW0VkME1hudp-B1K-rhM3U>
Subject: [core] 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: Tue, 11 Sep 2018 20:25:53 -0000

   tl;dr> ****  HOW SHOULD SID VALUES BE DOCUMENTED IN RFCs?  ****

BACKGROUND:

The ANIMA WG is using https://tools.ietf.org/html/draft-ietf-core-yang-cbor-06
(expired in August, I hope it will be updated soon) and
https://tools.ietf.org/html/draft-ietf-core-sid-04 to encode RFC8366
defined vouchers in CBOR.  They are then signed with CMS or COSE.

We have been using the sid.py pyang extension created by Michel Veillette
to allocate the sid from the YANG definitions.  We have two questions.

QUESTIONS:
1) as one can see at:
   https://tools.ietf.org/html/draft-ietf-anima-constrained-voucher-02#section-6.1.2

After the traditional dump of the yang tree view, we are showing the
resulting assignments in a table in the ID (slightly edited from above):

      SID Assigned to
   --------- --------------------------------------------------
     1001150 module ietf-constrained-voucher-request
     1001154 data .../voucher
     1001155 data .../assertion
     1001156 data .../created-on
     1001157 data .../domain-cert-revocation-checks
     1001158 data .../expires-on
     1001159 data .../idevid-issuer
     1001160 data .../last-renewal-date
     1001161 data .../nonce
     1001162 data .../pinned-domain-cert
     1001163 data .../prior-signed-voucher-request
     1001164 data .../proximity-registrar-cert
     1001165 data .../proximity-registrar-subject-public-key-info
     1001166 data .../serial-number

the 1001150:50 space of SIDs was assigned by comi.space.  This display was
produced originally by minor editing of the result of the --list-sids option
to the sid.py plugin.    The allocation does not start at 1001150 because
some IDs are used to number the YANG modules that were included.

We are among the first users of the sid.py plugin, and the (re-)numbering of
all of the include modules in this way is likely a mistake, which has not
been solved.  Before I solve the underlying problems and fix the output to
produce what I think I want, we felt it was important to ask the WG...

****
        HOW SHOULD SID VALUES BE DOCUMENTED IN RFCs?
****

I'm not enthusiastic about including the .sid files only, but it could be
done, and we could say that they are normative, while --list-sid style above
is not.

SHOULD ietf-core-sid say something about this?


2) Given that https://tools.ietf.org/html/draft-ietf-core-sid-04#section-6.1
   allocates the first 1,000,000 to IANA,   then comi.space has
   started to give out entries > 1,000,000 it seems that comi.space ought
   to get the 1,000,000 -> 1,999,999 "mega-range" assigned to it.

   The question is, what should a document that has allocated a range from
   comi.space do it's in IANA Considerations?

   If ietf-core-sid could be advanced sooner, and IANA could create the
   registry,  we could ask for an early allocation value in the 100,000 ->
   999,999 range from IANA.

   Alternatively, ietf-core-sid-04 could allocate a range to our document
   in the section 6.1.2  "RFC SID range assignment" sub-registry.


3) It appears that there might be a typo in ietf-core-sid-04, section 6.1.1:


  o  The range of 100,000 to 999,999 is reserved for standardized YANG
      modules.  The IANA policy for future additions to this sub-
      registry is "Specification Required" [RFC5226].  Allocation within
      this range requires publishing of the associated ".yang" and
      ".sid" files in the YANG module registry.

   +-------------+---------------+------------------------+
   | Entry Point | Size          | IANA policy            |
   +-------------+---------------+------------------------+
   | 0           | 1,000         | IETF review            |
   | 1,000       | 59,000        | RFC required           |
   | 60,000      | 40,000        | Experimental use       |
   | 100,000     | 1,000,000,000 | Specification Required |
   +-------------+---------------+------------------------+
                   ^^^^^^^^^^^^^-- seem to be too many zeros



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