[gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Carlton Samuels
carlton.samuels at gmail.com
Thu Oct 6 15:00:16 UTC 2016
+1.
Not to make too fine a point of it. But the EWG was tasked to re-imagine an
RDS. If this PDP is tasked to build on the works of EWG maybe it'd be
useful to re-visit certain ideas we now hold as verities.
-Carlton
==============================
*Carlton A Samuels*
*Mobile: 876-818-1799Strategy, Planning, Governance, Assessment &
Turnaround*
=============================
On Wed, Oct 5, 2016 at 7:38 PM, Holly Raiche <h.raiche at internode.on.net>
wrote:
> Folks
>
> Maybe we need to back up a bit and go back to the Charter and what we are
> supposed to be doing. Let me quote directly from it:
>
> First - background: Quoting the Charter on the Board decision to launch
> this PDP:
>
> *On 26 May, 2015, the ICANN Board passed a resolution adopting that
> Process Framework and reaffirming its 2012 request for a Board - initiated
> PD**P to define the purpose of collecting, maintaining and providing
> access to gTLD registration data, and to consider safeguards for protecting
> data, using the recommendations in the EWG’s Final Report as an input to,
> and, if appropriate, as the foundation for a new gTLD policy*
>
> Later - what The Charter tasked this Working Group with:
>
> *As part of its Phase 1 deliberations, **the PDP WG should work to reach
> consensus recommendations by considering, at a minimum, the following
> complex and inter-related questions:*
> * Users/Purposes: **Who should have access to gTLD registration data and
> why?*
> * Gated Access: **What steps should be taken to control data access for
> each user/purpose?*
> * Data Accuracy: **What steps should be taken to improve data accuracy?*
> * Data Elements: **What data should be collected, stored, and disclosed?*
> * Privacy: **What steps are needed to protect data and privacy?*
> * Coexistence: What steps should be taken to enable next-generation RDS
> coexistence with and replacement of the legacy WHOIS system?*
> *Compliance: What steps are needed to enforce these policies?*
> * System Model:What system requirements must be satisfied by any
> next-generation RDS implementation?*
> * Cost: What costs will be incurred and how must they be covered?*
> * Benefits: What benefits will be achieved and how will they be measured?*
> * Risks: What risks do stakeholders face and how will they be reconciled?*
>
> So accuracy’s there - along with a lot of other issues. That is not saying
> that accuracy is not covered in existing requirements on
> registries/registrars. But it is giving a broader meaning to RDS - i.e.,
> it’s not just about collection, maintenance and access to data; it’s also
> about safeguards, etc - using the EWG work.
>
> So thanks Rob. It’s a bit premature to rule issues out when they are well
> and truly on our table.
>
> Holly
>
>
> On 6 Oct 2016, at 6:37 am, Rod Rasmussen <rrasmussen at infoblox.com> wrote:
>
> Folks,
>
> Gotta chime in here, since the EWG provided a lot of thinking on this
> issue. If you haven’t already, please review the EWG report sections on
> data accuracy and also the concept of data validators and their
> relationship to the RDS. For example, I would note that a well-provisioned
> RDS would be able to provide some sort of validation checks against
> existing data in the use case of trying to prevent impersonation (a form of
> accuracy) of an existing registrant (a big brand like Facebook for
> instance). Another concept we found very important in the EWG is the idea
> of creating a contact data set tied to a contact ID that is portable
> between registrars and registries. This provides for the purpose-based
> contacts we talk about at great length in the report. It also is key for
> addressing some of the fundamental operational issues that lead to
> inaccurate, out-of-date data at various registrars. If you have a change
> in your contact information (a new e-mail for instance) and hold multiple
> roles in conjunction with many domains, you have a real challenge making
> updates throughout the universe of your domain names. Using a data
> validator and then acting via the RDS, when you make a change to your
> contact info, that automatically can be reflected in all domains you are
> associated with and thus improve accuracy tremendously. Those are just a
> couple examples of how an RDS can be involved in dealing with accuracy
> issues and represent many of the concepts you can address once you look
> beyond the current paradigm of registrar controlled contact information
> anchored specifically to individual domain names. Accuracy in the
> “generic” system (including registries, registrars, RDS, validators, some
> other group we haven’t thought of yet) is definitely in-scope. How that is
> done can take many forms and could have different roles played by different
> participants in the entire ecosystem.
>
> Cheers,
>
> Rod
>
> On Oct 5, 2016, at 10:36 AM, benny at nordreg.se wrote:
>
> But the data accuracy can’t be done in RDS, the accuracy is done on a
> registrar level when collecting data.
> RDS shall under no circumstances alter any information received from
> registry / registrars and showing any different info than what is collected
> on that level.
>
> WG can look at what accuracy they want registrars to do yes, but RDS
> doesn’t do anything.
>
> --
> Med vänliga hälsningar / Kind Regards / Med vennlig hilsen
>
> Benny Samuelsen
> Registry Manager - Domainexpert
>
> Nordreg AB - ICANN accredited registrar
> IANA-ID: 638
> Phone: +46.42197080
> Direct: +47.32260201
> Mobile: +47.40410200
>
> *From: *<gnso-rds-pdp-wg-bounces at icann.org> on behalf of "Metalitz,
> Steven" <met at msk.com>
> *Date: *Wednesday, 5 October 2016 at 19:32
> *To: *'Marika Konings' <marika.konings at icann.org>, Volker Greimann <
> vgreimann at key-systems.net>, "gnso-rds-pdp-wg at icann.org" <
> gnso-rds-pdp-wg at icann.org>
> *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement
> of Purpose
>
> Volker, what is the basis for your assertion that “data will be presented
> "as is" in this system, with no
> presumption of any prior cleanup work”?
>
> That statement will be true if we ultimately conclude that the current
> system is adequate and that we do not recommend establishment of a new
> RDS. However, if we do recommend a new system, then improvements to data
> accuracy are very much on the table, as the charter provision quoted by
> Marika indicates.
>
> Steve Metalitz
>
>
> *From:* gnso-rds-pdp-wg-bounces at icann.org [mailto:gnso-rds-pdp-wg-
> bounces at icann.org <gnso-rds-pdp-wg-bounces at icann.org>] *On Behalf Of *Marika
> Konings
> *Sent:* Wednesday, October 05, 2016 12:53 PM
> *To:* Volker Greimann; gnso-rds-pdp-wg at icann.org
> *Subject:* Re: [gnso-rds-pdp-wg] For your review - updated RDS Statement
> of Purpose
>
> Volker, please note that the PDP WG Charter (see https://community.icann.
> org/x/E4xlAw) includes the following question:
>
> *As part of its Phase 1 deliberations, **the PDP WG should work to reach
> consensus recommendations by considering, at a minimum,
> the following complex and inter-related questions:*
> *(…..)*
> · *Data Accuracy:* *What steps should
> be taken to improve data accuracy?*
> *(……)*
>
> Best regards,
>
> Marika
>
> On 05/10/16 05:58, "gnso-rds-pdp-wg-bounces at icann.org on behalf of Volker
> Greimann" <gnso-rds-pdp-wg-bounces at icann.org on behalf of
> vgreimann at key-systems.net> wrote:
>
> I would move to strike all references to data quality altogether from
> this document, e.g. "current", "accurate" etc.
> These are already required by existing policies and agreements and do
> not have to be referenced again at this point. We should focus on
> having
> to reflect the data as provided by the RNH at this stage, not make any
> presumptions about its quality.
>
> After all, data will be presented "as is" in this system, with no
> presumption of any prior cleanup work.
>
> Best,
> Volker
>
> >> THE purpose of the "Registration Data Service" (hereafter referred
> to
> >> as
> >> "RDS") is to manage authorised parties' access to information about
> >> [gTLD Domain Names, gTLD Nameservers, gTLD Registries and gTLD
> >> Registrars]
> >>
> >> Purpose 3(a/b) are possible use cases, not Purposes as such
> >>
> >> "Accurate" is definitely not a term to use if we ever expect to
> finish
> >> - "Current" would be more accurate (sic) / appropriate.
> > Agreed, with one minor suggestion:
> >
> > "access to information about generic top-level domain registries,
> registrars, names, and name servers."
> >
> > Scott
> > _______________________________________________
> > gnso-rds-pdp-wg mailing list
> > gnso-rds-pdp-wg at icann.org
> > https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
> --
> Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
>
> Mit freundlichen Grüßen,
>
> Volker A. Greimann
> - Rechtsabteilung -
>
> Key-Systems GmbH
> Im Oberen Werk 1
> 66386 St. Ingbert
> Tel.: +49 (0) 6894 - 9396 901
> Fax.: +49 (0) 6894 - 9396 851
> Email: vgreimann at key-systems.net
>
> Web: www.key-systems.net / www.RRPproxy.net <http://www.rrpproxy.net/>
> www.domaindiscount24.com / www.BrandShelter.com
> <http://www.brandshelter.com/>
>
> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
> www.facebook.com/KeySystems
> www.twitter.com/key_systems
>
> Geschäftsführer: Alexander Siffrin
> Handelsregister Nr.: HR B 18835 - Saarbruecken
> Umsatzsteuer ID.: DE211006534
>
> Member of the KEYDRIVE GROUP
> www.keydrive.lu
>
> Der Inhalt dieser Nachricht ist vertraulich und nur für den
> angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe,
> Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist
> unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten
> wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
>
> --------------------------------------------
>
> Should you have any further questions, please do not hesitate to
> contact us.
>
> Best regards,
>
> Volker A. Greimann
> - legal department -
>
> Key-Systems GmbH
> Im Oberen Werk 1
> 66386 St. Ingbert
> Tel.: +49 (0) 6894 - 9396 901
> Fax.: +49 (0) 6894 - 9396 851
> Email: vgreimann at key-systems.net
>
> Web: www.key-systems.net / www.RRPproxy.net <http://www.rrpproxy.net/>
> www.domaindiscount24.com / www.BrandShelter.com
> <http://www.brandshelter.com/>
>
> Follow us on Twitter or join our fan community on Facebook and stay
> updated:
> www.facebook.com/KeySystems
> www.twitter.com/key_systems
>
> CEO: Alexander Siffrin
> Registration No.: HR B 18835 - Saarbruecken
> V.A.T. ID.: DE211006534
>
> Member of the KEYDRIVE GROUP
> www.keydrive.lu
>
> This e-mail and its attachments is intended only for the person to
> whom it is addressed. Furthermore it is not permitted to publish any
> content of this email. You must not use, disclose, copy, print or rely on
> this e-mail. If an addressing or transmission error has misdirected this
> e-mail, kindly notify the author by replying to this e-mail or contacting
> us by telephone.
>
>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20161006/59f465e1/attachment.html>
More information about the gnso-rds-pdp-wg
mailing list