<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [council] Repost: a process to review/evaluate whether SSAC recommendations warrant action by the GNSO
- To: "<jrobinson@xxxxxxxxxxxx> Robinson" <jrobinson@xxxxxxxxxxxx>
- Subject: Re: [council] Repost: a process to review/evaluate whether SSAC recommendations warrant action by the GNSO
- From: "Mike O'Connor" <mike@xxxxxxxxxx>
- Date: Fri, 10 Jan 2014 09:37:44 -0600
- Cc: Council <council@xxxxxxxxxxxxxx>
- In-reply-to: <031801cf0e12$8e3a2850$aaae78f0$@afilias.info>
- List-id: council@xxxxxxxxxxxxxx
- References: <0D8A43EB-4259-4D95-94FD-61D2AB3F8E84@haven2.com> <E459067F-97E5-4A50-A3F2-B298E03E257E@haven2.com> <031801cf0e12$8e3a2850$aaae78f0$@afilias.info>
- Sender: owner-council@xxxxxxxxxxxxxx
hi Jonathan,
yes, the SSAC-liaison idea would fit nicely in this discussion, in my view.
i’m sorry to have missed/forgotten about that idea — i’d have thrown it into
this pile if i’d remembered.
thanks,
mikey
On Jan 10, 2014, at 8:45 AM, Jonathan Robinson <jrobinson@xxxxxxxxxxxx> 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>
> 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 GNSO" <council@xxxxxxxxxxxxxx>
> Cc: Patrik Fältström <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, 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.)
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|