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