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

Carsten Bormann <> Mon, 27 March 2023 08:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B239C151B1C for <>; Mon, 27 Mar 2023 01:02:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DIAHSCvjuows for <>; Mon, 27 Mar 2023 01:02:16 -0700 (PDT)
Received: from ( [IPv6:2001:638:708:32::21]) (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 482A0C151B0B for <>; Mon, 27 Mar 2023 01:02:14 -0700 (PDT)
Received: from [IPv6:2001:67c:370:128:e4b7:3fb7:6d89:e36e] (unknown [IPv6:2001:67c:370:128:e4b7:3fb7:6d89:e36e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4PlQJc2fVjzDCpT; Mon, 27 Mar 2023 10:02:08 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <22626.1679853692@localhost>
Date: Mon, 27 Mar 2023 17:02:04 +0900
Cc: " WG (" <>, Amanda Baber via RT <>, "" <>
X-Mao-Original-Outgoing-Id: 701596924.4079469-4bab5c32fb813b1bafbceb28b8565d31
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <10459.1679664690@localhost> <> <22626.1679853692@localhost>
To: Michael Richardson <>
X-Mailer: Apple Mail (2.3608.
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: Mon, 27 Mar 2023 08:02:19 -0000

On 2023-03-27, at 03:01, Michael Richardson <> wrote:
> 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 don’t know that either… Let’s find out.

>>> 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.

The difference RFC 8126 makes is the scope of the use.
Experimental is for an experiment, for which is " it's important
to make clear any expected restrictions on experimental scope.  "
Private use doesn’t require this effort: “ It is the responsibility of the sites making use
   of the Private Use range to ensure that no conflicts occur (within
   the intended scope of use).”.

>>> 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.

That might be a useful difference.

>>>> 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.

WGLC is a bit early for anything final anyway.  IESG approval is more like it.
(But then things might change in AUTH48, if they are broken enough.
But then, if things are broken, the rules will only be of limited help.)

Grüße, Carsten