ICANN/GNSO GNSO Email List Archives

[council]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [council] For your review - GNSO Review of GAC Communique Hyderabad

  • To: policy@xxxxxxxxxxxxxxx
  • Subject: Re: [council] For your review - GNSO Review of GAC Communique Hyderabad
  • From: Rubens Kuhl <rubensk@xxxxxx>
  • Date: Mon, 12 Dec 2016 19:30:13 -0200
  • Authentication-results: mail.nic.br (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br
  • Cc: Marika Konings <marika.konings@xxxxxxxxx>, "council@xxxxxxxxxxxxxx" <council@xxxxxxxxxxxxxx>
  • Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.br; s=dkim; t=1481578213; bh=qvCBLUb45ge7YBfS4w7n+D8nilMqvHasvaUqY801EtU=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=BldulrUiu/fAOIgXAV3HgIx+SHURxRJldb+aimNaGC88v2h+I9A3ov+knrsDlSzKQ jZvGOWaxzxcXPMa7+56xgIfk7agF59BYyPp9KlUNztuDoKrkFqP/Qd8YibfqD0J15w +piCytXsunegGYXYLlPGu9OCUJHKoMcir95W0HFw=
  • Dmarc-filter: OpenDMARC Filter v1.3.1 mail.nic.br 728E31D399B
  • In-reply-to: <20161212131037.196dc3a93c35c991bce5ceb11d0fbfbb.d89331e591.wbe@email17.godaddy.com>
  • List-id: council@xxxxxxxxxxxxxx
  • References: <20161212131037.196dc3a93c35c991bce5ceb11d0fbfbb.d89331e591.wbe@email17.godaddy.com>
  • Sender: owner-council@xxxxxxxxxxxxxx

Paul,

Setting apart what the role of ICANN and contracted parties are in this matter, 
we need to be aware that there are fundamental limitations that would prevent 
any of such entities to do what is described in the text. 

Currently, there is no Computer Science standard to define what is an abuse, 
its taxonomies or how to report them; it's not much different from the famous 
obscenity definition: "I know it when I see it.". So even if we somehow put 
ICANN in the role of making such standards, which would be unprecedented since 
standards in this area until now came from ISO, IETF, M3AAWG and APWG, it would 
fail miserably due to lack of a theoretical framework to base such standards 
on. 

That's why most of the work in the Information Security field refer to 
"practices"; this allow for not hardcoding a phenomena that is always fast 
evolving and be more effective by being more adaptable. 
I would even challenge the use of "best practices" in the context below since 
it would require a greater level adoption in the field, but this is a confusion 
that is already widely spread in a number of ICANN documents, unfortunately. 



Rubens


> Em 12 de dez de 2016, à(s) 18:10:000, policy@xxxxxxxxxxxxxxx escreveu:
> 
> Hi All,
> 
> The IPC has had a chance to consider the draft language for Section 2 and 
> propose the following (heavily) edited draft response:
> 
> ___________________________
> The GNSO Council would like to express concern that the list of questions set 
> out in Annex 1 has been categorised as “advice”.  In this context, the term 
> “advice” ought to be given its ordinary dictionary meaning, and a request to 
> the Board to provide various data and information does not constitute “GAC 
> Advice”, as this term is used in the ICANN Bylaws.  Since GAC Advice has a 
> specific status and treatment under the under the ICANN Bylaws, precision of 
> terminology is crucial to avoid any perception that there is an attempt to 
> direct the Board, rather than making a request for information and attempting 
> to impose a reasonable deadline for its provision.  That said, the GNSO 
> Council looks forward to reviewing ICANN’s responses to the questions listed 
> in Annex 1 to the Communiqué.   Some contracted parties to ICANN have or are 
> in the process of developing a number of “best practices” initiatives related 
> to registry and registrar operations. ICANN is responsible for setting 
> standards for abuse reporting and performance when determining compliance 
> with contractual obligations. The issue of DNS Abuse Mitigation raised by the 
> GAC may also be dealt with by the GNSO in GNSO PDP Working Groups, producing 
> relevant Consensus Policy recommendations then duly adopted by the Board.  
> Further, the issue of DNS Abuse Mitigation raised by the GAC is dealt with by 
> the GNSO as the issue arises, whether it be various active and/or open 
> projects on the Projects List 
> <https://gnso.icann.org/en/meetings/projects-list-28nov16-en.pdf>, or as part 
> of GNSO Policy Activities <https://gnso.icann.org/en/council/policy>. 
> ___________________________
> 
> I'm very happy to discuss the rationale for these proposed changes.  
> 
> Best,
> Paul
> 
> 
> -------- Original Message --------
> Subject: [council] For your review - GNSO Review of GAC Communique
> Hyderabad
> From: Marika Konings <marika.konings@xxxxxxxxx 
> <mailto:marika.konings@xxxxxxxxx>>
> Date: Thu, December 08, 2016 11:48 am
> To: "council@xxxxxxxxxxxxxx <mailto:council@xxxxxxxxxxxxxx>" 
> <council@xxxxxxxxxxxxxx <mailto:council@xxxxxxxxxxxxxx>>
> 
> Dear All,
>  
> Please find attached for your review the proposed GNSO Review of the GAC 
> Communique. This draft has been developed by the small drafting team that was 
> formed at ICANN57 consisting of Donna Austin, James Bladel, Heather Forrest, 
> Phil Corwin, Michele Neylon, Paul McGrady and Carlos Guttierez. Please share 
> any comments and/or input you may have with the mailing list. Consideration 
> of this document is also on the agenda for the GNSO Council meeting on 15 
> December. 
>  
> Best regards,
>  
> Marika
>  
> Marika Konings
> Senior Policy Director & Team Leader for the GNSO, Internet Corporation for 
> Assigned Names and Numbers (ICANN) 
> Email: marika.konings@xxxxxxxxx <mailto:marika.konings@xxxxxxxxx>  
>  
> Follow the GNSO via Twitter @ICANN_GNSO
> Find out more about the GNSO by taking our interactive courses 
> <http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages 
> <http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-efforts.htm#newcomers>.
>  



<<< Chronological Index >>>    <<< Thread Index >>>