ICANN/DNSO
GNSO WHOIS Task Force Teleconference on 18 February 2003 |
http://www.dnso.org/dnso/mp3/20030218GNSOTF.mp3
Attendees:
ISP - Tony Harris - co- chair
BC - Marilyn Cade - co-chair
Registry - Ram Mohan
Registrar - Ken Stubbs
Former GA Chair - Thomas Roessler
Former GA additional - Kristy McKee
Intellectual property Interests Constituency - Steve Metalitz
Intellectual property Interests Constituency - Laurence Djolakian
Non Com Users Constit. - Ruchika Agrawal
ALAC Liaison - Denise Michel
Guest Speaker:
Scott Hollenbeck - Verisign,
Progreg working group
GNSO Sec - Glen de Saint Géry
Ram Mohan introduced Scott
Hollenbeck working PROGREG group working with Verisign and was the principal
author for the EPP protocol that is reaching the status that all registries
are moving to.
Ram Mohan explained that the task force was considering privacy issues
as how these interact with WHOIS. The aim was to brief the group about the working
group and the ISG.
Scott Hollenbeck stated that at an early stage, privacy was an issue.
Privacy meaning the protection of data being exchanged from an originator to
be stored in a repository here meaning a registry.
Marilyn Cade asked Scott H.
to distinguish when a concern is about the security of the data, versus the
rules of privacy that relate to the data.
Scott Hollenbeck said that privacy was dealt with here in the context
of disclosure. All data is encrypted. The crux of the issue is disclosure and
the authority to disclose.
There are two different camps with two different opinions where and how the
mechanisms should be supported in the protocol.
One position favored a feature pushed
from the client's side - giving permission or not giving permission for the
data to be used in one way or another.
The other position was derived from the World Wide Web Consortium platform for
Privacy Preferences working group, P3P, that takes a server centered approach.
A privacy policy is developed for the repository, the policy is then expressed
in a possible mechanical way, then the policy is published in an initial exchange
between client and server. For example the server says what is done with the
data, whether it is to be disclosed to 3rd parties, used for marketing purposes
etc. The onus is on the downstream users to decide if they put data into the
repository.
The proponents of the first position did not come up with any coherent proposal
how to add it to the protocol.
The proponents of the second position put in an optional mechanism for the server
to announce its privacy policy for downstream operators.
The ISG reviewed the document and asked one question, why the tagging of each
element was not allowed, such as a telephone number to indicate whether it should
be disclosed to 3rd. parties or not.
The ISG's comment reopened the discussion of whether it should be the client
pushing it, and if so how should the data be marketed so that it is universally
usable
The ISG concerns were that if it was mandatory, operability would have to be
guaranteed and everyone would have to agree that it was a usable mechanism.
The problem in the working group is that the ISG's position is not seen as something
that is universally usable by everyone.
Marilyn Cade commented that the difference between the working group
and the ISG was all data going into the WHOIS and not differentiating between
individual and corporate data
Scott Hollenbeck said that it was not desirable to distinguish where
the data came from as that qualified as a policy decision.
The P3P approach has no negotiating capabilities, it transmits a policy to a
client,and is informed consent. It has been adopted in a "light version"
with data collection tailored to the environment. Another application APPEL
has negotiating capabilities on the client side, but has not been considered
due to cumbersomness and its immaturity.
The protocol gives flexibility for the registrar to express it in human understandable
terms. There is a range of ability to express different policies. Once the policy
is explained to the registrant, the registrant can choose whether to use it.
Granularity is not below the macro level
Marilyn Cade asked whether it was possible in the protocol to make a
decision that would limit access to specific information.
Scott H. said yes, it was an either or situation If the registry policy
is that the individual information would be subject to different privacy features
than the corporate information then that facility would be available.
The protocol distinguishes between individual and organizational elements.
Ken Stubbs wanted to know if there was any protocol close that could
distinguish individual from non individual data and mentioned a CORE protocol
that at the time of registration gave the opportunity to ratify if the registration
was individual or non individual. If individual, there was a specific registration
agreement that required a reaffirmation on penalty that if it was not an individual
registration, the domain could be canceled by the registrar or the registry.
If it was an individual registration, the registrant was presented with fields
that needed to be completed. Not necessarily data fields that would have been
required for an open disclosure. Is this contemplated in the process?
Scott H. said yes, it had been contemplated and certain data fields may
be optional.
Ken Stubbs said that the underlying theory was that if it was deemed
not to be individual, the domain name could be shut down almost arbitrarily.
Scott H. said, with regard to extensions, that new features could be
added without changing the core protocol. XML (extensible markup language) provides
features that can jump from one name space to another. The modification can
be attached to the new protocol. Extensions are used in Poland where there are
features for privacy and domain registration, Australia and by Verisign. In
addition ENUM, (telephone numbers to domain name mapping and DNS security have
features added through the extension mechanism.
Extensions would be useful in addressing privacy. Individual registry operators
could define their own extension in their own context.
Other ITEF efforts such as DNS security and ENUM would also use extensions to
build on domain names.
Ram Mohan, from a . info point of view, agreed that extensions, which
depend on jurisdiction and local needs, allow standardization on the EPP protocols.
Extensions are negotiated between the client and the server. Client contacts
server and the server publishes the extension available, client may choose which
to use presuming the extensions are optional. If the server requires the extension
to be used, should the client not select them, the server can deny service.
With regard to the ISG Comments relating to tagging every single element, the
working group is in active negotiations with the ISG looking for a compromise
which could make P3P elements mandatory instead of optional as they are presently.
A facet of mandatory implementation, is the possibility of defining a specific
WHOIS extension that is always there.
Marilyn Cade summed up taking the example that if it were determined
that accurate WHOIS data is required, there is a category of data publicly available,
and a category of data available via either subscription or privileged access.
Thus it would be possible to create a WHOIS specific extension and then address
if the data should be displayed or not and what kind of data.
Kristy McKee added that policy could go as far as was desired because
technology would enable this.
Marilyn Cade said constructively the task force could think about the
aspect that would be possible through a specific WHOIS extension.
Marilyn Cade thanked Scott Hollenbeck, on behalf of the task force,
for his informative contribution and he expressed his willingness to address
the group again.
Marilyn Cade drew the attention of the group to:
- the comments received during the public comment period.
http://www.dnso.org/dnso/dnsocomments/comments-whois/Arc03/
- the form of the report to be voted on at the GNSO Council meeting
- transmittal letter describing the issues
- dissenting opinion from A Non-commercial Constituency Representative
http://www.dnso.org/clubpublic/nc-whois/Arc00/msg00921.html
- PIR contribution
http://www.dnso.org/dnso/dnsocomments/comments-whois/Arc03/msg00013.html
Ruchika Agrawal stated that it was her own dissenting opinion as a WHOIS
task force member and the statement has not been approved by the non commercial
users constituency.
The co-chairs and task force members expressed disappointment at the contribution
made at the last minute by Ruchika.
Marilyn Cade expressed the task force goal:
working constructively and openly in a trust worthy manner together.
proposed to explain in the transmittal letter
- the dissenting opinion does not factually portray the work of the task force
- privacy has been taken seriously by the task force and is the subject of issues
reports
- the co-chairs work with Ruchika Agrawal on an issues report on privacy.
Issue Reports to be drafted by next
week.
Minor modifications made to the report for submission to the GNSO Council
Antonio Harris requested that
it be noted:
that the Non Commercial Users Constituency representative was asked to participate
in the issues report on privacy and declined.
Marilyn Cade and Antonio Harris thanked the task force members for their
participation.
Next call:
Topic for discussion:
1. Brainstorming on privacy
2. Becky Burr to address the group on .name
Next call scheduled: Tuesday 25 February, 11:00 EST (individual reminders
with dial-in number sent to the task force).
The call ended 19:35 CET, 13:35
EST
GNSO Secretariat