steve at shinkuro.com
Mon Sep 27 16:33:20 UTC 2021
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
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
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
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
On Mon, Sep 27, 2021 at 11:56 AM Michael Palage <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
> It is key that you familiarize yourself with these documents as well as the
> instructions provided by the GNSO Council to this team (see
> 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.
> Best regards,
> Michael Palage
> GNSO-Accuracy-ST mailing list
> GNSO-Accuracy-ST at icann.org
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> the website Terms of Service (https://www.icann.org/privacy/tos). You can
> visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the GNSO-Accuracy-ST