Re: [core] [IANA #1269224] Early review: draft-ietf-core-sid (IETF 116)

Michael Richardson <> Sun, 26 March 2023 18:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98F6AC1522D3 for <>; Sun, 26 Mar 2023 11:01:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 VNRUG0dcXiFi for <>; Sun, 26 Mar 2023 11:01:36 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 55025C14CF0D for <>; Sun, 26 Mar 2023 11:01:35 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF87B3898E; Sun, 26 Mar 2023 14:34:52 -0400 (EDT)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id 14G6H6MUlrRg; Sun, 26 Mar 2023 14:34:52 -0400 (EDT)
Received: from (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by (Postfix) with ESMTP id 0EDE03898C; Sun, 26 Mar 2023 14:34:52 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mail; t=1679855692; bh=6j4+BhRBt9rqAkGrFFEO3ir2k6Ol6YU8+eLMVFQeC+U=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=Xl2DkzGVz9JkTyOVsr48yTWV6tviW3oH+kLFaUVRBvkzyWAlXUmM/iAKqUgXS3e9a c0WJD3882xGgTcdoRCXIoO+sLzu7E9R+o+D01uWoBynjfAf3IbWw5+WCrusGaOYLa9 eVfeSM5+x2ywrl/jjswS7awgVj8FXxmX0AwHRB7CVQIV8WB96TzFFv/CtDuqz5ftMf 2PAj33Uz7+urC4rP0Mby9ep+cxfu0ValZHHTtSu7XBabqlqjhBUk4biT+mkp/9oXCx G+N219MyWqGl2LdnZrh3KVy8CBa0o4fS5cJezNStpecCQTqe2wonIeRSpNJUf6jY6h qaThtr6h1Blng==
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 9DF0E3F5; Sun, 26 Mar 2023 14:01:32 -0400 (EDT)
From: Michael Richardson <>
To: Carsten Bormann <>
cc:, Amanda Baber via RT <>,
In-Reply-To: <>
References: <> <> <> <10459.1679664690@localhost> <>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.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-sha512"; protocol="application/pgp-signature"
Date: Sun, 26 Mar 2023 14:01:32 -0400
Message-ID: <22626.1679853692@localhost>
Archived-At: <>
Subject: Re: [core] [IANA #1269224] Early review: draft-ietf-core-sid (IETF 116)
X-Mailman-Version: 2.1.39
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: Sun, 26 Mar 2023 18:01:40 -0000

Carsten Bormann <> wrote:
    > On 24. Mar 2023, at 22:31, Michael Richardson <> wrote:
    >> IANA has been extra vigilant this round.
    >> I am adding the WG to the list, since these are mostly my opinions.
    >> (However, I believe that I'm re-stating WG consensus)
    >> Amanda Baber via RT <> wrote:
    >>> 1) Section 6.4.2 says, 'The range of 60,000 to 99,999 (size 40,000) is
    >>> reserved for experimental YANG modules. This range MUST NOT be used in
    >>> operational deployments since these SIDs are not globally unique which
    >>> limit their interoperability. The IANA policy for this range is
    >>> "Experimental use".' However, Table 3 says that the policy is
    >>> "Experimental/Private use." Which is correct?
    >> I think that while it's for "experimental" YANG modules, the implication is
    >> that they are for Private Use.

    > I think they actually were meant for private, experimental use.
    > Even in private use, you should not fill up this space with your private needs.
    > You should use those for experiments only.

I don't know if you are agreeing or disagreeing withme.

    >> I have reread RFC8126 section 4.1 vs 4.2.

IANA has two different things, Experimental Use vs Private Use.
For SIDs, I'm not really sure what the effective difference would be.

    >> I observe that yang catalog scrapes YANG modules out of individual drafts
    >> and essentially they get "published" at that point.

    > That is not core-sids concept of “published”, which is “all numbers are
    > now stable and you can treat this as final”.

Yes, I know.
My point is that things get made public in different ways.
I think that Private Use allocations should never be public, but Experimental
Use might be.

    >>> 3) Another possible issue: if we have a SID file for a YANG module
    >>> called ietf-example, and another document comes along and provides a
    >>> new version of ietf-example, do we update the link in the "IETF YANG
    >>> SID Registry" to point to the new version of the YANG module, or
    >>> continue pointing to the old one?
    >> Yes, we would do that when the document is published.

    > (And I would expect that old revisions of both are also accessible, somewhere.)

We've resisted writing that SID values are made "final" at WGLC, because I
think that we didn't want to write IETF-specific instructions into YANG-SID.
But, I think that is what we want for IETF stream documents.

Michael Richardson <>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide