[council] Repost: a process to review/evaluate whether SSAC recommendations warrant action by the GNSO
Mike O'Connor
mike at haven2.com
Tue Jan 14 12:52:48 UTC 2014
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 at nic.sexy> 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 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
> — — — — —
>
>
>
>
PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/council/attachments/20140114/c6efc997/attachment.html>
More information about the council
mailing list