Hi Sara,
Sorry for the delay—needed to consult
with the tech team on this one.
ICANN’s Registration Reporting Interfaces
(RRI) is a RESTful API that uses HTTP basic authentication
(RRI does not provide a graphic interface). This API is
currently used by both Registry Operators and Data Escrow
Agents for their daily and monthly reporting, and soon to
incorporate Registrar Data Escrow Agents as well.
For the reports, the contents to upload
are described in the PPSP reporting specification (CSV
formatted text files in UTF-8 encoding).
The draft reporting specification for
Privacy/Proxy is attached. We’ve updated this to account for
the discussion on the call this week that seemed to prefer
quarterly rather than monthly reporting, though we can
revisit that if we get more input on that specific point.
For reference, the latest public version of for the
Registries is available at https://tools.ietf.org/html/draft-lozano-icann-registry-interfaces
Thanks, and have a great weekend, all!
Amy
Amy,
Additionally,
it would be helpful if you could provide a bit more info re
Report Model, Issue 2. Does ICANN’s reporting interface
allow for files to be uploaded or is it a fill in the
blank interface? If uploads are allowed, is there a limit
on file size, type of file that can be used? Any
additional information on how this interface works or is
intended to work that would be very helpful.
Thanks,
Sara
sara bockey
sr. policy manager | GoDaddy™
sbockey@godaddy.com
480-366-3616
skype: sbockey
This
email message and any attachments hereto is intended
for use only by the addressee(s) named herein and may
contain confidential information. If you have received
this email in error, please immediately notify
the sender and permanently delete the original and any
copy of this message and its attachments.
Amy,
As you know, several registrars were not
able to attend Tuesday’s call and I think it’s safe to say
many members a facing bandwidth issues.
As you also know, GDPR is fast
approaching and several sessions were held this week on the
topic. GDPR is mission critical and requires a lot of
registrar time investment. That said, it is likely that IRT
members have not had a chance to listen to the recording or
catch up on the mailing list. Therefore, I think it would
be appropriate to allow an additional week to respond to our
punch list below. There is no reason why we cannot allow
this additional time. We are not facing a hard deadline as
with GDPR, and it is very important for this IRT to produce
quality work, not quick work.
Thanks,
Sara
sara bockey
sr. policy manager | GoDaddy™
sbockey@godaddy.com
480-366-3616
skype: sbockey
This
email message and any attachments hereto is intended
for use only by the addressee(s) named herein and may
contain confidential information. If you have received
this email in error, please immediately notify
the sender and permanently delete the original and any
copy of this message and its attachments.
Dear Colleagues,
This is a
reminder to please submit your input on the points below
no later than your EOD Friday.
We will make any
final edits to the PPAA draft based on this feedback and
intend to send you the updated draft on Monday as soon
as the final edits are complete and reviewed internally.
You aren’t expected to review the draft prior to
Tuesday’s meeting-I realize this is a tight turnaround-I
will explain edits that were made so that you can more
easily review the updated draft after our call next
week.
Dear
Colleagues,
Thank you for
your active participation on today’s Privacy/Proxy
IRT call. We covered a lot of ground. If you could
not attend, I encourage you to listen to the
recording, available on the wiki, https://participate.icann.org/p39onhjd1g1/.
Please
review the items discussed today (summarized
below) and provide any additional input to the
list no later than your EOD Friday, 23 Feb.
Monthly
Reporting Specification
- Issue 1:
Report frequency—IRT members seemed to support a
requirement that these reports be submitted
quarterly (current draft suggested monthly).
Absent contrary input on the list this week, this
change will be made in next draft.
- Issue 2:
Report submission—on-list, some IRT members said
that using ICANN reporting interface was too
complicated and/or unnecessary. No one commented
on this topic during today’s meeting. Absent
substantial input on this topic on-list this week
indicating that many IRT members would support a
contrary reporting mechanism, no changes will be
made on this point.
- Issue 3:
Report format—on-list, some IRT members took issue
with requiring both per-registrar and per-TLD
reports. During the call, some IRT members
indicating per-TLD could be too labor intensive,
but other IRT members supported having per-TLD
reports. Additional IRT input is requested on this
point.
- Issue 4:
Report fields—on-list, suggestions have been made
for eliminating some fields, and adding others.
Based on the discussion in today’s call (absent
contrary and/or additional suggestions on-list)
the specification will be updated to: eliminate
“total” numbers for requests for specific
contacts, eliminate “publication” fields for LEA
and IP requests, add publication/disclosure-other
fields to capture non-LEA/IP requests, add coded
“reasons for denial” fields.
PP
Applicant Guide
- Issue 1:
Shift to “rolling” application period (eliminating
application phases). IRT members supported this
approach. Absent contrary feedback on-list we will
proceed with this approach.
- Issue 2:
Elimination of many “essay” questions in favor of
“checkbox” questions. IRT members supported this
approach. Absent contrary feedback on-list we will
proceed with this approach.
- Issue 3:
Fees proposal. IRT requested additional
documentation of costs to support fees proposal
(ICANN org will work to provide this ASAP).
LEA
Disclosure Framework Specification
- Issue 1:
Language re: notices to customers in Sections 6.3
and 4.3, while not directly contradictory, sets
different standards for the timing of notice to
customers regarding an LEA request. Per IRT input
on-list and on today’s call, edits will be made to
make clear that Section 4.3 controls, and language
to 4.3 to make clear that provide will notify
customer of a request in accordance with ToS and
timeframe requested by LEA, subject to any other
requirements under applicable law or court order.
Any additional input on this is requested by the
end of the week.
- Issue 2:
Required provider responses to high priority LEA
requests. Per discussion on-list and during
today’s call, it appears that
- If
“action” is clearly defined to include (1)
disclosure of the requested information, (2)
refusal to disclose the requested information
for one of the reasons listed in section 4.2.2,
and/or (3) in exceptional circumstances,
informing LEA that the provider requires
additional time to respond, then
- The
IRT appears to find a 24-hour response time
acceptable for high-priority requests from LEA
that qualify for this specification.
- IRT
feedback is specifically requested on this
point. Please respond to the list noting
whether you (1) support, (2) oppose, or (3)
would edit (explain how) the requirement that
providers be required to action high-priority
requests from LEA within 24 hours of receipt
of the request from LEA. If there is
disagreement on this, this will be flagged
during the public comment period.
Best,
Amy
Amy E.
Bivins
Registrar
Services and Engagement Senior Manager
Registrar
Services and Industry Relations
Internet
Corporation for Assigned Names and Numbers (ICANN)
Direct:
+1 (202) 249-7551
Fax: +1
(202) 789-0104
Email: amy.bivins@icann.org
www.icann.org