[ispcp] proposal to mitigate name-collision risks -- ISPs will do the heavy lifting

[Mike O'Connor]

hi all,

ICANN has just posted a proposal to mitigate the "name collision" problem.  their proposal creates unfunded customer-service obligations for ISPs worldwide.  i've attached ICANN's proposal to this note.  i've excerpted some of the interesting pieces within the text of this note.  

ISPs will be on the front lines of this process, since we are in many cases the only organizations that know which customer is using a given IP address.  so if a Registry detects name-collision traffic on their newly-delegated gTLD, they will have to send these notifications to ISPs who will in turn have to reach out to their customers.

my immediate question is "who funds all this?"  who provides the educational material, the mitigation techniques, the trouble-shooting when things go wrong?  who bears the liability if the repair-efforts cause harm to ISP customers?  who puts together the global outreach effort to let ISPs know that this is coming?  

i think we need to start thinking *hard* about this, and offer our thoughts during this public-comment period.  

mikey


here's what's supposed to happen in the "low-risk" namespaces (proposed to be 80% of applied-for gTLDs):

...once a TLD is first delegated within the public DNS root to name servers designated by the registry operator, the registry operator will not activate any names under the TLD in the DNS for a period of no less than 30 days. During this 30-day period, the registry operator will notify the point of contacts of the IP addresses that issue DNS requests for an un-delegated TLD or names under it. The minimum set of requirements for the notification is described in Appendix A of this paper. This measure will help mitigate the namespace collision issues in general. Note that both no-activate-name periods can overlap.

The TLD name servers may see DNS queries for an un-delegated name from recursive resolvers – for example, a resolver operated by a subscriber’s ISP or hosting provider, a resolver operated by or for a private (e.g., corporate) network, or a global public name resolution service. These queries will not include the IP address of the original requesting host, i.e., the source IP address that will be visible to the TLD is the source address of the recursive resolver. In the event that the TLD operator sees a request for a non-delegated name, it must request the assistance of these recursive resolver operators in the notification process as described in Appendix A.

APPENDIX A – NOTIFICATION REQUIREMENTS

Registry operator will notify the point of contact of each IP address block that issue any type of DNS requests (the Requestors) for names under the TLD or its apex. The point of contact(s) will be derived from the respective Regional Internet Registry (RIR) database. Registry operator will offer customer support for the Requestors or their clients (origin of the queries) in, at least, the same languages and mechanisms the registry plans to offer customer support for registry services. Registry operator will avoid sending unnecessary duplicate notifications (e.g. one notification per point of contact).

The notification should be sent, at least, over email and must include, at least the following elements: 1) the TLD string; 2) why the IP address holder is receiving this email; 3) the potential problems the Requestor or its clients could encounter (e.g., those described in section 6 of the Study report); 4) the date when the gTLD signed the registry agreement with ICANN, and the date of gTLD delegation; 5) when the domain names under the gTLD will first become active in DNS; 6) multiple points of contact (e.g. email address, phone number) should people have questions; 7) will be in English and may be in other languages the point of contact is presumed to know; 8) ask the Requestors to pass the notification to their clients in case the Requestors are not the origin of the queries, e.g., if they are providers of DNS resolution services; 9) a sample of timestamps of DNS request in UTC to help identify the origin of queries; 10) email digitally signed with valid S/MIME certificate from well- known public CA.




PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ispcp/attachments/20130807/175fb093/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-gtld-collision-mitigation-05aug13-en.pdf
Type: application/pdf
Size: 169463 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ispcp/attachments/20130807/175fb093/new-gtld-collision-mitigation-05aug13-en.pdf>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ispcp/attachments/20130807/175fb093/attachment-0001.html>