- Gnso-ssr - lists.icann.org

Re: [Gnso-ssr] discussion -- SAC061 -- SSAC Comment on ICANN’s Initial Report from the Expert Working Group on gTLD Directory Services
by Michele Neylon - Blacknight Feb. 17, 2014

Feb. 17, 2014

Stephanie In simple terms - unless you have the "key" you can't really access much about a domain with another registrar (Speaking about ccTLDs where Whois is often gated) And even if you can access data it's logged that your registrar did stuff Assuming you're using EPP etc Regards Michele ------------------------ Mr. Michele Neylon Blacknight http://Blacknight.tel Via iPhone so excuse typos and brevity On 16 Feb 2014, at 08:43, "Stephanie Perrin" <stephanie.perrin(a)mail.utoronto.ca<mailto:stephanie.perrin@mail.utoronto.ca>> wrote: That does raise interesting questions. First one I have, is do all registrars get to look at all data, or do they only get to look at a particular transaction? I would hope the latter, because that would be compliant with data protection law, if they get to look at all data that would not, in my view, be compliant. It would have been easy to engineer a consent mechanism in there to get around this problem, which would be normal in other commercial transactions, and would also perform a security function. The second question of course, remains begging in my view, with respect to the EWG work. How on earth are we going to accredit actors to look at the ARDS? Do all registrars get to look at all data all the time, if not how is it going to be policed? How many miscreant registrars are there out there? AS always, pardon the naivete of my questions. Stephanie On 2014-02-16, at 8:29 AM, Mike O'Connor wrote: thanks Stephanie and Greg for kicking this thread off so well. let me add another dimension to the discussion — i’m going to combine a couple of fuzzy terms to coin a new one and see if it sticks. “Policy Architecture” i’m involved in several WG’s that touch (or depend on) Whois, or its replacement. the most interesting puzzler is the IRTP-C PDP, which introduced the notion of “inter REGISTRANT transfer” to the existing inter REGISTRAR transfer policy. IRTP-C is now in the implementation process and there are turning out to be a lot of dependencies in there. one of the fundamental notions that IRTP-C introduced was the idea that registrars need determine whether the transfer is just inter-registrar, or whether it’s also inter-registrant. the question is, how will registrars determine whether the registrant is changing or not? one answer, which works in thick Whois environments, is to go look at whois data at the registry and see if registrant data is changing. if it is, then it’s an inter-REGISTRANT transfer and new safeguards apply. if not, it’s just an inter-registrar transfer. when we wrote that section of the report, we knew that it was hard to do that — but we were (correctly) counting on some things changing fairly soon. sure enough, the Thick Whois PDP has just been approved by the Board, which means that “go look at registry data” option will exist for all TLDs. the puzzler for me is who looks after these meta-level dependencies? what if Thick Whois had gone the other way? what if the EWG process concludes that registrars can’t look at that data? who minds that “architectural” framework in the policy-making process? mikey PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com<http://www.haven2.com/>, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) _______________________________________________ Gnso-ssr mailing list Gnso-ssr(a)icann.org<mailto:Gnso-ssr@icann.org> https://mm.icann.org/mailman/listinfo/gnso-ssr _______________________________________________ Gnso-ssr mailing list Gnso-ssr(a)icann.org<mailto:Gnso-ssr@icann.org> https://mm.icann.org/mailman/listinfo/gnso-ssr

1 0

discussion -- SAC063 -- SSAC Advisory on DNSSEC Key Rollover in the Root Zone
by Mike O'Connor Feb. 12, 2014

Feb. 12, 2014

hi all, here’s a last thread to talk about the root-key rollover topic and a starter-kit of GNSO-oriented questions - has the worldwide publicity effort been taken up? - is there anything the GNSO SGs and Constituencies can do to help with this effort? Could the root-key rollover outreach be used to leverage the broader goal of better-engaging with the technical community? - how’s that testbed coming along? again, could this collaboration be a point of leverage for broader technical outreach efforts? - how are those metrics coming? are they something that could be worked into the Data and Metrics for Policy-Making non-PDP WG that we are just launching in the GNSO? - where is the rollback procedure at? is that something that the GNSO take a look at before it’s implemented? - is there anything that the GNSO, and/or the GNSO Council, should be doing in Singapore to help move this along? - are there any other questions people would like to raise about this report? 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.

2 1

