Re: [regext] CONSENSUS CALL: discussion regarding rdapConformance

James Galvin <galvin@elistx.com> Tue, 02 August 2022 16:03 UTC

Return-Path: <galvin@elistx.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 0FA36C1BED06 for <regext@ietfa.amsl.com>; Tue, 2 Aug 2022 09:03:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=elistx-com.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 kkx0hfw6ucsO for <regext@ietfa.amsl.com>; Tue, 2 Aug 2022 09:03:00 -0700 (PDT)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 C5AC5C1BED32 for <regext@ietf.org>; Tue, 2 Aug 2022 09:03:00 -0700 (PDT)
Received: by mail-qk1-x736.google.com with SMTP id f14so10979801qkm.0 for <regext@ietf.org>; Tue, 02 Aug 2022 09:03:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=elistx-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=8jjV0tQGbwY1jQiF3vQ6rYpMWVO6LhIZVbOUCYzXJ1A=; b=fuso5pcuOJAj+OscAGJVnrpIBTzsZEiTpe5rA1KYQodPBT1InE3VwPCpUOyT803WRG 8E/iGEr5Tfy5ttypi0nciWsHkjtxPthjen3J0dXbmqPlwB6AuvzmIs7L1hDbGGNRXqLC ZoupOGcYQwZKtTLLXs1/LMf7reaUx+8M0FBUUg0JViTajFOp5XonlXM65W0DMWJiREdQ LEMdiQ2ojKEL1jee3fBOy7TDp99Is30rVocM2aVYhiVq3PNGcZEpNR53vyOHaaNUnExr m07Lrhwu/ZjTNtIjkWTK5OKnpvwrrMHs3AGDPjg092ZNrLuW6AHDHt0nemZPtww7/+cF 6peg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=8jjV0tQGbwY1jQiF3vQ6rYpMWVO6LhIZVbOUCYzXJ1A=; b=7fmMEyit+cQKwuhdgvMhh6OSwnOjssR5d1IE4FRtbD5Aj+sqK9Enalj1l1cfiR79pS wu/JXrhOH/xsMxSnB4ucEPH6frV0xYsY0MaYpXfS9Ut4OpI6uMMjBYZCAYU8pKTpf2bW EwGQG+58CundPzezZHhYrjMRWN5A0i3qJu033WVwbxOmpaADXf1Za5J/n024n49CrWGK JovUzgruDLmS+oFWun10cXud482822pFObPfX1uGDmPAc7mY4OorHA7ieOSQxF4mulmp DTyO8j+hG+z5sTUquh2ANucHZOOEDindpLAGJPSFNXK6LX9INJ6fTInAuMuP5oKm0hIP wcmQ==
X-Gm-Message-State: AJIora9sqnqGYandEMBwa9hSofhVTCz0aTbx850Ws/ZCE3OprM9PrFxU Rj6VCUrtetsnjjsGkMBbsKxyARENmvD8y0og
X-Google-Smtp-Source: AGRyM1so7VX7hW8cNs+dw42ObzRpAiXOl6xmXDErI21L3ZQDfzq79alzoOOa2VNOkdCuIgXnlR2m7w==
X-Received: by 2002:a05:620a:1727:b0:6b6:54c8:eae5 with SMTP id az39-20020a05620a172700b006b654c8eae5mr15855468qkb.160.1659456179587; Tue, 02 Aug 2022 09:02:59 -0700 (PDT)
Received: from [10.0.0.99] ([2601:154:c200:3460:1d1b:49ae:8a17:d1b1]) by smtp.googlemail.com with ESMTPSA id m5-20020a05620a290500b0069fe1dfbeffsm11458281qkp.92.2022.08.02.09.02.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Aug 2022 09:02:59 -0700 (PDT)
From: James Galvin <galvin@elistx.com>
To: "Gould, James" <jgould@verisign.com>
Cc: regext@ietf.org
Date: Tue, 02 Aug 2022 12:02:59 -0400
X-Mailer: MailMate (1.14r5853)
Message-ID: <643E79FA-3053-4673-AA0C-5B9DB009DDCC@elistx.com>
In-Reply-To: <8392B0AE-ED76-4F52-AB1C-FB5E8B7DDC51@verisign.com>
References: <8392B0AE-ED76-4F52-AB1C-FB5E8B7DDC51@verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/qy1kWYNHbOUm590lMp_dDYRYYEg>
Subject: Re: [regext] CONSENSUS CALL: discussion regarding rdapConformance
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: Tue, 02 Aug 2022 16:03:05 -0000

Speaking personally, I would agree.

Jim


On 2 Aug 2022, at 11:51, Gould, James wrote:

