[council] Repost: a process to review/evaluate whether SSAC recommendations warrant action by the GNSO

Fri Jan 10 17:39:04 UTC 2014

Thanks Jonathan.  I agree that our points are consistent.

Best regards,
Julie

On 1/10/14 11:55 AM, "Jonathan Robinson" <jrobinson at afilias.info> wrote:

>Thanks Julie,
>
>I replied before seeing this.
>
>Our points are consistent I think.
>
>Jonathan
>
>-----Original Message-----
>From: Julie Hedlund [mailto:julie.hedlund at icann.org]
>Sent: 10 January 2014 16:08
>To: Avri Doria; council at gnso.icann.org
>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 at acm.org> 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 at haven2.com]
>>> *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 at haven2.com <mailto:mike at haven2.com>>
>>>
>>> *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 at gnso.icann.org <mailto:council at gnso.icann.org> GNSO"
>>> <council at gnso.icann.org <mailto:council at gnso.icann.org>>
>>>
>>> *Cc: *Patrik Fältström <patrik at frobbit.se <mailto:patrik at frobbit.se>>
>>>
>>> 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.)
>>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5041 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/council/attachments/20140110/e88fa366/smime.p7s>