[gnso-rds-pdp-wg] IMPORTANT: Notes from RDS PDP WG Meeting - 12 December

Lisa Phifer lisa at corecom.com
Wed Dec 13 02:18:40 UTC 2017


Dear all,

Below please find notes from today's RDS PDP WG meeting.

To recap Action Items from today's call: https://community.icann.org/x/MgByB

WG Agreement: Domain Name Management is a legitimate purpose for collecting
some registration data, based on the definition: Information collected to
create a domain name registration, enabling management of the domain name
registration, and ensuring that the domain registration records are under
the control of the authorized party and that no unauthorized changes or
transfers are made in the record.

Action: Staff to add above WG agreement to working document.

Action: Marc Anderson to suggest how to rephrase the agreed definition to
make the "because" explicit and share on-list for the full WG to respond to
on-list prior to next week's call.

Proposed WG Agreement (to be tested by poll): For the purpose of DN
Management, the following data is NOT needed:

.         

.        Tech Contact

.        Admin Contact

.        Registrar Abuse Contact

Action: Poll on the above proposed agreement to test level of support
(noting that both agreement and disagreement were expressed during the call)
and obtain rationale as input to continuing discussion on next week's call.

Best regards,
Lisa

 

Action Items and Notes from RDS PDP WG Call - 12 December 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.

1. Roll Call/SOI Updates

.        Meeting Materials:  <https://community.icann.org/x/MgByB>
https://community.icann.org/x/MgByB

.        Call Handout:
<https://community.icann.org/download/attachments/74580018/Handout-12Dec-RDS
WGCall.pdf>
https://community.icann.org/download/attachments/74580018/Handout-12Dec-RDSW
GCall.pdf

.        SOI updates: Maxim Alzoba moved UCTN CWG to past groups

2. Complete deliberation on Domain Name Management as a legitimate purpose

a. Review poll results for Domain Name Management

.        Poll Results:
<https://community.icann.org/download/attachments/74580018/AnnotatedResults-
Poll-from-5DecemberCall.pdf>
https://community.icann.org/download/attachments/74580018/AnnotatedResults-P
oll-from-5DecemberCall.pdf

.        100% support for DN management as a legitimate purpose collecting
some registration data

.        70% supported option (b) for definition of Domain Name Management:

o   Domain Name Management is a legitimate purpose for collecting some
registration data, based on the extended definition: Information collected
to create a new domain name registration, enabling management of the domain
name registration, and ensuring that the domain registration records are
under the control of the authorized party and that no unauthorized changes,
transfers are made in the record.

.        Comment #1 from poll results:

o   Creating, managing and monitoring a Registrant's own domain name (DN),
for the beneficial interest of that registrant, including creating the DN,
updating information about the DN, transferring the DN, renewing the DN,
deleting the DN, maintaining a DN portfolio, and detecting fraudulent use of
the Registrant's own contact information

.        Should Option (b) be expanded to reflect the additional concepts
and included tasks provided in Comment (1)?

.        Possible alternative combo:

o   Information collected for the benefit of the registrant to create a new
domain name registration, enable management of the registrant's own domain
name registration, and ensure that the domain name records are under the
control of the authorized party and no unauthorized changes or transfers are
made in the record. This includes performing tasks that include creating the
DN, updating information about the DN, transferring the DN, renewing the DN,
deleting the DN, maintaining a DN portfolio, and detecting fraudulent use of
a Registrant's own contact information.

.        Note that if unauthorized change is made to the Registrant name,
the definition may not cover that. Possible fix is to refer to "the
legitimate registrant"

.        Should the purpose be limited to beneficial use of the Registrant,
for the Registrant's own domain name?  Is the phrasing in option (b) more
appropriate as-is?

.        What does detecting fraudulent use of the Registrant's own contact
information mean? Registrants (for example, trademark owners) may look at
registration data to detect if their contact data is being used without
their permission in domain name registrations that are not theirs. "Used to"
may help to clarify this.

.        Not sure why we need _new_ domain name registration.  It's any
domain name registration - delete "new" from "creating a domain name
registration"

.        Should monitoring domain name registrations be split off as a
separate purpose - separate from controlling your own domain names?

.        "For the benefit of" and "For the beneficial interest of" are two
different concepts - if this is retained, this wording needs to be chosen
carefully

.        No opposition voiced on the call to accepting Option (b) as a WG
agreement with minor edits to replace "," with "or" and delete "new" as
shown below --

WG Agreement: Domain Name Management is a legitimate purpose for collecting
some registration data, based on the definition: Information collected to
create a domain name registration, enabling management of the domain name
registration, and ensuring that the domain registration records are under
the control of the authorized party and that no unauthorized changes or
transfers are made in the record.

Action: Staff to add above WG agreement to working document

.        We need to state WHY purposes are legitimate purposes -- for
example, WHY is DN Management a legitimate purpose? Because collecting this
information is necessary to ensure the security of the DN registration?
Because information is necessary to create the DN registration?

