Page History

Notes/ Action Items

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 below.

1) Roll Call/SOI Updates

• Roll call will be taken from Adobe Connect
• Please remember to state your name for transcription purposes and mute your mics when not speakingNathalie Coupet: Appointed as the Executive Director of Opera Company Brooklyn

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

b) Review poll results for alternative contact requirements – see SummaryResults__poll_from_16AugustCall.pdf[community.icann.org]

Alternative contact method

and consider possible WG agreement - see AnnotatedResults-Poll-from-8AugustCall.pdf

• Note summary and annotated results of the poll circulated
• Support mainly for options A & C
• In no way is this question intended to change or ignore WG Agreement #29 ("At a minimum, one or more e-mail addresses must be collected for every domain name included in the RDS, for contact roles that require an e-mail address for contactability"). The alternative contact method would be in addition to one or more email addresses which would be mandatory per WG agreement #29. The alternative contact would be to allow for some flexibility with regards to other communication methods.
• Proposed WG agreement to reflect the results of the pollPoll statement: In order to provide resiliency to overcome communication failure, at least one alternative contact method (possibly multiple alternative contact methods) MUST be supported by the RDS as an optional field(s)
• 68% of WG members who participated in the poll agreed with the poll statement, 8% disagreed and 24% proposed alternative wording. Note, several of those proposing alternative wording did support the underlying concepts of the poll statement.
• Suggested rewording by Marc Anderson: To improve contactability with the domain name registrant (or authorized agent of the registrant), the RDS must be capable of supporting at least one alternative contact method as an optional field. Optional submission of alternative contact methods suggested supported by several WG members.
• Suggestion to declare rough consensus on suggested rewording.
• WG leadership team discussed the possibility of requiring alternative contact methods including phone and physical address, but decided to defer discussion to a later time - current proposed alternative rewording allows for "optional" alternative contact methods.
• Some noted that not requiring alternative contact methods including phone and physical address may reduce resiliency of contactability.
• Key concept should focus on the capability of the RDS to support the collection of alternative contact methods, without defining what those alternative contact methods look like.
• Requiring alternative contact methods could be a business decision to increase resiliency of contactability. RDS could only require one validated contact method (such as email) - if a registrant is not contactable via the required contact method, could result in loss of the registration of a domain name.
• Don't have to have more than X contacts (currently 3 - e-mail/phone/physical - fax optional 4), but need to support the ability to handle things like social network contacts, SMS, chat, and future comms methods.  People can still make individual decisions on what to provide/support. Different contact methods work differently in different countries around the world - one contact method may work more effectively in one country, while another may be more effective as a communication method elsewhere.
• Proposed WG agreement in the poll requires that the RDS must support at least one alternative contact method (possibly multiple), without requiring their collection. The objection of a small number of WG member (5) on the call to the proposed WG agreement was noted during the call, with the majority of WG members on the call supporting the WG agreement as reworded: To improve contactability with the domain name registrant (or authorized agent of the registrant), the RDS must be capable of supporting at least one alternative contact method as an optional field. Objections to proposed rewording included that the statement lacks clarity, that alternative fields that must be supported should not be optional, and more than one alternative field must be supported by the RDS.

Preliminary WG Agreement: To improve contactability with the domain name registrant (or authorized agent of the registrant), the RDS must be capable of supporting at least one alternative contact method as an optional field.

ACTION ITEM: Staff to record preliminary WG agreement concerning alternative contact method in key concepts deliberation document.

PBCs

• . No objections noted during the call to this proposed WG agreement.
• Note that this WG agreement does not imply that providing such an alternative communication method would be obligatory - may need to be determined at a later stage. Need to be careful to not defer too many decisions to a later date. Other question that may remain open is how many alternative contact method fields need to be provided for.
• Staff to set up poll to confirm WG agreement via poll.
• In the poll, remind respondents that this proposed WG agreement needs to be considered in the context of the previous WG agreements.

Action item #1: Staff to conduct poll to confirm proposed WG agreement via poll ("In order to provide resiliency to overcome communication failure, at least one alternative contact method (possibly multiple alternative contact methods) MUST be supported by the RDS as an optional field(s)").

c) Start deliberation on contact roles

