February 2014 - Gnso-ssr - lists.icann.org

Broken TMCH?
by Mike O'Connor March 4, 2014

March 4, 2014

hi all, here’s a snip from the chat transcript of the recent CEO/Community-Leaders webinar. i’m curious about the “broken TMCH” comment that Patrik made. Patrik (or others) would you like to expand on that? i’m curious whether that would be an SSR topic that one/all of the GNSO constituencies might want to request a review by the SSAC. here’s the chat transcript: Patrik Fältström: I would like to remind everyone that regarding the issues SSAC have seen on broken TMCH has not been acted on, at all. And I urge people to not rely on TMCH yet. In any process. Patrik Fältström: https://www.myicann.org/board-advice#advice-to-board_f=tmch&advice-to-board… Michele Neylon: Security + stability issues should be core Michele Neylon: I thought they were core to ICANN’s mission Patrik Fältström: I also want to point out that we do have new gTLDs that are so broken technically that I think various clauses that say EBERO could be invoked has matched. Michele Neylon: Patrik - already? Michele Neylon: wow Patrik Fältström: Part from me supporting the issue that Michele mentioned, that the fact people in some legislations cannot sign contracts with ICANN due to US-centric clauses is something that MUST be addresses, or else our enemies might be able to say that "the internal ICANN change processes does not work" PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)

4 15

discussion -- SAC061 -- SSAC Comment on ICANN’s Initial Report from the Expert Working Group on gTLD Directory Services
by Mike O'Connor Feb. 17, 2014

Feb. 17, 2014

hi all, here’s a thread to talk about the SSAC comment on EWG initial report. here are a few questions. view them as a starting-point, not a rigid requirement. if you have a comment that falls outside of these questions, please go ahead and make your post. i’m just posting these to start conversation, not restrict it. - what’s the current status of the EWG work? - where are we in the process of establishing a registration data policy? - who, if anybody, has taken these SSAC recommendations on board? - 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 comment? 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?

3 8

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

Mikey The lack of uniform Whois display means we all have crazy regex rules on our systems to make sense of what we run into in the wild ... M ------------------------ Mr. Michele Neylon Blacknight http://Blacknight.tel Via iPhone so excuse typos and brevity On 16 Feb 2014, at 19:36, "Mike O'Connor" <mike(a)haven2.com<mailto:mike@haven2.com>> wrote: hi Greg, you raise a couple of interesting questions. 1) in the case of a thin registry, how does the gaining registrar do that 2013 RAA verification and validation? it’s my understanding that job is easier if both registrars are under the 2013 RAA, because then they are both obligated to provide uniform Whois display. so a script could be written to pull that data from the losing registrar and that script could count on success. but what if the losing registrar isn’t a signatory to 2013 RAA yet? that looks like another in that pile of dependencies, no? 2) what about all the European registrars (like Michele) who <stirring up a hornet’s nest> haven’t signed the 2013 RAA yet because of the conflict with European privacy law? yet another dependency, i bet. OK. what i’ve learned from this topic so far is; - EWG still has substantial work to do, which certainly won’t be finished by Singapore — but maybe London - we should wait to see how SAC061 advice is incorporated into that EWG report before trying to decide what the next step is for the GNSO - so again, maybe London fair summary? is there anything in SAC061 the GNSO should look at in Singapore? mikey On Feb 16, 2014, at 3:30 PM, Greg Aaron <greg(a)illumintel.com<mailto:greg@illumintel.com>> wrote: The 2013 RAA says that when a domain is transferred between registrars, OR when a domain is transferred between registrants, “both Whois information and the corresponding customer account holder contact information related to such Registered Name” must be verified and validated. So it must happen with inter-registrar AND inter-registrant transfers. http://www.icann.org/en/resources/registrars/raa/approved-with-specs-27jun1… Registrars who have signed the 2013 RAA sponsor most of the gTLD domains that exist. The community must understand what the current policies are, see if proposed new policies are superior, what the implications of any new proposals are, etc. If the EWG final report doesn’t lay out all of that, then the GSNO will have to make sure it’s done, because it’s tasked with making/approving the policies that come out of the EWG work. I suspect that there are dependencies that have not been documented and discussed yet. And I note that the “ central repository” of WHOIS policies is not complete. http://whois.icann.org All best, --Greg From: gnso-ssr-bounces(a)icann.org<mailto:gnso-ssr-bounces@icann.org> [mailto:gnso-ssr-bounces@icann.org] On Behalf Of Stephanie Perrin Sent: Sunday, February 16, 2014 8:57 AM To: Mike O'Connor Cc: GNSO SSR List Subject: Re: [Gnso-ssr] discussion -- SAC061 -- SSAC Comment on ICANN’s Initial Report from the Expert Working Group on gTLD Directory Services Sorry forgot to answer your key question....as you pointed out in Buenos Aires from the mike, some people are doing all the work in the working groups. Absent that connective tissue, I have not seen any other mechanism. There is a lot of material to cover....hard to catch everything, if you are just sitting around reading all the minutes and notices etc. Transparency is not enough.... cheers Stephanie On 2014-02-16, at 8:42 AM, Stephanie Perrin 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 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

2 1

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