what about a process to review/evaluate whether SSAC recommendations warrant action by the GNSO
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.)
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@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@gnso.icann.org GNSO" <council@gnso.icann.org> Cc: Patrik Fältström <patrik@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, 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.)
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@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 im reposting this because id 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 im thinking was due to the pre-holiday crush. so im trying again. and making a formal request for an agenda slot. thanks, mikey Begin forwarded message: From: "Mike O'Connor" <mike@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@gnso.icann.org GNSO" <council@gnso.icann.org> Cc: Patrik Fältström <patrik@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 ICANNs 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 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 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, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
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@afilias.info> 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@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@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@gnso.icann.org GNSO" <council@gnso.icann.org> Cc: Patrik Fältström <patrik@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, 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.)
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@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@haven2.com <mailto:mike@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@gnso.icann.org <mailto:council@gnso.icann.org> GNSO" <council@gnso.icann.org <mailto:council@gnso.icann.org>>
*Cc: *Patrik Fältström <patrik@frobbit.se <mailto:patrik@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.)
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@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@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@haven2.com <mailto:mike@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@gnso.icann.org <mailto:council@gnso.icann.org> GNSO" <council@gnso.icann.org <mailto:council@gnso.icann.org>>
*Cc: *Patrik Fältström <patrik@frobbit.se <mailto:patrik@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.)
Thanks All, The very brief discussions I had in B A led me to understand that there was no issue with a liason from SSAC to the GNSO Council. The other way around could be more difficult, perhaps for the reasons touched on below. Somewhat ironically, the problem occurs in reverse with the GAC hence one of the issues being explored in the GAC / GNSO Consultation Group is that of a "Reverse Liason". Jonathan -----Original Message----- From: Mike O'Connor [mailto:mike@haven2.com] Sent: 10 January 2014 16:06 To: Avri Doria Cc: council@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 theres 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* thats the issue thats on Patriks mind, although im 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, im 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@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@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 im reposting this because id 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 im thinking was due to the pre-holiday crush.
so im trying again. and making a formal request for an agenda slot.
thanks,
mikey
Begin forwarded message:
*From: *"Mike O'Connor" <mike@haven2.com <mailto:mike@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@gnso.icann.org <mailto:council@gnso.icann.org> GNSO" <council@gnso.icann.org <mailto:council@gnso.icann.org>>
*Cc: *Patrik Fältström <patrik@frobbit.se <mailto:patrik@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 ICANNs 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 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
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.)
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@haven2.com] Sent: 10 January 2014 16:06 To: Avri Doria Cc: council@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 theres 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* thats the issue thats on Patriks mind, although im 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, im 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@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@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 im reposting this because id 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 im thinking was due to the pre-holiday crush.
so im trying again. and making a formal request for an agenda slot.
thanks,
mikey
Begin forwarded message:
*From: *"Mike O'Connor" <mike@haven2.com <mailto:mike@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@gnso.icann.org <mailto:council@gnso.icann.org> GNSO" <council@gnso.icann.org <mailto:council@gnso.icann.org>>
*Cc: *Patrik Fältström <patrik@frobbit.se <mailto:patrik@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 ICANNs 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 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
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.)
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@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@haven2.com] Sent: 10 January 2014 16:06 To: Avri Doria Cc: council@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@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@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@haven2.com <mailto:mike@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@gnso.icann.org <mailto:council@gnso.icann.org> GNSO" <council@gnso.icann.org <mailto:council@gnso.icann.org>>
*Cc: *Patrik Fältström <patrik@frobbit.se <mailto:patrik@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.)
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@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@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@haven2.com] Sent: 10 January 2014 16:06 To: Avri Doria Cc: council@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@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@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@haven2.com <mailto:mike@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@gnso.icann.org <mailto:council@gnso.icann.org> GNSO" <council@gnso.icann.org <mailto:council@gnso.icann.org>>
*Cc: *Patrik Fältström <patrik@frobbit.se <mailto:patrik@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@uniregistry.com — — — — —
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@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@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@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@haven2.com] Sent: 10 January 2014 16:06 To: Avri Doria Cc: council@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@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@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@haven2.com <mailto:mike@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@gnso.icann.org <mailto:council@gnso.icann.org> GNSO" <council@gnso.icann.org <mailto:council@gnso.icann.org>>
*Cc: *Patrik Fältström <patrik@frobbit.se <mailto:patrik@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@uniregistry.com — — — — —
PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
Hi Avri, I can confirm that there are no GNSO Council members who are also SSAC members. Just a note about your second question. According to the SSAC procedures anyone participating in the SSAC must be an SSAC member. If the GNSO were to appoint an inward liaison to the SSAC that person would have to go through the SSAC membership process -- that is, be qualified as an SSAC member regardless of liaison status and be appointed by the Board as such. For example, ALAC selected Julie Hammer as a liaison to the SSAC, but the SSAC evaluated and accepted Julie as an SSAC member as part of its regular membership process because she was qualified to be a member. Her potential liaison status was not a factor in that evaluation. I have included the text from the Operational Procedures below. I hope this information is helpful but please let me know if you have any questions. Best regards, Julie 2.7.4 SSAC Inward Liaisons [See http://www.icann.org/en/groups/ssac/operational-procedures-18jan13-en.pdf] Various ICANN SOs and ACs and related panels and entities (³groups²) have asked to send liaisons to the SSAC. The SSAC has generally welcomed the idea of inward liaisons, but it has insisted that an inward liaison also be a full-fledged member of the SSAC. These inward liaisons represent the community of their appointing group in a general sense, not as an authority speaking on their behalf. Inward liaisons provide information about the community and offer insight and context as needed to SSAC activities. Similarly, inward liaisons will learn about the SSAC and its activities by participation in SSAC and, within the constraints of confidentiality, may mention or comment on these activities to their appointing groups. Inward liaisons may be asked to facilitate communication with those groups. The groups with which the SSAC chooses to liaise are selected by the SSAC. Groups are selected based on an identified need to maintain a cooperative relationship. An inward liaison to the SSAC participates as a full member of the SSAC. An inward liaison participates in the other group according to the mutual agreement of both groups when the liaison relationship is established. Unless otherwise established by the mutual agreement of the SSAC and the other group, inward liaisons are expected to affirm their commitment to the obligations of SSAC membership as previously specified. On 1/10/14 10:53 AM, "Avri Doria" <avri@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@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@haven2.com <mailto:mike@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@gnso.icann.org <mailto:council@gnso.icann.org> GNSO" <council@gnso.icann.org <mailto:council@gnso.icann.org>>
*Cc: *Patrik Fältström <patrik@frobbit.se <mailto:patrik@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.)
Thanks Julie, I replied before seeing this. Our points are consistent I think. Jonathan -----Original Message----- From: Julie Hedlund [mailto:julie.hedlund@icann.org] Sent: 10 January 2014 16:08 To: Avri Doria; council@gnso.icann.org Subject: Re: [council] Repost: a process to review/evaluate whether SSAC recommendations warrant action by the GNSO Hi Avri, I can confirm that there are no GNSO Council members who are also SSAC members. Just a note about your second question. According to the SSAC procedures anyone participating in the SSAC must be an SSAC member. If the GNSO were to appoint an inward liaison to the SSAC that person would have to go through the SSAC membership process -- that is, be qualified as an SSAC member regardless of liaison status and be appointed by the Board as such. For example, ALAC selected Julie Hammer as a liaison to the SSAC, but the SSAC evaluated and accepted Julie as an SSAC member as part of its regular membership process because she was qualified to be a member. Her potential liaison status was not a factor in that evaluation. I have included the text from the Operational Procedures below. I hope this information is helpful but please let me know if you have any questions. Best regards, Julie 2.7.4 SSAC Inward Liaisons [See http://www.icann.org/en/groups/ssac/operational-procedures-18jan13-en.pdf] Various ICANN SOs and ACs and related panels and entities (³groups²) have asked to send liaisons to the SSAC. The SSAC has generally welcomed the idea of inward liaisons, but it has insisted that an inward liaison also be a full-fledged member of the SSAC. These inward liaisons represent the community of their appointing group in a general sense, not as an authority speaking on their behalf. Inward liaisons provide information about the community and offer insight and context as needed to SSAC activities. Similarly, inward liaisons will learn about the SSAC and its activities by participation in SSAC and, within the constraints of confidentiality, may mention or comment on these activities to their appointing groups. Inward liaisons may be asked to facilitate communication with those groups. The groups with which the SSAC chooses to liaise are selected by the SSAC. Groups are selected based on an identified need to maintain a cooperative relationship. An inward liaison to the SSAC participates as a full member of the SSAC. An inward liaison participates in the other group according to the mutual agreement of both groups when the liaison relationship is established. Unless otherwise established by the mutual agreement of the SSAC and the other group, inward liaisons are expected to affirm their commitment to the obligations of SSAC membership as previously specified. On 1/10/14 10:53 AM, "Avri Doria" <avri@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@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@haven2.com <mailto:mike@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@gnso.icann.org <mailto:council@gnso.icann.org> GNSO" <council@gnso.icann.org <mailto:council@gnso.icann.org>>
*Cc: *Patrik Fältström <patrik@frobbit.se <mailto:patrik@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.)
Thanks Jonathan. I agree that our points are consistent. Best regards, Julie On 1/10/14 11:55 AM, "Jonathan Robinson" <jrobinson@afilias.info> wrote:
Thanks Julie,
I replied before seeing this.
Our points are consistent I think.
Jonathan
-----Original Message----- From: Julie Hedlund [mailto:julie.hedlund@icann.org] Sent: 10 January 2014 16:08 To: Avri Doria; council@gnso.icann.org Subject: Re: [council] Repost: a process to review/evaluate whether SSAC recommendations warrant action by the GNSO
Hi Avri,
I can confirm that there are no GNSO Council members who are also SSAC members.
Just a note about your second question. According to the SSAC procedures anyone participating in the SSAC must be an SSAC member. If the GNSO were to appoint an inward liaison to the SSAC that person would have to go through the SSAC membership process -- that is, be qualified as an SSAC member regardless of liaison status and be appointed by the Board as such. For example, ALAC selected Julie Hammer as a liaison to the SSAC, but the SSAC evaluated and accepted Julie as an SSAC member as part of its regular membership process because she was qualified to be a member. Her potential liaison status was not a factor in that evaluation. I have included the text from the Operational Procedures below.
I hope this information is helpful but please let me know if you have any questions.
Best regards,
Julie
2.7.4 SSAC Inward Liaisons [See http://www.icann.org/en/groups/ssac/operational-procedures-18jan13-en.pdf]
Various ICANN SOs and ACs and related panels and entities (³groups²) have asked to send liaisons to the SSAC. The SSAC has generally welcomed the idea of inward liaisons, but it has insisted that an inward liaison also be a full-fledged member of the SSAC. These inward liaisons represent the community of their appointing group in a general sense, not as an authority speaking on their behalf. Inward liaisons provide information about the community and offer insight and context as needed to SSAC activities. Similarly, inward liaisons will learn about the SSAC and its activities by participation in SSAC and, within the constraints of confidentiality, may mention or comment on these activities to their appointing groups. Inward liaisons may be asked to facilitate communication with those groups.
The groups with which the SSAC chooses to liaise are selected by the SSAC. Groups are selected based on an identified need to maintain a cooperative relationship. An inward liaison to the SSAC participates as a full member of the SSAC. An inward liaison participates in the other group according to the mutual agreement of both groups when the liaison relationship is established. Unless otherwise established by the mutual agreement of the SSAC and the other group, inward liaisons are expected to affirm their commitment to the obligations of SSAC membership as previously specified.
On 1/10/14 10:53 AM, "Avri Doria" <avri@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@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@haven2.com <mailto:mike@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@gnso.icann.org <mailto:council@gnso.icann.org> GNSO" <council@gnso.icann.org <mailto:council@gnso.icann.org>>
*Cc: *Patrik Fältström <patrik@frobbit.se <mailto:patrik@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.)
No objections, I like the idea. J. Sent via iPhone. Blame Siri. On Jan 10, 2014, at 7:00, "Mike O'Connor" <mike@haven2.com<mailto:mike@haven2.com>> wrote: 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@haven2.com<mailto:mike@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@gnso.icann.org<mailto:council@gnso.icann.org> GNSO" <council@gnso.icann.org<mailto:council@gnso.icann.org>> Cc: Patrik Fältström <patrik@frobbit.se<mailto:patrik@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.)
participants (6)
-
Avri Doria -
Bret Fausett -
James M. Bladel -
Jonathan Robinson -
Julie Hedlund -
Mike O'Connor