.        Is the "because" implicit in the definition? Is there value in
making the "because" more explicit?

Action: Marc Anderson to suggest how to rephrase the agreed definition to
make the "because" explicit and share on-list for the full WG to respond to
on-list prior to next week's call.

c. Deliberate on Data Elements needed for Domain Name Management (slide 5 of
handout)

.        We will look at each task (creation, management, etc.) for each
data element -

.        For example, are Tech Contact and Admin Contact needed for any of
the tasks identified as part of DN Management as a purpose?

.        Slide 6, Task 1: Creating a domain name - is there any data
identified by DT2 that is NOT needed to create a DN registration?

.        From a clean slate perspective, what data is needed for managing
the DN and registration of the DN? What MUST we have to have to accomplish
that task?

.        Deliberation on this question: What data is absolutely necessary
for each of the following tasks...

First, considering just this Task: Create registrant Id; create DN; add DNS
data for DN

.        Unclear that Tech and Admin contacts are required for the above
task

.        Are Registrar Abuse contacts needed (collected) for the above task?
They are not collected by the Registrar, but they may be collected by the
Registry (or derived from available data at Registry)

.        There are certain data elements collected from the Registrar by the
Registry - but not at the time of registration, instead associated with the
Registrar's "account" with the Registry

.        Some registry operators have an interest in vetting the Registrant
prior to DN registration (e.g., restricted gTLDs such as .travel) - this may
require additional data for creation

.        Do you just need the Domain Name itself? Later, you need additional
data to associate the DN with a Registrant.

.        Doesn't the Registry need information about the Registrar? (not
collected perhaps, but available to the Registry based on prior association)

.        Is Registrar Name needed? Or just obtained by the Registry from
data already known?

.        The registry must know what registrar crated the domain.  It
records that at the time of the domain creation.  Or associates it. 

.        "need not be collected" should be equivalent with "need not exist".
By this standard, is it accurate to say registrar name "need not be
collected" in order to register a domain name?

.        From chat: In cases, where Name Servers info is collected (ip
addresses) , Technical info is required (whom we might ask a question if
something is wrong with those IP addresses), and in case where the domain
name is registered without addition of Name Servers, then Tech contacts
might not be required

.        In summary, just for the purpose of creating the DN, some but not
all on the call agreed that the following data is NOT needed: Tech Contact,
Admin Contact, Registrar Abuse Contact

Next, considering ALL of the tasks identified by DT2 and the data needed for
all of those tasks:

.        Doesn't Task 6 fall under ICANN Contractual Enforcement purpose?

.        Are the following data needed for any of the tasks listed on slide
6?

o   Tech Contact

o   Admin Contact (see comment below)

o   Registrar Abuse Contact

.        Isn't admin contact necessary for 3? (manage set of DNs to keep
them under the same admin control)

.        Do we need to differentiate between collected and stored for data
that is provided by the Registrar or derived by the Registry as opposed to
collected from the Registrant?

.        Can we just agree upon what data is needed for this purpose,
regardless of where it may be obtained from?

.        Is Registrar ID but not Registrar Name needed for this purpose?

Proposed WG Agreement (to be tested by poll): For the purpose of DN
Management, the following data is NOT needed:

.        Tech Contact

.        Admin Contact

.        Registrar Abuse Contact

Action: Poll on the above proposed agreement to test level of support
(noting that both agreement and disagreement were expressed during the call)
and obtain rationale as input to continuing discussion on next week's call.

3. Time permitting, start deliberation on Domain Name Certification as a
legitimate purpose

.        Deferred to next call

4. Confirm action items and proposed decision points

WG Agreement: Domain Name Management is a legitimate purpose for collecting
some registration data, based on the definition: Information collected to
create a domain name registration, enabling management of the domain name
registration, and ensuring that the domain registration records are under
the control of the authorized party and that no unauthorized changes or
transfers are made in the record.

Action: Staff to add above WG agreement to working document.

Action: Marc Anderson to suggest how to rephrase the agreed definition to
make the "because" explicit and share on-list for the full WG to respond to
on-list prior to next week's call.

Proposed WG Agreement (to be tested by poll): For the purpose of DN
Management, the following data is NOT needed:

.         

.        Tech Contact

.        Admin Contact

.        Registrar Abuse Contact

Action: Poll on the above proposed agreement to test level of support
(noting that both agreement and disagreement were expressed during the call)
and obtain rationale as input to continuing discussion on next week's call.

5. Confirm next WG meeting: Wednesday, 20 December at 06:00 UTC

 

Meeting Materials (all posted at https://community.icann.org/x/MgByB)

.        Including Call Handout:
<https://community.icann.org/download/attachments/74580018/Handout-12Dec-RDS
WGCall.pdf?version=1&modificationDate=1513016827000&api=v2>
Handout-12Dec-RDSWGCall.pdf (includes poll results and DT2 and DT3
definitions)

.         

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20171212/686f936c/attachment-0001.html>


More information about the gnso-rds-pdp-wg mailing list