[council] Re: what about a process to review/evaluate whether SSAC recommendations warrant action by the GNSO

Alan Greenberg alan.greenberg at mcgill.ca
Fri Dec 20 03:20:05 UTC 2013


As Patrik said, this is just being developed. It 
is populated with more recent ALAC advice and a 
lot of SSAC advice. The format is evolving and I 
am guessing on the next iteration will be populated with more data.

Alan

At 19/12/2013 03:04 PM, Mike O'Connor wrote:
>wow.  will you look at that!  another terrific 
>resource i'd never heard of before.
>
>i imagine this is the first time folks on the 
>Council list are seeing this reply from Patrik, 
>since he's not subscribed.  but for those of you 
>who don't already know, Patrik is the Chair of 
>the SSAC.  i'll elevate his "Advice to the ICANN 
>Board" link up into this reply post to make sure the rest of you see it
>
><https://www.myicann.org/board-advice>https://www.myicann.org/board-advice
>
>i agree -- it could be really useful to link the 
>GNSO into this process a bit more 
>proactively.  one of the appealing things about 
>that page is that it covers ALAC advice as 
>well.  this might also tie into our GAC - GNSO 
>engagement initiative that is under way.  this 
>page is still a pilot, but it's promised that a 
>more mature version will be rolled out 
>sometime.  this looks like a good starting point 
>for that review-process i'm 
>envisioning.  Patrik, have you figured out an 
>automated way to monitor that page?
>
>thanks!
>
>mikey
>
>
>On Dec 19, 2013, at 11:03 AM, Patrik Fältström 
><<mailto:patrik at frobbit.se>patrik at frobbit.se> wrote:
>
>>Mikey,
>>
>>I think you can/should tie an initiative like 
>>this to the new tracking mechanism that is 
>>built and tested for the SSAC and ALAC recommendations.
>>
>><<https://www.myicann.org/board-advice>https://www.myicann.org/board-advice>
>>
>>    Patrik Fältström
>>    SSAC Chair
>>
>>On 19 dec 2013, at 17:53, Mike O'Connor 
>><<mailto:mike at haven2.com>mike at haven2.com> wrote:
>>
>>>dear all,
>>>
>>>i would like to introduce a gap-closing 
>>>proposal for the GNSO -- namely, to take a 
>>>hard look at SSAC reports and determine 
>>>whether any of their recommendations bear on GNSO Consensus Policy.
>>>
>>>this gap between what the SSAC says and the 
>>>GNSO does has been an issue for me for quite 
>>>some time, and i think one easy way to close 
>>>it would be to routinely take up each SSAC 
>>>report and make that determination.  there 
>>>would likely be cases where we review the 
>>>reports among the stakeholder groups and conclude that:
>>>
>>>-- there are NO recommendations that require PDPs
>>>-- there ARE recommendations that require PDPs, or
>>>-- there are recommendations that we would 
>>>like to know more about before we decided whether a PDP is in order.
>>>
>>>
>>>i'll give an example of the reason why this is 
>>>on my mind.  in 2005 the SSAC produced an 
>>>extensive report that addressed the issue of 
>>>domain-name hijacking.  in 2011, six years 
>>>later, the members of the IRTP-B working group 
>>>stumbled across the following observation in 
>>>that ancient report and realized that it would be a good idea
>>>
>>>Collect emergency contact information from 
>>>registrants, registrars, and resellers for 
>>>parties who are suited to assist in responding 
>>>to an urgent restoration of domain name 
>>>incident. Define escalation processes 
>>>(emergency procedures) that all parties agree 
>>>can be instituted in events where emergency contacts are not available.
>>>
>>>
>>>it took six years for that very common-sense 
>>>idea to find it's way into Consensus 
>>>Policy.  and it probably took another year or 
>>>two to implement.  and it was all practically by accident.
>>>
>>>what if we:
>>>
>>>-- discuss this "formally review SSAC reports" 
>>>idea with our stakeholders and on the Council list for a while
>>>
>>>-- put an agenda item on our next call to 
>>>share what we've heard and test a way forward
>>>
>>>-- get started, presuming nobody thinks this is a horrible idea
>>>
>>>
>>>i've attached the recommendations from the 
>>>three (count 'em, three) SSAC reports that 
>>>were released in Buenos Aires.  just to give 
>>>you an idea of the substantive reports that 
>>>the SSAC is producing.  i think it would be 
>>>really helpful to run these through a process 
>>>to decide which, if any, of these 
>>>recommendations warrant action via PDP.  there 
>>>are plenty more SSAC reports to review in the backlog.
>>>
>>>thanks,
>>>
>>>mikey
>>>
>>>
>>>
>>>
>>>SAC061:  SSAC Comment on ICANN’s Initial 
>>>Report from the Expert Working Group on gTLD Directory Services
>>>
>>><http://www.icann.org/en/groups/ssac/documents/sac-061-en.pdf>http://www.icann.org/en/groups/ssac/documents/sac-061-en.pdf
>>>
>>>Recommendation 1: SSAC reiterates its 
>>>recommendation from SAC055: The ICANN Board 
>>>should explicitly defer any other activity 
>>>(within ICANN’s remit) directed at finding a 
>>>‘solution’ to ‘the WHOIS problem’ until the 
>>>registration data policy has been developed 
>>>and accepted in the community. The EWG should 
>>>clearly state its proposal for the purpose of 
>>>registration data, and focus on policy issues over specific implementations.
>>>
>>>Recommendation 2: The ICANN Board should 
>>>ensure that a formal security risk assessment 
>>>of the registration data policy be conducted 
>>>as an input into the Policy Development Process.
>>>
>>>Recommendation 3: SSAC recommends that the EWG 
>>>state more clearly its positions on the 
>>>following questions of data availability:
>>>
>>>A. Why is a change to public access justified?
>>>This explanation should describe the potential 
>>>impact upon ordinary Internet users and casual 
>>>or occasional users of the directory service.
>>>
>>>B. Does the EWG believe that access to data 
>>>currently accessible in generic Top Level 
>>>Domain (gTLD) WHOIS output should become restricted?
>>>If so, what fields and to what extent exactly? 
>>>Under the EWG proposal, queries from non- 
>>>authenticated requestors would return only 
>>>“public data available to anyone, for
>>>
>>>C. Should all gTLD registries be required to 
>>>provision their contact data into the 
>>>Aggregated Registration Data Service (ARDS)?
>>>There may be jurisdictions that prohibit by 
>>>law the export of personally identifiable 
>>>information outside the jurisdiction. If so, 
>>>the ARDS may not be a viable way to deliver 
>>>data accuracy and compliance across all gTLDs.
>>>
>>>D. Does the EWG propose more types of 
>>>sensitive registration data be provisioned 
>>>into ARDS than are found in current gTLD WHOIS output?
>>>
>>>Recommendation 4: The SSAC suggests that the 
>>>EWG address this recommendation from SAC058: 
>>>“SSAC Report on Domain Name Registration Data Validation”3:
>>>As the ICANN community discusses validating 
>>>contact information, the SSAC recommends that 
>>>the following meta-questions regarding the 
>>>costs and benefits of registration data validation should be answered:
>>>
>>>• What data elements need to be added or 
>>>validated to comply with requirements or 
>>>expectations of different stakeholders?
>>>• Is additional registration processing 
>>>overhead and delay an acceptable cost for 
>>>improving accuracy and quality of registration data?
>>>• Is higher cost an acceptable outcome for improving accuracy and quality?
>>>• Would accuracy improve if the registration 
>>>process were to provide natural persons with 
>>>privacy protection upon completion of multi-factored validation?
>>>
>>>
>>>
>>>SAC062:  SSAC Advisory Concerning the Mitigation of Name Collision Risk
>>>
>>><http://www.icann.org/en/groups/ssac/documents/sac-062-en.pdf>http://www.icann.org/en/groups/ssac/documents/sac-062-en.pdf
>>>
>>>Recommendation 1: ICANN should work with the 
>>>wider Internet community, including at least 
>>>the IAB and the IETF, to identify (1) what 
>>>strings are appropriate to reserve for private 
>>>namespace use and (2) what type of private 
>>>namespace use is appropriate (i.e., at the TLD 
>>>level only or at any additional lower level).
>>>
>>>Recommendation 2: ICANN should explicitly 
>>>consider the following questions regarding 
>>>trial delegation and clearly articulate what 
>>>choices have been made and why as part of its 
>>>decision as to whether or not to delegate any TLD on a trial basis:
>>>
>>>-- Purpose of the trial: What type of trial is 
>>>to be conducted? What data are to be collected?
>>>
>>>-- Operation of the trial: Should ICANN (or a 
>>>designated agent) operate the trial or should the applicant operate it?
>>>
>>>-- Emergency Rollback: What are the emergency 
>>>rollback decision and execution procedures for 
>>>any delegation in the root, and have the root 
>>>zone partners exercised these capabilities?
>>>
>>>-- Termination of the trial: What are the 
>>>criteria for terminating the trial (both 
>>>normal and emergency criteria)? What is to be 
>>>done with the data collected? Who makes the 
>>>decision on what the next step in the delegation process is?
>>>
>>>
>>>Recommendation 3: ICANN should explicitly 
>>>consider under what circumstances 
>>>un-delegation of a TLD is the appropriate 
>>>mitigation for a security or stability issue. 
>>>In the case where a TLD has an established 
>>>namespace, ICANN should clearly identify why 
>>>the risk and harm of the TLD remaining in the 
>>>root zone is greater than the risk and harm of 
>>>removing a viable and in-use namespace from 
>>>the DNS. Finally, ICANN should work in 
>>>consultation with the community, in particular 
>>>the root zone management partners, to create 
>>>additional processes or update existing 
>>>processes to accommodate the potential need 
>>>for rapid reversal of the delegation of a TLD.
>>>
>>>
>>>SAC063:  SSAC Advisory on DNSSEC Key Rollover in the Root Zone
>>>
>>><http://www.icann.org/en/groups/ssac/documents/sac-063-en.pdf>http://www.icann.org/en/groups/ssac/documents/sac-063-en.pdf
>>>
>>>Recommendations:
>>>
>>>Recommendation 1: Internet Corporation for 
>>>Assigned Names and Numbers (ICANN) staff, in 
>>>coordination with the other Root Zone 
>>>Management Partners (United States Department 
>>>of Commerce, National Telecommunications and 
>>>Information Administration (NTIA), and 
>>>Verisign), should immediately undertake a 
>>>significant, worldwide communications effort 
>>>to publicize the root zone KSK rollover 
>>>motivation and process as widely as possible.
>>>Recommendation 2: ICANN staff should lead, 
>>>coordinate, or otherwise encourage the 
>>>creation of a collaborative, representative 
>>>testbed for the purpose of analyzing behaviors 
>>>of various validating resolver 
>>>implementations, their versions, and their 
>>>network environments (e.g., middle boxes) that 
>>>may affect or be affected by a root KSK 
>>>rollover, such that potential problem areas 
>>>can be identified, communicated, and addressed.
>>>
>>>Recommendation 3: ICANN staff should lead, 
>>>coordinate, or otherwise encourage the 
>>>creation of clear and objective metrics for 
>>>acceptable levels of “breakage” resulting from a key rollover.
>>>
>>>Recommendation 4: ICANN staff should lead, 
>>>coordinate, or otherwise encourage the 
>>>development of rollback procedures to be 
>>>executed when a rollover has affected 
>>>operational stability beyond a reasonable boundary.
>>>
>>>Recommendation 5: ICANN staff should lead, 
>>>coordinate, or otherwise encourage the 
>>>collection of as much information as possible 
>>>about the impact of a KSK rollover to provide 
>>>input to planning for future rollovers.
>>>
>>>
>>>PHONE: 651-647-6109, FAX: 866-280-2356, WEB: 
>>><http://www.haven2.com/>www.haven2.com, 
>>>HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
>
>
>PHONE: 651-647-6109, FAX: 866-280-2356, WEB: 
><http://www.haven2.com>www.haven2.com, HANDLE: 
>OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/council/attachments/20131219/eab3cbdf/attachment.html>


More information about the council mailing list