Re: [council] Repost: a process to review/evaluate whether SSAC recommendations warrant action by the GNSO
Thanks Jonathan. I agree that our points are consistent. Best regards, Julie On 1/10/14 11:55 AM, "Jonathan Robinson" <jrobinson@xxxxxxxxxxxx> wrote: >Thanks Julie, > >I replied before seeing this. > >Our points are consistent I think. > >Jonathan > >-----Original Message----- >From: Julie Hedlund [mailto:julie.hedlund@xxxxxxxxx] >Sent: 10 January 2014 16:08 >To: Avri Doria; council@xxxxxxxxxxxxxx >Subject: Re: [council] Repost: a process to review/evaluate whether SSAC >recommendations warrant action by the GNSO > >Hi Avri, > >I can confirm that there are no GNSO Council members who are also SSAC >members. > >Just a note about your second question. According to the SSAC procedures >anyone participating in the SSAC must be an SSAC member. If the GNSO were >to appoint an inward liaison to the SSAC that person would have to go >through the SSAC membership process -- that is, be qualified as an SSAC >member regardless of liaison status and be appointed by the Board as such. > For example, ALAC selected Julie Hammer as a liaison to the SSAC, but the >SSAC evaluated and accepted Julie as an SSAC member as part of its regular >membership process because she was qualified to be a member. Her >potential liaison status was not a factor in that evaluation. I have >included the text from the Operational Procedures below. > >I hope this information is helpful but please let me know if you have any >questions. > >Best regards, > >Julie > >2.7.4 SSAC Inward Liaisons [See >http://www.icann.org/en/groups/ssac/operational-procedures-18jan13-en.pdf] > >Various ICANN SOs and ACs and related panels and entities (³groups²) have >asked to send liaisons to the SSAC. The SSAC has generally welcomed the >idea of >inward liaisons, but it has insisted that an inward liaison also be a >full-fledged member of the SSAC. These inward liaisons represent the >community of their appointing group in a general sense, not as an >authority speaking on their behalf. Inward liaisons provide information >about the community and offer insight and context as needed to SSAC >activities. Similarly, inward liaisons will learn about the SSAC and its >activities by participation in SSAC and, within the constraints of >confidentiality, may mention or comment on these activities to their >appointing groups. Inward liaisons may be asked to facilitate >communication with those groups. > >The groups with which the SSAC chooses to liaise are selected by the SSAC. > Groups are selected based on an identified need to maintain a cooperative >relationship. >An inward liaison to the SSAC participates as a full member of the SSAC. >An inward liaison participates in the other group according to the mutual >agreement of both groups when the liaison relationship is established. >Unless otherwise established by the mutual agreement of the SSAC and the >other group, inward liaisons are expected to affirm their commitment to >the obligations of SSAC membership as previously specified. > > > >On 1/10/14 10:53 AM, "Avri Doria" <avri@xxxxxxx> wrote: > >> >>Hi, >> >>I think these are complementary activities. >> >>I think that the activity Mikey suggested is an important activity, in >>fact a remedial activity - what else have we missed dealing with over >>the years. >> >>Having a liaison with the SSAC would be useful in that they could not >>only help clarify some of the issues we find analyzing these existing >>reports, but can help us with new ones coming in the future. >> >>One question, on another list, Patrik Fältström, chair of SSAC, spoke of >>the nature of SSAC and its inability to appoint a representative to a >>CWG. Might the same apply to a liaison to the GNSO Council? The same >>issue we had with the GAC. I don't know if we have any council members >>who are also SSAC members, but if they can't appoint a Liaison to the >>GNSO Council because of their rules, might the GNSO Council be permitted >>to appoint a liaison (or is this a reverse liaison) to the SSAC? Just a >>thought. >> >>I do agree that having an ongoing persistent connection between our >>groups is a good idea, whatever form it might take. >> >>avri >> >>On 10-Jan-14 09:45, Jonathan Robinson wrote: >>> Thanks Mikey, >>> >>> Personally, I am receptive but would like to make sure we understand >>>the >>> why and how as well as possible. >>> >>> One question, does this (or could it) link with the tentative proposal >>>I >>> mentioned in our Council meeting with the Board in BA where I suggested >>> that SSAC consider appointing a liaison to the GNSO Council. >>> >>> Informal conversations after that somewhat off-the-cuff suggestion led >>> me to understand that this was well received. >>> >>> Additional thoughts from others? >>> >>> Jonathan >>> >>> *From:*Mike O'Connor [mailto:mike@xxxxxxxxxx] >>> *Sent:* 10 January 2014 12:59 >>> *To:* Council >>> *Subject:* [council] Repost: a process to review/evaluate whether SSAC >>> recommendations warrant action by the GNSO >>> >>> hi all, >>> >>> welcome back from the holidays ‹ i¹m reposting this because i¹d like to >>> request a slot on the agenda of our upcoming meeting for this topic. >>> the first time around, this note met with resounding silence from the >>> Council, which i¹m thinking was due to the pre-holiday crush. >>> >>> so i¹m trying again. and making a formal request for an agenda slot. >>> >>> thanks, >>> >>> mikey >>> >>> Begin forwarded message: >>> >>> >>> >>> *From: *"Mike O'Connor" <mike@xxxxxxxxxx <mailto:mike@xxxxxxxxxx>> >>> >>> *Subject: [council] what about a process to review/evaluate whether >>>SSAC >>> recommendations warrant action by the GNSO* >>> >>> *Date: *December 19, 2013 at 10:53:13 AM CST >>> >>> *To: *"council@xxxxxxxxxxxxxx <mailto:council@xxxxxxxxxxxxxx> GNSO" >>> <council@xxxxxxxxxxxxxx <mailto:council@xxxxxxxxxxxxxx>> >>> >>> *Cc: *Patrik Fältström <patrik@xxxxxxxxxx <mailto:patrik@xxxxxxxxxx>> >>> >>> dear all, >>> >>> i would like to introduce a gap-closing proposal for the GNSO -- >>>namely, >>> to take a hard look at SSAC reports and determine whether any of their >>> recommendations bear on GNSO Consensus Policy. >>> >>> this gap between what the SSAC says and the GNSO does has been an issue >>> for me for quite some time, and i think one easy way to close it would >>> be to routinely take up each SSAC report and make that determination. >>> there would likely be cases where we review the reports among the >>> stakeholder groups and conclude that: >>> >>> -- there are NO recommendations that require PDPs >>> >>> -- there ARE recommendations that require PDPs, or >>> >>> -- there are recommendations that we would like to know more about >>> before we decided whether a PDP is in order. >>> >>> i'll give an example of the reason why this is on my mind. in 2005 the >>> SSAC produced an extensive report that addressed the issue of >>> domain-name hijacking. in 2011, six years later, the members of the >>> IRTP-B working group stumbled across the following observation in that >>> ancient report and realized that it would be a good idea >>> >>> Collect emergency contact information from registrants, registrars, >>> and resellers for parties who are suited to assist in responding to >>> an urgent restoration of domain name incident. Define escalation >>> processes (emergency procedures) that all parties agree can be >>> instituted in events where emergency contacts are not available. >>> >>> it took six years for that very common-sense idea to find it's way into >>> Consensus Policy. and it probably took another year or two to >>> implement. and it was all practically by accident. >>> >>> what if we: >>> >>> -- discuss this "formally review SSAC reports" idea with our >>> stakeholders and on the Council list for a while >>> >>> -- put an agenda item on our next call to share what we've heard >>>and >>> test a way forward >>> >>> -- get started, presuming nobody thinks this is a horrible idea >>> >>> i've attached the recommendations from the three (count 'em, three) >>>SSAC >>> reports that were released in Buenos Aires. just to give you an idea >>>of >>> the substantive reports that the SSAC is producing. i think it would >>>be >>> really helpful to run these through a process to decide which, if any, >>> of these recommendations warrant action via PDP. there are plenty more >>> SSAC reports to review in the backlog. >>> >>> thanks, >>> >>> mikey >>> >>> *SAC061: SSAC Comment on ICANN¹s Initial Report from the Expert >>>Working >>> Group on gTLD Directory Services* >>> >>> http://www.icann.org/en/groups/ssac/documents/sac-061-en.pdf >>> >>> 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 >>> <http://www.haven2.com/>, HANDLE: OConnorStP (ID for Twitter, Facebook, >>> LinkedIn, etc.) >>> >>> >>> PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com >>> <http://www.haven2.com>, HANDLE: OConnorStP (ID for Twitter, Facebook, >>> LinkedIn, etc.) >>> > > Attachment:
smime.p7s
|