[gnso-rds-pdp-wg] IMPORTANT: Action Items and Notes from GNSO Next Generation RDS PDP WG Call - 29 August 2017

Amr Elsadr amr.elsadr at icann.org
Tue Aug 29 23:37:47 UTC 2017 

Dear Working Group Members,

Below are the action items and notes from today’s WG call. The action items, notes, meeting materials and recordings are all posted on the meeting’s wiki page here: https://community.icann.org/x/XmfwAw. The transcripts will be posted on the same wiki page, when they are available.

Thanks.

Amr


Action Items:


  1.  Volunteer team to engage in email discussion over the next 2-3 weeks to assist with proposing an alternative WG agreement to balance points of views expressed regarding the Original Registration Date. Volunteers identified: Benjamin Akinmoyeje, Andrew Sullivan, Volker Greimann, Tim OBrien and Jonathan Matkowsky (coordinator)
  2.  Staff to incorporate WG agreements accepted during this call into the working draft, and to draft a poll on proposed WG agreements and additional questions to help prepare the WG for deliberation in our next call.
  3.  All WG members to review the 29 Aug Handout<https://community.icann.org/download/attachments/66086750/RDSPDP-Handout-For29AugCall-v2.pdf?version=1&modificationDate=1504017543000&api=v2> to prepare for deliberation on additional proposed data elements in next week’s WG call.

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/XmfwAw

1) Roll Call/SOI Updates

  *   No updates to SOIs

2) 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


  *   Slide 1
     *   Ten data elements at the bottom of slide 1 of the 29 Aug Handout<https://community.icann.org/download/attachments/66086750/RDSPDP-Handout-For29AugCall-v2.pdf?version=1&modificationDate=1504017543000&api=v2> to be discussed if time allowed were deferred to 5 September call
  *   Discussion took place on the WG mailing list over the past week regarding the difference between RDS and Registrar data
  *   Another discussion that took place on the mailing list was regarding improving contactability of registrants
  *   All inputs (including possible inconsistencies between agreements) to be further considered during iterative second pass deliberation on all WG agreements

   b) Review poll results: AnnotatedResults-Poll-from-22AugustCall-v2.pdf<https://community.icann.org/download/attachments/66086750/AnnotatedResults-Poll-from-22AugustCall-v2.pdf?version=1&modificationDate=1503943692000&api=v2>


  *   Question 2: Reseller
     *   Question 2: Reseller must be supported by the RDS, and must be provided for inclusion in the RDS by Registrars
     *   72% Support the agreement, 8% did not support the agreement and 20% suggested alternatives
     *   5 WG members who suggested alternatives did not disagree with the statement, but rather suggested improvements
     *   Proposed alternative agreement developed by leadership following examining all the comments submitted: Reseller must be supported by the RDS, and must be provided for inclusion in the RDS by Registrars (if applicable)
     *   "If applicable" included in proposed text, as might not always be practically feasible to include a reseller (such as if no resellers are involved in the domain name registration)
     *   Should resellers be involved, the proposed WG agreement isn't specific on which reseller in the chain of resellers is to be included in the RDS (registrar-facing reseller vs registrant-facing reseller) - discussion deferred until deliberation on policy and/or implementation
     *   Current RAA does not require the registrars to include resellers in the data submitted by them (”MAY” in 2013 RAA)
     *   Suggestion to replace the second "must" with "may" in the proposed WG agreement, so that it reads: Reseller must be supported by the RDS, and MAY be provided for inclusion in the RDS by Registrars
     *   Rough consensus was achieved on the first part of this agreement, but that we are now re-polling on the second part of the agreement only - that is, whether the agreement should be "MUST" or "MAY" be provided for inclusion in the RDS.
     *   Resellers may act similarly to P/P providers or lawyers who register domain names on behalf of customers/clients - may be required to assume responsibility of domain name registration, so need to be contactable
     *   In chains of resellers, some resellers do not disclose who the resellers in their chain are to avoid poaching of both resellers and registrants - makes it difficult for registrars to identify and provide this information, and may increase customer confusion
     *   WG agreement should be considered a high-level concept without having to deal with underlying specifics at this time, especially regarding implementation details - this may be deferred
     *   Resellers, which are known to the registrars must be included
     *   AC Room show of hands of whether registrars MUST provide the reseller information: 11/39 WG member agree, 8/39 WG members disagree
     *   Tentative conclusion to accept the first part of the statement "Reseller must be supported by the RDS" - second part of the statement "and must be provided for inclusion in the RDS by Registrars (if applicable)" deferred
     *   Suggestion for WG members who belong to the RrSG to request formal opinion on inclusion of resellers in the RDS from the RrSG, as most registrars do not have relationships with resellers
     *   Registrars who do have a relationship with resellers may wish to reach out to them, and relay their concerns to the WG
     *   Agreement to re-poll on two variants - Must and May - with qualifier (if applicable) and noting that there may be a chain of Resellers

