You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 20 Next »

The GNSO Next-Gen RDS PDP Working Group teleconference will take place on Tuesday, 13 September at 16:00 UTC for 90 minutes.

09:00 PDT, 12:00 EDT, 17:00 London, 18:00 CEST 

For other times: http://tinyurl.com/h7wt5rm

Proposed Agenda – Next-Generation RDS PDP WG Meeting – Tuesday 13 September at 16.00 UTC 

1. Roll Call / SOI

2. Continue discussion on Statement of Purpose:

•              What are the criteria for a statement of purpose?

•              What elements, if any, from the EWG statement of purpose (below) should be reflected in the statement of purpose?

•              What other elements need to be reflected in the statement of purpose?

3. Review latest version of possible requirements list & triage (below)

4. ICANN57: update on plans for F2F meeting

5. Confirm next meeting (Wednesday 21 September at 5.00 UTC) & next steps

 

Mp3

Transcript

AC Chat

Attendance

Apologies: Tjabbe Bos, Susan Kawaguchi, Jim Galvin, Benny Samuelsen, Rod Rasmussen(tentative), Susan Prosser, Holly Raiche, Grégory Mounier, Geoffrey Noakes, Darcy Southwell

On audio only


 

Notes and Actions - 13 September WG Call

1. Roll Call / SOI

  • No updates noted

  

2. Continue discussion on Statement of Purpose:

Suggested criteria for a statement of purpose:

  • What should be in A statement of purpose (not necessarily for THIS statement of purpose, which comes next)
  • Should a statement of purpose set boundaries for registration data requirements/policies, or
  • Should a statement of purpose establish a minimum for those requirements/policies?
  • Include an element that ties back to the organization's mission
  • Include a description of why registration data or the RDS is needed
  • Massive difference between the purpose of registration data and the purpose of an RDS - this is an important distinction we need to make
  • Must identify what it pertains to (e.g. reg data and/or RDS)
  • A list of purposes - not one single purpose (or least very unlikely)
  • Can be readily communicated to registrants (and to others) because the registrant has to be told what the purpose is for collecting their data
  • Sufficiently clear that we can establish a relationship between the purpose and use of that data
  • if the statement of purpose uses the phrase “domain name life cycle” we must be as exact/specific as possible as to what that means.   It can't be vague, because if it is vague it will cause confusing in the future.  We must all agree to the exact meaning of this (or any) word/phrase
  • you may not need to define lifecycle, but you could start spelling it out by saying RDS is expected to support registration, renewal, expiration, etc.so instead of defining, just call out which specific elements are expected to be part of the purpose for RDS

 

Suggested purpose(s) for registration data or RDS:

  • Provide information about a domain name - no disagreement noted
  • A purpose of registration data is to manage the "lifecycle" of a registration of a domain name
  • Suggested variant of the above: A purpose of data might be to provide information about the lifecycle of a domain name to enable management of a domain name registration
  • Need to know what is included in the "lifecycle" (see diagram), perhaps this is one of the purposes but not the only one (that is, not a boundary), noted that we have use cases that show additional needs. Many things we query WHOIS go beyond this - for example, to get data to avoid losing the domain name. Lifecycle may be too simplistic to use a frame for a statement of purpose.
  • Provide information that is needed to operate a domain in the DNS
  • A lot of the other information that people may want or have access to may be superfluous for the above purpose
  • Purpose is of registry data is to have a point of contact for the registrant of that domain.  now we may argue why people need access to the identity / point of contact of the registry
  • Provide an accurate point of contact for a registered domain name - but limiting that to contact between registrar/registrant (and registry?) is too narrow
  • Must also allow contact when P/P service is used to reach the actual registrant
  • Does our remit only allow us to deal with the information to operate a domain in the DNS? Everything else might not be our concern.
  • We need a POCK to ensure the domain resolves and can be fixed when it does not
  • We need a mechanism of contact, NOT a point of contact.
  • If we assume automated processes, the actual registration data can be a minimal set because the processes could get you into real-time contact with the registrant. There could be processes to obtain release of the actual data in certain circumstances
  • The current ND lifecycle is a combination of policies. some of those policies relate to protecting registrants from losing their domain (TRIP, RAP etc.). others seek to prevent misuse of the domain (GAP). So the lifecycle serves several purposes already. it's a little too simplistic to say that the lifecycle itself should be a purpose for data collection.
  • Per the 1998 white paper which led to the formation of ICANN: "Trademark holders (or legal representation) and domain name registrants and others should have access to searchable databases of registered domain names that provide information necessary to contact a domain name registrant when a conflict arises between a trademark holder and a domain name holder" - see https://www.icann.org/resources/unthemed-pages/white-paper-2012-02-25-en
  • if someone is going to "buy" a domain, they use WHOIS to look up the create/registrar/registrant
  • several scenarios where someone might need info on the life cycle for reasons other than managing the life cycle directly.  For example, an IT person for the domain registrant might need to know the expiration date so he/she can take steps to renew the domain.  That would be actively "managing" the life cycle.
  • On the other hand, someone who wants to acquire the domain name and looks up info on the life cycle to see if the domain is coming up for renewal.  That could provide insight on whether the current registrant is interested in keeping the domain or whether he/she might be interested in selling (say, if the domain had lapsed into the redemption period without renewal).  In that case, the info on the life cycle is informational only and the proposed buyer does not seek to "manage" the cycle itself, but still desires useful information ABOUT the life cycle.
  • The problem with life cycle is that it may wrap in other aspects of policy development - RDS provides a source of contact but not necessarily all the information used to carry out other policies

 

