Re: [regext] rfc7484bis

Rubens Kuhl <rubensk@nic.br> Mon, 17 August 2020 02:08 UTC

Return-Path: <rubensk@nic.br>
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 BEC603A12E3 for <regext@ietfa.amsl.com>; Sun, 16 Aug 2020 19:08:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 BZ8eN-0ohHyp for <regext@ietfa.amsl.com>; Sun, 16 Aug 2020 19:08:19 -0700 (PDT)
Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E6C3A12E2 for <regext@ietf.org>; Sun, 16 Aug 2020 19:08:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.nic.br (Postfix) with ESMTP id 3FA311DEC39 for <regext@ietf.org>; Sun, 16 Aug 2020 23:08:15 -0300 (-03)
X-Virus-Scanned: Debian amavisd-new at mail.nic.br
Received: from mail.nic.br ([127.0.0.1]) by localhost (mail.nic.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YV2IVDhVan2p for <regext@ietf.org>; Sun, 16 Aug 2020 23:08:12 -0300 (-03)
Received: from [192.168.15.10] (unknown [189.110.245.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rubensk@nic.br) by mail.nic.br (Postfix) with ESMTPSA id 4CB821DDF19 for <regext@ietf.org>; Sun, 16 Aug 2020 23:08:12 -0300 (-03)
From: Rubens Kuhl <rubensk@nic.br>
Content-Type: multipart/signed; boundary="Apple-Mail=_27449F47-DB60-4321-A1E2-AF971FE565FF"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Sun, 16 Aug 2020 23:08:10 -0300
References: <801B9484-0F94-4CB4-ABBC-AAC495361E80@centralnic.com> <00ae8cca-fc44-4279-b6f7-3f57d86474b1@www.fastmail.com> <61B05C2B-C1BD-469C-A77F-E68377446C30@viagenie.ca> <72a9bb42-3eb9-43fe-862f-32c1faadab75@www.fastmail.com>
To: regext@ietf.org
In-Reply-To: <72a9bb42-3eb9-43fe-862f-32c1faadab75@www.fastmail.com>
Message-Id: <9A8AB262-714E-456B-A52F-3E827437995E@nic.br>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
DMARC-Filter: OpenDMARC Filter v1.3.1 mail.nic.br 4CB821DDF19
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/61YeAXeqse9YlGRUkRUsVCDBo8M>
Subject: Re: [regext] rfc7484bis
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
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, 17 Aug 2020 02:08:23 -0000


> On 11 Aug 2020, at 16:27, Patrick Mevzek <pm@dotandco.com> wrote:
> 
> Hello Marc,
> 
> On Tue, Aug 11, 2020, at 13:55, Marc Blanchet wrote:
>> On 4 Aug 2020, at 15:47, Patrick Mevzek wrote:
>>> 
>>> PS: related but not directly, at least for domain registries, it would
>>> be
>>> nice to have an `SRV` record on `_rdap._tcp` or something to point to
>>> relevant
>>> RDAP server, even if that does not allow to encode the path (but maybe
>>> a solution with .well-known/ and URI template could be found), it
>>> allows at least
>>> for nice failover and load balancing. It may be a problem for gTLDs as
>>> they have
>>> restrictions in content of their zone.
>> 
>> well, this has been debated at length during the WEIRDS working group
>> work. I actually wrote a sentence about this in the RFC (in the
>> acknowledgements section). I’m not sure we want to restart the debate
>> again…
> 
> I am not saying to restart the debate, especially not in the context of a -bis document where protocol changes are not welcome.
> 
> But the RFCs are also 5 years old now and a lot of things change quickly.
> SVCB record in the DNS being one, while not there already.
> 
>>> Maybe the newly expected SCVB record could help...
>>> 
>>> A setup like that would allow for discoverability without
>>> centralization of data,
>>> which also removes IANA from the hot operational path when RDAP
>>> clients do queries.
>> 
>> yes. this is the well-known caveat of this RFC and discussed and debated
>> during WEIRDS. But experience up to now has not shown any issue, at
>> least to my knowledge. (and as a developer of the RDAP Browser mobile
>> app, I haven’t seen any issue fetching that registry. I do have found
>> thousands of issues with the registry/registrars RDAP servers however,
>> but that is another story).
> 
> I am not saying there is a current issue, fetching the JSON file from IANA
> webserver is clearly the smallest problem of any RDAP client.
> 
> But I also think there is currently no issue because basically the world did
> not shift to RDAP in any way yet. Which can easily be witnessed by the amount
> of broken servers so far - even if they are in a regulated space where compliance
> is an issue - and the total lack of ccTLDs in this space, at least in operations.

Of the 822 https:// URLs in https://data.iana.org/rdap/dns.json <https://data.iana.org/rdap/dns.json> , and 0 http:// URLs, there are some for ccTLDs:
.ar
.br
.ca
.cr
.cz
.id
.is
.no
.tz


So, I believe we could remove http:// as a transport option, and that there is no total lack of ccTLDs. Surely there could be more.


Rubens