Page History

Notes/ Action Items

Action Items:

1. Staff to add the 2 WG agreements resulting from the 12 September poll to the working document
2. Staff to distribute drafting team output on Original Registration Date to WG mailing list; all WG members invited to review and comment
3. Staff to prepare a poll to confirm support for the proposed WG agreement reached in this call; all WG members are encouraged to participate in the poll by COB Saturday23 September

Notes:

1. WG members invited to comment on whether the Additional Marketplace RPMs questions are in good enough form to send to Registry Operators for answers
2. Co-Chairs and staff to identify the targeted respondents for each question
3. Staff to research information published on websites of Registry Operators and TMCH providers, and provide links to information relevant to the Additional Marketplace RPMs questions, as well as a summary of the information that is discovered to be reviewed by the WG

Notes: 

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/ZGfwAw[community.icann.org] 

1) . Roll Callcall/updates to SOI Updates

•  None No updates to SOIs declared

2) Apply results of 12 Sept WG call to working document

• Results of the 12 September poll:

• Annotated Poll Results: https://community.icann.org/download/attachments/66086756/AnnotatedResults-Poll-from-12SeptCall.pdf
• 80% agreement that the RDS must support Registrant Postal Address data elements (Registrant street address, city, state/province and postal code), 20% disagree
• 92% agreement that the RDS must support Registrant phone + phone extension, 8% disagree

WG Agreement: The RDS must support Registrant Postal Address data elements: Registrant Street Address, City, State/Province, and Postal Code.

WG Agreement: The RDS must support Registrant Phone + Registrant Phone Ext (extension) data elements.

ACTION ITEM: Staff to add the 2 WG agreements resulting from the 12 September poll to be added to the working document

3)  Review recommendations from Drafting Team on Original Registration Date

• Concern of the Drafting Team with the Original Registration Date is that this is data that had not been previously collected - might present as false positives in the future
• If the data hasn't been collected, there is no way to know if the name has been deleted and re-registered
• If this feature is turned on, the earliest recorded registration date would present as the Original Registration Date, which would be a potentially misleading data element
• Team determined that it would be valuable to know if there was a previous registration of a domain object
• Team recommending instead that known occurrences of a domain object's registration be recorded and counted
• Counter would determine number of previous occurrences, or result in an unknown query result if there are no indications of previous registrations - no negative results should be counted, which may be due to unknown previous registrations - count should not be zero if no occurrences of previous registrations are counted, but instead should indicate “unknown”
• Benefit of counter would be to provide an indication of possible abuse, should the count increase suddenly over a short period of time
• Other counters that the Team has discussed included a count of domain transfers, or transfers between registrars - no consensus was reached on whether to include recommendations on them
• WG will not discuss the proposal during this call, but will revisit it when resuming discussion on data elements - WG members may discuss the proposal, and ask questions on the WG mailing list
• Team work and results encouraging as a technique in which a small group of volunteers can discuss a topic in detail, and return to the WG with draft text and rationale for full WG consideration over a 2-3-week period of time

ACTION ITEM: Staff to distribute drafting team output on Original Registration Date to WG mailing list; all WG members invited to review and comment

4) Resume deliberation on Purposes for gTLD registration data (see handout)

     a) Charter Question: For what specific (legitimate) purposes should gTLD registration data elements be collected?

    b) Review previous WG agreements on purposes for collection of data in the MPDS

• Handout: https://community.icann.org/download/attachments/66086756/RDSPDP-Handout-For20SeptCall-v2.pdf[community.icann.org]
• List of previously agreed to purposes for collection of data elements in the MPDS listed with related use cases in 20 September Call Handout on slides 3-5 (also listed without the use cases on slide 2)
• Previous WG agreement on public access to the MPDS - are previous WG agreements the combination of the agreements on purposes to collect the data elements in the MPDS, as well as public access to them?
• Concern raised over the previously agreed-to purposes for collection - these purposes may be appropriate for ICANN to disclose (provide access to) the data elements, but not for collection
• Purposes for which ICANN can collect data should be limited to ICANN's limited mission – perhaps ICANN should not be collecting data for the several purposes listed, but may display/provide access to data collected for legitimate purposes identified?
• Independent legal analysis (expected to be delivered soon) will provide information that may be useful to assess the appropriateness of ICANN collecting data elements for the agreed-to purposes
• The ICANN’s remit goes beyond support of the DNS - It's mission and values include the stable and secure operation of DNS, Preserve and enhance the operational stability, reliability, security, and global interoperability of the Internet, and so forth
• The purpose limitation principle states that personal data collected for one purpose should not be used for a new, incompatible, purpose.
• Some of the data elements in the MPDS are generated rather than collected, and play a role in the security and stability of the operation of the DNS

    c) Confirm updates to previous WG agreements on MPDS, for access

