Re: [core] Fwd: New Version Notification for draft-ietf-core-sid-10.txt

Andy Bierman <> Mon, 17 February 2020 18:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 86E19120860 for <>; Mon, 17 Feb 2020 10:05:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lMfCfVLgOnYE for <>; Mon, 17 Feb 2020 10:05:30 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::b29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ACC4712008F for <>; Mon, 17 Feb 2020 10:05:30 -0800 (PST)
Received: by with SMTP id p123so9095134ybp.2 for <>; Mon, 17 Feb 2020 10:05:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5obz3/AlAho5n4Y0jG68AUBkXwW20+dolEDiStH2RI4=; b=f8Gd0HOtsKpLZ8Ps+SIx0S/H3KbtKBf1Zv4LtIrbQGftyxjr+ynOEA4ghIUpLLbI3t +jEYlpfka79AnKem/xyz4l/PSVEg7Ky3PGkseWIHPpToa5/FbRlUB++UhxoW81ZA/ov1 D/sU20Eq+EQpSt7T2/1e0wAECWgFzju1fdQwrBKFR1V01bTRpHr3qN6pmnTwQ/uJQxap WVpixcK9K6WIv24w4TiVWNlhIJng+7XwQIaJLnbDaesydLlak4rW1K7hvToyGWRkoHlL KaJ00R/R2zWJdcprvFCkw7JWFJv33AYhIl34HeDoNAzvvihEnTJHgFV2fFx1pRjFwU+3 qV4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5obz3/AlAho5n4Y0jG68AUBkXwW20+dolEDiStH2RI4=; b=HREdV7xcf/n5OEUGfjxd1IVqjKkV1XGFidJVwzh+1fUW/LDw0+cl5N1cPhGHWKvSwU GWKd+MIYps+Z6PsWHqF5BAh73iGr0aNdWQ8+wmKS/K+RZETt9W+luBCXfikCxSnp6CeQ cGaQlgvxxFBwtkaMLRXWSHFGhEK4IISb/85Hr5/gXcd9ijeW/KX1v/XkLmFGct+UjLye h6mJxdExwSmv8fonPkDdSmN9AgDBODQPDF2Ee6U6hAl7UMnTfWJmrPe5Z8KymNobTZbe ZUvoSQOQC1Br7+Bvz3rmW59rlNr8gMrq4legftndy/agiyXgU3v/xOpgis/NuKn1haUM IrnQ==
X-Gm-Message-State: APjAAAVmyQyVFKC0FYx81eZI6A/0hmtQR9AzVxPkwexoFO2eDkS8rVuF ERbqDODR3dhaE1/EDz9EDIaWYfDZf9VFSVw9U+7JEg==
X-Google-Smtp-Source: APXvYqxG2KjzoIEMXdTbsy8JwHcGfhBp6qYDaqIqjgMD/wQ11Y5SXBgGP5DtQTLor757rT7b/6i8bpxaNc1qvNi8XWM=
X-Received: by 2002:a25:1544:: with SMTP id 65mr14762859ybv.107.1581962729592; Mon, 17 Feb 2020 10:05:29 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Andy Bierman <>
Date: Mon, 17 Feb 2020 10:05:18 -0800
Message-ID: <>
To: Ivaylo Petrov <>
Cc: core <>
Content-Type: multipart/alternative; boundary="0000000000008bb7da059ec9669f"
Archived-At: <>
Subject: Re: [core] Fwd: New Version Notification for draft-ietf-core-sid-10.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Feb 2020 18:05:42 -0000


Here are my comments on draft-ietf-core-sid-10:

sec 1:

      YANG modules, submodules and features

* Should it be noted somewhere that these  3 constructs are numbered
for YANG library

  purposes and are not used in protocol messages like the other
constructs listed?

sec 4:

* The intro should contain a YANG Tree Diagram [RFC 8340]

module: ietf-sid-file
  +--rw module-name?              yang:yang-identifier
  +--rw module-revision?          revision-identifier
  +--rw sid-file-version?         sid-file-version-identifier
  +--rw dependencies-revisions* [module-name]
  |  +--rw module-name        yang:yang-identifier
  |  +--rw module-revision    revision-identifier
  +--rw assigment-ranges* [entry-point]
  |  +--rw entry-point    sid
  |  +--rw size           uint64
  +--rw items* [namespace identifier]
     +--rw namespace     enumeration
     +--rw identifier    union
     +--rw sid           sid