Proposed WG Agreement (to be confirmed through repolling): "Reseller Name must be supported by the RDS, and MAY be provided for inclusion in the RDS by Registrars. Note: There may be a chain of Resellers."


  *   Question 3: URL of Internic Complaint Site
     *   71% support for the agreement “The URL of the Internic Complaint Site must be supported for inclusion in the RDS.” with little opposition
     *   Majority of discussion on this question focused on whether the URL to the Internic site should be included in the RDS, or whether it should be on a generally published web page instead of being conveyed through the RDS
     *   Accept this result as initial rough consensus

WG Agreement (to be recorded in working draft as point of rough consensus): "The URL of the Internic Complaint Site must be supported for inclusion in the RDS."


  *   Question 4: Original Registration Date
     *   77% support for the agreement: The Original Registration Date must be supported for inclusion in the RDS.
     *   However, 19% explicitly did not support this proposed agreement.
     *   Several WG members were unsure on what "Original Registration Date" was referring to
     *   Collecting/identifying original registration date will be complicated for already registered domain names - may be easier for new domain names being registered moving forward - not clear that this would cost-effectively implementable
     *   Proposed WG Agreement (developed by leadership, based on poll results, including comments) The Original Registration Date (see footnote below) must be supported for inclusion in the RDS. Footnote: This agreement received both strong support and noteworthy opposition in 22 August poll. Further deliberation to address concerns raised, including this data element's definition, starting from the working definition given on page 57 of the EWG Report: This is different than the creation date since the creation date picks up the latest time that the domain name was registered; it is possible that the domain name was previously registered and subsequently deleted multiple times. The Original Registration Date denotes the first date that the domain name was ever registered.
     *   Security community regards the date of the most recent re-registration date of a domain name as important when investigating bad actors
     *   Created_on is part of the EPP specification - (maybe it's spelled createDate or something like that)
     *   The WG previously agreed upon a Minimum Public Data Set which includes Create Date. However, Original Creation Date proposed by the EWG is intended to reflect something different – see definition above.
     *   Another possibility is to add a data element that captures the create date of the last time this domain name was registered (prior to deletion and re-registration)
     *   Alternative proposal: The most recent prior registration date (if the domain has been re-registered by anyone, not necessarily the current registrant) must be supported for inclusion in the RDS.
     *   Should this field be mandatory to populate, it will be impossible for some registries to fill it in - may end up being false in some cases - despite this data being desirable, should not be mandatory
     *   Even if the original registration date can be definitively identified, what is its utility? Acquiring this data from a third-party may not make it reliably accurate
     *   Suggested interpretation is that a string for a domain name that has been discontinued then re-registered should be considered a new domain name despite the string having been previously registered
     *   Purpose of collection of this data should be identified and agreed upon prior to mandating its provision/collection. (Note: The WG already has an agreement that policy must include definitions for all data elements)
     *   Original registration date is helpful in tracking bad actors/malicious web sites
     *   A valuable use case on use of the original registration date, is when it pre-dates the registration of a trademark, which may indicate the benign intent of its registration should a dispute over the domain name arise
     *   Working definition given on page 57 of the EWG Report: This is different than the creation date since the creation date picks up the latest time that the domain name was registered; it is possible that the domain name was previously registered and subsequently deleted multiple times. The Original Registration Date denotes the first date that the domain name was ever registered.

ACTION ITEM: Volunteer team to engage in email discussion over the next 2-3 weeks to assist with proposing an alternative WG agreement to balance points of views expressed regarding the Original Registration Date. Volunteers identified: Benjamin Akinmoyeje, Andrew Sullivan, Volker Greimann, Tim OBrien and Jonathan Matkowsky (coordinator)


  *   Questions 5 and 6: Registrar Abuse Contacts
     *   80% supported Registrar Abuse Contact Email with no opposition
     *   68% supported Registrar Abuse Contact Phone with 28% opposition
     *   Some comments suggested that Registrars should have a choice of contact method
     *   Potential alternative proposed by WG leadership: A Registrar Abuse Contact must be supported for inclusion in the RDS, and must be provided by Registrars. Registrars should have a choice of abuse contact method(s) they support.
     *   Registrars individually choosing/creating their own abuse contact methods might make it complicated for enterprises to contact them - registrars may choose alternative abuse contact methods, but must provide email and telephone contact methods
     *   Reason for opposing phone as an abuse contact method: Information tends to get lost during phone calls during reporting of abuse
     *   There is a need to clarify what the purpose of the abuse contact is - should be limited to complaints regarding a domain name, not the web content or hosting associated with it
     *   Purpose of the abuse contact is a good example of why all data elements need to be defined
     *   If the WG deviates from the requirement of provision of email and phone contacts for abuse, other forms of contact should include non-proprietary methods of contact as requirements
     *   Note existing WG Agreement #31: At least one element enabling contact must be based on an open standard and not a proprietary communication method.
     *   Most Internet users who face a problem online do not know what the technical nature of the problem is - may not be certain which abuse contact to use
     *   1) A very recent Consensus Policy (effective 1 August 2017) just stated that Registrar Abuse Contact Email and Registrar Abuse Contact Phone MUST be PUBLISHED (and must therefore be provided by registrars). See https://www.icann.org/resources/pages/rdds-labeling-policy-2017-02-01-en #1 2) I therefore suggest this wording: "The Registrar Abuse Contact Email and Registrar Abuse Contact Phone must be supported for inclusion in the RDS, must be provided by Registrars, and must be published."
     *   Possible alternative proposed WG agreement: Per recently approved consensus policy (https://www.icann.org/resources/pages/rdds-labeling-policy-2017-02-01-en), The Registrar Abuse Contact Email and Registrar Abuse Contact Phone must be supported for inclusion in the RDS, must be provided by Registrars
     *   During a show of hands, 13/38 WG members on the call agreed with proposed possible alternative WG agreement above
     *   Cited CL&D Consensus Policy is based on the result of bilateral negotiations between registrars and ICANN while drafting the 2013 RAA
     *   Suggestion to include a "privacy abuse contact" – this suggestion captured for later discussion when the WG deliberates on additional proposed data elements
     *   Given strong support and no opposition to Email as an abuse contact method, and noteworthy opposition to Phone as a contact method, the following agreement only is accepted from the 22 August poll results.
     *   Might make sense to have one common method of contact regarding abuse across all registrars

WG Agreement (to be recorded in working draft as point of rough consensus): "The Registrar Abuse Contact Email Address must be supported for inclusion in the RDS, and must be provided by Registrars."

ACTION ITEM: Staff to incorporate WG agreements accepted during this call into the working draft, and to draft a poll on proposed WG agreements and additional questions to help prepare the WG for deliberation in our next call.

   c) Deliberate and consider next steps in relation to remaining data elements that more agreed upon or were unsure should be in RDS: 29AugustCall-Handout<https://community.icann.org/download/attachments/66086750/RDSPDP-Handout-For29AugCall-v2.pdf?version=1&modificationDate=1504017543000&api=v2>


  *   WG members should be prepared to discuss remaining data elements in this week's poll question 7: Fax, SMS, IM, Social Media
  *   Slides in this call's handout compiled the comments submitted in this week's poll, broken down for each data element


