[gnso-rds-pdp-wg] Notes and action items from 13 September Meeting
Lisa Phifer
lisa at corecom.com
Tue Sep 13 18:23:19 UTC 2016
Dear all,
Below please find notes and action items from today's RDS PDP WG call.
Best regards,
Lisa
Notes and Actions - 13 September WG Call
These high-level notes are designed to help PDP WG members navigate through
the content of the call and are not meant as a substitute for the transcript
and/or recording. The MP3, transcript, and chat are provided separately and
are posted on the wiki at: https://community.icann.org/x/kRysAw
1. Roll Call / SOI
. No updates noted
2. Continue discussion on Statement of Purpose:
. Discussion of lifecycle on list has been informative:
. See
<https://community.icann.org/download/attachments/61611153/gTLD-Lifecycle.pd
f?version=1&modificationDate=1473789116546&api=v2> Diagram of gTLD Lifecycle
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, <http://etc.so/> 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>
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
.
<https://community.icann.org/download/attachments/59642802/RDS%20PDP%20List%
20of%20Possible%20Requirements%20D4%20-%20TriageInProgress%20-%2011%20Septem
ber.pdf?version=1&modificationDate=1473705495586&api=v2> Draft 4: RDS PDP
Initial List of Possible Requirements for gTLD registration data and
directory services (11 September 2016) [PDF] and
<https://community.icann.org/download/attachments/59642802/RDS%20PDP%20List%
20of%20Possible%20Requirements%20D4%20-%20TriageInProgress%20-%2011%20Septem
ber.docx?version=1&modificationDate=1473705508020&api=v2> [DOC] was
distributed on 12 September, containing new triaged PRs, new codings,
definitions for keywords and codings
. See slides (
<https://community.icann.org/download/attachments/61611153/Overview-of-PR-D4
-updates.pdf?version=1&modificationDate=1473789087176&api=v2> 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>
https://community.icann.org/x/shOOAwfor 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: Available at <https://community.icann.org/x/kRysAw>
https://community.icann.org/x/kRysAw
.
<https://community.icann.org/download/attachments/59642802/RDS%20PDP%20List%
20of%20Possible%20Requirements%20D4%20-%20TriageInProgress%20-%2011%20Septem
ber.pdf?version=1&modificationDate=1473705495586&api=v2> Draft 4: RDS PDP
Initial List of Possible Requirements for gTLD registration data and
directory services (11 September 2016) [PDF] and
<https://community.icann.org/download/attachments/59642802/RDS%20PDP%20List%
20of%20Possible%20Requirements%20D4%20-%20TriageInProgress%20-%2011%20Septem
ber.docx?version=1&modificationDate=1473705508020&api=v2> [DOC]
.
<https://community.icann.org/download/attachments/61611153/Overview-of-PR-D4
-updates.pdf?version=1&modificationDate=1473789087176&api=v2> Overview of
Update to Draft 4 of the PR List
.
<http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160630/ca1d889b
/EWGReport-Section2bPurposeStatement-0001.doc> EWG RDS Statement of Purpose
.
<https://community.icann.org/download/attachments/61611153/gTLD-Lifecycle.pd
f?version=1&modificationDate=1473789116546&api=v2> Diagram of gTLD Lifecycle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160913/dae033ed/attachment.html>
More information about the gnso-rds-pdp-wg
mailing list