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

Jasdip Singh <jasdips@arin.net> Wed, 15 June 2022 18:41 UTC

Return-Path: <jasdips@arin.net>
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 D9B01C14F730 for <regext@ietfa.amsl.com>; Wed, 15 Jun 2022 11:41:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 YjiHYJu0TV70 for <regext@ietfa.amsl.com>; Wed, 15 Jun 2022 11:41:00 -0700 (PDT)
Received: from smtp4.arin.net (smtp4.arin.net [IPv6:2001:500:4:201::54]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD685C15AAC5 for <regext@ietf.org>; Wed, 15 Jun 2022 11:39:35 -0700 (PDT)
Received: from CAS02CHA.corp.arin.net (cas02cha.corp.arin.net [10.1.30.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp4.arin.net (Postfix) with ESMTPS id A7CA310757B2; Wed, 15 Jun 2022 14:39:33 -0400 (EDT)
Received: from CAS01CHA.corp.arin.net (10.1.30.62) by CAS02CHA.corp.arin.net (10.1.30.63) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 15 Jun 2022 14:39:33 -0400
Received: from CAS01CHA.corp.arin.net ([fe80::99af:898b:219f:401]) by CAS01CHA.corp.arin.net ([fe80::99af:898b:219f:401%17]) with mapi id 15.00.1497.000; Wed, 15 Jun 2022 14:39:33 -0400
From: Jasdip Singh <jasdips@arin.net>
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>, "jgould=40verisign.com@dmarc.ietf.org" <jgould=40verisign.com@dmarc.ietf.org>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)
Thread-Index: AQHYgOdAb7Ky5AtiCEK1PR2tE1CCfw==
Date: Wed, 15 Jun 2022 18:39:32 +0000
Message-ID: <BE15864A-B5EC-407F-B769-E1D85F6F1623@arin.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.136.136.37]
Content-Type: text/plain; charset="utf-8"
Content-ID: <BA42A8D6F8AF5F45BF2062C0003D7E02@corp.arin.net>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/2SZzyaOQJDETL9Bhf6ZEvbYZ5IQ>
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:41:04 -0000

Hi.

Agree with Scott that we first fix the errata per the original intent of the authors, in order to have the STD 95 docs in a clearer state for the current approach (approach A).

Once that's out of the way, we can discuss the merits of the current approach (approach A) versus the 2 newly proposed one (approaches B and C).

Jasdip

On 6/15/22, 2:23 PM, "Hollenbeck, Scott" <shollenbeck@verisign.com> wrote:

    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
    >