<html>
<body>
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.<br><br>
Alan<br><br>
At 19/12/2013 03:04 PM, Mike O'Connor wrote:<br>
<blockquote type=cite class=cite cite="">wow. will you look at
that! another terrific resource i'd never heard of before.
<br><br>
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<br><br>
<a href="https://www.myicann.org/board-advice">
https://www.myicann.org/board-advice</a><br><br>
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? <br><br>
thanks!<br><br>
mikey<br><br>
<br>
On Dec 19, 2013, at 11:03 AM, Patrik Fältström
<<a href="mailto:patrik@frobbit.se">patrik@frobbit.se</a>>
wrote:<br><br>
<blockquote type=cite class=cite cite="">Mikey,<br><br>
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.<br><br>
<<a href="https://www.myicann.org/board-advice">
https://www.myicann.org/board-advice</a>><br><br>
Patrik Fältström<br>
SSAC Chair<br><br>
On 19 dec 2013, at 17:53, Mike O'Connor
<<a href="mailto:mike@haven2.com">mike@haven2.com</a>>
wrote:<br><br>
<blockquote type=cite class=cite cite="">dear all,<br><br>
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.<br><br>
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:<br><br>
<dl>
<dd>-- there are NO recommendations that require PDPs<br>
<dd>-- there ARE recommendations that require PDPs, or<br>
<dd>-- there are recommendations that we would like to know more about
before we decided whether a PDP is in order. <br><br>
</dl><br>
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<br><br>
<dl>
<dd>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.<br><br>
<br>
</dl>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. <br><br>
what if we:<br><br>
<dl>
<dd>-- discuss this "formally review SSAC reports" idea with
our stakeholders and on the Council list for a while<br><br>
<dd>-- put an agenda item on our next call to share what we've heard and
test a way forward<br><br>
<dd>-- get started, presuming nobody thinks this is a horrible
idea<br><br>
</dl><br>
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.<br><br>
thanks,<br><br>
mikey<br><br>
<br><br>
<br>
SAC061: SSAC Comment on ICANN’s Initial Report from the Expert
Working Group on gTLD Directory Services<br><br>
</b>
<a href="http://www.icann.org/en/groups/ssac/documents/sac-061-en.pdf">
http://www.icann.org/en/groups/ssac/documents/sac-061-en.pdf</a><br>
<br>
</b>
<dl>
<dd>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</b>. The EWG should clearly state its proposal for the purpose
of registration data, and focus on policy issues over specific
implementations.<br><br>
<dd>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.<br>
</b><br>
<dd>Recommendation 3: SSAC recommends that the EWG state more clearly its
positions on the following questions of data availability:<br><br>
<dd>A. Why is a change to public access justified?<br>
</b>
<dd>This explanation should describe the potential impact upon ordinary
Internet users and casual or occasional users of the directory
service.<br>
<br>
<dd>B. Does the EWG believe that access to data currently accessible in
generic Top Level Domain (gTLD) WHOIS output should become
restricted?<br>
</b>
<dd>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<br>
<br>
<dd>C. Should all gTLD registries be required to provision their contact
data into the Aggregated Registration Data Service (ARDS)? <br>
</b>
<dd>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.<br><br>
<dd>D. Does the EWG propose more types of sensitive registration data be
provisioned into ARDS than are found in current gTLD WHOIS output?</b>
<br><br>
<dd>Recommendation 4: The SSAC suggests that the EWG address this
recommendation from SAC058: “SSAC Report on Domain Name Registration Data
Validation”3:<br>
<dd>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</b>:<br><br>
<dd>• What data elements need to be added or validated to comply with
requirements or expectations of different stakeholders?<br>
<dd>• Is additional registration processing overhead and delay an
acceptable cost for improving accuracy and quality of registration
data?<br>
<dd>• Is higher cost an acceptable outcome for improving accuracy and
quality?<br>
<dd>• Would accuracy improve if the registration process were to provide
natural persons with privacy protection upon completion of multi-factored
validation?<br>
</b><br>
</dl><br><br>
SAC062: SSAC Advisory Concerning the Mitigation of Name Collision
Risk<br><br>
</b>
<a href="http://www.icann.org/en/groups/ssac/documents/sac-062-en.pdf">
http://www.icann.org/en/groups/ssac/documents/sac-062-en.pdf</a><br><br>
<dl>
<dd>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)</b>.<br><br>
<dd>Recommendation 2: </b>ICANN should explicitly consider the following
questions regarding trial delegation and clearly articulate what choices
have been made and why </b>as part of its decision as to whether or not
to delegate any TLD on a trial basis:<br><br>
<dd>-- Purpose of the trial:</b> What type of trial is to be conducted?
What data are to be collected?<br><br>
<dd>-- Operation of the trial</b>: Should ICANN (or a designated agent)
operate the trial or should the applicant operate it?<br><br>
<dd>-- Emergency Rollback</b>: What are the emergency rollback decision
and execution procedures for any delegation in the root, and have the
root zone partners exercised these capabilities?<br><br>
<dd>-- Termination of the trial:</b> 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?<br><br>
</dl><br>
</b>
<dl>
<dd>Recommendation 3: ICANN should explicitly consider under what
circumstances un-delegation of a TLD is the appropriate mitigation for a
security or stability issue.</b> 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.<br><br>
</dl><br>
SAC063: SSAC Advisory on DNSSEC Key Rollover in the Root
Zone</b><br>
<br>
</b>
<a href="http://www.icann.org/en/groups/ssac/documents/sac-063-en.pdf">
http://www.icann.org/en/groups/ssac/documents/sac-063-en.pdf</a><br><br>
Recommendations:</b><br><br>
<dl>
<dd>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</b>.<br>
<dd>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.<br>
</b><br>
<dd>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.<br>
</b><br>
<dd>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.<br>
</b><br>
<dd>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.<br><br>
</dl><br>
PHONE: 651-647-6109, FAX: 866-280-2356, WEB:
<a href="http://www.haven2.com/">www.haven2.com</a>, HANDLE: OConnorStP
(ID for Twitter, Facebook, LinkedIn, etc.) <br>
</blockquote></blockquote><br><br>
PHONE: 651-647-6109, FAX: 866-280-2356, WEB:
<a href="http://www.haven2.com">www.haven2.com</a>, HANDLE: OConnorStP
(ID for Twitter, Facebook, LinkedIn, etc.) <br>
</blockquote></body>
</html>