discussion -- SAC062 -- SSAC Advisory Concerning the Mitigation of Name Collision Risk
by Mike O'Connor Feb. 12, 2014

Feb. 12, 2014

hi all, here’s a thread to talk about the SSAC advisory on mitigating name collision risk. here are a few questions. same disclaimer — just a starting point for discussion. do remember that my main interest in starting this list is to explore the GNSO implications of the SSAC report. there are probably better places to have a super-technical discussion on this topic. - what’s the current status of the name collisions work in general? - where are we in the process identifying strings to reserve for private name spaces? - what is the current thinking about the type of namespace use is appropriate? - where are we on trial delegation as a mitigation approach, and where are those policy choices going to be made? - same for “un-delegation” — where are we at, where/when should the policy conversation take place? - is there anything that the GNSO, and/or the GNSO Council, should be doing in Singapore to help move this along? - are there any other questions people would like to raise about this report? 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.

1 0

examples of discussion-topics
by Mike O'Connor Feb. 12, 2014

Feb. 12, 2014

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.)

1 1

Re: [Gnso-ssr] starting up - refining our rules of engagement
by Michele Neylon - Blacknight Feb. 10, 2014

Feb. 10, 2014

Patrick I have the same problem though it's compounded by people not "getting" that my personal view might not be the RrSG view - unless I clearly state that it is Anyway .. So for the record - registrars speak for themselves and not for the RrSG unless clearly stated Regards Michele who is sick of disclaimers -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Domains http://www.blacknight.co/ http://blog.blacknight.com/ http://www.technology.ie Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 -----Original Message----- From: gnso-ssr-bounces(a)icann.org [mailto:gnso-ssr-bounces@icann.org] On Behalf Of Patrik Fältström Sent: Monday, February 10, 2014 1:50 PM To: Mike O'Connor; GNSO SSR List Subject: Re: [Gnso-ssr] starting up - refining our rules of engagement Thanks Mikey, Let me clarify that if any SSAC members are participating in this discussion, they do that 100% on their personal capacity, and they do not speak on behalf of SSAC, or represent SSAC. I have unfortunately to tell this repeatedly in ICANN nowadays because we have had a few incidents where third parties have claimed that "SSAC have the view that...". If SSAC have, or had a view, that will be clearly stated as such, and if nothing very special happens, the SSAC view will be presented by me. All of this so that SSAC members that are on this list can express themselves in these discussions freely. I can not, and I do not think ICANN can, risk having individuals with clue stay silent because they are tagged with a special affiliation. If you want to tag a special SSAC affiliation with anyway, it is me. Patrik Fältström SSAC Chair On 2014-02-10 08:44, Mike O'Connor wrote: > hi all, > > it seems like we have a good group of interested folks subscribed to > the list (thanks for handling the logistics Glen!). > > so why don't we get under way. > > i think i'll post a couple of emails rather than smashing everything > together in one huge inaugural post. so this one is to take a look at > the initial rules of engagement that i made up while drafting the > charter for this mailing list. as with almost everything i write, > there are probably some things in here that might be better said. so > let's use this thread to get that hashed out. > > here's what i wrote: > > > Approach > > The primary work product of this group will be periodic informal > suggestions of SSR-related topics to be considered by the GNSO. The > form of that consideration may vary. Possibilities include: > > o An Issue Report > o An alert to a currently-running working group or implementation > review team > o Notifications to constituencies and stakeholder groups > > > The group: > > o Will do its work via an email list - no teleconferences are planned > o Is open to all members of the ICANN community - all AC's and > SO's, staff, Board, etc. > o Will require that all participants submit or update their GNSO > Statement of Interest > <https://community.icann.org/pages/viewpage.action?pageId=14713457> before > they are subscribed to the list > o Will maintain open public email archives - and thus will not > discuss private or confidential information > o Will be convened by Mikey O'Connor until somebody gets tired of > him and offers to take over > o To join the mailing list > please *RSVP *gnso.secretariat(a)gnso.icann.org > <mailto:gnso.secretariat@gnso.icann.org> > > > > see anything in there that needs to change? or needs to be added? > this would be a good thread to talk about those things. > > off we go. > > mikey > > > PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com > <http://www.haven2.com>, HANDLE: OConnorStP (ID for Twitter, Facebook, > LinkedIn, etc.) > > > > _______________________________________________ > Gnso-ssr mailing list > Gnso-ssr(a)icann.org > https://mm.icann.org/mailman/listinfo/gnso-ssr >