• See presentation provided by Rod Rasmussen during the previous WG meeting
• PBC Types identified in the EWG report: Poll Statement: PBC types identified ( Admin, Legal, Technical, Abuse, Proxy/Privacy, Business) must be supported by the RDS but optional for registrants to provide
• 65% of WG members who participated in the poll agreed with the poll statement, 17% disagreed and 17% proposed alternative wording. Of the latter, several put forward alternative wording similar to the statement in the poll - if added to 65% who support it, would indicate rough consensus.
• Suggestion of leadership team to declare rough consensus on the statement: PBC types identified (Admin, Legal, Technical, Abuse, Proxy/Privacy, Business) must be supported by the RDS but optional for registrants to provide
• If the PBCs identified are optional, and not provided by the registrant, what other contacts would be provided as alternatives? If no PBCs are provided, and primary contact method (email) fails, then the result would be that the registrant would be in danger of losing the domain name.
• Future discussions, such as on gated access, could result in limited access to specific contacts depending on the accessibility of the requestor (example: UDRP provider may be granted access to legal contact) –“ could this mean that a blank field is returned if no info is entered for that specific contact? If a registrant decides not to provide PBCs it makes the registrant responsible for all queries so it would likely default to the registrant contact info. The additional roles are provided as a convenience to the registrant if he/she wants to make a distinction.
• The answer to "what is the value when it has not been provided" is that there must be a default value.  The default value is simply copied from something, perhaps the registrant information - the additional roles are provided as a convenience to the registrant who wants to make a distinction. In the absence of PBCs, the role will default to the registrant.
• Would adding a clarification like the following help: "Should a registrant decide not to provide a separate contact for these PBCs, the registrant contact is expected to deal with queries relating to these purposes identified.", or “Should a registrant decide not to provide a separate contact for these PBCs, the registrant contact will be provided as the default info for these PBCs”?
• Concerns raised should be noted for further/future discussion, but possibly not a good time to be prescriptive on specific PBCs at this time - need to consider various possible issues around this discussion
• In cases of physical persons and/or small companies, all these PBCs are likely going to be duplicates. Note that this refers to roles, not necessarily separate contacts. Default could potentially be to have one individual as default with the option of providing other points of contacts for these roles, where applicable? Do note that a contact does not necessarily need to be covered by an individual, it could also be in the form of a group email for example, or different email addresses that would go to the same individual could be provided to facilitate communication.
• In the current system it doesn't really matter which role you attach to a certain entry. In an RDS, the contact point would be more clearly defined and facilitate these different roles.
• WG Agreement #27 may also be relevant in this context. May need to refine definitions to ensure consistency and accuracy across WG agreements.
• Should a different paradigm be considered instead of using contacts - should 'role' be used instead?
• How does privacy/proxy info affect entries for other contact types? May also result in same information being provided.
• Are there any roles listed here that should not be collected for the RDS 3/33 WG members on the call noted objection to accepting the statement: "PBC types identified (Admin, Legal, Technical, Abuse, Proxy/Privacy, Business) must be supported by the RDS but optional for registrants to provide" as a WG agreement.
• It was pointed out that all WG agreements are labelled preliminary and will need to be considered in conjunction with all other recommendations which could result in changes / updates. WG agreements are part of an iterative process, and should not be perceived as a final conclusion - WG agreements may very well be revisited as the need arises.

• ? Associated with each role there would need to be some type of contact, which may not need to be a named individual.
• Shouldn't collect information for anything that doesn’t exist. It may force people to create placeholders or to overload their contacts. For example, business or privacy/proxy may not apply to all types of registrants. Could have all fields there which would default to a certain field if no info has been provided for a certain contact type.
• Thinking is that most of this would be optional to be provided. Fields could be mandatory but optional to fill out? We are calling these "roles" but alternatively they can be seen as "nature of query" identifiers so "Legal" need not point to a lawyer. Purpose based roles / contacts.
• Related question is to how to authenticate the users of these contact points. This will be a significant challenge. Certain assumptions will need to be made in order to move this conversation forward in order not to get hung up on this issue now.
• Tentative WG agreement could be that PBC types identified (Admin, Legal, Technical, Abuse, Proxy/Privacy, Business) must be supported by the RDS but optional for registrants to provide.
• Should possible poll also consider what happens if information is not provided by registrant - does it remain blank or does it default to other contact type provided or registrant email? Display requirements could maybe wait until later.

ACTION ITEMAction item #2: Staff to record preliminary WG Agreement in key concepts deliberation document: set up poll to test support for possible WG agreement on this topic ("PBC types identified (Admin, Legal, Technical, Abuse, Proxy/Privacy, Business) must be supported by the RDS but optional for registrants to provide." )

