IETF Logo Mail Archive

Re: [core] Robert Wilton's Discuss on draft-ietf-core-sid-21: (with DISCUSS and COMMENT)

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 20 October 2023 15:57 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1EDC151061; Fri, 20 Oct 2023 08:57:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpAfnXaa_4Vf; Fri, 20 Oct 2023 08:57:52 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 39F69C14F5E0; Fri, 20 Oct 2023 08:57:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CE2541800D; Fri, 20 Oct 2023 11:57:49 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cxShkyMRjWau; Fri, 20 Oct 2023 11:57:49 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 343881800C; Fri, 20 Oct 2023 11:57:49 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1697817469; bh=VIguZHktsvy2/8+K6ONVzqgzzMbMVv9KN5cRt96gisw=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=Ucb9vpOd5sQJDqslYrOXxNq61SaCZxcrTLcA5zR+KIvf2sCyUYVWt9sTZrOMfYofu McPquHH45l3J+QGzZntbqVcwPfao/Hy73HD/l2VKhqTzZ9spWIONIRA8gyMuJK/r6i WNazXbz2FS392yfYn8B/FQ0HTHRtaHwN01gjvz3vs7qSuiYS5NyjTMrDm+guvGRWne GJJtYx0FU8C4PqzyNMDIJmOqNG4mWE7rk/lRjh94bq64CU9c/HjWoA0kbzbNG+j3sB vjoj8HuCvsSUdYzil03h6f2yHkpDWJRg/kKkdQm0JU9n08DKxxD2qJb9e5gVEtRGG6 2o/16hicx8JZA==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2FBC648; Fri, 20 Oct 2023 11:57:49 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Robert Wilton <rwilton@cisco.com>
cc: The IESG <iesg@ietf.org>, draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, core@ietf.org
In-Reply-To: <169771413973.18245.13961801523377715904@ietfa.amsl.com>
References: <169771413973.18245.13961801523377715904@ietfa.amsl.com>
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: Fri, 20 Oct 2023 11:57:49 -0400
Message-ID: <17278.1697817469@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/v3gOS_6xRY4RByHgMp7J1Gm_edc>
Subject: Re: [core] Robert Wilton's Discuss on draft-ietf-core-sid-21: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Oct 2023 15:57:56 -0000

Thank you for persisting through this Rob!

Robert Wilton via Datatracker <noreply@ietf.org> wrote:
    > related aspects for creating/managing SID files in drafts that I want
    > to ensure
    > that the IESG is at very least aware of and happy with.

    > (1) p 23, sec 6.4.3.  Publication of the ".sid" file

    > For a YANG module approved for publication as an RFC, a ".sid" file
    > SHOULD be included in the Internet-Draft as a source code block.

    > I'm wondering if this is really the best approach.  I.e., I think to
    > guarantee
    > that the SID file is correct at the point of pulication (e.g., if names
    > of YANG

For the first year or two, with a new YANG module I strongly think that the
authors need to review the resulting sid file (the allocations) to be sure
that they are correct.

Yes, of course, IANA or RPC SHOULD double check.
It is here that we might run into bugs in pyang that the RPC will need
support on, and this is why I keep poking the Tools team about pyang
maintenance.

I also want to push back on the idea that SIDs are just for constrained
environments: we have heard from Andy that every byte counts in bigger
networks, and that comparing uin63s is gonna be way faster than XML string
compares.


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email