Hi All, Further to our discussion on the call yesterday (16 December) I just want to share some information on the formation and role of the CSC. In the IANA Stewardship proposal https://www.ianacg.org/icg-files/documents/IANA-transition-proposal-final.pd... , we can find the foundational mandate of the CSC in paragraphs 1129-1132 Customer Standing Committee (CSC) – Overseeing performance of IANA Functions as they relate to naming services. The CWG-Stewardship recommends the creation of a CSC to monitor the performance of PTI with the following mission: * “The Customer Standing Committee (CSC) has been established to perform the operational oversight previously performed by the U.S. Department of Commerce’s National Telecommunications and Information Administration as it relates to the monitoring of performance of the IANA naming function. This transfer of responsibilities took effect on [date]. * The mission of the CSC is to ensure continued satisfactory performance of the IANA function for the direct customers of the naming services. The primary customers of the naming services are TLD registry operators, but also include root server operators and other non-root zone functions. The mission will be achieved through regular monitoring by the CSC of the performance of the IANA naming function against agreed service level targets and through mechanisms to engage with the IANA Functions Operator to remedy identified areas of concern.” * The CSC is not mandated to initiate a change in the IANA Functions Operator via a Special IANA Function Review, but could escalate to the ccNSO and GNSO Councils or either body in the specific case where the issue in question applies only to ccTLDs or gTLDs respectively, which might then decide to take further action using agreed consultation and escalation processes (see Annex J). * The complete proposed charter of the CSC can be found in Annex G. Then in the foundational charter in paragraph 1314 we have the mandate * The CSC is authorized to monitor the performance of the IANA naming function against agreed service level targets on a regular basis. For me the CSC has excelled in performing this role as designed and mandated, this was confirmed by the CSC effectiveness review and charter reviews that took place during our first 3 years of operation which did not recommend any changes or increase in scope. Indeed going back to the charter and proposal we had accounted for the eventuality that the CSC may need to evolve: * Thereafter, the Charter will be reviewed at the request of the CSC, ccNSO or GNSO and may also be reviewed in connection with the IANA Function Review. * The effectiveness of the CSC will initially be reviewed two years after the first meeting of the CSC; and then every three years thereafter. The method of review will be determined by the ccNSO and GNSO. I have a personal opinion that based on the structure and method of formation of the CSC that the correct process for assessing the evolution of the role of the CSC is though the designed reviews that were very careful to be put in place to allow a structured evaluation based on the needs of the IANA customers. I don’t believe that we as the CSC internally should be seeking to expand our role without a clear mandate to do so from the ccNSO and GNSO. If members believe that this is a needed evolution then I think that the correct method to approach this is to do this through the ccNSO and GNSO councils making that request of us rather than us doing it internally. The CSC strikes a very delicate balance in its role and operation and I have serious concerns about changing that when it is working so effectively. A comment was made on the call that we cannot sit doing the same thing every month without change, however I will put forward that that is exactly what we should be doing, this is a very narrow scoped and designed committee that should not be exciting or challenging, it needs to be clean and effective and not be subject to scope creep for it to remain as effective as it has been to date. --- James Gannon
Thanks James for the straight response below I think it’s really helpful especially for newer members of the CSC (I still feel like one a lot of the time). I think the CSC has an extremely good (and well deserved) reputation for the work it does and you are right that has been shown in some of the recent reviews we have taken part in. IMHO We need to ensure that our priorities are to ensure we continue to do the things referred to in our charter well and continue to build on our excellent reputation. All that said I don’t think it will be do any harm to see if we can spend some time seeing if there are areas that we can add more value (I think dnssec is potentially a good example here), however I think we should do that in a clear and transparent manner, where we work with the PTI to work out what would be appropriate and useful and then should we decide there are additional SLAs areas we could monitor propose them to the ccNSO anmd GNSO council so they can formally ask us to take those actions. Brett -- Brett Carr Manager DNS and Network Engineering Nominet UK From: ICANN-CSC <icann-csc-bounces@icann.org> on behalf of James Gannon <lists@icann.guru> Date: Tuesday, 17 December 2019 at 14:35 To: "ICANN-CSC@icann.org" <ICANN-CSC@icann.org> Subject: [ICANN-CSC] Role of the CSC Hi All, Further to our discussion on the call yesterday (16 December) I just want to share some information on the formation and role of the CSC. In the IANA Stewardship proposal https://www.ianacg.org/icg-files/documents/IANA-transition-proposal-final.pd... , we can find the foundational mandate of the CSC in paragraphs 1129-1132 Customer Standing Committee (CSC) – Overseeing performance of IANA Functions as they relate to naming services. The CWG-Stewardship recommends the creation of a CSC to monitor the performance of PTI with the following mission: · “The Customer Standing Committee (CSC) has been established to perform the operational oversight previously performed by the U.S. Department of Commerce’s National Telecommunications and Information Administration as it relates to the monitoring of performance of the IANA naming function. This transfer of responsibilities took effect on [date]. · The mission of the CSC is to ensure continued satisfactory performance of the IANA function for the direct customers of the naming services. The primary customers of the naming services are TLD registry operators, but also include root server operators and other non-root zone functions. The mission will be achieved through regular monitoring by the CSC of the performance of the IANA naming function against agreed service level targets and through mechanisms to engage with the IANA Functions Operator to remedy identified areas of concern.” · The CSC is not mandated to initiate a change in the IANA Functions Operator via a Special IANA Function Review, but could escalate to the ccNSO and GNSO Councils or either body in the specific case where the issue in question applies only to ccTLDs or gTLDs respectively, which might then decide to take further action using agreed consultation and escalation processes (see Annex J). · The complete proposed charter of the CSC can be found in Annex G. Then in the foundational charter in paragraph 1314 we have the mandate · The CSC is authorized to monitor the performance of the IANA naming function against agreed service level targets on a regular basis. For me the CSC has excelled in performing this role as designed and mandated, this was confirmed by the CSC effectiveness review and charter reviews that took place during our first 3 years of operation which did not recommend any changes or increase in scope. Indeed going back to the charter and proposal we had accounted for the eventuality that the CSC may need to evolve: · Thereafter, the Charter will be reviewed at the request of the CSC, ccNSO or GNSO and may also be reviewed in connection with the IANA Function Review. · The effectiveness of the CSC will initially be reviewed two years after the first meeting of the CSC; and then every three years thereafter. The method of review will be determined by the ccNSO and GNSO. I have a personal opinion that based on the structure and method of formation of the CSC that the correct process for assessing the evolution of the role of the CSC is though the designed reviews that were very careful to be put in place to allow a structured evaluation based on the needs of the IANA customers. I don’t believe that we as the CSC internally should be seeking to expand our role without a clear mandate to do so from the ccNSO and GNSO. If members believe that this is a needed evolution then I think that the correct method to approach this is to do this through the ccNSO and GNSO councils making that request of us rather than us doing it internally. The CSC strikes a very delicate balance in its role and operation and I have serious concerns about changing that when it is working so effectively. A comment was made on the call that we cannot sit doing the same thing every month without change, however I will put forward that that is exactly what we should be doing, this is a very narrow scoped and designed committee that should not be exciting or challenging, it needs to be clean and effective and not be subject to scope creep for it to remain as effective as it has been to date. --- James Gannon
Dear colleagues, my comment was not about any kind of evolution, but about the execution of the existing agreement. I just want to add some references to IANA Naming Function Contract here to explain it. https://www.icann.org/iana_pti_docs/151-iana-naming-function-contract-v-30se... "ANNEX A: STATEMENT OF WORK FOR MANAGEMENT OF THE DNS ROOT ZONE .... 4. BASELINE REQUIREMENTS FOR DNSSEC IN THE AUTHORITATIVE ROOT ZONE .... f. Audit and Accountability Procedures i. Contractor shall periodically review/update: (1) its formal, documented,audit and accountability policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and (2) the formal, documented procedures to facilitate the implementation of the audit and accountability policy and associated audit and accountability controls. 1. Supplemental guidance on auditing and accountability policies may be found in NIST SP 800-12. 2. Specific auditing events include the following: a. Generation of keys. b. Generation of signatures c. Exporting of public key material d. Receipt and validation of public key material (i.e., from the ZSK holder or from TLDs) e. System configuration changes f. Maintenance and/or system updates g. Incident response handling h. Other events as appropriate ii. Incident handling for physical and exceptional cyber-attacks shall include reporting to ICANN in a timeframe and format as mutually agreed by ICANN and Contractor. iii. The auditing system shall be capable of producing reports on an ad-hoc basis for ICANN or the CSC. iv. A version of the reports provided to ICANN or the CSC must be made publically available." As I understood from this text - the form of monitoring for DNSSEC was already defined in the Contract. I just mentioned that I never saw the evidence that we have got such reports. It was my question. Please, correct me - may be I forgot something regards, Dmitry On 12/17/19 6:16 PM, Brett Carr wrote:
Thanks James for the straight response below I think it’s really helpful especially for newer members of the CSC (I still feel like one a lot of the time).
I think the CSC has an extremely good (and well deserved) reputation for the work it does and you are right that has been shown in some of the recent reviews we have taken part in.
IMHO We need to ensure that our priorities are to ensure we continue to do the things referred to in our charter well and continue to build on our excellent reputation.
All that said I don’t think it will be do any harm to see if we can spend some time seeing if there are areas that we can add more value (I think dnssec is potentially a good example here), however I think we should do that in a clear and transparent manner, where we work with the PTI to work out what would be appropriate and useful and then should we decide there are additional SLAs areas we could monitor propose them to the ccNSO anmd GNSO council so they can formally ask us to take those actions.
Brett
-- Brett Carr Manager DNS and Network Engineering Nominet UK
*From: *ICANN-CSC <icann-csc-bounces@icann.org> on behalf of James Gannon <lists@icann.guru> *Date: *Tuesday, 17 December 2019 at 14:35 *To: *"ICANN-CSC@icann.org" <ICANN-CSC@icann.org> *Subject: *[ICANN-CSC] Role of the CSC
Hi All,
Further to our discussion on the call yesterday (16 December) I just want to share some information on the formation and role of the CSC.
In the IANA Stewardship proposal https://www.ianacg.org/icg-files/documents/IANA-transition-proposal-final.pd..., we can find the foundational mandate of the CSC in paragraphs 1129-1132
Customer Standing Committee (CSC) – Overseeing performance of IANA Functions as they relate to naming services.
The CWG-Stewardship recommends the creation of a CSC to monitor the performance of PTI with the following mission:
·“The Customer Standing Committee (CSC) has been established to perform the operational oversight previously performed by the U.S. Department of Commerce’s National Telecommunications and Information Administration as it relates to the monitoring of performance of the IANA naming function. This transfer of responsibilities took effect on [date].
·The mission of the CSC is to ensure continued satisfactory performance of the IANA function for the direct customers of the naming services. The primary customers of the naming services are TLD registry operators, but also include root server operators and other non-root zone functions. The mission will be achieved through regular monitoring by the CSC of the performance of the IANA naming function against agreed service level targets and through mechanisms to engage with the IANA Functions Operator to remedy identified areas of concern.”
·The CSC is not mandated to initiate a change in the IANA Functions Operator via a Special IANA Function Review, but could escalate to the ccNSO and GNSO Councils or either body in the specific case where the issue in question applies only to ccTLDs or gTLDs respectively, which might then decide to take further action using agreed consultation and escalation processes (see Annex J).
·The complete proposed charter of the CSC can be found in Annex G.
Then in the foundational charter in paragraph 1314 we have the mandate
·The CSC is authorized to monitor the performance of the IANA naming function against agreed service level targets on a regular basis.
For me the CSC has excelled in performing this role as designed and mandated, this was confirmed by the CSC effectiveness review and charter reviews that took place during our first 3 years of operation which did not recommend any changes or increase in scope.
Indeed going back to the charter and proposal we had accounted for the eventuality that the CSC may need to evolve:
·Thereafter, the Charter will be reviewed at the request of the CSC, ccNSO or GNSO and may also be reviewed in connection with the IANA Function Review.
·The effectiveness of the CSC will initially be reviewed two years after the first meeting of the CSC; and then every three years thereafter. The method of review will be determined by the ccNSO and GNSO.
I have a personal opinion that based on the structure and method of formation of the CSC that the correct process for assessing the evolution of the role of the CSC is though the designed reviews that were very careful to be put in place to allow a structured evaluation based on the needs of the IANA customers. I don’t believe that we as the CSC internally should be seeking to expand our role without a clear mandate to do so from the ccNSO and GNSO. If members believe that this is a needed evolution then I think that the correct method to approach this is to do this through the ccNSO and GNSO councils making that request of us rather than us doing it internally.
The CSC strikes a very delicate balance in its role and operation and I have serious concerns about changing that when it is working so effectively. A comment was made on the call that we cannot sit doing the same thing every month without change, however I will put forward that that is exactly what we should be doing, this is a very narrow scoped and designed committee that should not be exciting or challenging, it needs to be clean and effective and not be subject to scope creep for it to remain as effective as it has been to date.
---
*James Gannon*
_______________________________________________ ICANN-CSC mailing list ICANN-CSC@icann.org https://mm.icann.org/mailman/listinfo/icann-csc
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Thanks for this Dimitry, this helps to allay some of my fears so is very useful for me, yes if we are speaking purely about exercising existing mandates to view reports etc then I have much less concern, I just don’t want to CSC to move towards any kind of active involvement in operational areas for PTI such as the management of the DNSSEC/KMF/TCR processes etc. As we agreed I think discussing the methods for receiving such reports etc would be a good topic for our working meeting in Cancun. --- James Gannon From: ICANN-CSC <icann-csc-bounces@icann.org> on behalf of Dmitry Burkov <dvburk@gmail.com> Date: Wednesday, 18 December 2019 at 05:07 To: "ICANN-CSC@icann.org" <icann-csc@icann.org> Subject: Re: [ICANN-CSC] Role of the CSC Dear colleagues, my comment was not about any kind of evolution, but about the execution of the existing agreement. I just want to add some references to IANA Naming Function Contract here to explain it. https://www.icann.org/iana_pti_docs/151-iana-naming-function-contract-v-30se... "ANNEX A: STATEMENT OF WORK FOR MANAGEMENT OF THE DNS ROOT ZONE .... 4. BASELINE REQUIREMENTS FOR DNSSEC IN THE AUTHORITATIVE ROOT ZONE .... f. Audit and Accountability Procedures i. Contractor shall periodically review/update: (1) its formal, documented,audit and accountability policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and (2) the formal, documented procedures to facilitate the implementation of the audit and accountability policy and associated audit and accountability controls. 1. Supplemental guidance on auditing and accountability policies may be found in NIST SP 800-12. 2. Specific auditing events include the following: a. Generation of keys. b. Generation of signatures c. Exporting of public key material d. Receipt and validation of public key material (i.e., from the ZSK holder or from TLDs) e. System configuration changes f. Maintenance and/or system updates g. Incident response handling h. Other events as appropriate ii. Incident handling for physical and exceptional cyber-attacks shall include reporting to ICANN in a timeframe and format as mutually agreed by ICANN and Contractor. iii. The auditing system shall be capable of producing reports on an ad-hoc basis for ICANN or the CSC. iv. A version of the reports provided to ICANN or the CSC must be made publically available." As I understood from this text - the form of monitoring for DNSSEC was already defined in the Contract. I just mentioned that I never saw the evidence that we have got such reports. It was my question. Please, correct me - may be I forgot something regards, Dmitry On 12/17/19 6:16 PM, Brett Carr wrote: Thanks James for the straight response below I think it’s really helpful especially for newer members of the CSC (I still feel like one a lot of the time). I think the CSC has an extremely good (and well deserved) reputation for the work it does and you are right that has been shown in some of the recent reviews we have taken part in. IMHO We need to ensure that our priorities are to ensure we continue to do the things referred to in our charter well and continue to build on our excellent reputation. All that said I don’t think it will be do any harm to see if we can spend some time seeing if there are areas that we can add more value (I think dnssec is potentially a good example here), however I think we should do that in a clear and transparent manner, where we work with the PTI to work out what would be appropriate and useful and then should we decide there are additional SLAs areas we could monitor propose them to the ccNSO anmd GNSO council so they can formally ask us to take those actions. Brett -- Brett Carr Manager DNS and Network Engineering Nominet UK From: ICANN-CSC <icann-csc-bounces@icann.org><mailto:icann-csc-bounces@icann.org> on behalf of James Gannon <lists@icann.guru><mailto:lists@icann.guru> Date: Tuesday, 17 December 2019 at 14:35 To: "ICANN-CSC@icann.org"<mailto:ICANN-CSC@icann.org> <ICANN-CSC@icann.org><mailto:ICANN-CSC@icann.org> Subject: [ICANN-CSC] Role of the CSC Hi All, Further to our discussion on the call yesterday (16 December) I just want to share some information on the formation and role of the CSC. In the IANA Stewardship proposal https://www.ianacg.org/icg-files/documents/IANA-transition-proposal-final.pd... , we can find the foundational mandate of the CSC in paragraphs 1129-1132 Customer Standing Committee (CSC) – Overseeing performance of IANA Functions as they relate to naming services. The CWG-Stewardship recommends the creation of a CSC to monitor the performance of PTI with the following mission: • “The Customer Standing Committee (CSC) has been established to perform the operational oversight previously performed by the U.S. Department of Commerce’s National Telecommunications and Information Administration as it relates to the monitoring of performance of the IANA naming function. This transfer of responsibilities took effect on [date]. • The mission of the CSC is to ensure continued satisfactory performance of the IANA function for the direct customers of the naming services. The primary customers of the naming services are TLD registry operators, but also include root server operators and other non-root zone functions. The mission will be achieved through regular monitoring by the CSC of the performance of the IANA naming function against agreed service level targets and through mechanisms to engage with the IANA Functions Operator to remedy identified areas of concern.” • The CSC is not mandated to initiate a change in the IANA Functions Operator via a Special IANA Function Review, but could escalate to the ccNSO and GNSO Councils or either body in the specific case where the issue in question applies only to ccTLDs or gTLDs respectively, which might then decide to take further action using agreed consultation and escalation processes (see Annex J). • The complete proposed charter of the CSC can be found in Annex G. Then in the foundational charter in paragraph 1314 we have the mandate • The CSC is authorized to monitor the performance of the IANA naming function against agreed service level targets on a regular basis. For me the CSC has excelled in performing this role as designed and mandated, this was confirmed by the CSC effectiveness review and charter reviews that took place during our first 3 years of operation which did not recommend any changes or increase in scope. Indeed going back to the charter and proposal we had accounted for the eventuality that the CSC may need to evolve: • Thereafter, the Charter will be reviewed at the request of the CSC, ccNSO or GNSO and may also be reviewed in connection with the IANA Function Review. • The effectiveness of the CSC will initially be reviewed two years after the first meeting of the CSC; and then every three years thereafter. The method of review will be determined by the ccNSO and GNSO. I have a personal opinion that based on the structure and method of formation of the CSC that the correct process for assessing the evolution of the role of the CSC is though the designed reviews that were very careful to be put in place to allow a structured evaluation based on the needs of the IANA customers. I don’t believe that we as the CSC internally should be seeking to expand our role without a clear mandate to do so from the ccNSO and GNSO. If members believe that this is a needed evolution then I think that the correct method to approach this is to do this through the ccNSO and GNSO councils making that request of us rather than us doing it internally. The CSC strikes a very delicate balance in its role and operation and I have serious concerns about changing that when it is working so effectively. A comment was made on the call that we cannot sit doing the same thing every month without change, however I will put forward that that is exactly what we should be doing, this is a very narrow scoped and designed committee that should not be exciting or challenging, it needs to be clean and effective and not be subject to scope creep for it to remain as effective as it has been to date. --- James Gannon _______________________________________________ ICANN-CSC mailing list ICANN-CSC@icann.org<mailto:ICANN-CSC@icann.org> https://mm.icann.org/mailman/listinfo/icann-csc _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi Dmitry, Hi all, We perform two distinct annual security audits, that follow different frameworks: 1. We perform a SOC 3 audit that covers how we administer the Root Zone Key Signing Key. This audit certifies the control environment is fit for purpose against the criteria for availability, processing integrity and security. The certification is public and available for all to read. All audit reports dating back to 2010 are available at https://www.iana.org/about/audits, and are publicly announced (see https://www.icann.org/news/announcement-2019-03-26-en as the most recent example.) 2. We perform a SOC 2 audit that covers how we administer the systems the underly our request processing and registry maintenance, what we call the Registry Assignment and Maintenance Systems (RAMS). This includes our Root Zone Management System, ticketing system and so forth. The nature of a SOC 2 audit is that the complete report is not for publication, and according to the requirements should have a limited controlled audience. These audits have been performed since 2013. Post-transition, by agreement, these reports are limited to the leadership of the counter-parties to the three IANA contracts/sub-contracts — RIR CEOs (for the IANA Number Services SLA), head of the IETF and IAB (for the IETF MOU that governs protocol parameters), and ICANN management (that contracts PTI to perform the IANA Naming Functions). The audit approach is also summarized at the above link (https://www.iana.org/about/audits). I’ve attached a graphic I found through a quick web search that helps illustrate the difference between SOC 3 and SOC 2 and their distribution (and SOC 1 for that matter, which we do not do, as it is limited to finance.) I hope that helps clarify. kim Kim Davies VP, IANA Services, ICANN President, Public Technical Identifiers (PTI) "ICANN-CSC on behalf of Dmitry Burkov" <icann-csc-bounces@icann.org<mailto:icann-csc-bounces@icann.org> on behalf of dvburk@gmail.com<mailto:dvburk@gmail.com>> wrote: Dear colleagues, my comment was not about any kind of evolution, but about the execution of the existing agreement. I just want to add some references to IANA Naming Function Contract here to explain it. https://www.icann.org/iana_pti_docs/151-iana-naming-function-contract-v-30se... [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_iana-5Fpt...> "ANNEX A: STATEMENT OF WORK FOR MANAGEMENT OF THE DNS ROOT ZONE .... 4. BASELINE REQUIREMENTS FOR DNSSEC IN THE AUTHORITATIVE ROOT ZONE .... f. Audit and Accountability Procedures i. Contractor shall periodically review/update: (1) its formal, documented,audit and accountability policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and (2) the formal, documented procedures to facilitate the implementation of the audit and accountability policy and associated audit and accountability controls. 1. Supplemental guidance on auditing and accountability policies may be found in NIST SP 800-12. 2. Specific auditing events include the following: a. Generation of keys. b. Generation of signatures c. Exporting of public key material d. Receipt and validation of public key material (i.e., from the ZSK holder or from TLDs) e. System configuration changes f. Maintenance and/or system updates g. Incident response handling h. Other events as appropriate ii. Incident handling for physical and exceptional cyber-attacks shall include reporting to ICANN in a timeframe and format as mutually agreed by ICANN and Contractor. iii. The auditing system shall be capable of producing reports on an ad-hoc basis for ICANN or the CSC. iv. A version of the reports provided to ICANN or the CSC must be made publically available." As I understood from this text - the form of monitoring for DNSSEC was already defined in the Contract. I just mentioned that I never saw the evidence that we have got such reports. It was my question. Please, correct me - may be I forgot something regards, Dmitry On 12/17/19 6:16 PM, Brett Carr wrote: Thanks James for the straight response below I think it’s really helpful especially for newer members of the CSC (I still feel like one a lot of the time). I think the CSC has an extremely good (and well deserved) reputation for the work it does and you are right that has been shown in some of the recent reviews we have taken part in. IMHO We need to ensure that our priorities are to ensure we continue to do the things referred to in our charter well and continue to build on our excellent reputation. All that said I don’t think it will be do any harm to see if we can spend some time seeing if there are areas that we can add more value (I think dnssec is potentially a good example here), however I think we should do that in a clear and transparent manner, where we work with the PTI to work out what would be appropriate and useful and then should we decide there are additional SLAs areas we could monitor propose them to the ccNSO anmd GNSO council so they can formally ask us to take those actions. Brett -- Brett Carr Manager DNS and Network Engineering Nominet UK From: ICANN-CSC <icann-csc-bounces@icann.org><mailto:icann-csc-bounces@icann.org> on behalf of James Gannon <lists@icann.guru><mailto:lists@icann.guru> Date: Tuesday, 17 December 2019 at 14:35 To: "ICANN-CSC@icann.org"<mailto:ICANN-CSC@icann.org> <ICANN-CSC@icann.org><mailto:ICANN-CSC@icann.org> Subject: [ICANN-CSC] Role of the CSC Hi All, Further to our discussion on the call yesterday (16 December) I just want to share some information on the formation and role of the CSC. In the IANA Stewardship proposal https://www.ianacg.org/icg-files/documents/IANA-transition-proposal-final.pd... [ianacg.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ianacg.org_icg-2Dfi...> , we can find the foundational mandate of the CSC in paragraphs 1129-1132 Customer Standing Committee (CSC) – Overseeing performance of IANA Functions as they relate to naming services. The CWG-Stewardship recommends the creation of a CSC to monitor the performance of PTI with the following mission: · “The Customer Standing Committee (CSC) has been established to perform the operational oversight previously performed by the U.S. Department of Commerce’s National Telecommunications and Information Administration as it relates to the monitoring of performance of the IANA naming function. This transfer of responsibilities took effect on [date]. · The mission of the CSC is to ensure continued satisfactory performance of the IANA function for the direct customers of the naming services. The primary customers of the naming services are TLD registry operators, but also include root server operators and other non-root zone functions. The mission will be achieved through regular monitoring by the CSC of the performance of the IANA naming function against agreed service level targets and through mechanisms to engage with the IANA Functions Operator to remedy identified areas of concern.” · The CSC is not mandated to initiate a change in the IANA Functions Operator via a Special IANA Function Review, but could escalate to the ccNSO and GNSO Councils or either body in the specific case where the issue in question applies only to ccTLDs or gTLDs respectively, which might then decide to take further action using agreed consultation and escalation processes (see Annex J). · The complete proposed charter of the CSC can be found in Annex G. Then in the foundational charter in paragraph 1314 we have the mandate · The CSC is authorized to monitor the performance of the IANA naming function against agreed service level targets on a regular basis. For me the CSC has excelled in performing this role as designed and mandated, this was confirmed by the CSC effectiveness review and charter reviews that took place during our first 3 years of operation which did not recommend any changes or increase in scope. Indeed going back to the charter and proposal we had accounted for the eventuality that the CSC may need to evolve: · Thereafter, the Charter will be reviewed at the request of the CSC, ccNSO or GNSO and may also be reviewed in connection with the IANA Function Review. · The effectiveness of the CSC will initially be reviewed two years after the first meeting of the CSC; and then every three years thereafter. The method of review will be determined by the ccNSO and GNSO. I have a personal opinion that based on the structure and method of formation of the CSC that the correct process for assessing the evolution of the role of the CSC is though the designed reviews that were very careful to be put in place to allow a structured evaluation based on the needs of the IANA customers. I don’t believe that we as the CSC internally should be seeking to expand our role without a clear mandate to do so from the ccNSO and GNSO. If members believe that this is a needed evolution then I think that the correct method to approach this is to do this through the ccNSO and GNSO councils making that request of us rather than us doing it internally. The CSC strikes a very delicate balance in its role and operation and I have serious concerns about changing that when it is working so effectively. A comment was made on the call that we cannot sit doing the same thing every month without change, however I will put forward that that is exactly what we should be doing, this is a very narrow scoped and designed committee that should not be exciting or challenging, it needs to be clean and effective and not be subject to scope creep for it to remain as effective as it has been to date. --- James Gannon _______________________________________________ ICANN-CSC mailing list ICANN-CSC@icann.org<mailto:ICANN-CSC@icann.org> https://mm.icann.org/mailman/listinfo/icann-csc _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_p...>) and the website Terms of Service (https://www.icann.org/privacy/tos [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_t...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Thanks James - really useful material. Holly
On Dec 18, 2019, at 1:35 AM, James Gannon <lists@icann.guru> wrote:
Hi All,
Further to our discussion on the call yesterday (16 December) I just want to share some information on the formation and role of the CSC. In the IANA Stewardship proposal https://www.ianacg.org/icg-files/documents/IANA-transition-proposal-final.pd... <https://www.ianacg.org/icg-files/documents/IANA-transition-proposal-final.pd...> , we can find the foundational mandate of the CSC in paragraphs 1129-1132
Customer Standing Committee (CSC) – Overseeing performance of IANA Functions as they relate to naming services.
The CWG-Stewardship recommends the creation of a CSC to monitor the performance of PTI with the following mission: “The Customer Standing Committee (CSC) has been established to perform the operational oversight previously performed by the U.S. Department of Commerce’s National Telecommunications and Information Administration as it relates to the monitoring of performance of the IANA naming function. This transfer of responsibilities took effect on [date]. The mission of the CSC is to ensure continued satisfactory performance of the IANA function for the direct customers of the naming services. The primary customers of the naming services are TLD registry operators, but also include root server operators and other non-root zone functions. The mission will be achieved through regular monitoring by the CSC of the performance of the IANA naming function against agreed service level targets and through mechanisms to engage with the IANA Functions Operator to remedy identified areas of concern.” The CSC is not mandated to initiate a change in the IANA Functions Operator via a Special IANA Function Review, but could escalate to the ccNSO and GNSO Councils or either body in the specific case where the issue in question applies only to ccTLDs or gTLDs respectively, which might then decide to take further action using agreed consultation and escalation processes (see Annex J). The complete proposed charter of the CSC can be found in Annex G.
Then in the foundational charter in paragraph 1314 we have the mandate The CSC is authorized to monitor the performance of the IANA naming function against agreed service level targets on a regular basis.
For me the CSC has excelled in performing this role as designed and mandated, this was confirmed by the CSC effectiveness review and charter reviews that took place during our first 3 years of operation which did not recommend any changes or increase in scope.
Indeed going back to the charter and proposal we had accounted for the eventuality that the CSC may need to evolve: Thereafter, the Charter will be reviewed at the request of the CSC, ccNSO or GNSO and may also be reviewed in connection with the IANA Function Review. The effectiveness of the CSC will initially be reviewed two years after the first meeting of the CSC; and then every three years thereafter. The method of review will be determined by the ccNSO and GNSO.
I have a personal opinion that based on the structure and method of formation of the CSC that the correct process for assessing the evolution of the role of the CSC is though the designed reviews that were very careful to be put in place to allow a structured evaluation based on the needs of the IANA customers. I don’t believe that we as the CSC internally should be seeking to expand our role without a clear mandate to do so from the ccNSO and GNSO. If members believe that this is a needed evolution then I think that the correct method to approach this is to do this through the ccNSO and GNSO councils making that request of us rather than us doing it internally.
The CSC strikes a very delicate balance in its role and operation and I have serious concerns about changing that when it is working so effectively. A comment was made on the call that we cannot sit doing the same thing every month without change, however I will put forward that that is exactly what we should be doing, this is a very narrow scoped and designed committee that should not be exciting or challenging, it needs to be clean and effective and not be subject to scope creep for it to remain as effective as it has been to date.
--- James Gannon _______________________________________________ ICANN-CSC mailing list ICANN-CSC@icann.org <mailto:ICANN-CSC@icann.org> https://mm.icann.org/mailman/listinfo/icann-csc <https://mm.icann.org/mailman/listinfo/icann-csc>
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
participants (5)
-
Brett Carr -
Dmitry Burkov -
Holly Raiche -
James Gannon -
Kim Davies