> Jim,
>
> For #1, I just want to ensure that " the RDAP protocol and RDAP Extensions Registry do not directly support versioning of extensions" does not prohibit the registration of versioned profile extension identifiers, since "icann_rdap_response_profile_1" and " icann_rdap_technical_implementation_guide_1" will need to be registered in the future.  The quick answer sounds to be no, so there is no risk of rejecting the inclusion of "versioning" or "visual versioning" in an extension identifier.  Is that correct?
>
> -- 
>
> 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 8/2/22, 10:12 AM, "James Galvin" <galvin@elistx.com> wrote:
>
>
>     On 2 Aug 2022, at 8:16, Gould, James wrote:
>
>     > Jim,
>     >
>     > I support the chair's proposal with two comments that I communicated at the REGEXT meeting during IETF114:
>     >
>     > 1. Registration of versioned policy (profile) identifiers will continue to be allowed in the RDAP Extensions Registry, such as "icann_rdap_response_profile_0" and " icann_rdap_technical_implementation_guide_0".
>
>     As a personal observation, I characterize this as “visual versioning”.  If you add a digit(s) to the end of a name then a user looking at it might interpret it as a version.  However, the extension registry would require each individual identifier to be registered.
>
>     On the other hand, there’s nothing that prevents an extension itself from defining for itself how it wants to support versioning.  This could get tricky but it’s all doable and allowed, if you really think you need to go in this direction.
>
>
>     > 2. There is the need to address extension versioning in the RDAP protocol in the future.
>
>     Speaking as a co-Chair, thanks for this.
>
>     Jim
>
>
>     >
>     > Thanks,
>     >
>     > --
>     >
>     > 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/1m04PmR9XEF1-za7UCKjWju29Q0X4ZlV36kgtkNy_9nrtrfCydLnDDElSTe_CiUylnFPzqFFEwm1yFvZGO0hNmhVs9jKbX_B2vRDmmgL0R-3Ssr7uj0yWSVVHl0GOhhucR_USzgvCu_qDlsJuljoobyjz7DFRUznl0CKPN6ld79cLmPkC4aZYh0-d3QRrvUy-K2MoTcm9quvVB9ky6ogN0p5XWoRarn4I0oXOyeBhZa129i76o8YRGI1U_T1CAMPk/http%3A%2F%2Fverisigninc.com%2F>
>     >
>     > On 8/1/22, 9:49 AM, "regext on behalf of James Galvin" <regext-bounces@ietf.org on behalf of galvin@elistx.com> wrote:
>     >
>     >     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.
>     >
>     >     As everyone knows there has been quite some discussion on the mailing list regarding how to implement rdapConformance.  This was a significant topic of discussion at the REGEXT meeting during IETF114.
>     >
>     >     Three options were proposed on the mailing list and unfortunately the Chairs do not believe there was a consensus on the mailing list as to how to proceed.  So, the Chairs developed a proposal for how to proceed and presented that at the IETF114 meeting.
>     >
>     >     Since all decision must be made on the mailing list, the purpose of this message is to state the proposal and ask for support or objections, similar to how we handle WGLC for documents.  Please indicate your support by replying to this message with a “+1” or explaining any objection you have.
>     >
>     >     This CONSENSUS CALL will close in two weeks on 15 August 2022 at close of business everywhere.
>     >
>     >     This proposal had consensus during the IETF114 meeting and is summarized as follows.
>     >
>     >     1. Given that both RFC7480 and RFC9083 are Internet Standards, the bar for changes is quite high.
>     >
>     >     2. There is a generally accepted consensus for how rdapConformance is to be used and it is widely deployed today.
>     >
>     >     3. Although any one of the three options could be a reasonable choice, none of them has a broad consensus sufficient to justify changing the Standard.
>     >
>     >     4. The proposal has two parts as follows:
>     >
>     >     A. Accept that the RDAP protocol and RDAP Extensions Registry do not directly support versioning of extensions and that both support unique extension identifiers.
>     >
>     >     B. Submit Errata to the appropriate RFC in STD95 to harmonize the example usage of the extension identifiers “lunarNIC” and “lunarNIC_level_0” to improve clarity on the uniqueness of identifiers.
>     >
>     >     For additional details working group members are referred to the slides used by the Chairs during the discussion and recording of the meeting:
>     >
>     >     SLIDES: https://secure-web.cisco.com/1lkpF6JHJoUQTmTLz50xTJYofDKJHZalBpkq8fBs57Fp-iIEyMfqRcvwWrL2KpWEP4CCXvsQevy-VDMepiVjghkRpAiKAH9zQPLHZaFjdwjE0R5YAzrQ2CN3Rwm5Bv1eQ_8yV47WFLmW5FVewqKZXOg6XiuD0f7YltIW8-XIkID-gXhEswQCLu7Lz73ec2KHhMdouEhINYZ51cqY21u4-5VULvCWKtn2oBVgHB_wklnye293K-f-KKoQf0yblvFoO/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fslides-114-regext-rdap-extension-identifier-and-rdapconformance%2F
>     >
>     >     RECORDING: https://secure-web.cisco.com/1Luzc6oRZhPnmff5v2BR0oDp_RV5XLdOqGaPh5FXetRm57Kd12ozJ2AkngZwdJj4tJX2WAzctukHcbF8elQ8FEFfphJNUIcGuJSINSFd6tXiNdcho375jyDIbh73pdXN5nUPLmEXV1oiOMNPeMs_0BY-hXkZizZhNYlu5qcxWBgSDh6GFOH5KjRow7YFAwb_n1IKwKW_kwO1xrhyAmlxQj9SB_4Qj6lbQpocSVKzQRJTXEPF-cqpgW9-KDDGDMogc/https%3A%2F%2Fwww.meetecho.com%2Fietf114%2Frecordings%23REGEXT
>     >
>     >     Thanks,
>     >
>     >     Antoin and Jim
>     >
>     >     _______________________________________________
>     >     regext mailing list
>     >     regext@ietf.org
>     >   https://secure-web.cisco.com/1htlQDwcCta04FTDcDRpbSyA_Yn6KqmoK-BVaOTiv9Ij6SgPdRFFdBmTodbZ87uKykaQ6aLFOvrata5DYpsXO7WcyKQnDsInJA_UITGbPyAIQ77Q6jJQJuEqJqtizIvhTVUSum-hh58yMxE8y-F183olkdUA-2q3O003lpGIK72MwcoQlos9iOpiWgK7RupM1p9nWYx69Lvmifs3YUTox99u6OyGAJaTvUmsyM9j9tfEO9g15XRiCDEugaTPYmltq/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext