IETF Logo Mail Archive

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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Wed, 15 June 2022 17:27 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 B10F7C14F738 for <regext@ietfa.amsl.com>; Wed, 15 Jun 2022 10:27:25 -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=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 FcAwu_z4kgIf for <regext@ietfa.amsl.com>; Wed, 15 Jun 2022 10:27:21 -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 82B90C14F730 for <regext@ietf.org>; Wed, 15 Jun 2022 10:27:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=1332; q=dns/txt; s=VRSN; t=1655314042; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=V9BLuIoybxv/ULtWOKbG1zc1u+7yY1IOzRa0NzB4p6o=; b=GSaagUGEpo5JsdN26jxPOCpLEtNik1VXmhUoXB5Ibnxq5/+4EfoMrE2M 0FinYlpGFoskr88qOx4o+jCokTb3j66ift3dmmF8mIP+yIIcuAUABxUXC sMjZK8bzxttZUkmECH4oVHGOikk8bC81USRnd2vkaFLDahPcJFxVbCn5P bECezrw0FPlhGNv98iPBqPug4CJHOuZizr7ljtKCRdW1JDMfFN/nSM7OY KeHg8xrHd97MfsxClPc9gxAbn1WvUxHpTjmN+vWUjrCctEClzOpNCwyDc wrYBzH8q9MMa2jYcQfrzVdDo3Yomzr1n6c3lF40DJPLpPtCE8hPvKDfep g==;
IronPort-Data: A9a23:TInH4a9HxF/qllk2rcB7DrUDx3+TJUtcMsCJ2f8bNWPcYEJGY0x3y jNJXWuDO/6DNDDxc913Pt+z8k4Evp6Ex4U3TQE6q3gxFiIbosf7XtnIdU2Y0wF+jCHgZBk+s 5hBMImowOQcFCK0SsKFa+C5xZVEOCXhqoPUUIYoAAgoLeNfYHpn2EsLd9IR2NYy24DnWl7V4 7senuWEULOb828sWo4rw//bwP9flKyaVOQw5wFWiVhj5TcyplFNZH4tDfjZw0jQG+G4KtWHq 9Prl9lVyEuCpktwVYn1+lrMWhZirrb6ZWBig1IIA/Ty2kAqSiYais7XP9JEAatbZqngc3mcB 7yhuLTpITrFMJEgl8wSaj1JGhpxI5ZKx7nfE0Wz7ovN9X/ZJi6EL/VGVCnaPKUywMAuPkdjx aRCbi4GaQqbweu6hqyhUe8qjcMmRCXpFNpH/Cg/lneAUK1gHcGrr6bivLe02B8rhsdKGfvYb ccSahJxYQ7BeBxAPBEcD5dWcOKA3yWgIm0D+A/9SawfylLwwwN4++HUOYDxVvuqechJxWSIj zeTl4j+KlRAXDCF8hKH+2mgh/fUtSrhWYRUErCkntZwjVKe1nA7CRAKWx28u/bRt6Klc9hFL RUL/Cc+9fJ371KxCNz8RFiypziOpBhFHcRKCOt84waIokbJ3zuk6qE/ZmYpQLQbWAUeHFTGC nfhcwvVOAFS
IronPort-HdrOrdr: A9a23:42VkoKP7G5kpf8BcThyjsMiBIKoaSvp037BN7TEVdfU1SL37qy nAppQmPHPP5gr5O0tOpTnoAsDpfZq2z+8X3WB+B9afdTijlmeuIJpr8IfuhxbxcheTysdtkY NtabJ3BtG1L1Rr5PyR3CCIV/It2sOO/qztv/rZ1HsFd2xXQrtt9Bh0ETyWFUBKRA1LbKBTKK ah
X-IronPort-AV: E=Sophos;i="5.91,302,1647302400"; d="scan'208";a="14798385"
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) 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:27:19 -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 13:27:19 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "jasdips@arin.net" <jasdips@arin.net>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: OK, What Next? (was RDAP Extensions Approach Analysis v2)
Thread-Index: AdiA3RR7otF4wPw1TSSmSp3x8+jo0A==
Date: Wed, 15 Jun 2022 17:27:19 +0000
Message-ID: <9829de8f693543abb91aa9f583472b34@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/Nt9skjmY6oAdpQPZ7SlmN58zPIA>
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:27:25 -0000

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

v2.23.0 | Report a Bug | By Email