[gnso-rds-pdp-wg] IMPORTANT: Notes from RDS PDP WG Meeting - 5 September
Lisa Phifer
lisa at corecom.com
Wed Sep 6 04:22:23 UTC 2017
Dear all,
Below please find notes from today's RDS PDP WG meeting.
To recap Action Items from today's call:
. Staff to add the three WG Agreements from this call to the Key
Concepts Deliberation Working Draft Document
. Staff to circulate recommendations in which the EWG leveraged
Registrant Type as an illustration of the many ways it can be used, and to
launch a poll with an open-ended comment box on how identification of
"Registrant Type" might be useful
Best regards,
Lisa
Action Items and Notes from RDS PDP WG Call - 5 September 2017
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 here: <https://community.icann.org/x/YmfwAw>
https://community.icann.org/x/YmfwAw
1) Roll Call/SOI Updates
. No updates to SOIs declared
2) Brief updates: Legal analysis project, Action item(s) from last week,
ICANN60 plans
. Independent legal counsel (WSGR) was engaged to perform legal
analysis on the impact of data protection laws on registration data and
directory services. Counsel requested clarifications on WG questions sent to
them, which have now been addressed. Final report from WSGR will be
circulated to the WG once it is delivered, which is currently expected
before the end of September.
. WG F2F meetings at ICANN 60:
o First meeting will be on Saturday, 28 October: 08:30 - 12:00 local time
o Second meeting will be on Wednesday, 1 November: 16:00 - 18:30 local
time
o WG members are asked to plan ahead to attend these meetings, whether in
person or remotely
. Action Item on "Original Creation Date"
o Discussion underway in small group of volunteers, per action assigned in
last week's call
o A few proposals on WG agreements have been suggested and are being
discussed
o Small group is aware of the required schedule to provide proposed
agreement(s) text for deliberation back to the WG Leadership Team as well as
to the broader WG
3) Continue deliberation on Data Elements beyond MPDS
a) Charter Question: "What data should be collected, stored and disclosed?"
focusing first on set of data required in RDS
b) Reach agreement(s) based on poll results:
AnnotatedResults-Poll-from-29AugustCall.pdf
<https://community.icann.org/download/attachments/66086754/AnnotatedResults-
Poll-from-29AugustCall.pdf>
. Question 2: Reseller
. Poll results:
. Reseller Name MUST be supported by the RDS, and MAY/MUST be
provided for inclusion in the RDS by Registrars. Note: There may be a chain
or Resellers identified by Reseller Name.
. 62% (b) - MAY be provided and 28% (a) - MUST be provided.
. Confirms last week's agreement on the first half of the statement,
but demonstrates lack of consensus on MUST vs MAY be provided.
. Decision to adopt this option as a tentative WG agreement, and
defer discussion of MAY vs. MUST be provided to second pass deliberation in
Phase 1 or Phase 2/3.
WG Agreement: Reseller Name MUST be supported by the RDS. Note: There may be
a chain or Resellers identified by Reseller Name
. Question 3: Registrar Abuse Contact(s)
. Poll results:
. Per recently-approved consensus policy on consistent labeling and
display (
<https://www.icann.org/resources/pages/rddslabeling-policy-2017-02-01-en>
https://www.icann.org/resources/pages/rddslabeling-policy-2017-02-01-en),
BOTH the Registrar Abuse Contact Email and Registrar Abuse Contact Phone
must be supported for inclusion in the RDS, and MUST be provided by
Registrars: 75% Support this statement
. Question on why 25% of WG members objected to including the abuse
contacts in the RDS, since a requirement to make them accessible exists in
the RAA today - what is the reason to objecting to including these contacts
in the RDS?
. 3 of the poll respondents not supporting this statement do support
one abuse contact being required, but do not support both abuse contact
methods being required.
. Re: question about distribution of responses across SGs, Leadership
Team does regularly review poll results to ensure that all SGs are
appropriately represented in the poll responses, but does not necessarily
make a distinction on how SG responses are distributed across each
individual poll question's answers
. Objection is the requirement to provide two abuse contacts for
inclusion in the RDS - one should be enough
. 2013 RAA requires that two abuse contacts be provided for inclusion
in the RDS - other contacts (such as LEA contacts) might be more
objectionable
. Note that last week we had good support for abuse contact email
address and slightly less support for abuse contact phone number - but we
decided to try to be consistent with the recently adopted CL&D policy and
support collection of both
. Concerns about burden on smaller registrars to provide a 24/7 abuse
hotline; however, a requirement to provide an abuse phone number doesn't
imply a 24/7 hotline
. Registrars should be able to provide both email and phone contacts
for abuse purposes, regardless of size of the registrar
. Discussion on publication of abuse contacts deferred until access
requirements are on the WG agenda for deliberation
. Registrars may not want abuse complaints over the phone. May need a
paper trail for every complaint to cover liability. So if someone calls,
registrars may tell them to send an email. In this case, a phone number
helps no one, wastes registrars's time
. Communication via phone does not preclude an audit or paper trail,
and could potentially be an efficient and more timely method of
communication
WG Agreement: Per recently-approved consensus policy on consistent labeling
and display (
<https://www.icann.org/resources/pages/rddslabeling-policy-2017-02-01-en>
https://www.icann.org/resources/pages/rddslabeling-policy-2017-02-01-en),
BOTH the Registrar Abuse Contact Email and Registrar Abuse Contact Phone
must be supported for inclusion in the RDS, and MUST be provided by
Registrars.
.
. Question 4: Alternative Contact Method(s)
. No clear consensus on this question, however about 75% of choices
involved either ALL or an open-ended list of alternative methods of contact
. "Optional for registrants to provide" was helpful in the text of
the answer choices as opposed to only "Optional"
. Some ambiguity in the question: Are these alternative contact
methods being suggested as option in addition tomandatory email/phone
contacts? Yes, these are intended to be optional methods in addition to any
that may be explicitly required by other WG agreements.
. Open ended list of alternative contact methods could be implemented
by including both the method of contact and the value in two separate fields
(both optional to provide). For example, identifying SMS as an alternative
contact method type and providing the SMS-capable phone number as the
alternative contact method value.
. Concern raised on implementation of open-ended alternative methods
of contact without specifying standards - ambiguous, and may create
implementation difficulties
. Phase 2 will address specific policy and phase 3 implementation
guidance - now we need to identify info required and why
. Informal show of hands to indicate whether WG members agree with
collection of an open-ended list of optional alternative contact methods:
Broad support shown in the AC room with no objection
. Previous WG agreements included rough consensus on a requirement to
collect contact information such as email, but no WG agreement thus far on
collection of fax and physical address as contact methods
. Fax is just one "additional" method - some organizations still use
if for "official" correspondence.
. Fax may be a means to provide notice during legal correspondence -
may indicate a need to collect fax as a contact method
. RDS should support fax as an alternative contact method that is
optional to provide
. Proposed clarification: This WG agreement on alternative contact
methods does not preclude agreements on requirements to include other
contact methods.
. Informal show of hands on Revised WG agreement (see below): 11
agree, none disagree
. Requirements for phone and physical address will be deliberated on
a future WG call
(Revised) WG Agreement: In the interest of maximizing contactability,
additional contact methods MUST be supported by the RDS as an open-ended
list and be optional for Registrants to provide. This does not preclude
agreements on requirements to include other contact methods.
ACTION ITEM: Staff to add the three WG Agreements from this call to the Key
Concepts Deliberation Working Draft Document.
c) Deliberate on remaining data elements to reach additional agreements:
<https://community.icann.org/download/attachments/66086750/RDSPDP-Handout-Fo
r29AugCall-v2.pdf?version=1&modificationDate=1504017543000&api=v2>
29AugustCall-Handout
Registrant Type (see definitions by EWG on slide 11 of the
<https://community.icann.org/download/attachments/66086750/RDSPDP-Handout-Fo
r29AugCall-v2.pdf?version=1&modificationDate=1504017543000&api=v2>
RDSPDP-Handout-For29AugCall)
. Are there other Registrant Types that WG members would like to
propose?
. Should registrants have the option to declare which Registrant Type
they are? Can this be gamed?
. Why is the Natural Person the default registrant if field is left
blank - this might provide undue protection to Legal Persons that they may
not qualify for
. Note that definitions P/P Provider and Legal Person, Registrant
Types include implications for collection of additional registration data -
if the Registrant Type is a P/P Provider that is accredited by ICANN,
Contact ID of the accredited Privacy/Proxy Provider must also be supplied to
enable relay/reveal request escalation to the PP PBC (or designated Business
PBC in the case of a Legal Person for consumer inquiries and complaints) -
has implication on collection as well as display of data elements
. One significance of the choice between natural and legal persons is
privacy laws, which give higher levels of privacy to natural persons
. Nominet policy for .uk includes a verification step to ensure that
those who declare themselves as natural persons indeed are natural, not
legal persons - not clear how this can be done in the RDS, but worth noting
. Nominet has many different classification options for Registrant
Type, but validation of contact information is not associated with these
options
. Extensive discussions took place on the PPSAI PDP on commercial use
of a domain name - would not be advisable to repeat that discussion on this
PDP. (Note that the EWG declined to specify Commercial Use as a data
element; Registrant Type does not imply the domain name is used for
commercial activity.)
. With the evolving privacy law environment, it is helpful to know if
a registrant is a natural or legal person - legal persons should wish for
their contacts to be publicly available
. Processes may exist to resolve disputes on gaming when a legal
person self-identifies as a natural person
. "Undeclared" may be an appropriate option, even for legal persons,
if the domains registered are not used at all (such as being parked)
. Possible to add an extension to EPP to allow for a Registrant Type
to be declared, however extensions to the protocol is optional - needs to be
standardized from an implementation perspective, and must be uniform across
all registry operators and registrars - this will require a great deal of
work, and not clear that the benefit is worth the effort (time and money)
required to implement - Evaluation of value vs benefit should be made
. Discussing Registrant Type is a solution to a problem that the WG
does not completely have an understanding of yet - need to first understand
the privacy law context before offering a solution, such as Registrant Type
- suggestion to defer the decision until after the WG receives the final
legal analysis report on the implications of data protection laws on
registration data and directory services
. Might be helpful to include a poll question with an open-ended
comment box on how "Registrant Type" might be useful, then revisit the
discussion following the delivery of the final legal analysis report
regarding implications of data protection laws such as the EU GDPR
ACTION ITEM: Staff to circulate recommendations in which the EWG leveraged
Registrant Type as an illustration of the many ways it can be used, and to
launch a poll question with an open-ended comment box on how identification
of "Registrant Type" might be useful
4) Confirm Action Items and WG Agreements:
ACTION ITEM: Staff to add the three WG Agreements from this call to the Key
Concepts Deliberation Working Draft Document
ACTION ITEM: Staff to circulate recommendations in which the EWG leveraged
Registrant Type as an illustration of the many ways it can be used, and to
launch a poll question with an open-ended comment box on how identification
of "Registrant Type" might be useful
WG Agreement: Reseller Name MUST be supported by the RDS. Note: There may be
a chain or Resellers identified by Reseller Name.
WG Agreement: Per recently-approved consensus policy on consistent labeling
and display (
<https://www.icann.org/resources/pages/rddslabeling-policy-2017-02-01-en>
https://www.icann.org/resources/pages/rddslabeling-policy-2017-02-01-en),
BOTH the Registrar Abuse Contact Email and Registrar Abuse Contact Phone
must be supported for inclusion in the RDS, and MUST be provided by
Registrars.
(Revised) WG Agreement: In the interest of maximizing contactability,
additional contact methods MUST be supported by the RDS as an open-ended
list and be optional for Registrants to provide. This does not preclude
agreements on requirements to include other contact methods.
5) Confirm next WG Meeting: Tuesday, 12 September at 16:00 UTC
Meeting Materials (all posted at <https://community.icann.org/x/YmfwAw>
https://community.icann.org/x/YmfwAw)
. 29AugustCall-Handout
<https://community.icann.org/download/attachments/66086750/RDSPDP-Handout-Fo
r29AugCall-v2.pdf?version=1&modificationDate=1504017543000&api=v2>
(remaining data elements for deliberation)
. 29 August Call poll (closed COB Saturday 2 September)
o Link to participate: https://www.surveymonkey.com/r/DKQTQHP
o PDF of Poll Questions: Poll-from-29AugustCall.pdf
<https://community.icann.org/download/attachments/66086750/Poll-from-29Augus
tCall.pdf?version=1&modificationDate=1504063965000&api=v2>
o SurveyMonkey Summary Poll Results:
SummaryResults-Poll-from-29AugustCall.pdf
<https://community.icann.org/download/attachments/66086754/SummaryResults-Po
ll-from-29AugustCall.pdf?version=1&modificationDate=1504440919000&api=v2>
o SurveyMonkey Raw Data Poll Results:
RawDataResults-Poll-from-29AugustCall.zip
<https://community.icann.org/download/attachments/66086754/RawDataResults-Po
ll-from-29AugustCall.zip?version=1&modificationDate=1504441274000&api=v2>
and XLS
<https://community.icann.org/download/attachments/66086754/RawDataResults-Po
ll-from-29AugustCall.xlsx?version=1&modificationDate=1504441287000&api=v2>
o Annotated Survey Results: AnnotatedResults-Poll-from-29AugustCall.pdf
<https://community.icann.org/download/attachments/66086754/AnnotatedResults-
Poll-from-29AugustCall.pdf?version=1&modificationDate=1504545312000&api=v2>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170906/8f5739ac/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list