Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)

"Hollenbeck, Scott" <shollenbeck@verisign.com> Wed, 15 June 2022 18:23 UTC

Return-Path: <shollenbeck@verisign.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08B8C14CF0E for <regext@ietfa.amsl.com>; Wed, 15 Jun 2022 11:23:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 xyZkHjhlmWpo for <regext@ietfa.amsl.com>; Wed, 15 Jun 2022 11:23:41 -0700 (PDT)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CADAC14F72A for <regext@ietf.org>; Wed, 15 Jun 2022 11:23:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=6080; q=dns/txt; s=VRSN; t=1655317421; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=znN7w6zTArEgnFxkut3ZzdJF/g/HmLwVgfMAOkn64hw=; b=AeZHCEGwgBunqDsz1FHhxjtrZxzJTHCNqiN05yyQv6uP5FLfAmc9vZzB V7qwGXWldzVeuOeb/fhQuseVsrDhQbQib9n5K8x/YiGta+kUgTPVjBbpG 7Nn38G2+4RO7dKiUiCXpIHI4ZmQ3be39yLkHTWe0WSUDmk5mMjzzYxVWq r2RjDgjORhN+vjjHrYwCGu2IPFZW6z8s1iYtK6Uuzy8Bs8zO2vGhuvIXw KJCFG9YYsMYoQgN6zIzJ7xckHNsy5rXNibQdMlvj1bG/XI91tKnP6KzfZ GPRoskXKqdlR1av3RP3cWS7MYweJUlNLvU5w5pHq9A3CIEye9s/S9pDNq g==;
IronPort-Data: A9a23:NTmP2q8RE39rLUq791bTDrUD7X+TJUtcMsCJ2f8bNWPcYEJGY0x3z jQeW22COviOYDb2eN8kO4+w9E9Qv5XcxoNmTlBorCkxFiIbosf7XtnIdU2Y0wF+jCHgZBk+s 5hBMImowOQcFCK0SsKFa+C5xZVEOCXhqoPUUIYoAAgoLeNfYHpn2EsLd9IR2NYy24DnWl7V4 7senuWEULOb828sWo4rw//bwP9flKyaVOQw5wFWiVhj5TcyplFNZH4tDfjZw0jQG+G4KtWHq 9Prl9lVyEuCpktwVYn1+lrMWhZirrb6ZWBig1IIA/Ty2kAqSiYais7XP9JEAatbZqngc3mcB 7yhuLTpITrFMJEgl8wEeCFRCBxTYZRL9ZWaLnuB8urJwlTJJi6EL/VGVCnaPKUywMAuPkdjx aRBbi4GaQqbweu6hqyhUe8qjcMmRCXpFNpH/Cg/lneAUK1gHcCrr6bivLe02B8rhsdKGfvYb ccSahJxYQ7BeBxAPBEcD5dWcOKA3yWgImwD+Q/9Sawf/TbfzyFz3//Wc4DRYeKUaeFOtF2Xn zeTl4j+KlRAXDCF8hKH/XWxguOawXvlVZgTD7y38Lhhh1i7ymkaEhZQVFanr7++kEHWc9BWM EAV4jEGpLIz8gqtQ8WVdwe1r3OUojYdVsZeVeog52mwJrH86RyfX3cCQy4ZMZk9qtVwQD0xk 1WO2dnzA2UprqeOTzSW8bL8QS6OBBX55FQqPUcsJTbpKfG6yG3vpnojlupeLZM=
IronPort-HdrOrdr: A9a23:687GaqFeT2Ac4PfxpLqEw8eALOsnbusQ8zAXPhhKOHlom7+j5q STdZMgpGTJYVcqKQkdcL+7WZVoLUm3yXcx2/hyAV7AZnidhILLFuFfBOLZqlWKJ8S9zJ8/6U 4KScRD4ajLY2SS+vyU3ODXKbsdKZK8gceVbK/lvhFQpC9RGthd0zs=
X-IronPort-AV: E=Sophos;i="5.91,302,1647302400"; d="scan'208";a="14799395"
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.24; Wed, 15 Jun 2022 14:23:39 -0400
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([10.173.153.49]) by BRN1WNEX02.vcorp.ad.vrsn.com ([10.173.153.49]) with mapi id 15.01.2375.024; Wed, 15 Jun 2022 14:23:39 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "jgould=40verisign.com@dmarc.ietf.org" <jgould=40verisign.com@dmarc.ietf.org>, "jasdips@arin.net" <jasdips@arin.net>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)
Thread-Index: AQHYgOGO4zykjhWlxEe4nUUkQGwkXq1QxLBQ
Date: Wed, 15 Jun 2022 18:23:39 +0000
Message-ID: <7be74f81a0044bdb9ef1bfa176a1fee0@verisign.com>
References: <4556087E-70F9-49C4-904A-1716061A99C4@verisign.com>
In-Reply-To: <4556087E-70F9-49C4-904A-1716061A99C4@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/AmKIbwfiHG9K16s4_9nkEzGQCEI>
Subject: Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jun 2022 18:23:45 -0000

