[Gnso-ssr] examples of discussion-topics

Wed Feb 12 13:11:39 UTC 2014

well!

that “how should we proceed?” question sure put the brakes on the conversation.  :-)

so, as your list moderator who will likely be fired someday soon, let me make an arbitrary decision (what a luxury).

i’m going to kick off three discussion threads, one for each of the SSAC reports that were presented to the community in Buenos Aires.  my goal is to have a bit of discussion about these prior to Singapore so that we can fit any action items into the GNSO Singapore agendas, formal and informal.

stand by — 3 more posts are on the way.

mikey

On Feb 10, 2014, at 7:58 AM, Mike O'Connor <mike at haven2.com> wrote:

> hi again,
> 
> sorry to pepper you with posts — this is the last, for now.
> 
> when i kicked off this conversation on the Council list, i served up some examples of topics that might be worthy of discussion on a list like this.  i thought i’d paste that into this post as a conversation-starter.
> 
> it seems to me that there are several ways to approach this “picking topics” puzzle.  one way would be to work through the SSAC reports in some sequence, one at a time.  we could figure out what that sequence is (oldest to newest, newest to oldest, or some kind of determination of highest-priority/most-urgent) and then carry on.  
> 
> another approach would be for people to simply suggest high-priority SSAC-report topics for us to consider.  or something else.  i haven’t got a really strong opinion here — i’m simply delighted that we’re starting the conversation and look forward to seeing where it goes.
> 
> here’s the series of examples i included in my post to the Council
> 
> 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
> 
> 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
> 
> 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
> 
> 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: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
> 
> _______________________________________________
> Gnso-ssr mailing list
> Gnso-ssr at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-ssr

PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-ssr/attachments/20140212/3738cef7/attachment.html>