* The SID file construct needs a wrapper container instead of 6
to-level data nodes.

  A yang-data extension (from ietf-restconf.yang in RFC 8040) should be used.

  There is an update to rc:yang-data, but it is not published yet.

     rc:yang-data sid-file {

         // all 6 fields defined here


* The IETF Trust Copyright is for 2016. There is probably a new template.

* Nit: list names are usually singular (dependencies-revisions,
assignment-ranges, items)

* The description-stmt for assignment-ranges should be expanded:

  - specify that the SID range for each entry is SID entry-point to
entry-point + (size - 1)

  - the SID ranges specified by all assignment-rages MUST NOT overlap

* The type for /assignment-ranges/size should not allow zero-length
ranges.  s/uint64/uint64 { range 1..max; }/

sec 6.3.2 Allocation Policy

* the range 1000 to 59,999 is rather small for the pool of all YANG modules
published in RFCs.
  Likewise, 40K for all experimental numbers seems really small. The SID
range is uint64

* Not sure these characterizations of small, medium, large are helpful.
Also max allocation of 1000
  seems rather arbitrary.  Better to say requestors need to justify the
size of each request.

sec 6.4.2 Allocation Policy

   SIDs never change

  * The IETF has shown very little ability to get all the names and module
structure correct on the first try.
     Or the first 15 tries.  Modules get refactored and names get changed
-- a lot.  This statement is unclear.
     (SID 42 is always SID 42? Or do you mean SID assignments never change?)

  * This section should say that reassignment of SIDs within an allocated
SID range MAY change during
     YANG module development. next section has text about this issue.


 * Should an early allocation be given if the adopted module imports
unadopted modules?
   This seems to force the WG to adopt or not use the allocated SID range

* Not sure how to fix the following  sentence, but maybe just remove it
since it is unclear

   Critically, the original document should never get through the IETF
   process and then be surprised to be referencing a document whose
   progress is not certain.

 * Not sure what "expired" means. It means they are burned and never
reallocated right?

 It would punish early adopters to do otherwise.

   Early Allocations are made with a one-year period, after which they
   are expired.

Appendix A

The example is rather long (8+ pages).
Do not have a suggestion for a shorter module though

Appendix B

It should be stated that SID generation for RPC or action "input" and
"output" schema nodes
should always be done, even if no parameters are defined in the original
RPC or action.
Another module can augment these nodes (but cannot add "input" or "output"
with augment).


On Wed, Feb 12, 2020 at 7:04 AM Ivaylo Petrov <> wrote:

> Dear all,
> In the latest version I believe we have addressed Andy's comments
> regarding .sid file versioning. I consider this to be the last comment that
> was still pending before we can go for a working group last call for the
> sid draft and the cluster of drafts known as CORECONF in general. Please
> let us know if there are still points that you consider should be handled
> before the WGLC. In the absence of further comments, I would like to ask
> the working group chairs to consider going for a last call.
> Thank you in advance!
> Best regards,
> Ivaylo
> ---------- Forwarded message ---------
> From: <>
> Date: Wed, Feb 12, 2020 at 3:53 PM
> Subject: New Version Notification for draft-ietf-core-sid-10.txt
> To: Ivaylo Petrov <>io>, Alexander Pelov <>io>, Michel
> Veillette <>
> A new version of I-D, draft-ietf-core-sid-10.txt
> has been successfully submitted by Ivaylo Petrov and posted to the
> IETF repository.
> Name:           draft-ietf-core-sid
> Revision:       10
> Title:          YANG Schema Item iDentifier (SID)
> Document date:  2020-02-12
> Group:          core
> Pages:          33
> URL:
> Status:
> Htmlized:
> Htmlized:
> Diff: 
> Abstract:
>    YANG Schema Item iDentifiers (SID) are globally unique 63-bit
>    unsigned integers used to identify YANG items.  This document defines
>    the semantics, the registration, and assignment processes of SIDs.
>    To enable the implementation of these processes, this document also
>    defines a file format used to persist and publish assigned SIDs.
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at
> The IETF Secretariat
> _______________________________________________
> core mailing list