[gnso-rds-pdp-wg] Instead of Less Access to Fewer Data Fields How About More Access to Newer Data Fields

Michael D. Palage michael at palage.com
Thu May 12 03:51:58 UTC 2016


Thanks for the welcome to the group. With regard to ICANN's "questions" regarding my clients RSEP I actually changed that word several times.  "Questions" was deemed the most diplomatic and G-rated response.

Yes I believe .EU and .US also include custom Whois fields.

While this client has chosen to empower the Registrant to have this data field published.  I could this on other potential clients that could see potential innovative uses in mandatory fields.  For example a .BRAND could have a field indicating where the registrant was a company owned store or a franchise.  I could see this being information that a consumer would like to know.  I could also see a generic TLD wanting to incorporate additional information into their Whois output along the lines of .US Nexus Category.  For example if I was running a restricted generic TLD based on criteria 1 thru 10.  I think it could be beneficial for a third party to understand what basis the registrant for that restricted TLD qualified. 

Perhaps I could off the following proposition. Registry Operators should be permitted to operate their TLD consistent with those laws in which they are subject. This would include collecting and publishing additional data fields in the Whois that they deemed in their best business interest. I do not believe this WG is proposing to establish any ceiling on what Registry Operators can legally collect and publish, it is merely focused on establishing the "mandatory" floor by which ALL Registry Operators must operate.  While there are some individuals that may not like a specific Registry Operators business model, the beauty of the free market system in which there are now over 1,000 gTLDs is these consumers get to vote with their wallet/purse. 

So if RightSide decided that they wanted to publish the children's names of all registrants in the Whois for their .FAMILY TLD, they should be free to do so.  While I do not know in what parallel universe where this would be an optimal/good business model, as long as the collection and publishing of this data was NOT in violation of any local/national laws I do not see why ICANN would be able to block this service/feature. I have a growing concern where ICANN is put into a position to exercise its arbitrary power as a regulator. If it is truly a "technical coordinating body" its focus should remain squarely on whether the proposed service poses a genuine security, stability or competition concern.

Looking forward to continued constructive dialog within the WG.

Best regards,


-----Original Message-----
From: Michele Neylon - Blacknight [mailto:michele at blacknight.com] 
Sent: Wednesday, May 11, 2016 6:18 PM
To: Michael D. Palage <michael at palage.com>; gnso-rds-pdp-wg at icann.org
Subject: Re: [gnso-rds-pdp-wg] Instead of Less Access to Fewer Data Fields How About More Access to Newer Data Fields


Welcome to the group.

On 11/05/2016, 22:31, "gnso-rds-pdp-wg-bounces at icann.org on behalf of Michael D. Palage" <gnso-rds-pdp-wg-bounces at icann.org on behalf of michael at palage.com> wrote:

>Hello All,
>I joined the WG a couple of weeks ago and I have been quiet as I try to 
>get up to speed.  One of the reasons that I joined this WG is a 
>Registry Client recently submitted an RSEP to ICANN seeking to add 
>additional data fields to the Whois/RDDS output.  To date four other 
>registries have been permitted to include additional data fields .NYC 
>(Nexus Contact Info) & .CAPETOWN/.JOBURG/.DURBAN (Reseller Contact Info).
>However, in the pre-evaluation ICANN raised questions about this RSEP 
>citing the "purpose" of Whois based upon the following 2006 GNSO 
>Resolution, http://gnso.icann.org/en/meetings/minutes-gnso-12apr06.html

I assume by  questions  you mean  objections ?
>The data field my Registry Client is seeking to add is not an 
>additional contact field (i.e. name, address, telephone, email, etc.).  
>It is a data new data field associated with the registrant.  The 
>registrant would be permitted per the RSEP to withhold this data from 
>the Whois/RDDS output if they like, but my Registry Client believes 
>that most registrants would want the additional data field published. I 
>view this as an innovative service and one of the reasons why the whole new gTLD program was undertaken.
>Now when you look at RFC 7485 you can see there have been a wide range 
>of additional data fields that have been included in other TLD Whois outputs.


The .ie ccTLD for example included a WIPO status field up until quite recently. They currently have a field  in-zone , and those are just two examples I found without any effort.

>In fact ICANN's Whois EWG on Page 51 thru 56 of their final report 
>specifically referenced additional fields such as SMS, Social Media 
>Primary, Social Media Secondary, etc.

I d have to dig out the report to refresh my memory on what we wrote exactly, but from memory I *think* we spoke in broad terms about possible contact points being collected as an option.

I don t think we were suggesting that they were either obligatory or that they would be available to everyone ie. published to the public.
I could be wrong ie. have a bad memory though ?

>I appreciate the strongly held beliefs of some of the participants 
>within this working group.  While I appreciate that many of these 
>battle lines are based upon historic/legacy approaches to Whois data 
>fields, I guess my hope/desire is that we do not throw out the baby 
>with bath water in connection with some innovative features that some 
>Registry Operators would like to try.

Totally agree and in the case of your client they re talking about something optional, so speaking personally I don t see any issue with it.
I think it d be a different matter if you were suggesting that a field was obligatory, but again you re speaking about a very specific TLD that probably has a very specific registration policy which might limit who can register a domain name in it.



More information about the gnso-rds-pdp-wg mailing list