IETF Logo Mail Archive

Re: [core] Murray Kucherawy's No Objection on draft-ietf-core-sid-22: (with COMMENT)

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 26 October 2023 17:54 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 02FB0C14CE52; Thu, 26 Oct 2023 10:54:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 IwoPTfdGcqA8; Thu, 26 Oct 2023 10:54:32 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [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 ietfa.amsl.com (Postfix) with ESMTPS id 57735C14CE31; Thu, 26 Oct 2023 10:54:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 069C11800F; Thu, 26 Oct 2023 13:54:30 -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 GJu0E94xdFWH; Thu, 26 Oct 2023 13:54:28 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6C7491800C; Thu, 26 Oct 2023 13:54:28 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1698342868; bh=zyDvbo2kzHIowOP11kT09xPMndNgRvuc8sRfTNEK/bw=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=uDr7rZWdiGwVqslUA3Jtk8RfD+np6zUsn9XON3WvB1oIIWMzjIE/qMi9PizFgDqQ9 mN3k3LqLsMCb63LOqUKVRV0EJrfAWYWqzdpl7BTfYLqHp2IUOFAXkm6QO1K7By5PK2 7aWHVFEF4CYcLUbXpg4IbiWOSSxbirbnTUJFRQzWTqzZDLo5r7KaEp0qetV7Msd10X UhicEO4igFNM2STw+bHSb9J8IeU9sKk+lWUTkjU84UOXspfZrbmIEnMj9pjdzk8CkS VcPTPoFOdNBuYYRfFzIrOQyUqmjAA0dhXNiPPwfVLiQSQl7pw0DWT0Tk28878X1NaC BJzDv78w6xuaA==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6733F157; Thu, 26 Oct 2023 13:54:28 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Murray Kucherawy <superuser@gmail.com>
cc: The IESG <iesg@ietf.org>, draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, core@ietf.org
In-Reply-To: <169830425849.60370.8571387158946572818@ietfa.amsl.com>
References: <169830425849.60370.8571387158946572818@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: Thu, 26 Oct 2023 13:54:28 -0400
Message-ID: <21335.1698342868@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/71PUDGGCJtZivhWNKNe3F2fg1cM>
Subject: Re: [core] Murray Kucherawy's No Objection on draft-ietf-core-sid-22: (with 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: Thu, 26 Oct 2023 17:54:37 -0000

Murray Kucherawy via Datatracker <noreply@ietf.org> wrote:
    > * In 6.3.1, why is "policy of SID range" considered part of "contact
    > information"?

This is for Mega-Ranges, that we/IANA would delegate to other SDOs.
We (visitors to iana.org) need to know to whom that SDO will give out
SID numbers.   Some SDOs might give them out to anyone with a document
related to them, while others might insist that queries only come from
internal requestors.
Cisco could ask for a Mega-Range for all of their private YANG modules.
vs IEEE could ask a Mega-Range for all the ethernet YANG modules.

    > * Also in 6.3.2, how do you imagine the designated expert evaluating "technical
    > capacity" to operate a registry?  I note that Robert raised a similar concern.

It's pretty subjective, I agree.
I'd look at a few things involving web/database clue which they host
themselves?  Or is it hosted WP with a ten year old template full of bugs?
Are the technical people funded to do this work?

    > * Sections 6.4 and 6.5 create registries that are going to be complicated for
    > the Designated Expert to work, and for the DE to present to the IESG proof that
    > the process was followed if asked.  I have to trust that all this complexity is
    > necessary.

I'm not sure how we could simplify it.
It doesn't seem that hard to me.
This text grew from reviews.
I see your point that it might be difficult from the DE to assemble the right
evidence if they haven't been thinking about filing that stuff ahead of time.

> * In 6.5.1, by "link", do you mean a URI?

Yes.


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