IETF Logo Mail Archive

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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Mon, 18 July 2022 19:36 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 ADB97C1595E6 for <regext@ietfa.amsl.com>; Mon, 18 Jul 2022 12:36:18 -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=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 CygGkDEZwIZ7 for <regext@ietfa.amsl.com>; Mon, 18 Jul 2022 12:36:14 -0700 (PDT)
Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.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 EB43DC14CF0C for <regext@ietf.org>; Mon, 18 Jul 2022 12:36:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2152; q=dns/txt; s=VRSN; t=1658172974; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dv20/vf3Hc2/GFMdmuSJHvL/2XoyjVyukjN9Vpa63dU=; b=TgsFiCpCq4VAR1e6zJxaz+waxDGyxxm8YRrgk2GqCtBhUka4JDG5Zyte mR5wIG1L0R0SMMuevHjUTiJ5I6FecXamxUBQun8Sh1n1QxV/zJrkcZlGc FpCnSSvy79Vzq83fWTkh0f06lmqjWalLvNHRLYnbq8jCaHWgOgQuHMXE1 w6/W0QiTJDA7XygGoJ2mca7PAk+AJrOMOtSka3fSasJx7duRsigUeo1Jq xb3Sgy5zDWN3vrZpL+WV2h4hmb4O2u3hP5ee8zxCUR0aAsoYxZyaQOGLt gPjUqkzPe4obEXWy5cK1oHwxhJuwiGdFp+b08/F/Y84J5G4n2r8CR4NkK A==;
IronPort-Data: A9a23:k5VPJKo0N6j+Br8LjngS6IlfKQVeBmJjZBIvgKrLsJaIsI4StFCzt garIBmAPq3fZGvze4sibty29k0Cv5WEytVqT1Ft+X9hRC4b8pacVYWSI3mrMnLJJKUvbq7FA +Y2MYCccZ9uHhcwgj/3b9ANeFEljfngqoIRjIcoAwgpLeNeYH5JZSlLxqho2OaEvfDjW1nX4 Yyr85WGULOY82Uc3lw8uvrrRCxH4ayaVAMw5jTSstgS4TcyP1FMZH4uDfnZw0nQG+G4LcbjL wr394xVy0uCl/sbIoj8zuukKB1iron6ZmBiglIOM0SrqkYa+nxqis7XPtJEAatco23hc9ycV LyhHHF/IOskFvSkpQgTb/VXOwBBBZVKyLPlHUSUsNOWk2HfWVu10cw7WSnaPaVAkgp2KUt00 6UnDh09NkrFmemx2qr9Q+UqmN44Ko/gO4Z3VnNIlGmfVKl9B8meGOOWtLe03x9p7ixKNe3eY M4dZDxlYR/DSwNCIFYMCZ042uyvgxETdhUB9Q/O9fNvugA/yiR4+bzEKfjwYeCvTMsFuWPBj FLFoH7AV0Ry2Nu3jGDtHmiXru3Amj7/VNdOTKO17P9xgVKVgGcUDTUaUFKhqr+4h1KwHdVFJ CQ8/yM0rK908EulQMPwUxqQoX+Y+BUaQZxRD4US4QeB24LU8xzfG3NsZiRMZ9E2qOc3SCAkk FiTkLvU6SdHuqeTEG2b+6fM93apJzJTKG4ZICUDCwEf5YClvpsoiFTESdML/LOJs+AZ0ArYm 1iixBXSTZ1K5SLX/81XJWz6vg8=
IronPort-HdrOrdr: A9a23:fgCy4aiNpTAjy7U4SfmmVOK2/HBQXgcji2hC6mlwRA09TyX+rb HKoB17726XtN9/YhEdcLy7VpVoIkmyyXcd2+B4AV7IZniEhILHFuBfxLqn7THmFzb36+JRkY xxGpITNPTASXx3l9zz7gX9MdoxqePszImYwcPT1W1kQw0vUbxn9AsRMGumO1d7XxZLHqA0E5 eg5s5KzgDKRUgq
X-IronPort-AV: E=Sophos;i="5.92,281,1650945600"; d="scan'208";a="15538101"
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.28; Mon, 18 Jul 2022 15:36:11 -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.028; Mon, 18 Jul 2022 15:36:11 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "jgould=40verisign.com@dmarc.ietf.org" <jgould=40verisign.com@dmarc.ietf.org>, "mario.loffredo@iit.cnr.it" <mario.loffredo@iit.cnr.it>, "andy@hxr.us" <andy@hxr.us>
CC: "regext@ietf.org" <regext@ietf.org>
Thread-Topic: RE: RE: RE: Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)
Thread-Index: AQHYmtHIyrThhqAtaUmvT/ndBqD/Ba2EgZCg
Date: Mon, 18 Jul 2022 19:36:11 +0000
Message-ID: <0162b5dae2ef44279d7665a68769aff8@verisign.com>
References: <DEAB137F-912F-4433-9274-102AA5D23270@verisign.com>
In-Reply-To: <DEAB137F-912F-4433-9274-102AA5D23270@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/pK22Sq-LvjPIyywYQHHB4JBPQEc>
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: Mon, 18 Jul 2022 19:36:18 -0000

> -----Original Message-----
> From: Gould, James <jgould=40verisign.com@dmarc.ietf.org>
> Sent: Monday, July 18, 2022 2:11 PM
> To: Hollenbeck, Scott <shollenbeck@verisign.com>; mario.loffredo@iit.cnr.it;
> andy@hxr.us
> Cc: regext@ietf.org
> Subject: [EXTERNAL] Re: RE: RE: RE: Re: [regext] OK, What Next? (was RDAP
> Extensions Approach Analysis v2)

[SAH] [snip]

> JG - I'm going to go back to Approach B, where there is a unique common
> prefix registered ("e.g., "foo") used by all extension elements and the
> extension's RDAP conformance values ("foo_level_0" or even pointed
> versions "foo_level_0_1").  You get the extension signaling and content
> consistency and the versioning is isolated to the RDAP conformance.  What is
> the issue with this approach?

[SAH] All I'm going to say (again) is that ANY approach that doesn't register 
an identifier with IANA and then use that same identifier as the value 
returned in the rdapConformance data structure and as the prefix for extension 
elements is inconsistent with the original intent of RFC 9083. Which gets us 
back to what *I* think we need to do:

1. Address the issue in 9083 by making the technical erratum correction I just 
repeated above, and then
2. Decide if some sort of version negotiation is a needed feature, and if it 
is, how to do it within the constraints of Standard 95.

Note (again) that we cannot use the errata process to make fundamental changes 
to 9083:

https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/

Scott

v2.23.0 | Report a Bug | By Email