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@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#whoi...> 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#whoi...> 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@tucows.com
+1.416 535 0123 Ext. 1392
*From: *Michael Palage <michael@palage.com> *Sent: *October 27, 2021 4:48 PM *To: *gnso-accuracy-st@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@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.