Jim, I didn't say that "lunarNIC_level_0" isn't supported. What I *am* saying is that both authors of the document agree that the existing text contains an editorial error that should be fixed such that the two sections of 9083 are consistent. We could just as easily change all instances of "lunarNIC" to "lunarNIC_level_0". That is the simplest path forward that doesn't require changing the original intention of the text. With the editorial error corrected we can decide if something else needs to be done to clarify how extensions are identified.

Don't forget that the WG did, in fact, reach consensus on the existing text when we went through the process to publish it as a Standard. "come to consensus on the desired extension registry approach or approaches" implies more significant changes to the existing text that can't be addressed with errata.  If that's what the WG wants to do, fine, but we'd better make our mind up about that sooner rather than later.

Scott

> -----Original Message-----
> From: Gould, James <jgould=40verisign.com@dmarc.ietf.org>
> Sent: Wednesday, June 15, 2022 1:59 PM
> To: Hollenbeck, Scott <shollenbeck@verisign.com>; jasdips@arin.net;
> regext@ietf.org
> Subject: [EXTERNAL] Re: Re: [regext] OK, What Next? (was RDAP Extensions
> Approach Analysis v2)
>
> Caution: This email originated from outside the organization. Do not click links
> or open attachments unless you recognize the sender and know the content
> is safe.
>
> Scott,
>
> I believe the first step is to come to consensus on the desired extension
> registry approach or approaches.  I personally like the use of
> "lunarNIC_level_0" in the rdapConformance to ensure that versioning of the
> specification is fully supported.  Approach B could be used to allow for the
> registered prefix "lunarNIC" to support the versioned rdapConformance
> value of "lunarNIC_level_0".  Approach C decouples the prefixes from the
> identifier, so both the prefixes and the versioned identifier would be
> registered.  Updating "lunarNIC_level_0" to "lunarNIC" in RFC 9083 doesn't
> address the versioning issue.
>
> --
>
> JG
>
>
>
> James Gould
> Fellow Engineer
> jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-
> B4BA42740803/jgould@Verisign.com>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://secure-web.cisco.com/1Vo_prxoZlgMn8n-
> d5tRNZLs8IMVwvIdRLWAsc8s3x5kUlfPvUAfGG1R9VSZZNwwpUgsNKglJCpiDP
> eFwBSZBKI4YSrEii3FEBUQowZ7sug1iltQCyWun0NzZ3J2Pc5cpHefSd6Rsyxb_od
> LmFg4jwJvB3kGsuwS_jHfZ3B2gS6K-OggLd3TEZVliRULU1rLr9-
> 6T9WbPHS2B3HnX6HNavcu67j9491BURhFuYYYd8bvMlMFUrQ5GURBZwxvue
> _-c/http%3A%2F%2Fverisigninc.com%2F>
>
> On 6/15/22, 1:27 PM, "regext on behalf of Hollenbeck, Scott" <regext-
> bounces@ietf.org on behalf of shollenbeck=40verisign.com@dmarc.ietf.org>
> wrote:
>
>     Thanks for doing all this work, Jasdip. Now we have to decide what to do
> with
>     all of this information.
>
>     As a first step, I think we need to submit errata to address issues with the
>     existing RFC(s). RFC 9083 uses both "lunarNIC" and "lunarNIC_level_0".  At
> a
>     minimum, Andy and I agree that "lunarNIC_level_0" should be replaced
> with
>     "lunarNIC".
>
>     Rationale: Section 2.1 of RFC 9083 describes "lunarNIC" as an example of an
>     identifying prefix and includes examples of this value being used as an
>     extension prefix. Section 4.1 says "For example, if the fictional Registry of
>     the Moon wants to signify that their JSON responses are conformant with
> their
>     registered extensions, the string used might be "lunarNIC_level_0". We
> believe
>     that 4.1 and 2.1 are inconsistent and that they can be made consistent by
>     changing "lunarNIC_level_0" with "lunarNIC" in 4.1.
>
>     Additional errata may be needed. If so, where, and what else needs to be
> done?
>
>     Scott
>     _______________________________________________
>     regext mailing list
>     regext@ietf.org
>     https://secure-web.cisco.com/1YfJ-
> 5LkVa3_5e2919NGv3HEyQy1AoEJ85v6gRz0tFZA0RXar6_Be-
> zQoFAL0wMeZscZWEZJviAtI80kqxbdAVGXbuyEWNIIHNvaf4rRa-
> WfawQjzoVSkJsMFmkxcrbEHSLKsRFsj63qrJ8fTXUta2zy5yiiuXzsiQAmJFxKCiJu
> dRDLfaCI_02bRNSDyvOwEWBccERhzp9KGqZgjvPpQrbcCOauHRjWfg-
> ipxnTEVxEhOAE-
> djs02lBSoMdQN6nJ/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%
> 2Fregext
>