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 above. 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 speaking
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 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 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). 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: Admin, Legal, Technical, Abuse, Proxy/Privacy, Business
- 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 (Admin, Legal, Technical, Abuse, Proxy/Privacy, Business)? 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 item #2: Staff to 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." ) 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 August at 16.00 UTC)
|