[council] Re: what about a process to review/evaluate whether SSAC recommendations warrant action by the GNSO
Alan Greenberg
alan.greenberg at mcgill.ca
Fri Dec 20 03:20:05 UTC 2013
As Patrik said, this is just being developed. It
is populated with more recent ALAC advice and a
lot of SSAC advice. The format is evolving and I
am guessing on the next iteration will be populated with more data.
Alan
At 19/12/2013 03:04 PM, Mike O'Connor wrote:
>wow. will you look at that! another terrific
>resource i'd never heard of before.
>
>i imagine this is the first time folks on the
>Council list are seeing this reply from Patrik,
>since he's not subscribed. but for those of you
>who don't already know, Patrik is the Chair of
>the SSAC. i'll elevate his "Advice to the ICANN
>Board" link up into this reply post to make sure the rest of you see it
>
><https://www.myicann.org/board-advice>https://www.myicann.org/board-advice
>
>i agree -- it could be really useful to link the
>GNSO into this process a bit more
>proactively. one of the appealing things about
>that page is that it covers ALAC advice as
>well. this might also tie into our GAC - GNSO
>engagement initiative that is under way. this
>page is still a pilot, but it's promised that a
>more mature version will be rolled out
>sometime. this looks like a good starting point
>for that review-process i'm
>envisioning. Patrik, have you figured out an
>automated way to monitor that page?
>
>thanks!
>
>mikey
>
>
>On Dec 19, 2013, at 11:03 AM, Patrik Fältström
><<mailto:patrik at frobbit.se>patrik at frobbit.se> wrote:
>
>>Mikey,
>>
>>I think you can/should tie an initiative like
>>this to the new tracking mechanism that is
>>built and tested for the SSAC and ALAC recommendations.
>>
>><<https://www.myicann.org/board-advice>https://www.myicann.org/board-advice>
>>
>> Patrik Fältström
>> SSAC Chair
>>
>>On 19 dec 2013, at 17:53, Mike O'Connor
>><<mailto:mike at haven2.com>mike at haven2.com> wrote:
>>
>>>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 ICANNs Initial
>>>Report from the Expert Working Group on gTLD Directory Services
>>>
>>><http://www.icann.org/en/groups/ssac/documents/sac-061-en.pdf>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 ICANNs 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 Validation3:
>>>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>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>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:
>>><http://www.haven2.com/>www.haven2.com,
>>>HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
>
>
>PHONE: 651-647-6109, FAX: 866-280-2356, WEB:
><http://www.haven2.com>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/20131219/eab3cbdf/attachment.html>
More information about the council
mailing list