Summary and Analysis of Public Comments

[Mark Mcfadden <mark.mcfadden@xxxxxxxxx>]

Summary and analysis of public comments for:
Zone File Access Concept Paper

13 April 2010

BACKGROUND

In one of many efforts to mitigate the potential for malicious conduct in new 
gTLDs, ICANN formed the community-led Zone File Access (ZFA) Advisory Group in 
December 2009.

For this Advisory Group, ICANN sought the participation of a diverse and 
knowledgeable set of volunteers to discuss alternatives for Zone File Access. 
The group was charged with discussing benefits and exploring methods to 
effectively and efficiently enhance access to zone file information in an 
environment with many gTLDs. The Anti-Phishing Working Group and others have 
described access to zone data as an effective tool for combating DNS abuse.

During January and February of 2010, the Advisory Group drafted a ZFA Concept 
Paper<http://www.icann.org/en/topics/new-gtlds/zfa-concept-paper-18feb10-en.pdf>
 that describes standardized forms of access to zone file information. The 
Paper, published on 22 February (see 
http://www.icann.org/en/announcements/announcement-22feb10-en.htm),  proposes 
four alternative implementation models for community consideration.

The Paper focuses on technical, operational, and administrative challenges for 
data providers and consumers in an environment with a potentially large number 
of gTLD registry zone files. Specifically, the work of the group targets 
consumer concerns relating to difficulties of accessing this important 
information in the new environment. For those combating DNS abuses, the goals 
of the program are to reduce the differences in and complexity of contractual 
agreements; standardize approaches; improve security and zone file access 
methods. Goals for gTLD registries include managing overhead related to zone 
file access and considering ways to improve service while maintaining 
administrative control over zone data.

Information about the Advisory Group and its work are located here: 
http://www.icann.org/en/topics/new-gtlds/zone-file-access-en.htm

The concept paper is located here:
http://www.icann.org/en/topics/new-gtlds/zfa-concept-paper-18feb10-en.pdf

The archived public comment forum is located here:
http://forum.icann.org/lists/zfa-concept-15feb10/

SUMMARY AND ANALYSIS

The public comment period was opened on 22 February 2010 and closed on 8 April 
2010.  A total of ten comments were submitted in the public comment process 
(one was a correction to an earlier submission).  Of these remaining nine 
comments, one came from a GNSO stakeholder group, two came from organizations, 
and six were individual submissions.

The relevant comments below are listed in the order they were submitted to the 
public comment forum.

Michael Palage expressed concerns about security: "in addressing the issues in 
the current zone file access system (Section 5) and the proposed implications 
of ICANN's proposed expansion of the gTLD name space (Section 6), the group has 
failed to account for the "one-size fits all" zone file access mandate that 
ICANN staff has incorporated into the existing and proposed registry 
agreements."  He further says, "I do not believe that a California not for 
profit public benefit corporation should be able to impose contractual terms 
that compromise a sovereign government's valid security concerns. This should 
not even be a question under well enshrined international law. Unfortunately, 
ICANN's legal counsel has argued in connection with the recent ICM Registry 
Independent Review Process, that the ICANN Board's actions should be measured 
in connection with the lower "Business Judgment Rule" recognized under 
California law."  He makes the suggestion that, "the bi-lateral approach 
proposed by the ZFAAG is the most prudent way forward as it allows registries, 
both public and private, to protect appropriate valid security and sovereignty 
concerns.  However, the ZFAAG should continue to evaluate the viability of a 
centralized repository for those registry operators that may wish to voluntary 
participate in such a program as opposed to the direct bi-lateral approach."

Chuck Gomes made some remarks about the relative costs of ZFA alternatives: 
"From an operational point of view, it seems to me that the ZFAPP Proxy 
approach would be the most costly because the Registry transfers zone files to 
ZFAPP and ZFAPP transfers zones in real times to consumers."  He also said, 
"Regarding the ZFAPP Repository and ZFAPP Proxy approaches, it appears to me 
that it might be an expensive proposition for a third party provider to offer 
7x24 customer service just for zone file access unless that service was 
combined with customer service for other areas.  In comparison, most registry 
operators, if not all, have a customer service team already in place that 
supports ZFA without adding incremental costs."  On the same topic he made 
another note: "An advantage stated for the ZFAPP Proxy approach is 'Lower costs 
to consumer and provider of zone file data'.  It may indeed be lower costs to 
registry operators, the providers of zone file data, but it is not obvious that 
it would necessarily result in less costs to users who want access because it 
seems like it would be the highest cost option for the third party provider."  
Finishing up his comments on costs, he said, "in my opinion, the ZFAPP 
Repository option would be more expensive to operate than the first two models 
or the current ZFA Practice and the ZFAPP Proxy model would be the most 
expensive option."  Chuck also makes a note about funding models in the Concept 
Paper: "The second paragraph of Section 7.5.3 says, "As an example, registry 
fees (that are lower as a result of the ZFAPP operation) could be used to fund 
the operations of the ZFAPP."  The problem with this idea is that it would 
likely require registry operators to open their books for inspection and expose 
proprietary data.  This seems like something that we would want to avoid; it is 
especially problematic for publicly traded companies."

Mike Secord is a user of Zone File data and stressed the need to standardize 
the zone file access system: "The current system does have some minor drawbacks 
which would become worse as the number of zone files increases. For myself, the 
main drawback is the zone file structure. The zone files I download are 
structured in different ways, so I need to make my processing script work 
differently for the different structures. Not a big deal with 13 zone files and 
4 different structures, but if new registries come up with their own 
structures, more programming will be needed to process them."  Mike expressed a 
clear preference for one of the models: "the Enhanced Bi-lateral model may be 
the best choice. By standardizing the different elements, it makes the whole 
process simpler for both the registry and the consumer. With standardization, 
new registries will be saved some of the work involved in setting up their zone 
file system."  He followed that up with a description of some potential 
problems with the clearinghouse and proxy models.  He finished by affirming 
that "the system does need standardization, but beyond that, it should be 
what's best for the registries."

Henry Combrinck feels that the current system puts few burdens on either the 
data producer or customer.  He notes that "once the initial agreement has been 
concluded between the parties, the burden on all involved is very low. The 
existing model works very well, so I'd suggest a path of least change with a 
continued approach of simplicity.  The "The Enhanced Bi-lateral Model" in my 
view would be the ideal approach since it extends on what is known to already 
work well."  He also suggests that in very large zones that delivering diff 
files rather than entire zones would meet many consumers' requirements: "The 
burden on the registrar to provide this is insignificant, since it can be 
automated with a simple "diff" script, or some other means, etc."  Finally 
Henry suggests that consumers could be asked to partially fund the approach: "A 
nominal annual fee would be fair w.r.t. providing the service."

Ken Greenwood (retail Process Engineering) focused on the consistency of the 
format of the zone files: "my main issue is with consistency across the zone 
files."  In considering funding, Ken said, "regarding charging the consumer for 
access to do zone files - if the "tiered" approach is taken, I'd like to 
understand more clearly what the differences in the data would be for each 
tiered cost and what those costs would be.   I believe that the files should 
remain free in their current structure - anything more elaborate may justify a 
nominal fee.   The third option listed of concept of paying by the download 
sounds absurd to me."

Jorge Monasterio wants to see all limitations to access to the zone file 
removed.  In particular, he would like to see the zone file access system be 
completely free for users and not under contractual restrictions: "Instead of 
erecting new barriers and policies that make it harder for the general public 
to get access to zone files, ICANN should be looking at ways to make the data 
more accessible to everyone."  One opportunity he suggests is removing the 
limitations on third party distribution of zone file data.  He also suggests 
increasing the frequency of updates: "ICANN should consider requiring an 
increase of the frequency of updates for the zone access file."  He also 
provides two suggestions for distribution of the zone file data: using digital 
signatures on the distributed zone files and transporting the data through 
torrents.

Joe St Sauver commented on a variety of aspects of the Concept Paper.  
Regarding the timing of zone file distributions he said, "The adequacy of that 
once-a-day take-it-or-leave-it format may once have been sufficient, when the 
zone files were small and relatively static, but today that historical model no 
longer does a good job of meeting the needs of the community."  Joe feels that 
publication of the raw zone file is no longer sufficient: "at least some users 
may only be interested in some subset of the records included in the zone file, 
such as perhaps only NS records, or perhaps only zone file records added since 
the zone file was last released. Those customers should not need to download 
(and then discard!) all the other irrelevant records to get just the subset of 
data they're actually interested in."   He also suggests that the transport for 
the zone files should be modernized to include GridFTP, Bittorrent or a 
peer-to-peer model.  He also says that, "ICANN should also consider requiring 
zone files to be made available on physical media."  St Sauver presents an 
argument in favor of reducing the authentication controls on zone file access.  
His summary is: "If zone file access controls aren't mitigating an actual 
articulable threat, and one file access control security isn't being actively 
policed, consideration should be given to simplifying zone file access: zone 
files could simply be shared via anonymous ftp or a publicly accessible web 
page rather than requiring registration and password-controlled access."  He 
also suggests that further work in the ZFA AG "should carefully describe and 
illustrate the sort of data that's included in the zone files to eliminate any 
possible misunderstanding when it comes to things like registrant point of 
contact information privacy."  Finally, regarding costs Joe indicates that he 
would prefer the zone file access to remain free to consumers.  However, he 
urges ICANN to carefully consider how fees might be allocated and, if revenue 
is generated from the program, how those revenues would be distributed amongst 
the providers."
The GNSO gTLD Registries Stakeholder Group "strongly favors the 'Enhanced 
Bi-lateral Model' over the other three models and finds the 'Repository Model' 
least favorable."  The Stakeholder Group comments that two objectives must be 
preserved in any Zone file access system: 1) registries must be able to know 
who accesses their zone files and when; and 2) registries must be able to shut 
down Zone File Access to a particular user in the event of abuse.  The 
Stakeholder Group also supports "standardizing the zone file protocol/data 
format" and "establishing best practices on timing of updates, procedures for 
customer support and security."  The registries question the need to build a 
zone access program through the Applicant Guidebook saying, "considering 
[...the...] very low level of real demand, significant costs of running the 
ZFAPP and availability of alternative solutions, does it really make sense to 
add a ZFAPP through regulatory measures?"  The registries also presented an 
argument for having new gTLD registries opt out of the zone file access 
program: "We also believe the current "one size fits all" model of Zone File 
Access should be reconsidered. Certain types of new gTLD applicants, such as 
banks or governmental organizations may have legitimate interest to not 
disclose their zone files due to security or other concerns. We suggest that 
ICANN introduce an option for a gTLD applicant to request a waiver of the 
obligation to provide Zone File Access. Such waiver may be granted by ICANN to 
certain TLDs."  The Registry Stakeholder Group then turns its attention to each 
one of the models.  About the Enhanced Bilateral Model it notes that, "three 
items might benefit more from flexibility than standardization: 1) timing of 
zone file updates; 2) procedures for customer support; and 3) security-related 
procedures (such as changing access passwords)."  In each of these areas, the 
registries provide an argument for operational flexibility for registry 
operators.  About the Repository Model, the registries express the concern 
"about possible conflicts of interests between the ZFAPP functions and other 
activities that entity or its affiliates may pursue. Full attention has to be 
paid to who the ZFAPP is, the reputation of that entity, its affiliations and 
the terms under which it will be operating."  About the Proxy Model, the 
Stakeholder Group notes that: "this model requires trusting a third party to 
manage access.  That could make it harder to manage abuse.  An implementation 
question regarding this model is: Who would do enforcement of zone file access 
agreement requirements?"  Finally, the Registries Stakeholder Group notes that 
the Clearinghouse Model "might be the least expensive of models 2, 3 & 4."  As 
an annex to their comments, the Stakeholder Group provides diagrams of the 
participant relationships for each one of the models in the Concept Paper.
James Bladel (GoDaddy.com) submitted a set of comments that included 
identification of a new, potential data product in the repository and proxy 
models: "historical centralized zone data."  GoDaddy.com suggested that, if a 
third party was acting as a zone file access provider, the operator "could make 
this data available through a single interface. Should the operator of such a 
system seek to market this, or other, derivative products, it should seek 
comment from the ICANN community, and approval of the ICANN Board of 
Directors."  In addition, GoDaddy.com made the following comment about the fee 
model for Zone File Access: "Zone data is currently made available to 
accredited registrars, at no charge, by the operating registry. Other 
(non-Registrar) parties can access the data for a fee. We ask that any new 
approach preserves this fee model, and minimizes the operational impact or 
investment required on the part of gTLD registries and accredited registrars."  
Finally, GoDaddy.com made the following comment on cost structures for 
consumers of zone file data: "We recognize the operational benefits of 
centralized Zone data access for registrars and other consumers, but are wary 
of advocating new cost structures where none exist today."


