<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">neato! birding together will be great.<div><br></div><div>by the way, i’m contemplating the idea that this group isn’t restricted to Councilors. anybody got any serious allergic reaction to that? i agree with Brett that we Councilors are ultimately responsible for gating the flow of PDP work (and administrative-overhead work, which i note comprises the bulk of that big workload — maybe a little refocusing is needed?). but i think reviewing SSAC reports in depth and highlighting relevant topics for broader discussion is a place where the SSR-interested folks can help the constituencies and council a lot. it might also be nice to dovetail the work of that group with the face-to-face meetings with the SSAC as well.</div><div><br></div><div>mikey</div><div><br></div><div><br><div><div>On Jan 13, 2014, at 10:09 PM, Bret Fausett <<a href="mailto:bret@nic.sexy">bret@nic.sexy</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Mikey, I’m definitely interested in birding of a feather with you on this. As I see it, we will need to figure out how to balance taking up work contemplated by the SSAC reports with the Council’s ongoing work. Although I am the new person here, my sense is that the plate is very full for the coming year.<br><br>I also think we need to balance regarding the SSAC reports as sacrosanct (they shouldn’t be taken as gospel) and redoing the work/analysis in those reports. <br><br> Bret<br><br><br>On Jan 13, 2014, at 3:51 PM, Mike O'Connor <<a href="mailto:mike@haven2.com">mike@haven2.com</a>> wrote:<br><br><blockquote type="cite"><br>hi Jonathan,<br><br>that will be fine. my hope is that maybe a small birds of a feather group would form to go off and puzzle on this a bit. heads up you SSR enthusiasts. ;-)<br><br>thanks,<br><br>mikey<br><br><br>On Jan 13, 2014, at 9:51 AM, Jonathan Robinson <<a href="mailto:jrobinson@afilias.info">jrobinson@afilias.info</a>> wrote:<br><br><blockquote type="cite">Mikey,<br><br>This will come out in first draft of the agenda for 23 January as an item<br>under AOB. <br><br>Please me know if you wish to see it "escalated" to the main agenda and I'm<br>sure we can accommodate that.<br><br>Jonathan<br><br>-----Original Message-----<br>From: Mike O'Connor [<a href="mailto:mike@haven2.com">mailto:mike@haven2.com</a>] <br>Sent: 10 January 2014 16:06<br>To: Avri Doria<br>Cc: <a href="mailto:council@gnso.icann.org">council@gnso.icann.org</a><br>Subject: Re: [council] Repost: a process to review/evaluate whether SSAC<br>recommendations warrant action by the GNSO<br><br><br>hi Avri,<br><br>i completely agree with your “remedial” point — i think there’s a lot of<br>stuff buried in those reports that we may want to take a look at.<br><br>that “trouble with conflicting work-processes and rules” puzzler is also on<br>our radar in the GAC GNSO early-engagement group. we may come up with some<br>mechanisms that might be models to consider with the SSAC as well.<br><br>one of the things that sets the SSAC apart is their operating rule of<br>complete confidentiality of SSAC work. i *think* that’s the issue that’s on<br>Patrik’s mind, although i’m not sure about that. if it is, it may not<br>matter which way the liaison role flows (them to us or us to them), the<br>liaison might not be able to share any information with the Council.<br><br>one way to sidestep this is to think about the possibility of a Council<br>sub-committee (ala the SCI) that just pays particularly close attention to<br>the *recommendations* of the SSAC, rather than trying to participate in the<br>work that leads up to those recommendations. <br><br>but, i’m getting ahead of myself here — and starting to dive into the actual<br>implementation discussion. <br><br>m<br><br>On Jan 10, 2014, at 9:53 AM, Avri Doria <<a href="mailto:avri@acm.org">avri@acm.org</a>> wrote:<br><br><blockquote type="cite"><br>Hi,<br><br>I think these are complementary activities.<br><br>I think that the activity Mikey suggested is an important activity, in<br></blockquote>fact a remedial activity - what else have we missed dealing with over the<br>years.<br><blockquote type="cite"><br>Having a liaison with the SSAC would be useful in that they could not only<br></blockquote>help clarify some of the issues we find analyzing these existing reports,<br>but can help us with new ones coming in the future.<br><blockquote type="cite"><br>One question, on another list, Patrik Fältström, chair of SSAC, spoke of<br></blockquote>the nature of SSAC and its inability to appoint a representative to a CWG.<br>Might the same apply to a liaison to the GNSO Council? The same issue we had<br>with the GAC. I don't know if we have any council members who are also SSAC<br>members, but if they can't appoint a Liaison to the GNSO Council because of<br>their rules, might the GNSO Council be permitted to appoint a liaison (or is<br>this a reverse liaison) to the SSAC? Just a thought.<br><blockquote type="cite"><br>I do agree that having an ongoing persistent connection between our groups<br></blockquote>is a good idea, whatever form it might take.<br><blockquote type="cite"><br>avri<br><br>On 10-Jan-14 09:45, Jonathan Robinson wrote:<br><blockquote type="cite">Thanks Mikey,<br><br>Personally, I am receptive but would like to make sure we understand <br>the why and how as well as possible.<br><br>One question, does this (or could it) link with the tentative <br>proposal I mentioned in our Council meeting with the Board in BA <br>where I suggested that SSAC consider appointing a liaison to the GNSO<br></blockquote></blockquote>Council.<br><blockquote type="cite"><blockquote type="cite"><br>Informal conversations after that somewhat off-the-cuff suggestion <br>led me to understand that this was well received.<br><br>Additional thoughts from others?<br><br>Jonathan<br><br>*From:*Mike O'Connor [<a href="mailto:mike@haven2.com">mailto:mike@haven2.com</a>]<br>*Sent:* 10 January 2014 12:59<br>*To:* Council<br>*Subject:* [council] Repost: a process to review/evaluate whether <br>SSAC recommendations warrant action by the GNSO<br><br>hi all,<br><br>welcome back from the holidays — i’m reposting this because i’d like <br>to request a slot on the agenda of our upcoming meeting for this topic.<br>the first time around, this note met with resounding silence from <br>the Council, which i’m thinking was due to the pre-holiday crush.<br><br>so i’m trying again. and making a formal request for an agenda slot.<br><br>thanks,<br><br>mikey<br><br>Begin forwarded message:<br><br><br><br>*From: *"Mike O'Connor" <<a href="mailto:mike@haven2.com">mike@haven2.com</a> <<a href="mailto:mike@haven2.com">mailto:mike@haven2.com</a>>><br><br>*Subject: [council] what about a process to review/evaluate whether <br>SSAC recommendations warrant action by the GNSO*<br><br>*Date: *December 19, 2013 at 10:53:13 AM CST<br><br>*To: *"<a href="mailto:council@gnso.icann.org">council@gnso.icann.org</a> <<a href="mailto:council@gnso.icann.org">mailto:council@gnso.icann.org</a>> GNSO"<br><<a href="mailto:council@gnso.icann.org">council@gnso.icann.org</a> <<a href="mailto:council@gnso.icann.org">mailto:council@gnso.icann.org</a>>><br><br>*Cc: *Patrik Fältström <<a href="mailto:patrik@frobbit.se">patrik@frobbit.se</a> <<a href="mailto:patrik@frobbit.se">mailto:patrik@frobbit.se</a>>><br><br>dear all,<br><br>i would like to introduce a gap-closing proposal for the GNSO -- <br>namely, to take a hard look at SSAC reports and determine whether any <br>of their recommendations bear on GNSO Consensus Policy.<br><br>this gap between what the SSAC says and the GNSO does has been an <br>issue for me for quite some time, and i think one easy way to close <br>it would be to routinely take up each SSAC report and make that<br></blockquote></blockquote>determination.<br><blockquote type="cite"><blockquote type="cite">there would likely be cases where we review the reports among the <br>stakeholder groups and conclude that:<br><br> -- there are NO recommendations that require PDPs<br><br> -- there ARE recommendations that require PDPs, or<br><br> -- there are recommendations that we would like to know more about<br> before we decided whether a PDP is in order.<br><br>i'll give an example of the reason why this is on my mind. in 2005 <br>the SSAC produced an extensive report that addressed the issue of <br>domain-name hijacking. in 2011, six years later, the members of the <br>IRTP-B working group stumbled across the following observation in <br>that ancient report and realized that it would be a good idea<br><br> Collect emergency contact information from registrants, registrars,<br> and resellers for parties who are suited to assist in responding to<br> an urgent restoration of domain name incident. Define escalation<br> processes (emergency procedures) that all parties agree can be<br> instituted in events where emergency contacts are not available.<br><br>it took six years for that very common-sense idea to find it's way <br>into Consensus Policy. and it probably took another year or two to <br>implement. and it was all practically by accident.<br><br>what if we:<br><br> -- discuss this "formally review SSAC reports" idea with our<br> stakeholders and on the Council list for a while<br><br> -- put an agenda item on our next call to share what we've heard and<br> test a way forward<br><br> -- get started, presuming nobody thinks this is a horrible idea<br><br>i've attached the recommendations from the three (count 'em, three) <br>SSAC reports that were released in Buenos Aires. just to give you an <br>idea of the substantive reports that the SSAC is producing. i think <br>it would be really helpful to run these through a process to decide <br>which, if any, of these recommendations warrant action via PDP. <br>there are plenty more SSAC reports to review in the backlog.<br><br>thanks,<br><br>mikey<br><br>*SAC061: SSAC Comment on ICANN’s Initial Report from the Expert <br>Working Group on gTLD Directory Services*<br><br><a href="http://www.icann.org/en/groups/ssac/documents/sac-061-en.pdf">http://www.icann.org/en/groups/ssac/documents/sac-061-en.pdf</a><br><br> Recommendation 1: SSAC reiterates its recommendation from SAC055:<br> The ICANN Board should explicitly *defer any other activity (within<br> ICANN’s remit) directed at finding a ‘solution’ to ‘the WHOIS<br> problem’ until the registration data policy has been developed and<br> accepted in the community*. The EWG should clearly state its<br> proposal for the purpose of registration data, and focus on policy<br> issues over specific implementations.<br><br> Recommendation 2: The ICANN Board should ensure that a *formal<br> security risk assessment of the registration data policy be<br> conducted as an input into the Policy Development Process.*<br><br> Recommendation 3: SSAC recommends that the EWG state more clearly<br> its positions on the following questions of data availability:<br><br> *A. Why is a change to public access justified?*<br><br> This explanation should describe the potential impact upon ordinary<br> Internet users and casual or occasional users of the directory<br></blockquote></blockquote>service.<br><blockquote type="cite"><blockquote type="cite"><br> *B. Does the EWG believe that access to data currently accessible in<br> generic Top Level Domain (gTLD) WHOIS output should become <br>restricted?*<br><br> If so, what fields and to what extent exactly? Under the EWG<br> proposal, queries from non- authenticated requestors would return<br> only “public data available to anyone, for<br><br> *C. Should all gTLD registries be required to provision their<br> contact data into the Aggregated Registration Data Service (ARDS)? <br>*<br><br> There may be jurisdictions that prohibit by law the export of<br> personally identifiable information outside the jurisdiction. If so,<br> the ARDS may not be a viable way to deliver data accuracy and<br> compliance across all gTLDs.<br><br> D. Does the EWG propose *more types of sensitive registration data<br> be provisioned into ARDS than are found in current gTLD WHOIS <br>output?*<br><br> Recommendation 4: The SSAC suggests that the EWG address this<br> recommendation from SAC058: “SSAC Report on Domain Name Registration<br> Data Validation”3:<br><br> As the ICANN community discusses validating contact information, the<br> SSAC recommends that *the following meta-questions regarding the<br> costs and benefits of registration data validation should be<br></blockquote></blockquote>answered*:<br><blockquote type="cite"><blockquote type="cite"><br> • *What data elements need to be added or validated to comply with<br> requirements or expectations of different stakeholders?*<br><br> *• Is additional registration processing overhead and delay an<br> acceptable cost for improving accuracy and quality of registration<br> data?*<br><br> *• Is higher cost an acceptable outcome for improving accuracy and<br> quality?*<br><br> *• Would accuracy improve if the registration process were to<br> provide natural persons with privacy protection upon completion of<br> multi-factored validation?*<br><br>**<br><br>**<br><br>*SAC062: SSAC Advisory Concerning the Mitigation of Name Collision <br>Risk*<br><br>**<br><br><a href="http://www.icann.org/en/groups/ssac/documents/sac-062-en.pdf">http://www.icann.org/en/groups/ssac/documents/sac-062-en.pdf</a><br><br> Recommendation 1: ICANN should work with the wider Internet<br> community, including at least the IAB and the IETF, to *identify (1)<br> what strings are appropriate to reserve for private namespace use<br> and (2) what type of private namespace use is appropriate (i.e., at<br> the TLD level only or at any additional lower level)*.<br><br> Recommendation 2*: *ICANN should explicitly consider the following<br> questions regarding trial delegation and *clearly articulate what<br> choices have been made and why *as part of its decision as to<br> whether or not to delegate any TLD on a trial basis:<br><br> -- *Purpose of the trial:* What type of trial is to be conducted?<br> What data are to be collected?<br><br> -- *Operation of the trial*: Should ICANN (or a designated agent)<br> operate the trial or should the applicant operate it?<br><br> -- *Emergency Rollback*: What are the emergency rollback decision<br> and execution procedures for any delegation in the root, and have<br> the root zone partners exercised these capabilities?<br><br> -- *Termination of the trial:* What are the criteria for terminating<br> the trial (both normal and emergency criteria)? What is to be done<br> with the data collected? Who makes the decision on what the next<br> step in the delegation process is?<br><br>**<br><br> Recommendation 3: ICANN should explicitly *consider under what<br> circumstances un-delegation of a TLD is the appropriate mitigation<br> for a security or stability issue.* In the case where a TLD has an<br> established namespace, ICANN should clearly identify why the risk<br> and harm of the TLD remaining in the root zone is greater than the<br> risk and harm of removing a viable and in-use namespace from the<br> DNS. Finally, ICANN should work in consultation with the community,<br> in particular the root zone management partners, to create<br> additional processes or update existing processes to accommodate the<br> potential need for rapid reversal of the delegation of a TLD.<br><br>**<br><br>*SAC063: SSAC Advisory on DNSSEC Key Rollover in the Root Zone*<br><br><a href="http://www.icann.org/en/groups/ssac/documents/sac-063-en.pdf">http://www.icann.org/en/groups/ssac/documents/sac-063-en.pdf</a><br><br>*Recommendations:*<br><br> Recommendation 1: Internet Corporation for Assigned Names and<br> Numbers (ICANN) staff, in coordination with the other Root Zone<br> Management Partners (United States Department of Commerce, National<br> Telecommunications and Information Administration (NTIA), and<br> Verisign), *should immediately undertake a significant, worldwide<br> communications effort to publicize the root zone KSK rollover<br> motivation and process as widely as possible*.<br><br> Recommendation 2: ICANN staff should lead, coordinate, or otherwise<br> encourage the creation of a collaborative, representative testbed<br> for the purpose of analyzing behaviors of various validating<br> resolver implementations, their versions, and their network<br> environments (e.g., middle boxes) that may affect or be affected by<br> a root KSK rollover, *such that potential problem areas can be<br> identified, communicated, and addressed.*<br><br> Recommendation 3: ICANN staff should lead, coordinate, or otherwise<br> encourage*the creation of clear and objective metrics for acceptable<br> levels of “breakage” resulting from a key rollover.*<br><br> Recommendation 4: ICANN staff should lead, coordinate, or otherwise<br> encourage *the development of rollback procedures to be executed<br> when a rollover has affected operational stability beyond a<br> reasonable boundary.*<br><br> Recommendation 5: ICANN staff should lead, coordinate, or otherwise<br> encourage the collection of as much information as possible about<br> the impact of a KSK rollover to provide input to planning for future<br> rollovers.<br><br><br>PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com <br><http://www.haven2.com/>, HANDLE: OConnorStP (ID for Twitter, <br>Facebook, LinkedIn, etc.)<br><br><br>PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com <br><http://www.haven2.com>, HANDLE: OConnorStP (ID for Twitter, <br>Facebook, LinkedIn, etc.)<br><br></blockquote></blockquote><br><br>PHONE: 651-647-6109, FAX: 866-280-2356, WEB: <a href="http://www.haven2.com/">www.haven2.com</a>, HANDLE:<br>OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)<br><br><br></blockquote><br><br>PHONE: 651-647-6109, FAX: 866-280-2356, WEB: <a href="http://www.haven2.com/">www.haven2.com</a>, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)<br><br><br></blockquote><br><div apple-content-edited="true">
<div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">--<br>Bret Fausett, Esq. • General Counsel, Uniregistry, Inc. <br>12025 Waterfront Drive, Suite 200 • Playa Vista, CA 90094-2536<br>310-496-5755 (T) • 310-985-1351 (M) • <a href="mailto:bret@uniregistry.com">bret@uniregistry.com</a><br>— — — — — <br><br><br><br></div>
</div>
<br></div></blockquote></div><br><div apple-content-edited="true">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline !important; float: none; ">PHONE: 651-647-6109, FAX: 866-280-2356, WEB: <a href="http://www.haven2.com">www.haven2.com</a>, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)</span>
</div>
<br></div></body></html>