ICANN/DNSO
DNSO Mailling lists archives

[nc-whois]


<<< Chronological Index >>>    <<< Thread Index >>>

[nc-whois] WHOIS Task force teleconference minutes - January 21, 2003


[To: nc-whois@dnso.org]

Please find the minutes of the WHOIS Task Force teleconference on January
21, 2003.
A text version will follow.

Please let me know whether there are any changes that should be made.
DNSO.Secretariat@dnso.org.

Thank you.

GNSO Secretariat
Title: notes/20011112.GAmdr-agenda.html

ICANN/DNSO

GNSO WHOIS Task Force teleconference January 21 2003- minutes


27 January 2003

http://www.dnso.org/dnso/mp3/20030121WhoisTFteleconf.mp3

ATTENDEES:
Co-chair -Tony Harris
Co-chair - Marilyn Cade
BC - Bret Fausett
gTLD Registries - Ram Mohan
gTLD Registries - J. Beckwith Burr
IPIC - Steve - Metalitz
Registrars - Ken Stubbs
NCUC - Ruchika Agrawal
( Former GA Chair) Thomas Roessler
(Former GA - representative) - Kristy McKee

Guests from the Security Committee:
Steve Crocker
Rick Wesson

GNSO Secretariat - Glen de Saint Géry

Apologies:

(Former GA - representative) - Abel Wisman

Marilyn Cade
introduced the two speakers who worked on the Security Advisory Committee and clarified that the WHOIS task force did not address accuracy in IP databases but that work was foreseen on ccTLD issues and some input had been received from them during the work of the task force.
Rick Wesson explained that originally the task force title was WHOIS for gTLDs, and that the gTLD dropped off in editing. The security committee did not want to see the issue as broad based into ccTLDs as there are privacy issues at stake.
Steve Crocker thanked the task force for their invitation and appreciated the cross group coordination that was essential in making things work.
He stated that their work was focussed on security and stability with regard to operational questions. What needs to be done when something is broken in a domain name operation, not when there is a violation.
The picture that emerged was that good contact information was highly desirable.
Problems that arose with data accuracy were:
- stale /aged data - a problem under all circumstances
- resistance to having good information because the data is often misused, thus no updating or updating with inaccurate data.
A side effect is that people often do not give accurate data because they think it will be misused was the crux of the matter.
Rick Wesson added that the focus was on gTLDs and the ccTLDs were never really discusses as they seem to have different standards than the gTLDs.
Marilyn Cade said that the task force had identifies a category of people who purposefully put in inaccurate data because their intent was to perpetrate fraud, while Rick Wesson said that they had distinguished a category of people who did not put in accurate information without going into the legal aspects.
Steve Metalitz said that there were a number of new mechanisms mentioned, such as validation, and datamining mentioned in the report. How would these methods be developed?
Rick Wesson explained that some ccTLD operators discovered ways of mitigating datamining.
Steve Crocker said that there should be a balance between the intended functional utility and putting controls in place. Promoting accuracy is part of an ongoing business relationship where regular contact is needed.
Ken Stubbs mentioned two points in the Security Advisory report:
- validation at the point of registration
- concept of the last verified date
Rick Wesson commented that on the first point there had not been enough research for it to be done on a global base while the second point identified an issue for the community to work on.
Marilyn Cade verified that the primary focus of the Security Advisory Committee was the impact of inaccurate information on security, assuming that the users of accurate data would be network operators, ISPs and transport providers. While the task force focus was broader and inclusive of these.
Marilyn Cade further pointed out consistencies between the task force and that the security committee recommendations on:
- The accuracy of Whois data must be improved, both at the time of its initial registration and at regular intervals. Whois records known to be false or inaccurate, or to have information that can not be validated, must be frozen or held until they can be updated or removed was consistent with the accuracy group,
- A standard format for Whois data must be developed, appeared as an issue report subject
- Whois data must contain a "Last Verified Date" that reflects the last point in time at which the information was known to contain valid data. It must also contain a reference to the data verification process, would probably be supported by the implementation committee.
Ken Stubbs asked whether there is a standard format for WHOIS across the Internet registries, to which Rick Wesson answered that the number registries did not all provide the same format, it took them 10 years to align. All the RIR registries do now. CRISP is working on a unified format.
Steve Crocker commented that the group did not want to lay down an implementation plan as they felt that should be left to the IETF protocol design and operators. Their goal was the effect they wanted to accomplish and not the mechanism by which to do it.
Marilyn Cade quoted recommendation 5 in the Security Advisory report:
A publicly available list of publicly available Whois servers must be available using a widely known and available resource, e.g., a web page or DNS SRV records.
and asked how this would solve a problem, how does this address unmet needs?
Rick Wesson commented that there is no list, but that the resources have been identified as critical and as the IANA function of the separate body of ICANN maintains this, there are in fact two recommendations that should be side by side:
- IANA should maintain a list of publicly available WHOIS servers.
The way they should do this is using DNS SRV records. Locating WHOIS is important and there is a mechanism proposed to do this.
Marilyn Cade went on to ask how this addresses complaints from WHOIS users that they have to go to multiple Registrars WHOIS to search?
Rick Wesson explained that it was not to address a particular problem but that the resource location mechanism for WHOIS was not there and the group suggested that resources, up to now not documented, could be documented in the DNS.
Marilyn Cade commented that third party services are emerging that offer unified searching, some of the third parties would not be contracted to ICANN, thus how would those third parties be includedif this recommendation were put forward?
Steve Crocker explained that the primary relationship was with the registrar, if there is a third party relationship for searching , it is usual but would fall within the business relationship and does not belong to WHOIS as such.
Further to what Rick Wesson said he explained that with respect to a domain, asking for that domain's corresponding WHOIS database could be just another port number related to a domain. While there are not port numbers related to domains that mechanism does not exist. Identifying or locating the WHOIS corresponding to a domain is a mechanical matter and not a political or business issue.

