Re: [core] [Anima] documenting SID usage in IETF specification

Andy Bierman <> Tue, 11 September 2018 23:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA1FD130F63 for <>; Tue, 11 Sep 2018 16:32:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p0aCYa8MvGwZ for <>; Tue, 11 Sep 2018 16:32:42 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2EFA6130F59 for <>; Tue, 11 Sep 2018 16:32:42 -0700 (PDT)
Received: by with SMTP id q13-v6so50852lfc.2 for <>; Tue, 11 Sep 2018 16:32:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tXZ1rq9gX01WW7kNl5mQmG1et0TGwBc/LAOGHi8zjck=; b=hl9NoxsHm6jnlnvT1/ev0gN7E11z7/8YUJTTe8rCqQbUS1TtG/cvqTfbk0sZQLlWud +6IQe9Li/JM+ET0kkCdH0+uA9LRcxeEpnLxT0USEbmZXj8TVlDaFyz4If8P1+UAv+1D2 cXq6Xzmo+5+NMKxUSBdp4/mpJzCs+t0nvB4EgOW0Cq+3OpCYORB/NaArb09ejyyY705E rzgM1sE5zOfWWKm0S2S/ur1/v8P+pihZrmSrkw56oQp/krBDQwSR0eOXmSwFToh2xKqV pojtpSlfKI/DWM8VhXwPxh6YPwz5dFCfdzBtDIpHb883mirm6qLo7F5dW50sXVMlZDF0 YTjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tXZ1rq9gX01WW7kNl5mQmG1et0TGwBc/LAOGHi8zjck=; b=WB5+Zed5624w2WcxR1gYMZDT2I9dH9lriZ1jOoa6R0vTwYbLR8qydAN8OpPfuHy0tc JOnSr4cnCy0x+siH6hecHkqJUO0dJos3b3uOC9ddpxGdzg0X2rhs0uaYuLPZs+tcIGmU nDhDF3cJnfJHY1G8Ik51AvX6MdFNsg8R7Wj9dGEgqroIJq1uWm1nTRAteB+Mpm6Zu9ew Ouw/3OsYKzGKCIFnTtGFX672P1YdTzD3NZ/m3KtDm5QivYnBuW3ZZ6eePsA88Yp972UG eMnhRyelxMHSHK2vKb1c6kW4vjOLVKEtumFpZV4fulQdUmoCmsL1nHJvwcl+7oanYQEN x8Dw==
X-Gm-Message-State: APzg51ANzSuzCt9qftjeLgmaJJbthA84r0Xf+W9llqAoRxvGcRDNIyM/ 7VFdKyv5T7m7RTohrp+ek55hP+CgLMhEcxliH0ezhA==
X-Google-Smtp-Source: ANB0VdbBqLbc18PVVq6+jikWlfrQoT+RpeO5zyrA5MukgW35qIb7PLyKE7Q19jW5omkalg5sQe8rnHflebyQTYepsY4=
X-Received: by 2002:a19:8c55:: with SMTP id i21-v6mr17222908lfj.90.1536708760004; Tue, 11 Sep 2018 16:32:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:48c9:0:0:0:0:0 with HTTP; Tue, 11 Sep 2018 16:32:39 -0700 (PDT)
In-Reply-To: <>
References: <17342.1536697549@localhost> <>
From: Andy Bierman <>
Date: Tue, 11 Sep 2018 16:32:39 -0700
Message-ID: <>
To: Carsten Bormann <>
Cc: Core <>,
Content-Type: multipart/alternative; boundary="000000000000c3810d0575a0e3c4"
Archived-At: <>
Subject: Re: [core] [Anima] documenting SID usage in IETF specification
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: Tue, 11 Sep 2018 23:32:45 -0000

On Tue, Sep 11, 2018 at 3:12 PM, Carsten Bormann <> wrote:

> On Sep 11, 2018, at 22:25, Michael Richardson <>
> wrote:
> >
> > SHOULD ietf-core-sid say something about this?
> Yes, we should have a common way of handling SID allocations in RFCs.
> draft-ietf-core-sid sounds like a natural way to place this, but what goes
> into what document is often a question of who has time to write something
> at a particular point in time.  So let’s discuss this with the authors.
> In any case, this probably should stay at the level of a suggestion more
> than prescribing a normative way of doing things — the conventions we use
> for this may evolve faster than the rest of the technical content of
> draft-ietf-core-sid.
You probably want to make a clear distinction between Internet Drafts with
volatile SID assignments
and RFCs with permanent SID assignments.

Do you want early implementation (of modules using SID)  to be as painful
as possible or as seamless as possible?
Renumbering SID assignments may be extremely disruptive to actual
Correctness of a SID file within a source document is not the same thing as
correctness of all SID files
across an entire administrative domain.

I agree the administration of SID assignments is out of scope for CORE WG
but punting
the problem to vendors or operators will not be good enough.

Grüße, Carsten


> _______________________________________________
> core mailing list