The GNSO Next-Gen RDS PDP Working Group teleconference will take place on Tuesday, 25 October 2016  at 16:00 UTC for 90 minutes  

09:00 PDT, 12:00 EDT, 17:00 London, 18:00 CEST 

For other times:  http://tinyurl.com/jtazk2p

Proposed Agenda – RDS PDP WG Meeting – 25 October 2016     

1)      Roll call/SOI update

2)      Continue work on statement of purpose (latest version dated 19 October: https://community.icann.org/x/tiW4Aw)

3)      Brief update on ICANN57 plans:

  • Introduce approach for deliberations on possible requirements

4)      Confirm next meeting date: Thursday, 3 November 2016 at ICANN57 (see http://sched.co/8cxj)

Attendance

Apologies: Susan Prosser, Michele Neylon, Kal Feher, Sam Lanfranco, Andrew Sullivan, Peter Kimpian, Nathalie Coupet, Holly Raiche

Staff:

Mp3

AC Chat

Transcript


Notes 25/10 – RDS PDP WG Meeting

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 update

  • Roll call will be taken from AC
  • Please remember to update your SOI

2)  Continue work on statement of purpose

  • Latest version dated 25 October: https://community.icann.org/x/tiW4Aw)
  • Additional comments submitted by Peter Kimpian have also been reflected version displayed on-screen
  • re: proposed alternative term "ensure" - this may be too strong. "Promote" may not be the right term either - or is it a reasonable description?
  • re: leadership team proposed alternative phrasing - promoting both availability and accuracy may be desirable.
  • Another alternative phrasing:  "A purpose of RDS is to provide an authoritative source of registration data.  A purpose of RDS is to collect accurate data." We need to associate "accuracy" with "collection" in some way, not with display.
  • Is purpose statement co-mingling the goals of the RDS system with the goals of the policy framework surrounding it?
  • Note that "Authoritativeness" was discussed at length in the Thick Whois PDP WG:  see report https://gnso.icann.org/en/issues/whois/thick-final-21oct13-en.pdf at pp. 35-38
  • Further alternative phrasing: "A purpose of RDS is to provide authoritative access to registration data." Focuses on RDS providing access to data, obtained from authoritative source.
  • What's in the registry is authoritative. What the registrar collects is a separate issue. One of the reasons that a PDP decided that all gTLDs should be "Thick" is to ensure that registries had all of the data and could be authoritative.
  • Authoritativeness is "Not to be confused with accuracy: accurate data is not necessarily authoritative nor is authoritative data necessarily accurate." For example, "accurate" data for someone else may be used fraudulently in another registration. By some definitions, this would be considered "inaccurate."
  • Straw poll: "A purpose of RDS is to provide authoritative access to registration data." Question: What does "authoritative" mean in this context? Possible alternatives:  "access to authoritative registration data" or "provide an authoritative source of data." Authoritative may be considered more precise than "reliable."
  • Can #2 and #5 be merged with regard to authoritative source of information. [Note that listed data isn't necessarily exhaustive - that will be defined by policy.] If so, #5 can be dropped, at least with regard to "authoritative" - remaining text in #5 then deals with accuracy.
  • With regard to accuracy, a database store data to make it accessible - but this system may not be responsible for promoting accuracy. The requirement for accuracy should be applied to the data itself.
  • "Service" not equal "System" - the service reflects policy and should provide accurate data; a database system stores that data...
  • "Draft Registration Data and Directory Service Statement of Purpose" means we can talk about policy without tying it into a specific technical implementation.
  • We need to distinguish better between the instrument and the policy - proposed text "A purpose of RDS policy..."
  • We may need to look at every place we use "RDS" and determine what we mean by it, and whether it should be followed by "policy."

Action: Staff to capture this proposed text for #2 and #5, as well as Peter Kimpian's comments, for discussion on-line/after ICANN57.

3) Brief update on ICANN57 plans:

  • Introduce approach for deliberations on possible requirements
  • Refer to draft slides to be posted on meeting page and also used at ICANN57.
  • Iterating through 3 charter questions in a randomized manner, per our work plan - this proposal explores how that will occur.
  • Prerequisites, dependencies, codes, and keywords are not fixed but intended to help organize possible requirements in various ways during deliberation.
  • Randomized approach is intended to not favor one question over another and get past barrier that WG could not agree upon which should come first for deliberation
  • Iterative approach reflects interdependencies between questions, allowing all to be considered during deliberation
  • See proposed approach for selecting subsets for deliberation - gives us a place to start but allows for adjustment as we go

Action: Staff to re-distribute Mind Map along with draft slides describing this approach. All WG members to review these materials to prepare for our WG F2F meeting at ICANN57.

4) Confirm next meeting date: Thursday, 3 November 2016 at ICANN57 (see http://sched.co/8cxj)  


Meeting Materials:

 

 

  • No labels