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

Tue Jan 14 04:09:00 UTC 2014

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.

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. 

    Bret

On Jan 13, 2014, at 3:51 PM, Mike O'Connor <mike at haven2.com> wrote:

> 
> hi Jonathan,
> 
> 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.  ;-)
> 
> thanks,
> 
> mikey
> 
> 
> On Jan 13, 2014, at 9:51 AM, Jonathan Robinson <jrobinson at afilias.info> wrote:
> 
>> Mikey,
>> 
>> This will come out in first draft of the agenda for 23 January as an item
>> under AOB.  
>> 
>> Please me know if you wish to see it "escalated" to the main agenda and I'm
>> sure we can accommodate that.
>> 
>> Jonathan
>> 
>> -----Original Message-----
>> From: Mike O'Connor [mailto:mike at haven2.com] 
>> Sent: 10 January 2014 16:06
>> To: Avri Doria
>> Cc: 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 completely agree with your “remedial” point — i think there’s a lot of
>> stuff buried in those reports that we may want to take a look at.
>> 
>> that “trouble with conflicting work-processes and rules” puzzler is also on
>> our radar in the GAC GNSO early-engagement group.  we may come up with some
>> mechanisms that might be models to consider with the SSAC as well.
>> 
>> one of the things that sets the SSAC apart is their operating rule of
>> complete confidentiality of SSAC work.  i *think* that’s the issue that’s on
>> Patrik’s mind, although i’m not sure about that.  if it is, it may not
>> matter which way the liaison role flows (them to us or us to them), the
>> liaison might not be able to share any information with the Council.
>> 
>> one way to sidestep this is to think about the possibility of a Council
>> sub-committee (ala the SCI) that just pays particularly close attention to
>> the *recommendations* of the SSAC, rather than trying to participate in the
>> work that leads up to those recommendations.  
>> 
>> but, i’m getting ahead of myself here — and starting to dive into the actual
>> implementation discussion.  
>> 
>> m
>> 
>> On Jan 10, 2014, at 9: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.)
>>>> 
>> 
>> 
>> PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE:
>> OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
>> 
>> 
> 
> 
> PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
> 
> 

--
Bret Fausett, Esq. • General Counsel, Uniregistry, Inc. 
12025 Waterfront Drive, Suite 200 • Playa Vista, CA 90094-2536
310-496-5755 (T) • 310-985-1351 (M) • bret at uniregistry.com
— — — — — 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/council/attachments/20140113/d6a7ff6c/attachment.html>