IETF Logo Mail Archive

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

Andrew Newton <andy@hxr.us> Fri, 01 July 2022 13:17 UTC

Return-Path: <andy@hxr.us>
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 59334C15A752 for <regext@ietfa.amsl.com>; Fri, 1 Jul 2022 06:17:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hxr-us.20210112.gappssmtp.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 D5o8igmP8LAb for <regext@ietfa.amsl.com>; Fri, 1 Jul 2022 06:17:16 -0700 (PDT)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C796C15A740 for <regext@ietf.org>; Fri, 1 Jul 2022 06:17:16 -0700 (PDT)
Received: by mail-vs1-xe32.google.com with SMTP id j1so2287001vsj.12 for <regext@ietf.org>; Fri, 01 Jul 2022 06:17:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HvkhYyp+PFchQJ64Q1PDQ47xFhNq6IsvLHfjPtIKFP8=; b=COD0yIVDhLhhqjtpyIQot7dUGvwOvCmWQ8HzB6nAv90O3DXd/ipZOb1+3PYWI+tmQG CAZdQ5OQYJ5HsybKb0nRCeAN4TJIC00FC7Hwl+ZObx2+eMggCSPAmGV74HPi9mFGDlRb TcpWO9L1g90g3j7urBAvMcrDd5HgbVOvulDQZam3UendEmsWe0jFjFbjjcHApjjYBoz4 VfTdhxJK9dAzIJenRu+wTTazrVbNVyyHLZDUv+TpH95fbgO9Qv4Qn4SWGIzlEHbM2gl2 52KiPeXA/lX+8QhiniArGcnofCWA1bH/lqFOL7NSrNq8FQtVef14WpprS2M4xbgnevxV M/5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=HvkhYyp+PFchQJ64Q1PDQ47xFhNq6IsvLHfjPtIKFP8=; b=IYljiM0P0DHoiwiHvU/WL0n4ZKO17jE8IyFnl3jjvi8HJ8cPwWnuzQd9WWBBrW0Mcv ODi37hGyLxDjDq/5eFcRWrut/a/XxsIrgBdEDkS3iY5z4vBhnk8HkuRDsvf4S8pvZjTr U0bDcWBQSeRqVCy7574I6XwXGJhNKbhJ/WykAu/OC57xZVBkKZ3rZwffI0UZf1p9BcCw AG92AsEL3nC+N6QlwpBRyrJ9wyI/+9LPmnanSuwgsf8rj+LpDyVmXpVLGasf+0CZU+e6 Ci/KsAqazPvsQJcViZAgTS1xtUMOvzH3l6a1ptglZ65OBvNaskPEOTRI5t4Np/AyMnwB XXwg==
X-Gm-Message-State: AJIora9w5ZUiJOsHIBZhNWWVONSUw4oJJgZD7FZrwBjRL2YzjON1AxeP g2r82BhZy90jmAqi4UxqbEE8vR8qA0w+iWXXwOtNaw==
X-Google-Smtp-Source: AGRyM1s1s/Smv5CuPfNwN189OIbq6IYbcfnE4vFCbjlM6UXuGiGUunqfQQJLahV8d+R3707WlP0JPO98GV02YTYsiwc=
X-Received: by 2002:a67:d318:0:b0:356:6fa0:b39b with SMTP id a24-20020a67d318000000b003566fa0b39bmr10150222vsj.2.1656681434788; Fri, 01 Jul 2022 06:17:14 -0700 (PDT)
MIME-Version: 1.0
References: <E20B858D-7ABA-4BF5-AF0A-A0070A6BCD61@verisign.com>
In-Reply-To: <E20B858D-7ABA-4BF5-AF0A-A0070A6BCD61@verisign.com>
From: Andrew Newton <andy@hxr.us>
Date: Fri, 01 Jul 2022 09:17:03 -0400
Message-ID: <CAAQiQRc6HJ+JcVWmJTZJhObL=gqdjxwH7UMONUYQbCV1cjfYtw@mail.gmail.com>
To: "Gould, James" <jgould=40verisign.com@dmarc.ietf.org>
Cc: "shollenbeck=40verisign.com@dmarc.ietf.org" <shollenbeck=40verisign.com@dmarc.ietf.org>, "mario.loffredo@iit.cnr.it" <mario.loffredo@iit.cnr.it>, "regext@ietf.org" <regext@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/2Z6akxVU0rktySmYH4WMC4_UYTg>
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: Fri, 01 Jul 2022 13:17:18 -0000

James,

Comments in-line...

On Mon, Jun 27, 2022 at 12:36 PM Gould, James
<jgould=40verisign.com@dmarc.ietf.org> wrote:
>
>
> The question is how we handle versioning, which is an aspect not covered in the existing RFCs.  The only version reference is in the RDAP Conformance definition in section 4.1 of RFC 9083 with "rdap_level_0" and "lunarNIC_level_0".  If the use of "lunarNIC_level_0" was a mistake, then versioning is completely absent for extensions.

In my opinion, this is not accurate. The identifier is the version. If
I understand your position correctly, you believe that the identifier
should contain a separate, embedded, syntactically-parsable version
identifier. And that is not an unreasonable position. However, what
are the benefits of having it? And what are the complications of
having it? If this sub-identifer were also an opaque identifier, then
I don't see much benefit. If it were to have semantics, then what are
those semantics?

>
> Approach A is a showstopper to me since it cascades versioning to all elements with no perceived value and with the cost of interoperability issues when the version number does change.

What do you mean by "all elements" here? Can you provide an example?

-andy

v2.23.0 | Report a Bug | By Email