<<<
Chronological Index
>>> <<<
Thread Index
>>>
[council] what about a process to review/evaluate whether SSAC recommendations warrant action by the GNSO
- To: "council@xxxxxxxxxxxxxx GNSO" <council@xxxxxxxxxxxxxx>
- Subject: [council] what about a process to review/evaluate whether SSAC recommendations warrant action by the GNSO
- From: "Mike O'Connor" <mike@xxxxxxxxxx>
- Date: Thu, 19 Dec 2013 10:53:13 -0600
- Cc: Patrik Fältström <patrik@xxxxxxxxxx>
- List-id: council@xxxxxxxxxxxxxx
- Sender: owner-council@xxxxxxxxxxxxxx
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.)
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|