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

["Mike O'Connor" <mike@xxxxxxxxxx>]

neato!  birding together will be great.

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.

mikey


On Jan 13, 2014, at 10:09 PM, Bret Fausett <bret@xxxxxxxx> wrote:

> 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@xxxxxxxxxx> 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@xxxxxxxxxxxx> 
>> 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@xxxxxxxxxx] 
>>> Sent: 10 January 2014 16:06
>>> To: Avri Doria
>>> Cc: council@xxxxxxxxxxxxxx
>>> 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@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.)
>>>>> 
>>> 
>>> 
>>> 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@xxxxxxxxxxxxxxx
> — — — — — 
> 
> 
> 
> 


PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP 
(ID for Twitter, Facebook, LinkedIn, etc.)