What elements, if any, from the EWG statement of purpose should be reflected in the statement of purpose?

  • Noting that this isn't necessarily framed as a statement of purpose, what elements should be included?
  • perhaps we need an example of a statement of purpose to model our statement after - does anyone have one to recommend?
  • How about 4th bullet - that seems to get more to purpose? Are some of the purposes listed there appropriate or not appropriate?
  • how about just "support a framework to address issues involving registrants" drop the rest
  • want the RDS purpose statement to include "provide information about a domain name"
  • RDS is for identification of point of contact for registrant/registrar/registry. one purpose to use that data are the items listed in the 4th bullet
  • The statement may not be a good fit for what this WG is trying to craft now
  • Are we trying to avoid what "appropriate" is and ultimately it will come down to that?
  • If someone is going to buy a domain, they use WHOIS to look it up, and that's one of the purposes of the RDS - but not the only purpose
  • registrant data is used for law enforcement purposes, or efforts to combat cyber-crime - at least one WG member noted: This is the first place I start when investigating these issues.

Action Item #1: Leadership team take output from today's call to draft a strawman statement of purpose to facilitate further discussion next week - focusing on creating a framework for a statement of purpose that the WG could flesh out with content

 

3. Review latest version of possible requirements list & triage

  • Draft 4: RDS PDP Initial List of Possible Requirements for gTLD registration data and directory services (11 September 2016) [PDF] and [DOC] was distributed on 12 September, containing new triaged PRs, new codings, definitions for keywords and codings
  • See slides (Overview of Update to Draft 4 of the PR List) highlighting main updates made to this version, including:
  • Draft 4 contains additional possible requirements that were submitted by WG members as well as those suggested during cross-community session in Helsinki, as well as input provided by RySG in response to Outreach #2
  • Applied keywords and codings: C = coding, K = keywords (previously known as groups). Annex B provides the details on the codings and keywords.
  • Annex A lists new source documents (sources for additional PRs added in Draft 4)
  • Some additional possible requirements may not have direct relevance to the RDS (see those with ?? in the Phase/Code/Keyword columns
  • Excel version of Draft 4 will be circulated shortly to WG to facilitate filtering and sorting, in combination with a short video which will explain how to apply filtering and sorting.

 

Action item #2: WG members encouraged to review latest version of possible requirements, paying specific attention to: are PRs marked as ?? relevant to the RDS; are triaged phase and keyword values correct; are new codes correct for each individual PR; are essential PR sources still missing? See https://community.icann.org/x/shOOAw for all PR sources, including pending assignments.

 

4. ICANN57: update on plans for F2F meeting

  • After random online drawing to finalize WG timeslots:
  • F2F RDS PDP WG meeting is 9-1 local time on the first day of ICANN57 (November 1)
  • Update to GNSO Council will be provided on Friday (November 2) at 10 local time

 

5. Confirm next meeting (Wednesday 21 September at 5.00 UTC) & next steps

  • NOTE that next week's meeting is at alternative time: 5 UTC
  • Discussion will include strawman statement of purpose

Meeting Materials

  • No labels