ACTION ITEM: All WG members to review the 29 Aug Handout<https://community.icann.org/download/attachments/66086750/RDSPDP-Handout-For29AugCall-v2.pdf?version=1&modificationDate=1504017543000&api=v2> to prepare for deliberation on additional proposed data elements in next week’s WG call.

3) Confirm action items and proposed decision points


  1.  ACTION ITEM: Volunteer team to engage in email discussion over the next 2-3 weeks to assist with proposing an alternative WG agreement to balance points of views expressed regarding the Original Registration Date. Volunteers identified: Benjamin Akinmoyeje, Andrew Sullivan, Volker Greimann, Tim OBrien and Jonathan Matkowsky (coordinator)
  2.  ACTION ITEM: Staff to incorporate WG agreements accepted during this call into the working draft, and to draft a poll on proposed WG agreements and additional questions to help prepare the WG for deliberation in our next call.
  3.  ACTION ITEM: All WG members to review the 29 Aug Handout<https://community.icann.org/download/attachments/66086750/RDSPDP-Handout-For29AugCall-v2.pdf?version=1&modificationDate=1504017543000&api=v2> to prepare for deliberation on additional proposed data elements in next week’s WG call.

Proposed WG Agreement (to be confirmed through repolling): "Reseller Name must be supported by the RDS, and MAY be provided for inclusion in the RDS by Registrars. Note: There may be a chain of Resellers."