CONCLUSION



This summary should not be considered a full and complete recitation of every 
comment, concern, or recommendation contained in the public comments.  It is an 
attempt to capture in broad terms the nature and scope of the comments.  In 
several instances substantial written comments were submitted to elaborate on 
and support the positions presented.  This summary has been prepared in an 
effort to highlight key elements of these submissions in an abbreviated format, 
not to replace them.  Every effort has been made to avoid mischaracterizations 
and to present fairly the views provided.  Any failure to do so is 
unintentional.

NEXT STEPS

This summary of public comments will be used to inform the group's work on Zone 
File Access. The Zone File Access Advisory Group will continue to meet to 
develop a recommended model for enhanced zone file access and materials for 
inclusion in the next version of the new gTLD Applicant 
Guidebook<http://icann.org/en/topics/new-gtlds/dag-en.htm>. Further information 
about the timing and details of the new gTLD Applicant Guidebook are available 
on the ICANN website. In coordination with public comment on the Applicant 
Guidebook, the Zone File Access Advisory Group will develop an implementation 
plan for Zone File Access.

CONTRIBUTORS (in order of first appearance (with abbreviation) and number of 
postings if more than one):

Michael Palage
Chuck Gomes (2, one a posted correction)
Mike Secord
Henry L Combrinck
Ken Greenwood - Retail Process Engineering
Jorge Monasterio
Joe St Sauver
GNSO gTLD Registries Stakeholder Group
James M. Bladel, GoDaddy.com


--------------------------------------------------------------
Posted on behalf of the ZFA Advisory Group
Mark McFadden
IANA Resource Specialist
mark.mcfadden@xxxxxxxxx<mailto:mark.mcfadden@xxxxxxxxx>