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

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

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.)