Marilyn Cade addressed the two last recommendations in the Security advisory report:
- A Whois service must discourage the harvesting and mining of its data and said that the task force did not address the port 43 issue, but agreed that it should be addressed in an issue report.
- Whois services must provide mechanisms to protect the privacy of registrants was consistent with the task force recommendation, and that it was gathering information about privacy concerns for an issues report.
Rick Wesson mentioned that PROREG, an IETF working group, submitted a document to the ISG with a number of comments that have come back is that there has to be privacy protection mechanisms in the protocol for the ISG to give an RFC number for this protocol. For privacy enhancement in the protocol, there must be privacy protection at the output of the data.

There is ongoing funded research in several European countries.
Marilyn Cade mentioned that from her perspective, there would be a complicated definition of privacy that could be sliced up.
Steve Metalitz asked for the references to the IETF group that addressed privacy issues, and Rick Wesson promised to forward them to the task force.
Ken Stubbs asked if there were privacy initiatives with regard to the registries for the IP addresses to which Rick Wesson answered that IP registries have different amounts, different kinds of data, different processes and pressures.
Ken Stubbs went further on to express concern that the ccTLDs currently using the system have sufficient volume for conclusions to be drawn.
There is no real clarity from the ISG group about the identification of privacy issues.
Marilyn Cade mentioned that there was a recommendation in the Security Advisory group modifying the registrars contract that required a policy change and suggested that it should be incorporated as advice in an issues report.
Steve Crocker signed off thanking the task force for the opportunity of sharing the Security Advisory committees work and hoped that it would be an ongoing communication process.
Steve Metalitz asked what happens to the recommendations made by the Security Advisory committee and whether there was a mechanism for the Board to take comments on it?
Further work is being undertaken by the committee on security issues, the WHOIS was a specific request that was addressed.
Marilyn Cade asked about the applicability to the large ccTLDs and Rick answered that the document was about gTLDs.
Marilyn Cade thanked Rick Wesson for his valuable participation and said that the task force may come back for further discussion and questions.
Rick Wesson signed off.

Work Assignments:

Marilyn Cade
summarized saying that there was a significant amount of consistency between the security Advisory committee, whose focus was narrower and did not take consensus policy into account, and the task force recommendations.
Issues reports should look at the statement in the implementation plan and take into account the recommendation of the Advisory committee.
In the implementation group, the issue of last verified data is not a topic of discussion, it is looking at time of renewal and how to handle it in the context of complaints and challenges.
Links need to be made to the Security Advisory committee report and the implementation committee report in the final WHOIS report.

Issue reports:
- short, clear headings, a background section clearly distinct from the list of issues.
Suggestions how to address the issues should be in a separate section.
Time line: finished for the Rio de Janeiro meeting

Work to be done:
1. Final report -Thomas Roessler
2. 4 issue reports:
- Issue report on mid-term work to be treated as one report with two different topics, so that it could be a topic for a new task force - Thomas Roessler, Steve Metalitz and Becky Burr
- Searchability - Kristy McKee suggests in addition a lawyer work on appendix A, Agreement Provisions
- Uniformity - Ram Mohan
- Privacy - additional input from task force members - Ruchika Agrawal

Next week call

Ruchika Agrawal to lead discussion on what has been done,
- list of questions
- academic studies on accuracy
Characteristics of registrants

Time line:
Priority: Final report for 1st February

Next Call: Tuesday 28, 11:00 EST, 16:00 UTC

 


 

 


 


Information from:
© GNSO Council



<<< Chronological Index >>>    <<< Thread Index >>>