NCSG-DISCUSS Archives

NCSG-Discuss

NCSG-DISCUSS@LISTSERV.SYR.EDU

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Rafik Dammak <[log in to unmask]>
Reply To:
Rafik Dammak <[log in to unmask]>
Date:
Sun, 11 Oct 2015 22:49:38 +0900
Content-Type:
multipart/alternative
Parts/Attachments:
text/plain (5 kB) , text/html (9 kB)
Hi Tamir,

2015-10-11 4:10 GMT+09:00 Tamir Israel <[log in to unmask]>:

> Thanks Rafik,
>
> On second though, I think you are probably right. I know for .CA, LEA
> requests go directly to CIRA but now that I think about it, it must be
> because of the way our WHOIS is setup. It would make sense for LEA requests
> to go to registrars rather than ICANN.
>
>
ccTLD space is another world, even more diverse and unknwon :)


> If that's the case though then, as you say, it might still be worth
> exploring transparency reports, even if these end up coming from the GAC or
> are imposed onto registrars via ICANN policy. As an accountability
> mechanism, these reports are becoming fairly standard to have in the
> telecommunications context..
>

ICANN sounds receiving requests and it happened that its teams get involved
in some operations which raised the issue about the expansion of ICANN
remit .


>
> Not sure if the DIDP process is the most appropriate mechanism for it
> though. Any thoughts on how something like that could be moved forward (or
> reasons why it should not be moved forward) would be appreciated.. There
> might be a clearer picture of how to design such a thing after the dublin
> meeting (which, regrettably, I cannot attend).
>
>
maybe not but the transparency report seems a good framework to start with
if we talk about compliance and abuse reports.  I won't think that ICANN
should push the registrars and registries for a specific way to do it , but
if we can work the contracted parties on that matter it will be worthy to
explore. there are already some guidelines/principles/ framework that we
can suggest here to registries and registrars. such transparency would
protect more users interests.

Best,

Rafik

>
> On 10/10/2015 9:28 AM, Rafik Dammak wrote:
>
> Hi Tamir,
> 2015-10-10 2:11 GMT+09:00 Tamir Israel <[log in to unmask]>:
>
>> Perhaps a single independent commissioner-type may make the most sense.
>> The trick I think would be to ensure independence. That tends to be
>> easier to do if there are more than one, because you can allocate one
>> per stakeholder group. Still, I think by encoding some criteria (no
>> strong industry or ICANN affil for 2 years back or something; nomination
>> committee w/CS representation; dedicated funding for independence) it
>> can be done.
>>
>> Another quick thought here: I did not see a proactive disclosure section
>> in the document. Would it be worth adding?
>>
>> Related, does anyone know if ICANN handles law enforcement requests or
>> whether these are handled by the registrars? If so, it would seem that
>> including the obligation to issue annual LEA transparency reports would
>> not be out of line.
>>
>>
>
> to be honest, it is unclear how ICANN handle direct requests from LEA,
> while we may get more information from registrars on the type of requests
> they get.
>  there is some work going with the new Compliance Chief Officer regarding
> how to handle requests or abuse reports (but not necessarily LEA) . here a
> blog post with some updates
> https://www.icann.org/news/blog/update-on-steps-to-combat-abuse-and-illegal-activity
> (there are 2 sessions at ICANN meeting in wednesday 21st Oct
> https://dublin54.icann.org/en/dublin54/schedule/wed-practices-combating-abuse
> & https://dublin54.icann.org/en/dublin54/schedule/wed-compliance . I
> invited weeks ago The Compliance Chief Officer to come to NCSG meeting in
> Tuesday 20th Oct so we can discuss with him.
>
> I would highlight that LEAs have their GAC Public Safety working group and
> it has several sessions in Dublin meeting too. that was shared by the LEAs
> representatives who came to NCSG meeting in Buenos Aires. it will be
> interesting to see what they are planning to do and push for.
>
> definitely, the idea of LEA transparency reports should be suggested .
>
> Best,
>
> Rafik
>
>>
>>
>> On 10/7/2015 8:46 AM, Michael Karanicolas wrote:
>> > That's a very interesting idea. I feel like the structure of appeals
>> > is probably the trickiest conceptual aspect of improving the DIDP, so
>> > good to consider alternatives. I think in part it would depend on the
>> > level of demand for information that ICANN gets, and how often appeals
>> > go forward. It's also important to bear in mind that, whoever is
>> > deciding these things, they need to have access to absolutely
>> > everything ICANN has, and a high level of familiarity with the inner
>> > workings of ICANN, so that they could determine, for example, whether
>> > particular information would compromise the integrity of ICANN's
>> > deliberative and decision-making process in line with the second
>> > defined condition for nondisclosure.
>> >
>> > This is in addition to the qualities Karel mentions (robust, cost
>> > effective, timely appeals) - which I also fully agree with.
>> >
>> > On Tue, Oct 6, 2015 at 2:12 PM, Tamir Israel <[log in to unmask]> wrote:
>> >> On 10/6/2015 1:02 PM, Michael Karanicolas wrote:
>> >>> This sort of brings us back to a fundamental challenge with reforming
>> ICANN's
>> >>> access to information system, which is the need for some sort of
>> analogous independent branch (I'm not completely certain the Ombudsman fits
>> the bill).
>> >> On this point, I'm not sure how far we dare go here, but would it be
>> >> unreasonable to set up an arb panel comparable to the ones private ones
>> >> used for the UDRP (only, of course, appointed by a cross-stakeholder
>> >> nomination committee and with strict independence criteria) for
>> >> evaluating such things?
>> >>
>> >> Best,
>> >> Tamir
>> >>
>>
>>
>>
>
>


ATOM RSS1 RSS2