Return-Path: 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 68B601200B4 for ; Fri, 14 Feb 2020 06:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=antoin.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIOCZFZESkRk for ; Fri, 14 Feb 2020 06:45:07 -0800 (PST) Received: from walhalla.antoin.nl (walhalla.antoin.nl [IPv6:2001:985:b3c0:1:e2cb:4eff:fe5e:3096]) (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 43885120041 for ; Fri, 14 Feb 2020 06:45:07 -0800 (PST) Received: by walhalla.antoin.nl (Postfix, from userid 5001) id 46D21280565; Fri, 14 Feb 2020 15:45:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=antoin.nl; s=walhalla; t=1581691505; bh=ia9A5yFHMDGmeEwaLiFBW6pzflJCHk2/JwwO7LX/xuU=; h=From:Subject:Date:References:To:In-Reply-To:From; b=LiZNdQQpis6x+DJOHwG/GhEUe7b3PG0KrGgUSE3kMCJgVeNJdscQ2euozjcUwbpyu WM2ZJEcbSt1doNlSmAm9Bx16GPIG73zmB3gsQdD2XId59y5qxcggRLc+RPfA/v2mte pDs3fk0bF1yXn0X/1P89BJt9MoZuDLyAIJYvugzk= Received: from [IPv6:2001:985:b3c0:1:3553:14ba:de4e:655a] (unknown [IPv6:2001:985:b3c0:1:3553:14ba:de4e:655a]) by walhalla.antoin.nl (Postfix) with ESMTPSA id 22D092802A2 for ; Fri, 14 Feb 2020 15:45:03 +0100 (CET) From: Antoin Verschuren Content-Type: multipart/alternative; boundary="Apple-Mail=_73D256BF-3DCE-4115-82CC-8C5B774C470B" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Fri, 14 Feb 2020 15:45:02 +0100 References: <7498F6EF-3BDD-4FEE-B30E-53BDCB3B9B8D@antoin.nl> <94998f24-4736-47f9-9da7-d0653d1f0676@www.fastmail.com> <42DBD0A4-2FAB-40F0-A3B0-EEE5F105CCDC@elistx.com> To: regext In-Reply-To: <42DBD0A4-2FAB-40F0-A3B0-EEE5F105CCDC@elistx.com> Message-Id: X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [regext] CALL FOR ADOPTION: draft-gould-casanova-regext-unhandled-namespaces X-BeenThere: regext@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Registration Protocols Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 14:45:11 -0000 --Apple-Mail=_73D256BF-3DCE-4115-82CC-8C5B774C470B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This call for adoption has ended with no objections. The chairs therefor accepted this document as a Working Group Document. For the WG: We still need a volunteer for this document to be the = document shepherd. This is an excellent opportunity to get to know the = IETF processes for new working group members, so please volunteer! No = real technical insight about this draft is needed to volunteer, so = don=E2=80=99t be shy. The only thing that you will need to do is to = verify that all comments during WGLC and IESG review are attended to = once the document reaches that state, and fill in a template about that = process. This and all other things the chairs will help you with, but we = need an independent document shepherd to state that the correct process = was followed. For the authors: Please resubmit the latest version of your draft with = the following name: draft-ietf-regext-unhandled-namespaces We have pre-approved the publication of this draft as a WG document. Regards, Jim and Antoin > Op 7 feb. 2020, om 15:59 heeft James Galvin het = volgende geschreven: >=20 > With chair hat on: >=20 > As the CALL FOR ADOPTION comes to a close, the chairs want to thank = you for your comments and let you know we=E2=80=99re leaning towards = interpreting your message as a no objection. >=20 > Would you like to clarify your position? >=20 > Thanks, >=20 > Antoin and Jim >=20 >=20 >=20 > On 28 Jan 2020, at 2:10, Patrick Mevzek wrote: >=20 >> On Fri, Jan 24, 2020, at 09:50, Antoin Verschuren wrote: >>> This is a formal adoption request for Extensible Provisioning = Protocol >>> (EPP) Unhandled Namespaces: >>> = https://datatracker.ietf.org/doc/draft-gould-casanova-regext-unhandled-nam= espaces/ >>>=20 >>> Please review this draft to see if you think it is suitable for >>> adoption by REGEXT, and comment to the list, clearly stating your = view. >>=20 >> The subject can be interesting to the working group and might warrant = an RFC >> (although registries and registrars worked for 20 years without = trouble >> in handling this case, so one might imagine it is maybe too late or >> not a big enough problem). >>=20 >> However, as discussed previously, in its current form this draft will >> introduce interoperability problems[1], so this just exchanges one = problem with another. >>=20 >> So I am mildly convinced work is required, and mildly unconvinced = that >> the draft as it stands completely address the issue. >>=20 >> [1] TL;DR: a registrar has no way to automatically discover >> a registry is using the mechanism outlined in this document, >> as not announced in the greeting part. >>=20 >> --=20 >> Patrick Mevzek >> pm@dotandco.com >>=20 >> _______________________________________________ >> regext mailing list >> regext@ietf.org >> https://www.ietf.org/mailman/listinfo/regext >=20 > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext --Apple-Mail=_73D256BF-3DCE-4115-82CC-8C5B774C470B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
This call for adoption has ended with no = objections.
The chairs therefor accepted this = document as a Working Group Document.

For the WG: We still need a volunteer = for this document to be the document shepherd. This is an excellent = opportunity to get to know the IETF processes for new working group = members, so please volunteer! No real technical insight about this draft = is needed to volunteer, so don=E2=80=99t be shy. The only thing that you = will need to do is to verify that all comments during WGLC and IESG = review are attended to once the document reaches that state, and fill in = a template about that process. This and all other things the chairs will = help you with, but we need an independent document shepherd to state = that the correct process was followed.

For the authors: Please resubmit the = latest version of your draft with the following name:
draft-ietf-regext-unhandled-namespaces
We have pre-approved the publication of this draft as a WG = document.

Regards,

Jim and Antoin





Op 7 feb. 2020, om 15:59 heeft James Galvin <galvin@elistx.com> = het volgende geschreven:

With chair hat on:

As the CALL FOR ADOPTION comes to a close, the chairs want to = thank you for your comments and let you know we=E2=80=99re leaning = towards interpreting your message as a no objection.

Would you like to clarify your position?

Thanks,

Antoin and Jim



On 28 Jan 2020, = at 2:10, Patrick Mevzek wrote:

On Fri, Jan 24, 2020, at 09:50, Antoin = Verschuren wrote:
This = is a formal adoption request for Extensible Provisioning Protocol
(EPP) Unhandled Namespaces:
https://datatracker.ietf.org/doc/draft-gould-casanova-regext-un= handled-namespaces/

Please review this = draft to see if you think it is suitable for
adoption by = REGEXT, and comment to the list, clearly stating your view.

The subject can be interesting to = the working group and might warrant an RFC
(although = registries and registrars worked for 20 years without trouble
in handling this case, so one might imagine it is maybe too = late or
not a big enough problem).

However, as discussed previously, in its current form this = draft will
introduce interoperability problems[1], so this = just exchanges one problem with another.

So = I am mildly convinced work is required, and mildly unconvinced that
the draft as it stands completely address the issue.

[1] TL;DR: a registrar has no way to = automatically discover
a registry is using the mechanism = outlined in this document,
as not announced in the = greeting part.

--
=  Patrick Mevzek
 pm@dotandco.com

_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

= --Apple-Mail=_73D256BF-3DCE-4115-82CC-8C5B774C470B--