Re: [eppext] RDAP adoption?

Mario Loffredo <mario.loffredo@iit.cnr.it> Wed, 11 November 2015 08:50 UTC

Return-Path: <mario.loffredo@iit.cnr.it>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661BD1A86F2 for <eppext@ietfa.amsl.com>; Wed, 11 Nov 2015 00:50:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.731
X-Spam-Level:
X-Spam-Status: No, score=-1.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 29jtWNg3T5aP for <eppext@ietfa.amsl.com>; Wed, 11 Nov 2015 00:50:07 -0800 (PST)
Received: from smtp.iit.cnr.it (mx3.iit.cnr.it [146.48.98.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2AE11A86E9 for <eppext@ietf.org>; Wed, 11 Nov 2015 00:50:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id C2D92600E64 for <eppext@ietf.org>; Wed, 11 Nov 2015 09:50:02 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mx3.iit.cnr.it
Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx3.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMXoP9VZdCTU for <eppext@ietf.org>; Wed, 11 Nov 2015 09:50:00 +0100 (CET)
Received: from [192.12.193.108] (pc-loffredo.nic.it [192.12.193.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.iit.cnr.it (Postfix) with ESMTPSA id 1A644601163 for <eppext@ietf.org>; Wed, 11 Nov 2015 09:50:00 +0100 (CET)
To: eppext@ietf.org
References: <564167D3.7050805@dcrocker.net> <56422EE7.5040007@iit.cnr.it> <62A1F9F1-08B9-45E2-8443-5748EFF3FF07@nic.br>
From: Mario Loffredo <mario.loffredo@iit.cnr.it>
Message-ID: <56430136.9090804@iit.cnr.it>
Date: Wed, 11 Nov 2015 09:49:58 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <62A1F9F1-08B9-45E2-8443-5748EFF3FF07@nic.br>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/JaiVivvGDED6U-c7nvw2xj8VA9k>
Subject: Re: [eppext] RDAP adoption?
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Nov 2015 08:50:09 -0000

Il 10/11/2015 19:01, Rubens Kuhl ha scritto:
>> I speak on behalf  of .it and it seems to me that there are some big problems we have to face in order to implement a RDAP server.
>> The first three things coming in my mind about RDAP responses are the following:
>>
>> - domain status
>>   Due to Italian regulation, we have introduced some statuses in addition to EPP standard and RGP extension statuses.
>>   At the moment, the only way to represent this statuses according to the RDAP profile is to add an unrecognized member together with a status reported in RFC7483
> It seems gTLDs are facing the same issue, and the same seems to be the same: an I-D defining those values.
>
>> - Registrar role publicIDs member
>>   The RDAP profile states that the entity with the registrar role MUST contain a publicIDs member to identify IANA Registrar ID from the IANA's Registrar ID registry.
>>   In .it, we have a lot of medium/small registrars registering only .it domains so none of them appear in the IANA Registrar ID registry.
>>   Furthermore, there are some domains managed by the registry itself (nic.it for example) or by italian public entities registrars (government, regions, and so on)
> The gTLD RDAP Profile only applies to gTLDs. ccTLDs don't have follow any of ICANN's specs in this regard;
I know it

> is there any IETF document precluding .it from using some kind of internal ID ?
No there isn't

>
>> - Registrant/admin/tech role required fields
>> According to .it regulation,  each contact cannot give the consent to publish the personal data on WHOIS.
>> Street,City and Country are part of the personal data so they might not appear in a RDAP response
>>
> Empty data might seem to solve it as well, but I wonder whether this requirement also came from gTLD profile or from a technical standard ?
No problem. I realized that these fields are required only in gTLD 
profile and can be empty in other cases.
>> Maybe these problems are common to other ccTLDs.
>> In my humble opinion, we need a discussion about the adoption of RDAP from ccTLDs in order to have, at the end, a RDAP profile for ccTLDs .
> ccTLDs are known for liking their independence, so it's really up to you to make the .it RDAP profile... but there are some commonalities in the EEE (European Economic Area) that might suggest an European ccTLD RDAP profile that could include VAT, Privacy Laws etc. Perhaps CENTR could be a venue to that development ?
>
>
This is what I really hope. At the last EPP workshop in Stockholm about 
EPP extensions all the partecipants agreed that there are two many 
extensions. So I wonder, what is the sense to have a RDAP profile for 
.it, a RDAP profile for .fr, and so on ?
Maybe, for example, the concepts causing the introduction of non 
standard domain statuses in .it are similar to other countries.
Now that we have two standards, EPP and RDAP, allowing a very high 
degree of technical interoperability, we should work to increase 
conceptual interoperability as much as possible.
At least in Centr we should start a more standardized approach to the 
issue of local differences in order to limit the number of RDAP profiles 
as well as the number of EPP extensions.

Regards,
Mario


>
>
> Rubens
>
>
> _______________________________________________
> EppExt mailing list
> EppExt@ietf.org
> https://www.ietf.org/mailman/listinfo/eppext