c) Deliberate and consider next steps in relation to remaining data elements that most agreed should be in RDS (see AnalysisResults-Poll-from-28JuneCall.pdf)

• Focus of discussion on data elements (including mostly agreed data elements) is focused on possibility for collection in RDS, not access.
• Data elements already covered by previous WG agreements include Registrant Name/Organization, Registrant Country, Registrant Email, PBCs (Admin, technical and P/P) as well as PBCs discussed on today's call.
• Remaining data elements in the mostly agreed category to be considered include reseller, URL of Internic complaint site (ICANN WHOIS Problem reporting site), original registration date, registrar abuse contact email address and registrar abuse contact phone.
• URL of complaint site (INTERNIC site) is not distinct for individual registrants - not necessary to discuss in the context of collection of data to be included in the RDS. Not every data element is collected from the registrant (example: some data elements are generated)
• Registrar may not know the ultimate reseller, so may complicate collection of this data element. Dealing with collection of data of unknown resellers (such as chains of resellers) could be dealt with during implementation.
• No objection to the RDS supporting the 5 remaining data elements in the mostly agreed category – to be confirmed through poll.
• 5 data elements on which more WG members disagreed or were unsure: Registrant Fax + Registrant Fax Ext, Registrant SMS, Registrant IM, Registrant Social Media and Registrant Alt Social Media
  • Should the RDS support these 5 data elements?
  • Preliminary WG agreement from today regarding the RDS supporting at least one additional contact method (optional to collect) may cover the question of the RDS supporting these data elements - discussion on these 5 contacts provides further specificity on which alternative contact methods must be supported by the RDS, and may be collected. Some noted that it may not be necessary to provide this level of specificity with regards to alternative contact methods to accommodate new methods that may not exist yet. Alternative approach could be to consider optional "other" field that is free-form syntax. It could even be multi-valued (i.e., you can have more than one).
  • Some of these decisions are going to be influenced by the legal opinion on privacy considerations - The DPAs have pointed out in the past that over collection is an issue.  Does not mean the registrar does not have to collect it. But some elements might not be held in the RDS, let alone displayed or published.
  • Independent legal review on compliance with GDPR is expected to provide a final report soon, which may require some preliminary WG agreements to be revisited.
  • Faxes are sometimes used within certain legal contexts - this should be considered.

ACTION ITEM: Staff to create a poll to gauge support on 5 remaining mostly agreed data elements being supported by the RDS: reseller, URL of complaint site (INTERNIC site), original registration date, registrar abuse contact email address and registrar abuse contact phone

3) Confirm Action Items:

1.    ACTION ITEM: Staff to record preliminary WG agreement concerning alternative contact method in key concepts deliberation document as follows: “To improve contactability with the domain name registrant (or authorized agent of the registrant), the RDS must be capable of supporting at least one alternative contact method as an optional field”.

2.    ACTION ITEM: Staff to record preliminary WG Agreement concerning PCBs in key concepts deliberation document as follows: “PBC types identified (Admin, Legal, Technical, Abuse, Proxy/Privacy, Business) must be supported by the RDS but optional for registrants to provide”.

3.    ACTION ITEM: Staff to create a poll to gauge support on 5 remaining mostly agreed to data elements (per 28 June poll) being supported by the RDS: reseller, URL of complaint site (INTERNIC site), original registration date, registrar abuse contact email address and registrar abuse contact phone.

Preliminary WG Agreement: To improve contactability with the domain name registrant (or authorized agent of the registrant), the RDS must be capable of supporting at least one alternative contact method as an optional field.

Preliminary WG Agreement: PBC types identified (Admin, Legal, Technical, Abuse, Proxy/Privacy, Business) must be supported by the RDS but optional for registrants to provide

d) Deliberate on RDS vs Registrar Data

• Note discussion on this topic that occurred on the mailing list.
• Focus here is on RDS, not RDDS. Need to make sure that everyone is clear when they are discussing what they are referring to. Let's not get distracted by the words or what it is called. Is important to differentiate between the public system and the eco-system that sits behind that which collects/processes the information.
• Needs to be clear that registrars will collect information that will not go into the RDS. Not up to this WG to define what registrars do above and beyond what is required for the RDS.
• What is currently in the RAA is based on the current system, based on the recommendations of this WG, these requirements will likely change.

3) Confirm next WG meeting (Tuesday 22 4) Confirm next WG meeting (Tuesday 29 August at 16.00 UTC)