IETF Logo Mail Archive

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

"Gould, James" <jgould@verisign.com> Wed, 15 June 2022 17:58 UTC

Return-Path: <jgould@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 4A3ABC15790C for <regext@ietfa.amsl.com>; Wed, 15 Jun 2022 10:58:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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_BLOCKED=0.001, 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=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 iGFN4e_JC-bC for <regext@ietfa.amsl.com>; Wed, 15 Jun 2022 10:58:48 -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 DB6A7C14CF08 for <regext@ietf.org>; Wed, 15 Jun 2022 10:58:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=3432; q=dns/txt; s=VRSN; t=1655315928; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Sof48oMx0h3qc6VluHWZshq/H4DuMTX6IYDM3cYpQ1w=; b=hTY2JbAoD/yiqZGHiDh/DBunqHNDRA+pD+aSu+LLKrWXO4GEcc8WDS3D vYmv68tCg1Vd41JbhPNTwCNTt5yN6YbubvFh0lMegxQnoXXs/BWo79Bre zlTvoz3rrJ8AMtN+Kw7ayjK2f+rOCFGsb/gAbSbsTMCgeqRpPo+hFB+kO ASfaoUYA+IvrVHn6z+RYbNtrKqvKSyfsMRmvu8FR/S1K3oLXRc8pCkt93 QJqniXUbTw4UBa5CrXrxFze9apYMEZqE3W/F1/oDpHjhU9HgOYDsfOe58 yuCSU6j+r0shY4vpjTMnSr1X5zaq6OdWNmhOKcQyO5pSEhFv9u4TYx2fn Q==;
IronPort-Data: A9a23:iqmdJ6DWlWLIqxVW/0Tiw5YqxClBgxIJ4kV8jS/XYbTApD1x1zMGz mYbDTyEbK6OZGOnKY1/aorl/BlTu8eGmINlTANkpHpgcSlH+JHPbTi7wuUcHAvJd5GeExg3h yk6QoOdRCzhZiaE/n9BClVlxJVF/fngqoDUUYYoAQgsA149IMsdoUg7wbRh3Nc12YLR7z6l4 rseneWOYDdJ5BYpagr424rbwP+4lK2v0N+wlgVWicFj5DcypVFMZH4sDfjZw0/Df2VhNrXSq 9Drl+jlozyDr3/BPfv++lrzWhVirrf6Y1DS2iIOM0SoqkAqSicais7XOBeAAKv+Zvrgc91Zk b1wWZKMpQgBLozGs94BYzpkTywkPqN82YDbYmGTmJnGp6HGWyOEL/RGJnsQZLI+19YvWCdQ/ vsCMHYEYladnfmwhrm8T4GAhOx6dI+yY9hZ4yw7i22JZRolacmrr6Hi59BfwTM8rt5DB/fFZ sUfLzFoaXwsZjUWZghGWMJhwo9EgFHFaSV78QPO/JY0yHjS0yJq+bL3FOHKL4niqcJ92xzwS nj913/5BRUeOdqVxDGGpy70mOLVnDj6V4RUH7q93vJviUeYgG0eFBNQUkG0ydG7g1WyWspEA 0UO+yxoq6UunGSxQ9bwTwGQoXOYsFgbQdU4LgEhwAuXzPPL5QuJXjFBVSBbLtknr4o8Qnogz FnQ2c3zHjopu7qQIZ6AyoqpQfqJEXB9BQc/ieUsFGPpP/GLTFkPsy/y
IronPort-HdrOrdr: A9a23:8lktNq9uMPc/xe3tdUJuk+AFI+orL9Y04lQ7vn2ZLiYlF/Bw9v re/sjzuiWVtN98Yh8dcLO7V5VoKEm0naKdirNhXotKMjOGhEKYaK9v6of4yyDtFmnU5odmuZ tIQuxbBMfrBVZ3yeT38GCDeeoI8Z2i/LqzjenTi01xSxpnApsM0y5iBh2FHlZNSA5KOJo8GP OnjfZ6mw==
X-IronPort-AV: E=Sophos;i="5.91,302,1647302400"; d="scan'208";a="14798876"
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) 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 13:58:45 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) by BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) with mapi id 15.01.2375.024; Wed, 15 Jun 2022 13:58:45 -0400
From: "Gould, James" <jgould@verisign.com>
To: "shollenbeck=40verisign.com@dmarc.ietf.org" <shollenbeck=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: AQHYgOGO4zykjhWlxEe4nUUkQGwkXg==
Date: Wed, 15 Jun 2022 17:58:45 +0000
Message-ID: <4556087E-70F9-49C4-904A-1716061A99C4@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.59.22031300
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <34A0161F66CF594991955A91C9F335D8@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/chjTqVqL8iZzKwQDQsD125Umgi8>
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 17:58:52 -0000

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://verisigninc.com/>

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-WfawQjzoVSkJsMFmkxcrbEHSLKsRFsj63qrJ8fTXUta2zy5yiiuXzsiQAmJFxKCiJudRDLfaCI_02bRNSDyvOwEWBccERhzp9KGqZgjvPpQrbcCOauHRjWfg-ipxnTEVxEhOAE-djs02lBSoMdQN6nJ/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

v2.23.0 | Report a Bug | By Email