[GNSO-Accuracy-ST] Accuracy definition updates

Fri Oct 29 16:35:09 UTC 2021

I'm in agreement with Sarah's wording.

The actual application of syntactic validation and operational validation
depends on the specific data elements.  For example, there's not much that
can be done to validate the syntax of the Name or Organization data
elements.  We will need specific requirements for each data element.

Attached is an attempt at capturing the complete set of collection,
validation and sensitivity rules.  V0 means no validation, V1 means
syntactic validation, V2 is operational validation, and V3 is identity
validation.  The reason for using ranges, e.g. V1..V3, is to allow
registrars to use higher levels of validation if they choose to.  If we
want to preclude them from doing so, it's easy to specify the precise level
of validation they must do, though I doubt that's the policy we actually
want.

The attachment is a draft.  Please do comment or ask questions.

Thanks,

Steve

On Fri, Oct 29, 2021 at 12:09 PM Sarah Wyld <swyld at tucows.com> wrote:

> Hello team,
>
> Thank you for the opportunity to consider further updates to the working
> definition of registration data accuracy.
>
> We have reviewed Michael’s suggested text and have some notes/questions
> (see below); we’re of course happy to discuss but think that the definition
> we proposed, including both the bold text sentence and the explanatory
> paragraphs following it, with some changes as noted below/taken from your
> proposal, is more clear.
>
> Notes:
>
>    - Technical contact data may not be provided by the Registrant, but
>    instead by the Account Holder, and accuracy requirements still apply.
>
>
>    - We have taken onboard the changes from Michael’s definition as
>       prompting update of our proposed definition to include the
>       Account-Holder-provided data
>
>
>    - The additional explanatory text (paragraphs below the bold-text
>    sentence) is important for explaining syntactical and operational accuracy
>    and should be included in the definition; this helps make the definition
>    clear and useful without trying to include all the information in the first
>    sentence.
>
>
>    - Also taken onboard the feedback re clarity of operational accuracy
>       and made adjustments in the relevant text
>
>
>    - Is there a singular definition of Registrar Data Directory Services
>    (RDDS) data  elements? We think “registration data elements” is more clear
>    and directly relates to the RAA and so we’ve stuck to that language here.
>
> Our updated working definition, based on current contractual and Consensus
> Policy requirements, with the updates from Michael’s proposed changes
> included:
>
> *Accuracy shall be strictly defined as syntactical accuracy of the
> registration data elements provided by the Registered Name Holder or
> Account Holder as well as the operational accuracy of either the telephone
> number or the email address.*
>
> To be determined to be *syntactically accurate*, the contact must satisfy
> all requirements for validity (see Whois Accuracy Program Specification
> <https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#whois-accuracy>
> Sections 1b-d). For example, for email addresses all characters must be
> permissible, the “@” symbol is required, and there must be characters
> before the “@” symbol.
>
> To be determined to be *operably accurate*, the contact must be operable
> as defined in the Whois Accuracy Program Specification
> <https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#whois-accuracy>
> Section f. The RAA currently requires validation of syntactical accuracy
> and verification of operational accuracy including an affirmative response
> from the Registered Name Holder for either email or phone.
>
>
>
> Thanks,
>
>
>
>
>
> --
>
> *Sarah Wyld*, CIPP/E
>
>
>
> Policy & Privacy Manager
>
> Pronouns: she/they
>
>
>
> swyld at tucows.com
>
> +1.416 535 0123 Ext. 1392
>
>
>
>
>
> *From: *Michael Palage <michael at palage.com>
> *Sent: *October 27, 2021 4:48 PM
> *To: *gnso-accuracy-st at icann.org
> *Subject: *[GNSO-Accuracy-ST] All Aboard !!!
>
>
>
> Hello All,
>
>
>
> Per my comments yesterday during our open plenary call, I made very clear
> that it is my strong desire to have our work complete by ICANN75.  In order
> for that to happen, there may be times that I will have to gently nudge in
> a neutral fashion people to get things done.  In advance of our call next
> week, I want to tee up a more in-depth discussion of a working accuracy
> definition.
>
>
>
> Listed below is current definition that the RrSG has extracted from the
> RAA:
>
>
>
> Accuracy shall be strictly defined as syntactical accuracy of the
> registration data elements provided by the Registered Name Holder as well
> as the operational accuracy of either the telephone number or the email
> address.
>
>
>
> Having read all the documents and listened to all of the
> comments/discussion I would like to put on the table for
> consideration/discussion the following friendly amendment.
>
>
>
> Accuracy encompasses both syntactical accuracy and operational accuracy of
> Registration Data Directory Service (RDDS) data elements processed by
> Registrars. Syntactical accuracy is imposed on all RDDS data elements
> processed by Registrars, whereas operational accuracy is only required of
> either email or telephone of RDDS data elements.  An additional requirement
> of operational accuracy is an affirmative response from the recipient to
> the confirmation request.
>
>
>
> The basis of these friendly amendments are as follows:
>
>
>
>    - I am proposing the definition to include syntactical and operational
>    accuracy for ALL data elements that are processes (including voluntary
>    ones) not just mandated ones. If a registrar is collecting data elements
>    they should apply the same standard to all elements, both mandatory and
>    voluntary.
>    - I do not believe that the operational aspect of the RrSG definition
>    properly encapsulated the affirmative response component set forth in the
>    Whois Accuracy Program Specification.
>
>
>
> Any thoughts or comments.
>
>
>
> If there are any alternative definitions, I ask that they be provided to
> the group via the mailing list 24 hours prior to our next call.
>
>
>
> Best regards,
>
>
>
> Michael
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> GNSO-Accuracy-ST mailing list
> GNSO-Accuracy-ST at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-accuracy-st
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
> 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...
URL: <https://mm.icann.org/pipermail/gnso-accuracy-st/attachments/20211029/7d7fcc28/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 9F73B6C55F1E4658A57DAA18B5854D29.png
Type: image/png
Size: 14057 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/gnso-accuracy-st/attachments/20211029/7d7fcc28/9F73B6C55F1E4658A57DAA18B5854D29-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Validation 2021-10-29.pdf
Type: application/pdf
Size: 530626 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/gnso-accuracy-st/attachments/20211029/7d7fcc28/Validation2021-10-29-0001.pdf>