[regext] Re: [Ext] Re: RESTful EPP Charter side meeting Thursday 13:00

Gavin Brown <gavin.brown@icann.org> Fri, 26 July 2024 09:41 UTC

Return-Path: <gavin.brown@icann.org>
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 F3EDAC1519AB for <regext@ietfa.amsl.com>; Fri, 26 Jul 2024 02:41:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level:
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 j_7SGBjatbMK for <regext@ietfa.amsl.com>; Fri, 26 Jul 2024 02:41:52 -0700 (PDT)
Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.77]) (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 31BB1C169404 for <regext@ietf.org>; Fri, 26 Jul 2024 02:41:52 -0700 (PDT)
Received: from MBX112-E2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.7]) by ppa2.lax.icann.org (8.18.1.2/8.18.1.2) with ESMTPS id 46Q9fnbL006261 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Jul 2024 09:41:50 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 26 Jul 2024 02:41:48 -0700
Received: from MBX112-W2-CO-1.pexch112.icann.org ([169.254.44.235]) by MBX112-W2-CO-1.pexch112.icann.org ([169.254.44.235]) with mapi id 15.02.1544.011; Fri, 26 Jul 2024 02:41:48 -0700
From: Gavin Brown <gavin.brown@icann.org>
To: George Michaelson <ggm@algebras.org>
Thread-Topic: [Ext] [regext] Re: RESTful EPP Charter side meeting Thursday 13:00
Thread-Index: AQHa3hnUpWDrBIcWrkOAuKqi8xfZGLIHFRMAgAABioCAAAcJAIAABcIAgAAHWQCAAAuQgIAAb7wAgAGTKIA=
Date: Fri, 26 Jul 2024 09:41:48 +0000
Message-ID: <A79D4776-D18B-4EB3-AB00-B686FEFEDA46@icann.org>
References: <603C6F0D-CED2-4624-8F2E-6A9F4BEB6083@sidn.nl> <CAN8C-_KWKxJ47CkL31UNPCgs0wqi6zce=j4aFPvDY4e4cnXn7g@mail.gmail.com> <CAKr6gn1FDy7NX37-G1xoFJJjw1GDmPFkhnZow-2PpWastEMyKg@mail.gmail.com> <BB28FA75-B408-40AF-A68B-1192C84DC98E@rfc1035.com> <CAKr6gn2bdRNJ3wTqSbQ3OqwHEF557WfOzHDhFSM+w0qNzGaFhA@mail.gmail.com> <4bc66e03d6654dd6bf903eaa59a460d3@verisign.com> <CAKr6gn3mkdYeiYghOnM2X5eXmM0yGC3ct=Z8SvZTkdUhuORZ7g@mail.gmail.com> <A7A61E11-A851-42FE-8D07-ADE2F1D45892@icann.org>
In-Reply-To: <A7A61E11-A851-42FE-8D07-ADE2F1D45892@icann.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.47.236]
x-source-routing-agent: True
Content-Type: text/plain; charset="us-ascii"
Content-ID: <BDFD3D95140AD248BA9DC90F58B2FC59@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-07-26_08,2024-07-25_03,2024-05-17_01
Message-ID-Hash: ITDPJRTKQSVAH4PXHIR27SXO4SZSPNKK
X-Message-ID-Hash: ITDPJRTKQSVAH4PXHIR27SXO4SZSPNKK
X-MailFrom: gavin.brown@icann.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-regext.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "Hollenbeck, Scott" <shollenbeck@verisign.com>, "regext@ietf.org" <regext@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [regext] Re: [Ext] Re: RESTful EPP Charter side meeting Thursday 13:00
List-Id: Registration Protocols Extensions Working Group <regext.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/0d1kI9nxGMkooNyJ49cBEqI4mW4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Owner: <mailto:regext-owner@ietf.org>
List-Post: <mailto:regext@ietf.org>
List-Subscribe: <mailto:regext-join@ietf.org>
List-Unsubscribe: <mailto:regext-leave@ietf.org>

<the hat drifts slightly closer>

Just to add, ICANN Org hopes to start to be more proactive in facilitating the rollout of new registry technologies moving forward, while retaining measures to address security, stability and competition issues.

We hope to be able to talk a bit more about our plans at the ICANN DNS Symposium which will be held on 25 September 2024 in Santa Marta, Colombia:

https://www.icann.org/ids

G.

> On 25 Jul 2024, at 10:38, Gavin Brown <gavin.brown@icann.org> wrote:
> 
> Hi George and Scott,
> 
> <takes hat off, but leaves it sort of floating somewhere close to the top of head>
> 
> This WG, or whichever WG ends up doing this work (if any), should not be hesitant to take on work because of ICANN. The IETF should support a much wider audience than gTLD registries and registrars. This initiative has come from the ccTLD world, and it would be unfair to those operators to make their lives difficult "because ICANN".
> 
> G.
> 
>> On 25 Jul 2024, at 03:58, George Michaelson <ggm@algebras.org> wrote:
>> 
>> I think thats wise. Well said Scott.
>> 
>> I shouldn't put words in people's mouths but back in the CRISP days
>> discussing whois replacement, I got a sense that the "whois problem"
>> excised the ICANN board and seniors quite a lot. Maybe it was down to
>> personalities, personal interests, but the idea of some consistency in
>> data management was big.
>> 
>> I am less sure modern ICANN thinks like that. I don't understand the
>> constituencies who make up "decision making" in this space. I would
>> hope the contracts don't say literally "whois on port 43" but a more
>> nuanced statement of public data which means RDAP can be grandfathered
>> in instead of some "no not like that" outcome.
>> 
>> And in like sense if it said ".. its EPP specified over <here>" then
>> we might find ourselves in a difficult place if we said "its not EPP"
>> but if we can say "EPP is now defined by ..." then we'd be on smoother
>> grounds.
>> 
>> Or not. It's ICANN.
>> 
>> I fully expect (based on what I think I've read) that some people here
>> say "its not EPP if it's not XML and SOAP" and maybe they're right.
>> But the intent is to have extensible provisioning. If the fit now is
>> for a HTTPS REST method, it's extensible, and it's for provisioning,
>> I'm more of a mind to call it EPP-ng than "not EPP"
>> 
>> -G
>> 
>> _______________________________________________
>> regext mailing list -- regext@ietf.org
>> To unsubscribe send an email to regext-leave@ietf.org
> 
> --
> Gavin Brown
> Principal Engineer, Global Domains & Strategy
> Internet Corporation for Assigned Names and Numbers (ICANN)
> 
> https://www.icann.org
> 

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org