• Are the agreed-to purposes for collection of data elements in the MPDS considered legitimate purposes for access to the MPDS? - Need to align purposes for collection with WG agreements for MPDS public access
• General agreement that there are legitimate purposes for collecting MPDS - need to enumerate which purpose(s) they are
• Specifically, we already have several agreements on this: WG Agreement #2) Every data element in the MPDS should have at least one legitimate purpose, #3) Every existing data element in the MPDS does have at least one legitimate purpose for collection, and #23) RDS policy must state purpose(s) for public access to the MPDS
• Informal show of hands in the AC room on purposes for collection of data elements in the MPDS being legitimate purposes for access to the MPDS: 6/19 agree, 2/19 disagree
• Stated reason for disagreement: I'm putting disagree because I'm not sure it's that simple. I think we need to consider who has access for these purposes and under what circumstances. I don't think all these purposes would apply to unlimited public access.
• When considering the data elements that would be included in the MPDS, they were individually mapped to the legitimate purposes agreed-to for collection of data elements in the MPDS in order to identify at least one for each data element that would provide applicability for public access
• It is unclear how some of the purposes listed for collection of data elements in the MPDS (for example, legal action) are practically relevant without access to registrant data, which is not included in the MPDS. In other words, the purpose cannot be satisfied by only MPDS data elements, even if it makes use of (some) MPDS data elements.
• The MPDS needs to be public, so there is no way to prevent the use of this data for all the purposes listed for collection, however, the purposes themselves are not necessarily legitimate purposes for collection and access to the MPDS
• The purposes listed are not necessarily relevant to purposes for access to the MPDS, which is already publicly accessible, but may be more appropriate when considering purposes that may warrant requiring gated access to data beyond the MPDS
• All that is required is to identify one reason for collection and display of a public data element – example: the nameserver data must be public (minimum requirement), or the domain name would not work (although this is a DNS and not RDS requirement) – would other purposes for nameserver be irrelevant?
• WG Leadership Team to revisit the approach of use of these purposes for collection/access to the MPDS
• Disagreement between WG members on the call on whether data elements in the MPDS can be considered PII, or not
• Note WG Agreement #20 on access to the MPDS: gTLD registration data in the MPDS must be accessible without requestor identification, authentication, or stated purpose
• There may not be value in expanding the agreed-to purposes for collection of elements in the MPDS to purposes for display of the MPDS at this point
• Previous WG agreement #23: RDS policy must state purpose(s) for public access to the MPDS
• Informal show of hands in the AC room to be confirmed by poll - do you agree with this statement: There must be at least one purpose for collecting the MPDS and that purpose must include justification for making MPDS public - 7/19 agree, no disagreements
• Friendly amendments modified the proposed agreement to refer to purposes for each data element and to replace “justification” with sufficiency  -  see final text below
• Intent to move on to access of data beyond the MPDS during upcoming WG calls; many WG members on call supported moving on
• Poll question should include reference to the informal show of hands on this question during the call

Proposed WG Agreement (to be confirmed by Poll): There must be at least one purpose for collecting each data element in the MPDS, and that purpose must be sufficient for making that data element public.

ACTION ITEM: Staff to prepare a poll to confirm support for the proposed WG agreement reached in this call; all WG members are encouraged to participate in the poll by COB Saturday23 September

   d) Consider WG agreements on purposes for collection of data beyond MPDS (deferred)

   e) Discuss approach for deliberating on purposes for access to data beyond MPDS (deferred)

5) Confirm action items and proposed decision points

1. ACTION ITEM: Staff to add the 2 WG agreements resulting from the 12 September poll to be added to the working document
2. ACTION ITEM: Staff to distribute drafting team output on Original Registration Date to WG mailing list; all WG members invited to review and comment
3. ACTION ITEM: Staff to prepare a poll to confirm support for the proposed WG agreement reached in this call; all WG members are encouraged to participate in the poll by COB Saturday23 September

WG Agreement: The RDS must support Registrant Postal Address data elements: Registrant Street Address, City, State/Province, and Postal Code.

WG Agreement: The RDS must support Registrant Phone + Registrant Phone Ext (extension) data elements.

