[gtld-tech] Whois advisory feedback meeting @IETF91

Gould, James JGould at verisign.com
Tue Nov 25 21:11:36 UTC 2014


Greg,

My feedback is embedded below.


—


JG


[cid:77031CC3-BE7A-4188-A95F-D23115A30A4D at vcorp.ad.vrsn.com]

James Gould
Distinguished Engineer
jgould at Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://VerisignInc.com>

On Nov 25, 2014, at 11:06 AM, Greg Aaron <greg at illumintel.com<mailto:greg at illumintel.com>> wrote:

Question #8: It is permissible for the registry contracts or the RAA to specify fields that are mandatory above and beyond those in the EPP specification.  The EPP spec is a baseline as far as data fields, and allows registries (or in this case ICANN) to have policy authority and make fields such as Street #1 mandatory.  The 2013 RAA requires that registrars collect, validate, and provision street and phone info … so I don’t see how there’s any open question for discussion here.   Besides, I can’t see how ICANN could ever allowed registrations that do not include a street address or phone number – it would make WHOIS accuracy efforts impossible.


Yes, contracts can and do define fields that are mandatory that are not mandatory in EPP.  The key is which contract is referenced here, Registrar or Registry.  In the case that we’re talking about, the phone and street is mandatory according to the Registrar Agreement (RAA) but not in the Registry Agreement.  The registries are not required to validate that the Registrars do pass a phone and street for every contact, so the Registry WHOIS itself is not required to display those fields.  Simply stating that the RAA makes a field required for the Registrar does not flow through to the Registry and the Registry WHOIS.


Question #9 might be addressed in the registry contract.  Does Spec 4 paragraph 1.3 allow the association of two Admin contacts to one domain,  for example?

Paragraph 1.3 of Specification 4 of the Registry Agreement, states “For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed”.  In the case of multiple contacts of a given type (e.g. Admin), there are a set of fields with a different set of keys (“Admin ID”, “Admin Name”, etc.), so Paragraph 1.3 does not cover it.


Question #10: go back to the Applicant Guidebook Question 26, and also look at contract Spec 4 paragraph 1.10.    It is the Searchable WHOIS service that allows wildcarding.  The registry contract says that registries are not required to offer searchable WHOIS; those who want to can offer it.    The contract also says that if it is offered, Searchable WHOIS must be provided on the Web-based WHOIS service ONLY, not on port 43 (see Spec 3 paragraph 1.10.1).   If ICANN is stating that port 43 output must return only one record at a time, that seems to be in keeping with the contract and is an FYI clarification, not a new requirement.


You can’t imply an anti-requirement in one service based on a requirement of a different service.  The existing port 43 WHOIS servers of some of the registries that participated in the meeting support partial match of the object handles (domain name, host name) to display a list of matching records instead of a single record when more than one matches.  This has been the behavior for a long time, so the clarification inadvertently is removing functionality that equates to a new requirement.  If the intent of the clarifications is to not define new requirements, then this item should be removed.  For example, do the following command line whois queries against the .COM, .NET WHOIS servers for EXAMPLE.COM<http://EXAMPLE.COM>:

$ whois EXAMPLE.COM<http://EXAMPLE.COM>

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

EXAMPLE.COM.AU
EXAMPLE.COM.FLORAMEIYUKWONG.COM<http://EXAMPLE.COM.FLORAMEIYUKWONG.COM>
EXAMPLE.COM.RAFAELYALUFF.COM<http://EXAMPLE.COM.RAFAELYALUFF.COM>
EXAMPLE.COM<http://EXAMPLE.COM>
...

Now, to return the record information, =“xxx” can be used:

$ whois ="EXAMPLE.COM<http://EXAMPLE.COM>"

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

   Server Name: EXAMPLE.COM<http://EXAMPLE.COM>.AU
   Registrar: ENETICA PTY LTD
   Whois Server: whois.enetica.com.au<http://whois.enetica.com.au>
   Referral URL: http://www.enetica.com.au

   Server Name: EXAMPLE.COM.FLORAMEIYUKWONG.COM<http://EXAMPLE.COM.FLORAMEIYUKWONG.COM>
   IP Address: 173.203.204.123
   Registrar: GODADDY.COM<http://GODADDY.COM>, LLC
   Whois Server: whois.godaddy.com<http://whois.godaddy.com>
   Referral URL: http://registrar.godaddy.com

   Server Name: EXAMPLE.COM.RAFAELYALUFF.COM<http://EXAMPLE.COM.RAFAELYALUFF.COM>
   IP Address: 173.203.204.123
   Registrar: DOMAIN.COM<http://DOMAIN.COM>, LLC
   Whois Server: whois.domain.com<http://whois.domain.com>
   Referral URL: http://www.domain.com

   Domain Name: EXAMPLE.COM<http://EXAMPLE.COM>
   Registrar: RESERVED-INTERNET ASSIGNED NUMBERS AUTHORITY
   Whois Server: whois.iana.org<http://whois.iana.org>
   Referral URL: http://res-dom.iana.org
   Name Server: A.IANA-SERVERS.NET<http://A.IANA-SERVERS.NET>
   Name Server: B.IANA-SERVERS.NET<http://B.IANA-SERVERS.NET>
   Status: clientDeleteProhibited
   Status: clientTransferProhibited
   Status: clientUpdateProhibited
   Updated Date: 14-aug-2014
   Creation Date: 14-aug-1995
   Expiration Date: 13-aug-2015
...

Other WHOIS servers function in a similar fashion, so is the intent of the clarification to change this behavior and if so should it?



All best,
--Greg


