Re: [regext] CONSENSUS CALL: discussion regarding rdapConformance

"Kowalik, Pawel" <> Wed, 03 August 2022 20:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 901CEC14F74E for <>; Wed, 3 Aug 2022 13:07:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.106
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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EGiiVcEVq66p for <>; Wed, 3 Aug 2022 13:07:12 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 19982C14F730 for <>; Wed, 3 Aug 2022 13:07:10 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 4LyjYz5NTjz9sct; Wed, 3 Aug 2022 22:07:03 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=MBO0001; t=1659557223; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Pw0oBNGw0Et3GXzfD3wKf51GdJbFrDBgq+vmluX9Uqo=; b=I5Arct98sC63XJCtUUsAJGWGLjcMxJmQcYtQe3C2txZydEMTdGUpRHd6f3Qhi7jz/OxK1S 4mOoQfARqEInr+CS1TMIHSKMSIx3tOpjNSN5Wmd8ZKr/FTkMvxYOdsWvViIm6lE7JzCBxB ePK+xzPIgPwI0SF5z7GSPwxLJ+IFbfBW0u6ULxnnul1wDDjQqNzELKC0XHm+UejpuDKbPv lHA6fMkMJWyxOJJOWfS2DbDcJILyoG/iKACOVIY+Hf0rt9YjiKR1EoEApem0MPd9HsdKN4 2Oq8g57gEtyhVYOv+lVX0qWXQ4fHCMPVfaWt3Z5is8mwT1hFAqYxW3Kq7YEBYg==
X-Header: Open-Xchange USM Mailer (USM Version: 7.10.6-3, EAS Version: 7.10.6-3, Build a2a9aab90a381dc42c41d4027a81f55809971437)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
From: "Kowalik, Pawel" <>
Mime-Version: 1.0
Date: Wed, 03 Aug 2022 22:07:02 +0200
Message-ID: <1724010220.9863.1659557222988@localhost>
References: <>
In-Reply-To: <>
To: James Galvin <>
X-MBO-RS-ID: b4bbd356d7e7b967a7e
X-MBO-RS-META: okxod49g781m4ptef7dssxo5abthbjm9
Archived-At: <>
X-Mailman-Approved-At: Mon, 08 Aug 2022 06:07:37 -0700
Subject: Re: [regext] CONSENSUS CALL: discussion regarding rdapConformance
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Aug 2022 20:16:20 -0000


Kind regards
Pawel Kowalik 

> Am 01.08.2022 um 15:49 schrieb James Galvin <>:
> 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:
> Thanks,
> Antoin and Jim
> _______________________________________________
> regext mailing list