michael at palage.com
Mon Sep 27 17:02:32 UTC 2021
Just to add to Marika’s helpful and timely comments. Our ICANN colleagues have also prepared some excellent preliminary briefing documents that I have been reviewing and which will be shared with the group shortly. We are trying to pace the flow of information, so as to not scare anyone off since we are still waiting for additional volunteers to join.
While SSAC was not included in the preliminary list that I had shared in my Welcome email, I can confirm that it was cited and summarized in Background Briefing Assignment #1, and detailed the three aspects of SAC 058 that you noted, e.g. syntactical validation, operational validation, and identity validation.
To Marika’s point please feel free to edit the document and supplement according.
From: Marika Konings <marika.konings at icann.org>
Sent: Monday, September 27, 2021 12:40 PM
To: steve at shinkuro.com; Michael Palage <michael at palage.com>
Cc: gnso-accuracy-st at icann.org
Subject: Re: [GNSO-Accuracy-ST] Welcome
Thanks, Steve, we will get this added to the index of relevant resources. Note we have updated the settings of the google doc so that anyone can add comments. If you spot anything else that is missing, please feel free to suggest in the document itself.
Caitlin, Berry and Marika
From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces at icann.org <mailto:gnso-accuracy-st-bounces at icann.org> > on behalf of Steve Crocker <steve at shinkuro.com <mailto:steve at shinkuro.com> >
Date: Monday, 27 September 2021 at 18:33
To: Michael Palage <michael at palage.com <mailto:michael at palage.com> >
Cc: "gnso-accuracy-st at icann.org" <gnso-accuracy-st at icann.org <mailto:gnso-accuracy-st at icann.org> >
Subject: Re: [GNSO-Accuracy-ST] Welcome
Thanks for taking this on.
I glanced quickly at the compilation of resources. I did not see a reference to SAC 058, "SSAC Report on Domain Name Registration Data Validation." I think this report, and in particular, Section 3, on pages 7-8, titled Taxonomy of Validation , are a solid basis for the work of this group.
Here is the text of section 3.
3. Taxonomy of Validation
Verification, validation and resolution have been used interchangeably in various literature on this topic. We choose “validation” to refer to the assessment of data as described by this document. Verification in this document refers to the process of validating. Resolution has an entirely different technical meaning that is out of scope for this document. The SSAC asserts there are three types of validation for elements of the registration data.
1. Syntactic Validation refers to the assessment of data with the intent to ensure that they satisfy specified syntactic constraints, conform to specified data standards, and are transformed and formatted properly for their intended use. For example, if the data element is expected to be an email address is it formatted as an email address? In general, it is expected that syntactic validation checks would be entirely automated and could be executed inline with a registration process, follow up information reviews, and whenever registration data changes. (See Edelman, B. (2002) Large-Scale Intentional Invalid WHOIS Data: A Case Study of "NicGod Productions" / "Domains For Sale” Cambridge, MA: Harvard University at http://cyber.law.harvard.edu/archived_content/people/edelman/invalid-whois/ [cyber.law.harvard.edu] <https://urldefense.com/v3/__http:/cyber.law.harvard.edu/archived_content/people/edelman/invalid-whois/__;!!PtGJab4!u5NwC2cny3f54eyaS5KogdELkowtqrc57gWQt0SEMd4ZGCZTcXc90_284soTrl_vi5OWsKhGXA$> )
2. Operational Validation refers to the assessment of data for their intended use in their routine functions. Examples of operational validation include 1) checking that an email address or phone number can receive email or phone calls; 2) checking that a postal address can receive postal mail; 3) checking that the data entered are self-consistent, i.e. that all data are logically consistent with all other data. It is expected that many operational validation checks would be automated and some could be executed inline with a registration process.
3. Identity validation refers to the assessment that the data corresponds to the real world identity of the entity. It involves checking that a data item correctly represents the real world identity for the registrant. In general, identity validation checks are expected to require some manual intervention.
On Mon, Sep 27, 2021 at 11:56 AM Michael Palage <michael at palage.com <mailto:michael at palage.com> > wrote:
Dear Scoping Team members,
I want to start by personally thanking everyone for volunteering for this effort. As you may have heard, I’ve recently been appointed by the GNSO Council to lead this effort.
While I know many of you know me, there are a couple of new faces so I would like to give a brief background about myself and my motivation for volunteering as chair.
I have been a participant in the ICANN multistakeholder model (MSM) now for almost 23 years and during that time I have served in a number of capacities, including the Chair of ICANN’s second ever Working Group, aptly name Working Group B. Suffice it to say that over the years I have had a front row seat watching the continued evolution of the Policy Development Process. During this time I have actively participated in a number of stakeholder groups, e.g. Registrars, Registries, Business, IPC, and ALAC. I believe this diverse background allows me see and understand topics from multiple perspectives, and will help me to ensure that all points of view are heard on these complex issues. As required by the rules, I must remain neutral in all of the discussions, but remaining neutral also means I have a duty to make sure that all relevant viewpoints are heard and addressed.
My primary motivation in volunteering for this effort is my concern about the ongoing sustainability of the MSM which I have devoted the past 23 years of my professional life trying to safeguard. Both those within the ICANN community, as well as others outside of it, have expressed to me their dissatisfaction with the MSM and how inefficient it can be. And although they raise some good points, I firmly believe that we can always do better and that we should never give up on improving the MSM.
When I first got involved in ICANN one of the strongest selling points of the MSM was that it could respond more quickly to market dynamics than traditional government/regulatory forces. My concern is that I see a growing number of my ICANN colleagues seemingly giving up on the MSM model and taking their issues directly to national governments or International Organizations rather than focusing on getting things done through the ICANN MSM. It is as if there is a perception that governments can more efficiently respond to market dynamics than can the MSM. I believe there needs to exist a symbiotic relationship between the ICANN policy development process and national legislative initiatives. This is all part of the grand public-private partnership which is ICANN.
The best way to help the efficiency of the MSM, in my humble view, is to become a part of it to demonstrate once again the value of the public-private partnership and to hopefully show that we can respond to market and regulatory demands. However, the ultimate success of this group is not driven by the chair, but rather by the cooperation and willingness of the Working Group members to be able to listen to all sides of an issues, understand the problems being faced, and to resolve to address those problems. This will of course necessitate compromise on all sides where appropriate.
I’ve asked the staff support team to help me in putting together a short survey which we will be circulating shortly in the next 24-48 hours. I really need everyone to complete this survey before our first call.
Finally, as you may have seen, we already have a workspace (see https://community.icann.org/x/hQIuCg) and the staff support team has already pulled together an index of relevant resources (see <https://urldefense.com/v3/__https:/docs.google.com/document/d/1UsNgPAVavQ0b257LVquHxPTZ7IPnp6fr/edit__;!!PtGJab4!u5NwC2cny3f54eyaS5KogdELkowtqrc57gWQt0SEMd4ZGCZTcXc90_284soTrl_vi5NB6yfk-w$> https://docs.google.com/document/d/1UsNgPAVavQ0b257LVquHxPTZ7IPnp6fr/edit# [docs.google.com]). It is key that you familiarize yourself with these documents as well as the instructions provided by the GNSO Council to this team (see https://community.icann.org/x/QoFaCg).
We have an incredible ICANN policy support team in Marika, Barry, Caitlin, Terry and others and I believe you will see that in the preparatory materials that they have prepared.
Our first meeting will be on Tuesday 5 October at 14.00 UTC for which you will receive a calendar invite shortly. In addition to introductions and sharing of expectations, I also plan to start a conversation on how to best organize and plan our work as our first order of business will be to develop a work plan. To support this conversation, the staff support team is working on a set of background briefings for each assignment that will be shared shortly. I am a big fan of using an agile approach so I would like the team to consider limiting the number of plenary sessions and trying to get some of the work done using small teams. But of course, a decision on this will be in your hands.
I look forward to working with all of you and please look out for further communications ahead of our first meeting.
GNSO-Accuracy-ST mailing list
GNSO-Accuracy-ST at icann.org <mailto:GNSO-Accuracy-ST at icann.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the GNSO-Accuracy-ST