Re: [regext] Re-chartering REGEXT?

Marc Blanchet <marc.blanchet@viagenie.ca> Tue, 16 April 2024 15:13 UTC

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 D20B5C14F69B for <regext@ietfa.amsl.com>; Tue, 16 Apr 2024 08:13:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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=viagenie-ca.20230601.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 JBtKaRSO1SWZ for <regext@ietfa.amsl.com>; Tue, 16 Apr 2024 08:13:05 -0700 (PDT)
Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (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 81634C14F619 for <regext@ietf.org>; Tue, 16 Apr 2024 08:13:05 -0700 (PDT)
Received: by mail-qv1-xf30.google.com with SMTP id 6a1803df08f44-69b9365e584so13782486d6.1 for <regext@ietf.org>; Tue, 16 Apr 2024 08:13:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viagenie-ca.20230601.gappssmtp.com; s=20230601; t=1713280384; x=1713885184; darn=ietf.org; h=message-id:in-reply-to:to:references:date:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=CBcrFaoa/8b0CEUwTTPExPywJYlS0fFk22OucwfazV0=; b=OCO5D2bhZQQcxVMo8dMXlQBszAwbKKcMK8z6fjo2bcXS85TMazMkhD/KjyS0+Lu0MB U3zZ4l1z01p9XUy4VdVY20l0whAEH5rTwaurLUJ7yhHc/7huRF+fN5vOBYr6QK1oBonA 97OM1tuXCIAoi7089X6tQOnL3TKbv6WkbkzjLerguUKmzfgJJ1hOomU4obmKmg1lpyQK UrlbGjdTwMZa5vCxSdMSSjxjnJmZqGJyjFIxra/jmXhVLLBw82QI33WE3ztky+Tdl9T/ /YMTerQpVhwVh04eIaOdzUxdPNDPW8qjlYr0yoyMTb1V22vfhhN258P2QU933+Rb+lso SBRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713280384; x=1713885184; h=message-id:in-reply-to:to:references:date:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CBcrFaoa/8b0CEUwTTPExPywJYlS0fFk22OucwfazV0=; b=Kt19PMVT/QOuVLBQHcjvB8te6FdeNPRpDPVu7SfKYLqkPh1VFEtXU5ZcBwia15NQsy S//cSNGm+M0jgisLXyhFaw9mHvy835oSc/eDi83DkFP4gCb/26ARP/o+BEOJ9tG6hW+n YO46LL5Ye41Bw0bKm6xc5UmuYsNDMa0LctnmWUKMnEV0jYeADU5GCFsltL7gJQqDonig ME6iixmxiyn0t5G3JNE2cAEueiJ8ZDP930gkwS5pvQ9VJignFUN5mtCrMuuOFQw7C3tO CCdoLQkf5OZi5cXyu69dz18K/FDrSz0+HHe/TdfXCGXe6BBVcA9aAL6dq/sWfKVtSGHb 4M+w==
X-Gm-Message-State: AOJu0YzhdgSvv+ORSz51T2b5w3E5HOzA8o5DJjE+uimGG6B/P49bRQvp qL/j7FhVDlGP0JiGQeY0/OEK9quxcs0TPG23TuIdHzA3A2VcksL8jI9NbhHJj8xp64JlwNLPq7g nvPUyB4EEaT4ce9Yodb9l9+imnAALRfBoqXaOm/6nfr/o6WGqLyULP/aQ1tvELsGlAUpOSbwoXq O3CsVeIGYQ4BBBHld7T4t/58/9W+1LL+r8RDo=
X-Google-Smtp-Source: AGHT+IEJ4WkjpSwz9hEvyy96ZEfPC3DHHLgMcToTl2koQAFywF6hItPDOyCinFBdtvkoEJwx4n6uKA==
X-Received: by 2002:a05:6214:20c:b0:69f:74f7:a96a with SMTP id i12-20020a056214020c00b0069f74f7a96amr2351993qvt.11.1713280384169; Tue, 16 Apr 2024 08:13:04 -0700 (PDT)
Received: from smtpclient.apple (modemcable108.66-162-184.mc.videotron.ca. [184.162.66.108]) by smtp.gmail.com with ESMTPSA id q8-20020a05621410e800b0069b20891f0dsm7482130qvt.30.2024.04.16.08.13.03 for <regext@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Apr 2024 08:13:03 -0700 (PDT)
From: Marc Blanchet <marc.blanchet@viagenie.ca>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
Date: Tue, 16 Apr 2024 11:12:52 -0400
References: <50556621-BBB1-41D8-A167-96508F5FF0C6@sidn.nl> <CAAQiQRezKGVaSdqb9nRKhw3Jdd+0R=Tikhe0hQgsq8vMcGGTgQ@mail.gmail.com> <92D7BA88-CC1C-4A5E-9407-BCAE029FAFA3@verisign.com> <CAKr6gn1H2fDcwyWN4L-_hOQY9O2biBwD07udQ=VHpAg4F1J2mQ@mail.gmail.com> <7d11998d3bb3485f977275aa66263610@verisign.com>
To: Registration Protocols Extensions <regext@ietf.org>
In-Reply-To: <7d11998d3bb3485f977275aa66263610@verisign.com>
Message-Id: <79420B05-25C3-467A-BFB5-8DFA18751C20@viagenie.ca>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/dOXBr1kmyO-wPleiLefHYvwAgXQ>
Subject: Re: [regext] Re-chartering REGEXT?
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, 16 Apr 2024 15:13:09 -0000

It appears to me that we are putting the carriage before the horse in this discussion. I would suggest to write a milestone like “a RESTy EPP” but not too much details to leave room for what it will finally be, and leave the discussion on how it is implemented,  how much it is really an EPP transport or not, to the wg mailing list, meetings, and documents.

Regards, Marc.

> Le 16 avr. 2024 à 11:02, Hollenbeck, Scott <shollenbeck=40verisign.com@dmarc.ietf.org> a écrit :
> 
> I think there's a basic question to be answered first: what's the goal?
> 
> If the answer is "a RESTful API for EPP", it might be possible to do that within the confines of the existing charter if it can be done without changing any of the existing core EPP RFCs. There's an old axiom about the IETF not standardizing APIs, but we've already done RDAP. Maybe this is similar.
> 
> If the answer is "specify a web service that's EPP-ish", I agree that rechartering is probably necessary.
> 
> Scott
> 
>> -----Original Message-----
>> From: regext <regext-bounces@ietf.org> On Behalf Of George Michaelson
>> Sent: Monday, April 15, 2024 7:15 PM
>> To: regext@ietf.org
>> Subject: [EXTERNAL] Re: [regext] Re-chartering REGEXT?
>> 
>> 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.
>> 
>> I don't think the new protocol is just a new transport *LAYER* but I also do
>> support re-charter to include consideration of this protocol suite.
>> 
>> My reasoning is that we're the people who are going to wind up having to talk
>> about it. Of course it's irritating from a perspective of RDAP and EPP
>> proponents to see more work jammed into this WG and I actually generally
>> dislike charter extension, but the context is clear:
>> 
>> The protocol is in the registry-registrar and client-registrar interaction space we
>> work on.
>> 
>> G
>> 
>> On Tue, Apr 16, 2024 at 3:37 AM Gould, James
>> <jgould=40verisign.com@dmarc.ietf.org> wrote:
>>> 
>>> Andy,
>>> 
>>> REPP is not a transport, but a new provisioning protocol that is not
>> supported in the existing charter.  If you believe REPP is a transport, please
>> describe how it complies with section 2.1 of RFC 5730.
>>> 
>>> Thanks,
>>> 
>>> --
>>> 
>>> JG
>>> 
>>> 
>>> 
>>> James Gould
>>> Fellow Engineer
>>> jgould@Verisign.com
>>> <applewebdata://13890C55-AAE8-4BF3-A6CE-
>> B4BA42740803/jgould@Verisign.c
>>> om>
>>> 
>>> 703-948-3271
>>> 12061 Bluemont Way
>>> Reston, VA 20190
>>> 
>>> Verisign.com
>>> <http://secure-
>> web.cisco.com/10VTAY9gOxn3SyGCbx0Iw10mjg42vKiJd9gTlNVhf
>>> 28244PWyM4jb2c-ibruKGejaYoPvmqmnSM9Z2eNTlzxMBoW7sZ23A5-
>> 6ZDa51f4CX1aG2k
>>> 
>> D89FjLRT5lrZaVa9cMZxyPuSEYmYARHamAXBNMOFMXHHnujQGPhAF2M8id
>> 1FtuOAGKUZx_
>>> 9lN0uy8-nt1j1GSUq_MDc4bXP3HycIzx_GA3O2pl8aT3qQv-
>> UMzd2TyyR6F9rxo3by0Gxd
>>> nKWY4K-F9kROR8T3Y8pcLSeN_xYzXCTdgqo-
>> ReR6LfvzIrlt1RqQuo4CdEXYRT7bpkT1Oz
>>> /http%3A%2F%2Fverisigninc.com%2F>
>>> 
>>> 
>>> 
>>> 
>>> On 4/15/24, 1:20 PM, "regext on behalf of Andrew Newton (andy)"
>> <regext-bounces@ietf.org <mailto:regext-bounces@ietf.org> on behalf of
>> andy@hxr.us <mailto:andy@hxr.us>> 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.
>>> 
>>> 
>>> Maarten,
>>> 
>>> 
>>> I think proposing some charter text is a good idea.
>>> 
>>> 
>>> And I support this if the charter is to be used to exclude some
>>> proposals for EPP transports but not others, as has been argued.
>>> 
>>> 
>>> -andy
>>> 
>>> 
>>> On Thu, Apr 11, 2024 at 11:59 PM Maarten Wullink
>>> <maarten.wullink=40sidn.nl@dmarc.ietf.org
>> <mailto:40sidn.nl@dmarc.ietf.org>> wrote:
>>>> 
>>>> Hello everyone,
>>>> 
>>>> The REGEXT WG charter seems to be limited to only allow work on EPP
>> extensions?
>>>> 
>>>> The WG preliminary consensus is that updating the charter for new
>> transports (requires RFC5730, sec 2.1 compliance) is not required.
>>>> Because a new transport is regarded as a type of extension, so for anything
>> else we would need to update the charter?
>>>> 
>>>> This means there is no defined process anywhere, currently, for EPP
>>>> related work, such as RESTful EPP (or anything else that is not a extension),
>> which according to some in this WG is not a transport but something else.
>>>> 
>>>> RESTful EPP does not require modification of the EPP RFCs, it does include
>> support for alternative data representations such as JSON.
>>>> 
>>>> The participants of this WG are the experts in this area, and the right people
>> to also work on improvements and/or enhancements of the EPP protocol and
>> new work such as RESTful EPP.
>>>> 
>>>> Therefore, I propose that we expand the charter of this WG to also include
>> the above-mentioned activities e.g. not strictly limiting the WG to extensions
>> only.
>>>> 
>>>> I’m willing to help in updating the charter if this something we agree on
>> doing.
>>>> 
>>>> Best,
>>>> 
>>>> Maarten
>>>> 
>>>> ------
>>>> ps:
>>>> 
>>>> The previous version of the charter included text, that did allow work on
>> more than extensions only:
>>>> 
>>>> “The working group may also, in consultation with its responsible
>>>> area director, take on work related to the operation of Internet
>>>> identifier registries, beyond the EPP and RDAP protocols.”
>>>> 
>>>> See:
>>>> https://secure-
>> web.cisco.com/1pZ9xY4B2hhezD1LASpYU9C9QLU_I8ijwDhrAON
>>>> iX2WujSy1_vkXH6R3dC-
>> XOs3hs8GhnjSqn4hoIrURMcauciMp2aW9yObvXrtcQfNn5y3
>>>> 
>> 9QAI_y_nrDueqrchdGrckElb2y8uY6jnSOVocfgGUy3JGWGYYRDY4eaaVGYW4p
>> 0HCiWX
>>>> l_U-V5l_hWGXcSEavgzX-crhYmdNvhH-
>> u2THur7He9dDY47ixzEm4kaOgHenXF4Mjj6X
>>>> 
>> w63FB7TA6StLsEn1cH4ZzXrkRso6sqhMOPIxW0M12SiAp3Az1rqdgYd_E/http
>> s%3A%2
>>>> F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-regext%2F01-00%2F
>>>> <https://secure-
>> web.cisco.com/1pZ9xY4B2hhezD1LASpYU9C9QLU_I8ijwDhrAO
>>>> NiX2WujSy1_vkXH6R3dC-
>> XOs3hs8GhnjSqn4hoIrURMcauciMp2aW9yObvXrtcQfNn5y
>>>> 
>> 39QAI_y_nrDueqrchdGrckElb2y8uY6jnSOVocfgGUy3JGWGYYRDY4eaaVGYW4
>> p0HCiW
>>>> Xl_U-V5l_hWGXcSEavgzX-crhYmdNvhH-
>> u2THur7He9dDY47ixzEm4kaOgHenXF4Mjj6
>>>> 
>> Xw63FB7TA6StLsEn1cH4ZzXrkRso6sqhMOPIxW0M12SiAp3Az1rqdgYd_E/htt
>> ps%3A%
>>>> 2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-regext%2F01-00%2F>
>>>> 
>>>> This was modified for the current charter, but still not very specific and may
>> allow for work on RESTful EPP?
>>>> 
>>>> "The working group may also take on work to develop specifications
>>>> that describe the following types of information exchanged between
>>>> entities involved in Internet identifier registration that are using
>>>> the RDAP or EPP protocols:
>>>> • Uniform representation formats for publishing local policy or
>>>> configuration options regarding EPP and RDAP use.
>>>> • Data formats for files exchanged between registration entities
>>>> that need insertion in or extraction from EPP or RDAP.
>>>> • Technical guidance for registration processes that are supported
>>>> by EPP or RDAP.”
>>>> 
>>>> 
>>>> _______________________________________________
>>>> regext mailing list
>>>> regext@ietf.org <mailto:regext@ietf.org>
>>>> https://secure-
>> web.cisco.com/1KvgG0690znrXWuB3hdtOx8bFSBFJMVkNZ5g8zP
>>>> 
>> MeStofdEIwM5iRQBNJUcSsE6gROXlW9ce2rNNyP9JIFNMdD3qAJa8xrA2wKLF
>> akvQ61D
>>>> 
>> RHxQLVjdwPbxzo5BV1itYp75wcGjQk4CwDA0lQI54wUygUhug3rcMp5yeQb9
>> _PLgXgM8
>>>> eklr87_hvlNWXU_-41hgJWbb4kMACk-
>> BRDzKtZHXPAUm6b27OZrVUNee4FpEbr5z2Zmh
>>>> GFmjGtaGbOFxjlmkUq5FUncipetsTP1KpPA-
>> g33rNu37yQBieczmC5kkY/https%3A%2
>>>> F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
>>>> <https://secure-
>> web.cisco.com/1KvgG0690znrXWuB3hdtOx8bFSBFJMVkNZ5g8z
>>>> 
>> PMeStofdEIwM5iRQBNJUcSsE6gROXlW9ce2rNNyP9JIFNMdD3qAJa8xrA2wKL
>> FakvQ61
>>>> 
>> DRHxQLVjdwPbxzo5BV1itYp75wcGjQk4CwDA0lQI54wUygUhug3rcMp5yeQb
>> 9_PLgXgM
>>>> 8eklr87_hvlNWXU_-41hgJWbb4kMACk-
>> BRDzKtZHXPAUm6b27OZrVUNee4FpEbr5z2Zm
>>>> hGFmjGtaGbOFxjlmkUq5FUncipetsTP1KpPA-
>> g33rNu37yQBieczmC5kkY/https%3A%
>>>> 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
>>> 
>>> 
>>> _______________________________________________
>>> regext mailing list
>>> regext@ietf.org <mailto:regext@ietf.org>
>>> https://secure-
>> web.cisco.com/1KvgG0690znrXWuB3hdtOx8bFSBFJMVkNZ5g8zPMe
>>> 
>> StofdEIwM5iRQBNJUcSsE6gROXlW9ce2rNNyP9JIFNMdD3qAJa8xrA2wKLFakv
>> Q61DRHxQ
>>> 
>> LVjdwPbxzo5BV1itYp75wcGjQk4CwDA0lQI54wUygUhug3rcMp5yeQb9_PLgX
>> gM8eklr87
>>> _hvlNWXU_-41hgJWbb4kMACk-
>> BRDzKtZHXPAUm6b27OZrVUNee4FpEbr5z2ZmhGFmjGtaG
>>> bOFxjlmkUq5FUncipetsTP1KpPA-
>> g33rNu37yQBieczmC5kkY/https%3A%2F%2Fwww.ie
>>> tf.org%2Fmailman%2Flistinfo%2Fregext
>>> <https://secure-
>> web.cisco.com/1KvgG0690znrXWuB3hdtOx8bFSBFJMVkNZ5g8zPM
>>> 
>> eStofdEIwM5iRQBNJUcSsE6gROXlW9ce2rNNyP9JIFNMdD3qAJa8xrA2wKLFak
>> vQ61DRHx
>>> 
>> QLVjdwPbxzo5BV1itYp75wcGjQk4CwDA0lQI54wUygUhug3rcMp5yeQb9_PL
>> gXgM8eklr8
>>> 7_hvlNWXU_-41hgJWbb4kMACk-
>> BRDzKtZHXPAUm6b27OZrVUNee4FpEbr5z2ZmhGFmjGta
>>> GbOFxjlmkUq5FUncipetsTP1KpPA-
>> g33rNu37yQBieczmC5kkY/https%3A%2F%2Fwww.i
>>> etf.org%2Fmailman%2Flistinfo%2Fregext>
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> regext mailing list
>>> regext@ietf.org
>>> https://secure-web.cisco.com/1D0Tq_GXiIN4Z2FKElYhxl8f-
>> orxRNy6qSMpHUfKK
>>> 
>> QBDULJas_XL2jaCJh8sPN4Jnvglu7_qVHK9tDK4m13QKgWqw1TfhejL4tbxhT2
>> KaR9hdAl
>>> 
>> SZK8SzRYpUJxz6e1HUj7wQqKB6Ddsk9YvBLj3ZYRpL1aooJCUOv5WRxnxbRdlG
>> R568g1hO
>>> 0GxFPH7gdfT-wVTrpiLbgcA80j163vTPg6XScic7apv2-
>> uxH6PmiHhniI0S7HOBWggvyDd
>>> 
>> ymhHEyIKjl0VBrj241hwWtsGVrrgux981psezLUf6xTDpDZxkvwNdxyrHfZN1kg
>> CA_WARX
>>> /https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
>> 
>> _______________________________________________
>> regext mailing list
>> regext@ietf.org
>> https://secure-web.cisco.com/1D0Tq_GXiIN4Z2FKElYhxl8f-
>> orxRNy6qSMpHUfKKQBDULJas_XL2jaCJh8sPN4Jnvglu7_qVHK9tDK4m13QKg
>> Wqw1TfhejL4tbxhT2KaR9hdAlSZK8SzRYpUJxz6e1HUj7wQqKB6Ddsk9YvBLj3Z
>> YRpL1aooJCUOv5WRxnxbRdlGR568g1hO0GxFPH7gdfT-
>> wVTrpiLbgcA80j163vTPg6XScic7apv2-
>> uxH6PmiHhniI0S7HOBWggvyDdymhHEyIKjl0VBrj241hwWtsGVrrgux981psezL
>> Uf6xTDpDZxkvwNdxyrHfZN1kgCA_WARX/https%3A%2F%2Fwww.ietf.org%2
>> Fmailman%2Flistinfo%2Fregext
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext