+1
Volker
Give
us a simple form to fill out or whatever and we can do that.
I
suspect some of us will be trying to collect and share this
information anyway as part of our transparency reports
Road,Graiguecullen,Carlow,R93
X265,Ireland Company No.: 370845
Annual is periodic, right? So if every provider send ICANN an
email including this statistic data on or around Dec 31, this
recommendation would be fulfilled from the providers' side.
ICANN then only needs to aggregate this data and provide the
data to the public in aggregated form.
Let's aim for the simplest implementation. If you want, we
can discuss the format that these mails should have so you
have standardization if that worries you, but the
recommendation requires only this:
Name of provider:
Number of publication
requests received:
Number of publication
requests honored:
Number of disclosure
requests received:
Number of disclosure
requests honored:
Don't ask us to implement something for this if it can be
fulfilled much simpler.
Volker
Am 16.02.2018 um 16:58 schrieb Amy
Bivins:
Hi, All,
Apologies for the delayed
response on this one. To be clear—if you have ideas for
how we can make this easier for providers, while following
the WG recommendation, we can certainly make some changes
to this proposal. As a reminder, the WG recommendation
was:
“providers should be required to maintain statistics on
the number of Publication and Disclosure requests received
and the number honored, and provide these statistics in
aggregate form to ICANN for periodic publication. The data
should be aggregated so as not to create a market where
nefarious users of the domain name system are able to use
the information to find the P/P service that is least
likely to make Disclosures.” (See Final Report, p.
18).
The
recommendation for two reports—one showing requests by TLD
and another by registrar—was simply an idea for a way to
parse the data to gain more information, but we don’t have
to proceed this way. The thinking was that being able to see
numbers of requests by TLD and by registrar could provide
more information about where abuse (or alleged abuse) is
more or less frequent. But there’s nothing in the WG
recommendation that requires that.
However,
regarding the recommendation that providers simply be able
to send an email to ICANN with these numbers, we don’t think
this is feasible. There needs to be standardization of the
reports so that they can be aggregated and published on a
TBD frequency (if less-frequent than a month is preferred by
the IRT, we have some room to work here as the Final Report
didn’t specify frequency). We are proposing to use the RRI
interface, as contracted parties in the IRT expressed an
interest in this tool earlier in the IRT discussions.
Best,
Amy
Exactly
Michele,
I am not sure we can automate the tracking here when it
comes to disclosure requests without some serious
investment.
If we cannot automate this, it will be manual labor, which
is also very costly.
The tracking of the different phases is just way to complex.
Are we trying to solve something here or merely following
marching orders from the WG? Which is an option, but then I
would like to ask the WG if this is what they thought it
would be and if they realized the attached costs to such a
reporting system?
Theo
On 14-2-2018 15:42, Michele Neylon -
Blacknight wrote:
I’ve been discussing
this internally
One of the queries I
have is why on earth you need to generate two reports.
The TLD data is already included in the first one.
Road,Graiguecullen,Carlow,R93
X265,Ireland Company No.: 370845
Agreed
with Volker,
Perhaps we
should zoom in a little next week what exactly we
envision here. Part of the debate, what do these numbers
tell us exactly? How are they useful? Etc.
Theo
On 14-2-2018
12:08, Volker Greimann wrote:
As this
adds a whole new level of bureaucracy to the already
highly manual amount of work that abuse departments
have to deal with and as it is something that only
applies to privacy service providers and not to
registrars, we should aim at making this as
lightweight as possible. We should not require
additional implementatation work or APIs, a quarterly
or even annual email to ICANN should be sufficient.
Volker
Am 13.02.2018
um 21:22 schrieb Amy Bivins:
Dear
Colleagues,
A new draft
PPAA specification, the monthly reporting
specification, is ready for your review. This
specification includes the requirements for provider
reports to ICANN.
This
specification is proposed to implement the
recommendation from the Final Report,
“providers should be required to maintain
statistics on the number of Publication and
Disclosure requests received and the number
honored, and provide these statistics in aggregate
form to ICANN for periodic publication. The data
should be aggregated so as not to create a market
where nefarious users of the domain name system
are able to use the information to find the P/P
service that is least likely to make Disclosures.”
(See Final Report, p. 18).
We can
discuss this during our call next week if you have
any questions or comments. I’ll also be sending the
updated Applicant Guide to the list later this week,
for discussion on Tuesday.
Looking
ahead, we are working to finalize the RRI
Specification that accompanies the attached
reporting specification. The RRI Specification will
include the technical specifics for submitting these
reports via the API. I’ll send it to the list as
soon as it is available. We are also in the process
of reviewing the Labeling Specification, pursuant to
IRT feedback, and will have an updated draft for the
IRT to review as soon as possible.
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
_______________________________________________
Gdd-gnso-ppsai-impl mailing list
Gdd-gnso-ppsai-impl@icann.org
https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
_______________________________________________
Gdd-gnso-ppsai-impl mailing list
Gdd-gnso-ppsai-impl@icann.org
https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
_______________________________________________
Gdd-gnso-ppsai-impl mailing list
Gdd-gnso-ppsai-impl@icann.org
https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems
www.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems
www.twitter.com/key_systems
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.