[gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose

Thu Oct 6 16:10:50 UTC 2016

I agree with Greg Aaron, Rod, Dick and others that dealing with accuracy is
very much in our scope.

Arguments to the contrary tend to look like a Defense of Bad Data.  I can't
think of any reasons to defend bad data, unless one wants a bad database.

It's reasonable to strive for perfectly accurate data, but accept that one
will never get there.  There should be commercially reasonable and
proportionate methods to get as close as practically possible.

We have not (in this group) discussed data migration, but assuming a
Garbage In, Garbage Out approach doesn't seem reasonable.  Whether all the
data is validated before migration, or just validated as part of a normal
validation cycle, it needs be validated.

Moving to a different attack vector on data accuracy, our scope doesn't
just include the output method or the end product.  We are dealing, if you
will, with the life cycle of the data.  Holly's helpful reminder of our
charter makes that clear, and wishing otherwise won't make it so.

Greg

On Thu, Oct 6, 2016 at 11:00 AM, Carlton Samuels <carlton.samuels at gmail.com>
wrote:

> +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-1799 <876-818-1799>Strategy, 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-bounce
>> s 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
>>
>
>
> _______________________________________________
> 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/91df46a1/attachment.html>