WG Agreement (to be recorded in working draft as point of rough consensus): "The URL of the Internic Complaint Site must be supported for inclusion in the RDS."

WG Agreement (to be recorded in working draft as point of rough consensus): "The Registrar Abuse Contact Email Address must be supported for inclusion in the RDS, and must be provided by Registrars."

4) Confirm next WG meeting (Tuesday 5 September at 16.00 UTC)

Meeting Materials:

  *   29AugustCall-Handout<https://community.icann.org/download/attachments/66086750/RDSPDP-Handout-For29AugCall-v2.pdf?version=1&modificationDate=1504017543000&api=v2>
  *   22 August Call poll
     *   Link to participate: https://www.surveymonkey.com/r/22August17
     *   PDF of Poll Questions: Poll-from-22AugustCall.pdf<https://community.icann.org/download/attachments/66086750/SurveyMonkey_poll%20questions%2022%20August%202017.pdf?version=1&modificationDate=1503494133908&api=v2>
     *   SurveyMonkey Summary Poll Results: SummaryResults-Poll-from-22AugustCall.pdf<https://community.icann.org/download/attachments/66086750/SummaryResults-Poll-from-22AugustCall.pdf?version=1&modificationDate=1503854062000&api=v2>
     *   SurveyMonkey Raw Data Poll Results: RawDataResults-Poll-from-22AugustCall.zip<https://community.icann.org/download/attachments/66086750/RawDataResults-Poll-from-22AugustCall.zip?version=1&modificationDate=1503854077000&api=v2> and XLS<https://community.icann.org/download/attachments/66086750/RawDataResults-Poll-from-22AugustCall.xlsx?version=1&modificationDate=1503854087000&api=v2>
     *   Annotated Survey Results: AnnotatedResults-Poll-from-22AugustCall-v2.pdf<https://community.icann.org/download/attachments/66086750/AnnotatedResults-Poll-from-22AugustCall-v2.pdf?version=1&modificationDate=1503943692000&api=v2>



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

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