From: gtld-tech-bounces at icann.org<mailto:gtld-tech-bounces at icann.org> [mailto:gtld-tech-bounces at icann.org] On Behalf Of Gould, James
Sent: Tuesday, November 25, 2014 8:49 AM
To: Gustavo Lozano
Cc: gtld-tech at icann.org<mailto:gtld-tech at icann.org>
Subject: Re: [gtld-tech] Whois advisory feedback meeting @IETF91

* PGP - S/MIME Signed by an unverified key: 11/25/2014 at 8:49:12 AM
Gustavo,

Below are the notes that I took from the meeting.  Hopefully others have additional notes to add or update to these.

  1.  Gustavo started the meeting by defining the purpose of the WHOIS Clarifications in clarifying items in Specification 4 of the New gTLD Registry Agreement and the 2013 Registrar Accreditation Agreement (RAA), based on questions posted to ICANN.  The goal was to not create new requirements.
  2.  Gustavo described changes between Version 1 and 2 of the WHOIS Clarifications.
  3.  Gustavo stated that new fields require the use of an RSEP.
  4.  The new target date for enforcing the WHOIS Clarifications is March 31, 2015 instead of February 12, 2015.  ICANN asked whether there is a more reasonable date and the feedback was “as late as possible”.

     *   There was the recommendation to enable registries to test the PDT testing validation ahead of enforcing it.

  1.  Question - Can we wait for RDAP?  RDAP will take time and we cannot wait.
  2.  Question - Why return non-existent fields using a key and empty value?

     *   To stay in line with Specification 4 of the Registry Agreement
     *   It was brought up that there is a mix of including non-existent fields and also support for optional fields.
     *   Excluding non-existent fields could also support Specification 4 of the Registry Agreement, since Specification 4 of the Registry Agreement did not include any empty fields.
     *   Action Item - ICANN to bring the feedback back for internal discussion and provide a response to the gtld-tech list.

  1.  Question - Why is the contact name optional, since it’s required in EPP?

     *   ICANN believed that it was either name or organization, but that is not the case.
     *   Action Item - ICANN took note of this to address.  The recommendation is update it to “Registrant/Admin/Tech[/Billing] Name and Organization - Name is required and Organization is optional"

  1.  Question - Why is the contact phone and contact street required?

     *   Contact phone and street is a required field in the RAA.
     *   Contact phone and street is not required in EPP and is not required for the registries, so therefore it should not be required in the Registry WHOIS.  Cascading a Registrar requirement in the RAA that is not a Registry or EPP requirement through to a Registry WHOIS requirement must not be done.
     *   Action Item - ICANN took note of this to address.

  1.  Question - How to handle multiple contacts of the same type (Admin, Tech, Billing)

     *   Specification 4 of the Registry Agreement only supports a single contact per type, so the Registry must select only one to display.

  1.  Question - Why include the requirement that WHOIS queries for domain name data MUST return only one record per WHOIS query?

     *   Multiple registries support wildcard queries in WHOIS, where if more than one object (domain or host) matches the query name ( with or without TLD ), a list of matching names is returned instead of a single record.  This is a useful feature that would need to be removed based on the Clarifications requirement.  As earlier stated, the goal of the Clarifications was to not create new requirements.
     *   Action Item - ICANN took note of this to address.

Can ICANN respond with a status and update on the action items?

Thanks,

—


JG

<image001.png>

James Gould
Distinguished Engineer
jgould at Verisign.com<x-msg://107/jgould@Verisign.com>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://verisigninc.com/>

On Nov 14, 2014, at 3:41 PM, Gustavo Lozano <gustavo.lozano at icann.org<mailto:gustavo.lozano at icann.org>> wrote:


Hello Colleagues,

Attached the slides that I used during this meeting.

Please note that some of the clarifications / updates presented in the slides may change based on the feedback obtained during the meeting.

Regards,
Gustavo

From: Gustavo Lozano <gustavo.lozano at icann.org<mailto:gustavo.lozano at icann.org>>
Date: Thursday, November 13, 2014 at 10:07
To: "gtld-tech at icann.org<mailto:gtld-tech at icann.org>" <gtld-tech at icann.org<mailto:gtld-tech at icann.org>>
Subject: Re: Whois advisory feedback meeting @IETF91

Hello Colleagues,

The room has enough capacity for all of you interested in assisting physically based on the emails that I received.

Adobe Connect will be used for remote participation. Please log into https://icann.adobeconnect.com/tech-services at the time of the meeting (http://www.timeanddate.com/worldclock/converted.html?iso=20141113T15&p1=103&p2=1440).

The dial-in bridge will not be available, we will use Adobe Connect for audio. If possible, please use a headset for remote participation.

Regards,
Gustavo

From: Gustavo Lozano <gustavo.lozano at icann.org<mailto:gustavo.lozano at icann.org>>
Date: Tuesday, November 11, 2014 at 10:42
To: <gtld-tech at icann.org<mailto:gtld-tech at icann.org>>
Subject: Whois advisory feedback meeting @IETF91

Hello Colleagues,

If you are at the IETF91, an informal meeting to get feedback about the Whois advisory published by ICANN (i.e.
 https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014-09-12-en), will take place at Tapa Tower - Iolani 3 on Thursday (15.00 to 16.30 local time).

Please send me a email if you are planing to assist in order to validate that the capacity of the room is sufficient.

Regards,
Gustavo
ICAN
<whois_advisory.pdf>

* Gould, James <JGould at verisign.com<mailto:JGould at verisign.com>>
* Issuer: Symantec Corporation - Unverified

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20141125/7e5e84fe/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png
Type: image/png
Size: 4109 bytes
Desc: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20141125/7e5e84fe/BF09FAA4-32D8-46E0-BED0-CD72F43BD6E081-0001.png>


More information about the gtld-tech mailing list