Changes

Jump to navigation Jump to search
m
Christiane moved page ICANN 71 - The Hague* to ICANN 71 over redirect: Standardize
Line 1: Line 1:  
{{ICANNMeetings|
 
{{ICANNMeetings|
| logo            = ICANNLogo.png
+
| logo            = ICANN71logo.PNG
 
| dates          = June 14-17, 2021
 
| dates          = June 14-17, 2021
 
| location        = The Hague, NL  
 
| location        = The Hague, NL  
 
| host            =  
 
| host            =  
 
| venue        = Virtual
 
| venue        = Virtual
| website      = https://71.schedule.icann.org/  
+
| website      = [https://71.schedule.icann.org/ ICANN 71] (registration required)
 
| totalregistrants =
 
| totalregistrants =
 
| registration    =  
 
| registration    =  
Line 33: Line 33:  
::For instance, [[Volker Greimann]] asked, "Why is NIS2 focussing on [[DNS]] as opposed to hosting, e.g, where the content is? Why are Hosters not subjected to the same requirements?"
 
::For instance, [[Volker Greimann]] asked, "Why is NIS2 focussing on [[DNS]] as opposed to hosting, e.g, where the content is? Why are Hosters not subjected to the same requirements?"
 
*[[Paul Muchene]] and [[Jeff Neuman]] had a side discussion about [[RDAP]]. Paul: doesn’t it already do what these proposals seek? Jeff: RDAP is a technical protocol. It is policy agnostic.”  
 
*[[Paul Muchene]] and [[Jeff Neuman]] had a side discussion about [[RDAP]]. Paul: doesn’t it already do what these proposals seek? Jeff: RDAP is a technical protocol. It is policy agnostic.”  
*[[Alexander Seger]], representing the European Council, gave an update on the 2nd Additional Protocol to the Budapest Convention on Cybercrime on enhanced cooperation and disclosure of electronic evidence Budapest convention on cybercrime (the [[Budapest Convention]]), which has 66 member parties and concerns criminal law, not civil
+
*[[Alexander Seger]], representing the [[EC|European Council]], gave an update on the Second Additional Protocol to the [[Budapest Convention]] on Cybercrime on enhanced cooperation and disclosure of electronic evidence Budapest convention on cybercrime, which has 66 member parties and concerns criminal law, not civil.
    
====Reputation Block Lists====
 
====Reputation Block Lists====
Line 55: Line 55:  
===Policy===
 
===Policy===
 
====GNSO====
 
====GNSO====
 +
The GNSO held 18 sessions.
 
* [[Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data (EPDP)|EPDP Phase 2A Update]]<br/>
 
* [[Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data (EPDP)|EPDP Phase 2A Update]]<br/>
 
:Two outstanding issues:
 
:Two outstanding issues:
Line 68: Line 69:  
* Last year the RrSG became a formal professional (as opposed to commercial) association, and they held their first General Assembly at ICANN 71. Their legal office is located in Germany ([[Thomas Rickert]] Law Firm) so that they can have their own bank account and credit card.
 
* Last year the RrSG became a formal professional (as opposed to commercial) association, and they held their first General Assembly at ICANN 71. Their legal office is located in Germany ([[Thomas Rickert]] Law Firm) so that they can have their own bank account and credit card.
 
* [[Liz Behsudi]] from the [[I&JN]] gave a presentation on the think tank's [https://www.internetjurisdiction.net/domains/toolkit  DNS Abuse toolkit]. She discussed legal interoperability, the think tank's three foci, domains, content, and data, the importance of different thresholds for responses to DNS Abuse and understanding the typology of notifiers, and why the EU electronic evidence proposal may affect whois data.
 
* [[Liz Behsudi]] from the [[I&JN]] gave a presentation on the think tank's [https://www.internetjurisdiction.net/domains/toolkit  DNS Abuse toolkit]. She discussed legal interoperability, the think tank's three foci, domains, content, and data, the importance of different thresholds for responses to DNS Abuse and understanding the typology of notifiers, and why the EU electronic evidence proposal may affect whois data.
* [[Graeme Bunton]] presented on developments at the [[DNS Abuse Institute]], which is following the logic that there are two ways to reduce DNS abuse: # prevent it or # react to it. Bunton explained that economic realities indicate that there should be more emphasis on reactive solutions because they don’t have to be integrated into current technology. He also discussed [[CART]], which will include domain look-up, who’s reporting, type of malware/spam, and required information so that registrars can get information about abuse complaints from [[API]] and reporters can go to one place. He hopes it will be new, improved [[DAAR]], non-binary, better, fairer, and more concerned with the persistence than the existence of abuse.
+
* [[Graeme Bunton]] presented on developments at the [[DNS Abuse Institute]], which is following the logic that there are two ways to reduce DNS abuse:  
 +
# prevent it or  
 +
# react to it.  
 +
Bunton explained that economic realities indicate that there should be more emphasis on reactive solutions because they don’t have to be integrated into current technology. He also discussed [[CART]], which will include domain look-up, who’s reporting, type of malware/spam, and required information so that registrars can get information about abuse complaints from [[API]] and reporters can go to one place. He hopes it will be new, improved [[DAAR]], non-binary, better, fairer, and more concerned with the persistence than the existence of abuse.
 +
 
 
======RySG======
 
======RySG======
 
'''GeoTLD Group Community Session'''
 
'''GeoTLD Group Community Session'''
Line 130: Line 135:     
====ALAC====
 
====ALAC====
The key issues discussed in the ALAC meeting were: the prospects for [[SSAD]]; the [[U.S. Patent and Trademark Office v. Booking.com]] decision, the debate over whether domain names should be trademarked, and fears over the privatization of generic nouns; the potential policy implications of [[Verisign]]'s US Patent 10,979,384; and questions over why ICANN's GDPR response is talking so long: is it due to technical or policy complications?
+
The At-Large community held ten sessions about at-large policy, outreach, and operations.The key issues discussed in the ALAC meeting were: the prospects for [[SSAD]]; the [[U.S. Patent and Trademark Office v. Booking.com]] decision, the debate over whether domain names should be trademarked, and fears over the privatization of generic nouns; the potential policy implications of [[Verisign]]'s US Patent 10,979,384; and questions over why ICANN's GDPR response is talking so long: is it due to technical or policy complications?
 +
 
 
====SSAC====
 
====SSAC====
 
[[SAC115]]
 
[[SAC115]]
 
====RSSAC====
 
====RSSAC====
The RSSAC held a working session to develop the "Requirements for Measurements of the Local Perspective on the Root Server System." The main debate was over whether the data (results from the tool) should be made publicly available. If the tool is primarily for root server operators then the team should drop the recursive operator language. Likewise, there were concerns over the [[RFC]] language used around “data repository users should publish their results.” RSOs just using it for their own needs may hesitate if they know their results will be published elsewhere. Public availability may be fine for researchers. [[Wes Hardaker]] suggested that there could be a button on the results page that says “publish results;” he has had good results with this type of button on a DNSSEC checking tool. Thus, he argued results publication should be opt-in, not opt-out. Conversely, [[Brad Verd]] argued that data results should be shared in exchange for using the service and that the notice that users can opt out can be included at the beginning or end of the process. [[Paul Hoffman]] reminded the group to emphasize that the tool is for information, not giving best/good evaluations or determinations.
+
The RSSAC held a working session to develop the "Requirements for Measurements of the Local Perspective on the Root Server System." The main debate was over whether the data (results from the tool) should be made publicly available. If the tool is primarily for root server operators then the team should drop the recursive operator language. Likewise, there were concerns over the [[RFC]] language used around “data repository users should publish their results.” RSOs just using it for their own needs may hesitate if they know their results will be published elsewhere. Public availability may be fine for researchers. [[Wes Hardaker]] suggested that there could be a button on the results page that says “publish results;” he has had good results with this type of button on a [[DNSSEC]] checking tool. Thus, he argued results publication should be opt-in, not opt-out. Conversely, [[Brad Verd]] argued that data results should be shared in exchange for using the service and that the notice that users can opt-out can be included at the beginning or end of the process. [[Paul Hoffman]] reminded the group to emphasize that the tool is for information, not giving best/good evaluations or determinations.
 
 
 
=====DNSSEC & Security=====
 
=====DNSSEC & Security=====
Line 143: Line 149:  
# Multiple DNS providers <br/> It is difficult to accommodate the transfer of DNS services from one provider to another because the effects may be worse than expected. Multi-signer protocol (RFC 8901) has been completed but there are many moving parts and things left to do  
 
# Multiple DNS providers <br/> It is difficult to accommodate the transfer of DNS services from one provider to another because the effects may be worse than expected. Multi-signer protocol (RFC 8901) has been completed but there are many moving parts and things left to do  
    +
==References==
 
[[Category:ICANN Meetings]]
 
[[Category:ICANN Meetings]]
Bureaucrats, steward, Administrators, translator
2,307

edits

Navigation menu