Sorry, you need to enable JavaScript to visit this website.
Skip to main content

Jeff Neuman thanked everyone for their presence and participation and proposed sending the questions to the CRISP . Next Regular Task Force Call:18January 2005 see: GNSO calendar Questions submitted by Jeff Neuman and revised by Steve Metalitz ( in italic

Last Updated:
Date

WHOIS Task Forces 1 & 2



4 January, 2005 - Minutes

ATTENDEES:

GNSO Constituency representatives:


gTLD Registries constituency: - Jeff Neuman - Co-Chair

gTLD Registries constituency - David Maher

Commercial and Business Users constituency - Marilyn Cade
Commercial and Business Users constituency - David Fares
Registrars constituency - Tom Keller

Registrars constituency - Paul Stahura

Intellectual Property Interests Constituency - Steve Metalitz

Intellectual Property Interests Constituency - Niklas Lagergren,



At-Large Advisory Committee (ALAC) liaisons - Thomas Roessler



ICANN Staff Manager: Barbara Roseman

GNSO Secretariat: Glen de Saint Géry



Absent:

Registrars constituency - Jordyn Buchanan - Co-Chair - apologies

Internet Service and Connectivity Providers constituency: - Antonio Harris - apologies

Registrars constituency - Tim Ruiz

Nominating committee representative - Amadeu Abril l Abril

Intellectual Property Interests Constituency - Jeremy Banks

Non Commercial Users Constituency - Marc Schneiders

Non Commercial Users Constituency - Milton Mueller - apologies

Non Commercial Users Constituency - Kathy Kleiman

Internet Service and Connectivity Providers constituency - Maggie Mansourkia

At-Large Advisory Committee (ALAC) liaisons - Wendy Seltzer



MP3 recording



Agenda

1. Questions to send in advance to the CRISP working group in preparartion for the call on Wednesday, 12 January 2005, at 11:00 am EST.



Jeff Neuman reported that he had sent an e-mail to ICANN staff, Paul Verhoef, John Jeffrey, Kurt Pritz, Dan Halloran, Tina dam, Tim Cole requesting a call to discuss the email sent by staff that was discussed on the last call, 21 December 2004. The only response received was from Paul Verhoef stating that he was not available untill 6 January 2005, but no response was given as when would be good time to hold the discussion.

Jeff Neuman proposed sending out another email.

Barbara Roseman reported that she asked for senior staff to be on the present call.

Marilyn Cade proposed that in the formal written request it should be stated that the task force considered a call with the staff a priority and would work with staff to find another time if necessary, other than the regular task force call time.

Jeff Neuman proposed sending a formal written request, including Marilyn Cade's proposition, and adding that the discussion should take place as soon as possible.

Glen gave an update that notice of the open call had gone out to Whois task force 1,2 & 3, Council members, the Constituency lists, the GAC. Quotes were being obtained from different telephone providers who would also be able to provide a transcript of the call and better services than the usual provider.

Jeff Neuman commented that he had written up some questions that he thought were relevant, but invited other members to ask additional ones. First question: What's the status of the protocol, if not officially a standard, what steps need to be taken?



Marilyn Cade: Can we please start with What is it?

Jeff Neuman: Brief overview in layman's terms of what IRIS is,? Other questions, general questions: Have there been any registrars or registries/ resellers that have committed to adopting the protocol? What do they have to do to adopt the protocol?

Marilyn Cade: How does the protocol relate to the distribution of models where there's a wholesaler model of resellers?

Jeff Neuman: do all registries/registrars/resellers have to adopt the protocol for it to be effective? What if only some registrars or registries in a given TLD adopt it? What happens to the model, does it break down?

Marilyn Cade:What does adoption of the protocol really mean, and fully implement it?

Jeff Neuman: For example, it's one thing to adopt the IDN standard, but then resolution capabilities have to be built. One thing to adopt a standard, what has to be built to support it from a software /hardware standpoint?

Marilyn Cade: can we ask if there's any additional burden on the processing times? Given that this presupposes multiple dipping into the data base information to verify different elements of the information.

Jeff Neuman: For registry/registrar, will Registries have SLAs on response time, what effect if any, will there be on processing response time?

Jeff Neuman: Any other general questions?

Marilyn Cade: When they do the overview, they'll probably tell us this, as I understand IRIS, the flexibility in the standard is there to gather all the data and then decide which fields are displayed?

Jeff Neuman: Who gets to decide what is displayed? Who has control over what is displayed?

Marilyn Cade: Not my question, I would have assumed that the GNSO would come up with consistent policy on what's displayed, but what's the granularity that the standard provides of what is displayed versus what is gathered? Is it element by element?

Jeff Neuman: I can answer that, it's element by element.

Thomas Roessler: You're both talking about something similar: Can a query be limited to certain data fields, can a response be limited to certain data fields? Can you create sets of what can be displayed depending on the requestor

Jeff Neuman: IRIS looks for the information regardless of whether it comes f from a registry or a registrar. Provides a way to provide the data behind the scene. For a thick registry does the IRIS protocol make any judgment whose data is authoritative? Does it go to the registry or the registrar, and who determines that? This is most important in thick whois tlds.

Thomas Roessler: It should be apparent whether the data is a referral.

Jeff Neuman: So the person getting the response knows where the data is coming from.

Thomas Roessler: Is it possible to map how the data is retrieved

Jeff Neuman: Authenticating the requestor, or getting information about the requestor, is there a way to identify who the requestor is? Does IRIS support this, or is it silent on this, and can you implement IRIS to find out who the requestor is and determine if they fit an access profile? Is there a way for the whois provider to know who is doing the requesting? Or is IRIS extensible so you can add different fields at implementation?

Marilyn Cade: What is the mechanism for operating different access levels? Can you block access to the "reserve data" until this information is filled in?

Jeff Neuman: the other question on top of that, lets say it is not enough to fill in those fields and the whois provider needs to cross check that against another data base of preauthenticated requestors will the protocol support that?

Marilyn Cade: So we should follow each of those, one scenario would be that the data is gathered but not validated, the other is the data is gathered and validated

Steve Metalitz: another question about that authentication process , whether that is that applicable to other functions besides whois data,? If there is an authentication function to this that determines whether or not you have access to certain data can that authenitcation function be used for other purposes as well, such as registration?

Thomas Roessler: We should pay a little attention to the difference between authorization and authenitcation. What we would have with the two tiered approach is in the first place authorization, that would be mostly focused on authentication making sure that the information provided during the authorization is information that comes from the sender. Not sure what way to go about it,

Jeff Neuman: we should go down both ways of authorizing access, some people argue that to prevent data mining is to basically be sure that the certificate provided by the requestor, some believe that only authorized or pre-authenticated should able to get the information. We should ask if IRIS will support either or both.

Thomas Roessler: What can be implemented with this specific protocol, when we are asking what kind of authorization models it supports, that might be independent from how to authenticate information submitted during the authorization stage.

Jeff Neuman: We should be clear about whether we're asking about authentication or authorization. In task force 1 they talked about the possibility of anonymous access for law enforcement for example, so we should ask whether there's a way to do that?

Marilyn Cade: Is there support for a special class of access that is "anonymous access" For instance, for law enforcement

Thomas Roessler: what do we mean by anonymous access

Marilyn Cade: If you were in an environment where you were going to gather the details of the person who asked for the data you would not want to disclose those details, example, xxxx Child Protection Services.

Thomas Roessler : Concealing the identity of certain requestors from the registry/registrar?

Jeff Neuman: is it possible to conceal the identity of certain requestors from everyone or concealing it partial?

Steve Metalitz: Does the protocol address what record is made/preserved for each transaction, and if so could the protocol support limiting the uses of those records? 2 Examples:

1. Know who has made what queries about whois data might be valuable information for marketing purposes. Would there be a way to prevent that use?

2. Is a record created and is it preserved in a way that law enforcement could have access

Paul Stahura: Do you mean the record of who looked up the whois information?

Steve Metalitz: Yes, we discussed one model in which that record would exist and if there were some evidence of abuse then law enforcement or somebody else could have access to that record under certain circumstances. One of the models discussed in tiered access was that the record would be created and preserved and would be accessible under some circumstances. How would that fit into the protocol?

Paul Stahura: The requestor looks up the information, does the protocol provide a way to track what happens to that information ,like whether it is stored or given out, has it a certain life time and disappears after a while? Once the requestor looks up the data, can we track how its used? If there are restrictions on how to use the data, can we check up on that?

Jeff Neuman: we can ask them, but probably the answer will be no, there is nothing built in there

Paul Stahura: Is there something like the Time to Live of dns, then the data has to be asked for again? Otherwise we are going to have requestors and no matter how much checking we do with the identity of people etc the information will be able to be used over again.

Jeff Neuman: We can ask but feels that the answer will be that it is a policy determination

Paul Stahura:If we can up with a policy that it information could remain for a day, does the protocol help us with the implementation of that policy?

Jeff Neuman: Okay, we have about 18 questions now. If you have other questions, please send them around. I'll put up this list to the group, please correct any of your questions that I might have misstated. We'll send these questions to the presenters on Thursday.

Jeff Neuman: I'll send a second request to Staff to get a date to discuss their response to our recommendations on national privacy policy. Didn't get a response to the first request.





Any Other Business:

Constituency statements on recommendation 1 due on 31 January 2005.

The registrar constituency reported that they could probably only provide feedback that was not officially voted on by the constituency for that date.

Thanks to Barbara Roseman's notes, these minutes are so detailed.