3 2

Fwd: SSR affiliations
by Mike O'Connor Feb. 10, 2014

Feb. 10, 2014

hi all, here’s who we are right now. we’ve got more people queued up who have yet to fill out their Statement of Interest. Glen and i are working on a wiki page where we can list members and affiliation without posting email addresses to this public list. stay tuned. m Begin forwarded message: > From: Glen de Saint Géry <Glen(a)icann.org> > Subject: SSR affiliations > Date: February 10, 2014 at 9:15:00 AM CST > > > 1 At Large > 2 Individual > 1 IPC > 2 ISPCP > 5 NCUC > 3 RrSG > 8 RySG > 2 SSAC > 17 Staff PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)

1 0

Clarification, SSAC Advice
by Patrik Fältström Feb. 10, 2014

Feb. 10, 2014

One clarification is needed in the text Mikey did send out. > The current process is for the SSAC to give advice to the Board... That is not correct. SSAC can give advice to anyone, and each recommendation do have a specific target audience. This has been a bit unclear historically, but is I claim more and more clear in the recommendations themselves. The subset of the advice that SSAC and ALAC give to the board can nowadays be tracked on this page: <https://www.myicann.org/board-advice> If you for example look at SAC007 that is mentioned, it does explicitly include recommendations for registries and registrars. That said, what I think you Mikey want to point out is that there is a gap between whoever makes a recommendations and whoever is to implement it. That I agree with. For interactions with the board, SSAC and ALAC now do have the tool I link to above to track the progress. We in SSAC are happy to try to close the gap and I am prepared on listening on proposed changes to for example our publication procedure. Patrik Fältström SSAC Chair

1 0

starting up - refining our rules of engagement
by Mike O'Connor Feb. 10, 2014

Feb. 10, 2014

hi all, it seems like we have a good group of interested folks subscribed to the list (thanks for handling the logistics Glen!). so why don’t we get under way… i think i’ll post a couple of emails rather than smashing everything together in one huge inaugural post. so this one is to take a look at the initial rules of engagement that i made up while drafting the charter for this mailing list. as with almost everything i write, there are probably some things in here that might be better said. so let’s use this thread to get that hashed out. here’s what i wrote: Approach The primary work product of this group will be periodic informal suggestions of SSR-related topics to be considered by the GNSO. The form of that consideration may vary. Possibilities include: An Issue Report An alert to a currently-running working group or implementation review team Notifications to constituencies and stakeholder groups The group: Will do its work via an email list – no teleconferences are planned Is open to all members of the ICANN community – all AC's and SO's, staff, Board, etc. Will require that all participants submit or update their GNSO Statement of Interest before they are subscribed to the list Will maintain open public email archives – and thus will not discuss private or confidential information Will be convened by Mikey O'Connor until somebody gets tired of him and offers to take over To join the mailing list please RSVP gnso.secretariat(a)gnso.icann.org see anything in there that needs to change? or needs to be added? this would be a good thread to talk about those things. off we go. mikey PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)

2 2

Re: [Gnso-ssr] starting up - refining our rules of engagement
by Michele Neylon - Blacknight Feb. 10, 2014

Feb. 10, 2014

Mikey It might not be a bad idea to see if we have: - Members from all the ACs and SOs - Someone from infosec I'm not suggesting name who is on here - a simple X registrars, Y ALAC etc., would be helpful Just my two cents M -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Domains http://www.blacknight.co/ http://blog.blacknight.com/ http://www.technology.ie Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From: gnso-ssr-bounces(a)icann.org [mailto:gnso-ssr-bounces@icann.org] On Behalf Of Mike O'Connor Sent: Monday, February 10, 2014 1:45 PM To: GNSO SSR List Subject: [Gnso-ssr] starting up - refining our rules of engagement hi all, it seems like we have a good group of interested folks subscribed to the list (thanks for handling the logistics Glen!). so why don't we get under way... i think i'll post a couple of emails rather than smashing everything together in one huge inaugural post. so this one is to take a look at the initial rules of engagement that i made up while drafting the charter for this mailing list. as with almost everything i write, there are probably some things in here that might be better said. so let's use this thread to get that hashed out. here's what i wrote: Approach The primary work product of this group will be periodic informal suggestions of SSR-related topics to be considered by the GNSO. The form of that consideration may vary. Possibilities include: * An Issue Report * An alert to a currently-running working group or implementation review team * Notifications to constituencies and stakeholder groups The group: * Will do its work via an email list - no teleconferences are planned * Is open to all members of the ICANN community - all AC's and SO's, staff, Board, etc. * Will require that all participants submit or update their GNSO Statement of Interest<https://community.icann.org/pages/viewpage.action?pageId=14713457> before they are subscribed to the list * Will maintain open public email archives - and thus will not discuss private or confidential information * Will be convened by Mikey O'Connor until somebody gets tired of him and offers to take over * To join the mailing list please RSVP gnso.secretariat(a)gnso.icann.org<mailto:gnso.secretariat@gnso.icann.org> see anything in there that needs to change? or needs to be added? this would be a good thread to talk about those things. off we go. mikey PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com<http://www.haven2.com>, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)