Proposed WG Agreement (to be confirmed by Poll): There must be at least one purpose for collecting each data element in the MPDS, and that purpose must be sufficient for making that data element public.

6) AOB

• Can the Leadership Team provide insight on what ICANN is doing with the EU Data Commissioners, and what will be happening at the upcoming meeting in Brussels?

• ICANN’s ad hoc GDPR compliance task force is attempting to arrange a meeting
• Leadership Team not aware of insight about this meeting beyond what has been publicly distributed
• Although unrelated to the GDPR compliance task force, note that Leadership Team is also expecting the final legal analysis report from outside counsel before the end of September 2017, and will distribute to the WG upon receipt

6) Confirm next WG meeting (Tuesday 26 September at 16.00 UTC)

Meeting Materials:

• 12 September Call poll (closed COB Saturday 16 September)

• Link to participate: https://www.surveymonkey.com/r/R27QB5W[surveymonkey.com]
• PDF of Poll Questions:Poll-from-12September-Call.pdf[community.icann.org]
• SurveyMonkey Summary Poll Results:SummaryResults-Poll-from-12SeptCall.pdf[community.icann.org]
• SurveyMonkey Raw Data Poll Results: RawDataResults-Poll-from-12SeptCall.zip[community.icann.org] and XLS[community.icann.org]
• Annotated Survey Results: AnnotatedResults-Poll-from-12SeptCall.pdf[community.icann.org]

2. Discuss proposed list of questions from Additional Marketplace RPMs Sub Team

• General question(s)/comment(s):
  • Sub Team did not make a list of data sources to collect in order to assist in answering the questions – following the WG review of these questions, if the WG agrees that data is required and if those are identified, they may be added to the current request being considered by the GNSO Council, noting that the data request submitted to the GNSO was specific to Sunrise Registrations and Trademark Claims – not known if this will require additional resources
  • If data is required, the WG will need to identify which Registry Operators run protected marks lists programs, and will have to carefully take into account when those programs came into effect - example: Donuts ran that program, but implemented it for gTLDs that it subsequently acquired, so might have provided Additional Marketplace RPMs following the Sunrise Period for those particular gTLDs
  • If statistics on DPML registrations are collected, would need to collect this data in a time-series format – different numbers of strings would be covered by a Protected Marks Lists depending on the date and the marketing of the program, and the increasing number of gTLDs being covered by the program
• Preliminary Note:
  • Original set of questions drafted by the Co-Chairs included a preliminary note from them, most of which was retained in the draft final report, as it provides the backdrop of what the Sub Team was meant to do
  • Only addition is the third paragraph that noted that some questions were deleted, with a link to where they have been archived as per the Sub Team request
• Question 1:
  • This question was moved up the list to serve as an overarching issue on the topic of Additional Marketplace RPMs
• Question 2:
  • Regarding the use of the term “non-mandated”, should a complete list of non-mandated RPMs be provided in order to mitigate against each WG member developing his/her understanding of what those might be?
• Question 3:
  • Not clear what relevance the information being sought has in determining the effectiveness of the ICANN-mandated RPMs – specifically, the question is asking who gets what information from where; how does this assist in understanding the effectiveness of RPMs such as the UDRP, URS or Sunrise?
  • Sub Team discussed this question and was somewhat split on whether to include the question, or not - but may be useful in terms of evaluating different uses of the TMCH takes place to support services beyond the ICANN-mandated RPMs
  • Primary purpose of retaining this question was to provide a greater understanding of the relationship between Additional Marketplace RPMs, and data made available via the TMCH
  • Explanatory note included for the benefit of the WG members - no plans to include it in potential surveys
  • These questions are not a questionnaire to go to others so much as the questions we think this WG should be considering. They may give rise to questions we ask others.
• Question 4:
  • Should the question in the first bullet be sent along with the questionnaire planned to be sent to TM owners (especially those who might have experienced being blocked by a Protected Marks List) on Sunrise and Trademark Claims?
  • The question presumes that it is possible for a trademark owner to use a Protected Marks List on a category of goods and services basis – is this level of granularity in the Protected Marks List service true?
  • The question is attempting to seek clarification on whether a Registry Operator that provides a Protected Marks List service is indeed providing protection to trademarks in their respective categories of goods and services, or whether the protection is not restricted to these verticals, and provides blocking services across all of the Registry Operator’s gTLDs – if true, this might affect trademark owners who own the same trademark in different categories of goods and services
  • Question may need to be reworded to clarify its intent
  • Might be more practical to send the question to Registry Operators who provide Additional Marketplace RPMs, as they develop their own rules, and would be in a better position to provide a response
