Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT)

Benjamin Kaduk <> Thu, 15 July 2021 04:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DB953A1AE2; Wed, 14 Jul 2021 21:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MFIB732u93Gv; Wed, 14 Jul 2021 21:29:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A98F23A1ADE; Wed, 14 Jul 2021 21:29:05 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 16F4Svl0013842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Jul 2021 00:29:03 -0400
Date: Wed, 14 Jul 2021 21:28:56 -0700
From: Benjamin Kaduk <>
To: Michael Richardson <>
Cc:, The IESG <>,,
Message-ID: <>
References: <> <219605.1626281575@dooku> <> <5344.1626291161@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5344.1626291161@localhost>
Archived-At: <>
Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT)
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: Thu, 15 Jul 2021 04:29:07 -0000

On Wed, Jul 14, 2021 at 03:32:41PM -0400, Michael Richardson wrote:
> {again, not an author of this document}

(thanks for the reminder!)

> Benjamin Kaduk <> wrote:
>     >> (I don't think we have resolved the question of how/if/when we provide the sid
>     >> file to IANA when part of another RFC. In theory, IANA creates the sid file
>     >> when the YANG module is first provided. In practice, we need it for interop
>     >> work prior to WGLC)
>     > (Also an interesting question, but probably not something that needs to be
>     > enshrined in the RFC.)
> Someone has to document some interaction with IANA.
> I guess draft-ietf-anima-constrained-voucher, close to WGLC, will show us
> whether we got things right or not :-)
> {insert curse about living in interesting times}
> ...
>     >> Conceptually, SID files could be processed by unconstrained target
>     >> systems such as network management systems.  Such systems need to take
>     >> extra care to make sure that they are only processing SID files from the
>     >> same authoritative source as the YANG modules that they are using.
>     > This topic also seems worth covering, so thanks for including it.
>     > It's not entirely clear to me that it's a security requirement to use the
>     > exact same source for YANG module and SID files or some other trustworthy
>     > authority might be acceptable, so we might want to think about this some
>     > more.
> I'm just trying to say: if you trusted IANA for the .yang, then trust them
> for .sid.  If your source of truth was IEEE, then get the .sid from them too.

And I'm saying that doing that is clearly safe and a defensible course of
action.  There may also be other safe courses of action, though, so I don't
want to commit us to "need to use the same source for YANG modules and SID
files" without having it be a considered decision.