[GNSO-Accuracy-ST] Additional questions for ICANN Org

[Alan Greenberg]

Roger, 

My first sentence was less than clear.

I am submitting these questions to the scoping team for forwarding to ICANN Org.

I did raise the first questions in a meeting and was asked to put them in writing.

Earlier when we submitted questions to ICANN Org, we were assured that additional questions could later be submitted. My understanding is that our practice has been that the questions did not first need to be approved by the entire team.

Alan

On February 25, 2022 11:55:20 a.m. EST, Roger D Carney via GNSO-Accuracy-ST <gnso-accuracy-st at icann.org> wrote:
>Good Morning,
>
>As I don't think recall these questions being discussed by the Scoping Team, I assume Alan, that you are sending these to ICANN Compliance in your own capacity and not from the Accuracy Scoping Team?
>
>
>Thanks
>Roger
>
>
>________________________________
>From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces at icann.org> on behalf of Alan Greenberg <alan.greenberg at mcgill.ca>
>Sent: Thursday, February 24, 2022 11:08 PM
>To: Accuracy Scoping Team <gnso-accuracy-st at icann.org>
>Subject: [GNSO-Accuracy-ST] Additional questions for ICANN Org
>
>Caution: This email is from an external sender. Please do not click links or open attachments unless you recognize the sender and know the content is safe. Forward suspicious emails to isitbad at .
>
>
>
>I am submitting the following five questions to ICANN Compliance.
>
>Alan Greenberg, Member representing the ALAC
>The 2013 RAA Whois Accuracy Program Specification section 4 requires a
>Registrar take certain actions if it has any information that specific RDDS
>fields are wrong (fields references are any of the name, postal address,
>e-mail address, voice telephone number, and (where available) fax number).
>
>The example given in section 4 of having such information is: “Registrar
>receiving a bounced email notification or non-delivery notification message
>in connection with compliance with ICANN's Whois Data Reminder Policy or
>otherwise”.
>
>Question 1: In the view of ICANN Compliance, does this example apply only
>to Registrars who happen to monitor such email bounce or non-delivery
>notifications, or are Registrars obliged to do such monitoring?
>
>Question 2: If a Registrar is obliged to monitor such email notification
>of non-delivery, are they similarly required to monitor other delivery
>methods (such as postal mail failure to deliver, or a message to through
>the Registrar’s domain management portal never being viewed)?
>
>Question 3: If a Registrar is obliged to do such monitoring, does ICANN
>Compliance audit this requirement?
>
>
>
>Section 4 goes on to require that “Registrar must verify or re-verify, as
>applicable, the email address(es) as described in Section 1.f…”
>
>Question 4: With respect to the reference to “email address(es)”, since
>the information about inaccuracy may be about any of the name, postal
>address, e-mail address, voice telephone number, and (where available) fax
>number, is the Registrar only required to verify or re-verify the email
>addresses (even if the inaccuracy was in respect to one of the other
>fields)? If other fields are included, please be specific as to what fields
>must be verified or re-verified.
>
>
>Question 5: The ICANN Org comments on the RrSG definition of accuracy
>saying that accuracy requirements are not limited to syntactical and
>operational accuracy implies that it may also include the requirement that
>the field contents are in fact associated with the RNH, and lacking such
>association, they may be deemed inaccurate. Is this an accurate reading of
>the ICANN Org comment, and if not, please explain just what the
>characteristics are that might make such fields inaccurate (in cases which
>are not as blatant as Mickey Mouse residing on Main Street of Disneyland)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-accuracy-st/attachments/20220225/0a4cc374/attachment-0001.html>