• Question 5:
  • Regarding the term "exact matches", Donuts provides a service titled "DPML Plus" (http://donuts.domains/what-we-do/brand-protection/), which provides expanded matches - will this be addressed?
  • The Sub Team focused on exact matches only
  • Operators that extend the TM Claims Service beyond the mandated 90 days will only result in receipt of notices that correspond to exact matches to registrations in the TMCH - expanded matches should not be relevant to this question
  • Question 5 deals with the Claim services. Question 4 deals with DPML and speaks to the fact that there were variants of the DPMLs.
• Question 6:
  • No comments or questions
• Next Steps:
  • ACTION ITEM: WG members invited to comment on whether the Additional Marketplace RPMs questions are in good enough form to send to Registry Operators for answers
  • ACTION ITEM: Co-Chairs and staff to identify who the targets of each one of the questions are, and report back to the WG with suggestions
  • The WG needs to discuss whether there is any data relevant to answering the questions, and identify the sources for this data
  • Some of the information being sought is already available, so will not be necessary to request information from stakeholders, such as Registry Operators who publish their rules of use of the Additional Marketplace RPMs - this data can be collected and analyzed by staff and reported back to the Co-Chairs and the full WG
  • May still be useful to at least share the questions with others such as Registry Operators and Deloitte for feedback on the questions themselves, and what input they might have on the data that may be helpful to collect
  • Responses from Registry Operators may potentially be qualitatively superior to what is published on their websites as well as supplement what may be learnt from information on their websites, and may reveal how Additional Marketplace RPMs affect ICANN-mandated RPMs
  • May also be useful to get an understanding how the policies governing the Additional Marketplace RPMs have evolved over time – this would require Registry Operator input
  • ACTION ITEM: Staff to research information published on websites of Registry Operators and TMCH providers, and provide links to information relevant to the Additional Marketplace RPMs questions, as well as a summary of the information that is discovered to be reviewed by the WG
  • WG members may identify additional follow-up questions to the information that is publicly available
  • Staff is already starting to compile data in spreadsheets with tables and graphs on Sunrise Registrations including numbers of Sunrise Registrations, what types of registries offered them, as well as start and end dates for Sunrise Periods
  • Generally, these questions appear to address and/or be asking questions from the perspectives of trademark owners and Registry Operators, but not from the perspective of registrants who are not rights holders, and might be affected by these protections - is this something we should address now or later?
  • The Sub Team had a narrow remit to develop questions that would prompt fact-based responses from Registry Operators, TMCH provider and trademark owners on how the Additional Marketplace RPMs fit in with and influence the use of the ICANN-mandated RPMs, but not broad enough to seek answers from registrants or end users on how they may be affected
  • Should some of these questions (such as the first bullet in question 4) be included in surveys targeting registrants - how these services have affected them, were their registration attempts blocked?
  • Important to bear in mind what the remit of this PDP is, which is to review the ICANN-mandated RPMs – voluntary practices being offered by Registry Operators are not within the scope of this PDP, provided that none of these services are explicitly not permitted by ICANN

3. AOB

• Co-Chairs will participate in GNSO Council meeting later today to participate in the discussion on the motion to approve the WG's DMPM request form.
• The GNSO Council meeting is audiocast live for non-Councilors to listen in. The link to the audiocast as well as the agenda for this meeting, and documents, can be found here: https://gnso.icann.org/en/meetings/agenda-council-20sep17-en.htm  
• When will responses to the questions that were sent to INTA/Nielsen be provided?
• Has the schedule been impacted by the WG call being cancelled last week? - Schedule will remain the same with the APAC time zone friendly call remaining the fourth call of the month (including the cancelled call in the count)
• PDP timeline will be revised following the Council decision on the motion regarding the data request - the Co-Chairs and staff have been discussing the timeline, and ways to improve the effectiveness of the WG in making progress

4. Next steps/next meeting

•  The next Review of all Rights Protection Mechanisms (RPMs) in all gTLDs PDP Working Group is scheduled for Thursday, 28 September 2017 at 03:00 UTC for 90-minute duration.
• Drafting Team Action Item Response regarding "Original Registration Date" Original Registration Date - 18 September 2017[community.icann.org] and pdf[community.icann.org]
• RDSPDP-Handout-For20SeptCall-v2.pdf[community.icann.org]