1 0

List charter
by Mike O'Connor Feb. 10, 2014

Feb. 10, 2014

hi again, here’s another thread-starting post. this one is similar to the last one, except with a broader focus. this is a copy of the charter that i wrote for us. i have no editorial pride — so if there is something in here that you think needs changing, or needs to be added, or needs to be removed, this would be a good thread to have that discussion. thanks, mikey > Invitation to Join the GNSO-SSR | A GNSO Sponsored Security, Stability, Resiliency (SSR) Mailing List > Last Updated: 4 February 2014 > Date: > 3 February 2014 > Charter > > GNSO-SSR – A GNSO Sponsored Security, Stability, Resiliency (SSR) Mailing List > To join RSVP gnso.secretariat(a)gnso.icann.org > > Premise > > This charter briefly describes an open group sponsored by the GNSO. This group will informally review SSAC reports to determine whether they contain recommendations that might deserve broader consideration in the GNSO. > Problem Statement > > Recommendations made by the SSAC sometimes are relevant to GNSO policy making, yet the mechanism for the GNSO to find out or act on them is not well developed. > The current process is for the SSAC to give advice to the Board, with the presumption that the Board will pass relevant issues along to the GNSO for consideration. This doesn't appear to be happening in all cases, with sometimes-unsatisfactory results. Here are two examples: > The SSAC produced an extensive report (SAC007) in 2005 that addressed the issue of domain-name hijacking. In 2011, six years later, members of the GNSO IRTP-B working group stumbled across the following observation in that report and realized that it was 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 its way into Consensus Policy and probably another year or two to implement. > The SSAC wrote a report (SAC045) in 2010 titled "Invalid Top Level Domain Queries at the Root Level of the DNS" which provided an early warning about the "name collisions" problem. Again, an opportunity to proactively research this issue was missed and ICANN finds itself scrambling to deal with an issue that is much complicated by the fact that a number of the highest-volume invalid strings are now applied-for strings and soon to be delegated into the root. > A related problem is that the stakeholder-group structure of the GNSO does not have an SSR-focused forum for this kind of cross-GNSO conversation. > How does not solving this problem get in the way of achieving ICANN's objectives? > The implication is that the GNSO may sometimes fail to consider SSAC recommendations in a timely way, or at all. > Specifically, not solving the problem raises the possibility of: > Negative impacts on SSR of the DNS – as a result of not considering or implementing SSAC recommendations, or building trust relationships in an SSR community of interest > Increased implementation costs – as a result of delay in considering SSAC proposals that may bear on GNSO consensus policy > Lower quality of implementation – as a result of not taking fullest advantage of the rigor of the multi-stakeholder analysis and PDP processes > Value to be gained > > In addition to addressing the problems listed above, the GNSO will benefit from having this group by: > Broadening the pool of participants -- by identifying and engaging community members who have interest and skills in SSR of the DNS > Building trust relationships – by providing community members an opportunity to work together in a low-key setting > Approach > > The primary work product of this group will be periodic informal suggestions of SSR-related topics to be considered by the GNSO. The form of that consideration may vary. Possibilities include: > An Issue Report > An alert to a currently-running working group or implementation review team > Notifications to constituencies and stakeholder groups > The group: > Will do its work via an email list – no teleconferences are planned > Is open to all members of the ICANN community – all AC's and SO's, staff, Board, etc. > Will require that all participants submit or update their GNSO Statement of Interest before they are subscribed to the list > Will maintain open public email archives – and thus will not discuss private or confidential information > Will be convened by Mikey O'Connor until somebody gets tired of him and offers to take over > To join the mailing list please RSVP gnso.secretariat(a)gnso.icann.org > PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)

1 0