From nobody Mon Aug  1 07:00:08 2022
Return-Path: <marc.blanchet@viagenie.ca>
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 5BF18C15949B
 for <regext@ietfa.amsl.com>; Mon,  1 Aug 2022 07:00:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level: 
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 RCVD_IN_DNSWL_HI=-5, 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=viagenie-ca.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 Qa4PD5qDx6pK for <regext@ietfa.amsl.com>;
 Mon,  1 Aug 2022 07:00:02 -0700 (PDT)
Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com
 [IPv6:2607:f8b0:4864:20::f31])
 (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 E4B5EC15A724
 for <regext@ietf.org>; Mon,  1 Aug 2022 07:00:02 -0700 (PDT)
Received: by mail-qv1-xf31.google.com with SMTP id m10so8476348qvu.4
 for <regext@ietf.org>; Mon, 01 Aug 2022 07:00:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=viagenie-ca.20210112.gappssmtp.com; s=20210112;
 h=mime-version:subject:from:in-reply-to:date:cc
 :content-transfer-encoding:message-id:references:to;
 bh=acl4PJjQzmT59bRFkCHB0McQwUBILdfpXm8bDj5Ew2o=;
 b=BPxbarfrXXC4OpUfHF7yBfvliCxGKH7C6+ua0WnNecy2XNEI1hQxLSPv72UX3PEvD1
 SrbLVknGR6246s38fnZGs4wG0PMC59GzQBs+QIt71dxGN1SucU5m+K1kuUQ1XQdXh7m5
 v230mpTEQAd/Se1E10EzbDGoJ4K4/IlFMiU7PeYstOe2AvhKhWY9sJgYQJASbDPxlZ5/
 f3yISFlOoOzzmJzJO8UU+Eb0j+DcvIeUBfialvxCnL3MUo/qA+qh1eZ3qyGaoQuajyrk
 w1qWQkfi3SIzwMLKGtlYsN3pl6NwYoypO0mf6pDezJhzIFlqRzTqd2Duj6C0wYDeM4PO
 HDBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
 :content-transfer-encoding:message-id:references:to;
 bh=acl4PJjQzmT59bRFkCHB0McQwUBILdfpXm8bDj5Ew2o=;
 b=wEI3Hvf7fWAiBBBveBH9mecLAacIjGSUeCA6b2Cm2hLfYvrck/k9kb+FWNFLzVWTBH
 fL/lw9UjMgOKxZW3pJa9/+PnA3GUrN1CDmG6PphUR8aTCCVwg9LJG5Zqikj4lTFYCB8B
 slyNiiMTUuov0EkDVPzxwH2WktNkc0VAZA1OEoca5+N7FnpwIZ08n6Lq/eG6+GAgMEgW
 xNDXpzEeo7kPj76Sk9oSh/RGPz2FQ4mt4h8xACxvPLzcWVJT3qKDHItmewvIwgk2XLUY
 9dNtqBQ7R9Vq6k03/g2jUmF0A8l2hGj//a+U4PUyjKSuj/kf2Fj5pyuVMq832etmOBCp
 Pv7w==
X-Gm-Message-State: ACgBeo1LpCvw3o/NqCuk25W1rBRy97zZMTJfsCCczIox7f/v0itOu5TH
 infdhMsv82F9HRqVO8LlHezh67Y0jmPOQly7
X-Google-Smtp-Source: AA6agR4PQ1lDwggIT9uVLneVLbKM+o3/z8B3m4WJ/fDaYdiCk1l/cosw4fX2vejlwQJzp6Duv+x0nQ==
X-Received: by 2002:a05:6214:c2b:b0:476:813a:b173 with SMTP id
 a11-20020a0562140c2b00b00476813ab173mr5042013qvd.31.1659362401584; 
 Mon, 01 Aug 2022 07:00:01 -0700 (PDT)
Received: from smtpclient.apple (modemcable161.124-162-184.mc.videotron.ca.
 [184.162.124.161]) by smtp.gmail.com with ESMTPSA id
 i18-20020a05620a249200b006b5fc79427fsm8918567qkn.77.2022.08.01.07.00.00
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 01 Aug 2022 07:00:00 -0700 (PDT)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Marc Blanchet <marc.blanchet@viagenie.ca>
In-Reply-To: <6F2A5598-FED5-4099-AAF2-2843435CDCDF@elistx.com>
Date: Mon, 1 Aug 2022 09:59:59 -0400
Cc: REGEXT WG <regext@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A62073C9-2F71-45E4-8EC5-1102B018ED47@viagenie.ca>
References: <6F2A5598-FED5-4099-AAF2-2843435CDCDF@elistx.com>
To: James Galvin <galvin@elistx.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/0jRUJk-7VvwqjFGLzn3SfPjC-XI>
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: Mon, 01 Aug 2022 14:00:07 -0000



> Le 1 ao=C3=BBt 2022 =C3=A0 09:49, James Galvin <galvin@elistx.com> a =
=C3=A9crit :
>=20
> 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.
>=20
> 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.
>=20
> 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 =E2=80=9C+1=E2=80=9D or =
explaining any objection you have.
>=20
> This CONSENSUS CALL will close in two weeks on 15 August 2022 at close =
of business everywhere.
>=20
> This proposal had consensus during the IETF114 meeting and is =
summarized as follows.
>=20
> 1. Given that both RFC7480 and RFC9083 are Internet Standards, the bar =
for changes is quite high.
>=20
> 2. There is a generally accepted consensus for how rdapConformance is =
to be used and it is widely deployed today.
>=20
> 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.
>=20
> 4. The proposal has two parts as follows:
>=20
> A. Accept that the RDAP protocol and RDAP Extensions Registry do not =
directly support versioning of extensions and that both support unique =
extension identifiers.
>=20
> B. Submit Errata to the appropriate RFC in STD95 to harmonize the =
example usage of the extension identifiers =E2=80=9ClunarNIC=E2=80=9D =
and =E2=80=9ClunarNIC_level_0=E2=80=9D to improve clarity on the =
uniqueness of identifiers.


Works for me.

Marc.

>=20
> For additional details working group members are referred to the =
slides used by the Chairs during the discussion and recording of the =
meeting:
>=20
> SLIDES: =
https://datatracker.ietf.org/doc/slides-114-regext-rdap-extension-identifi=
er-and-rdapconformance/
>=20
> RECORDING: https://www.meetecho.com/ietf114/recordings#REGEXT
>=20
> Thanks,
>=20
> Antoin and Jim
>=20
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

