Re: [CWG-Stewardship] Service Level Expectations Design Team Template
Sorry, Jordan and anyone else I may have offended or put off. The word was poorly chosen. I certainly agree that no one should settle for less than they have today, and I have no problem with further clarity. I do have a problem with requirement which would force internal changes within IANA at the same time as the transition is going on. That violates the rule of making as few changes as possible in parallel. Alan At 01/03/2015 03:59 PM, Jordan Carter wrote:
Alan, all:
Since operational communities want a workable solution, calls of 'hostage' are probably wide of the mark and to be honest don't help the conversation flow. They could indeed unkindly be described as a tactic designed to stifle debate. I can't see that being your intention here, but it could be the effect of your words.
We, IANA customers, need this system to work because our work in turn depends on it. The names community should be entitled to at least as good an outcome from the post-transition settlement as today's settlement offers, but that baseline is no reason not to pitch for greater clarity and certainty when we can.
I've had some private correspondence suggesting there are some real issues that mean my simple distinction & view isn't necessarily workable. There may be substantive SLA improvements compared with status quo that are needed. I don't know yet. If there are, I'm happy to change my mind and argue they should be done as part of the transition.
Given the CWG has spent quite some time on a wide range of issues that are of less importance than this, I'm sure some time spent assuring operational quality won't be wasted.
Will try and write more later today.
Jordan
On Monday, 2 March 2015, Alan Greenberg <<mailto:alan.greenberg@mcgill.ca>alan.greenberg@mcgill.ca> wrote: This worries me.
How do we define "needs"? It sounds perilously close to that community holding the transition hostage for something that they want.
Alan
At 01/03/2015 02:17 AM, Jordan Carter wrote:
I've thought of a b/c mid point complication:
It is: whether anything needs to be added to currently documented SLA standards to allow the transition to be acceptable to any key customer community.
That's not a wholesale review but it's a little more than b), while respecting the need for conservatism and efficiency....
Jordan
On Sunday, 1 March 2015, Seun Ojedeji <seun.ojedeji@gmail.com > wrote: +1 to Jordan's specific suggestion as well; considering that everything works just fine right now is an indication that repeating the current SLA would at least maintain status quo. Will be good if that methodology is applied to other design teams as much as possible. The goal is to build a stronger ICANN and so long as we have a multistakeholder means/process to do that, then our job is done. Cheers! sent from Google nexus 4 kindly excuse brevity and typos. On 1 Mar 2015 01:46, "Chris Disspain" <ceo@auda.org.au> wrote: You read me right, man ;-)
Cheers,
Chris On 1 Mar 2015, at 11:35 , Jordan Carter <jordan@internetnz.net.nz> wrote:
Hi all, I think Chris's proposal makes sense too in logically separating: a) porting across existing service level obligations to the post-transition environment; b) creating the possibility of reviewing and changing them in future; and c) reviewing and updating the substantive content If I read him right a) and b) should be done, but c) should not. That might trim the work this design team needs to do and make finalising the names community proposal easier... cheers Jordan On 1 March 2015 at 08:56, Avri Doria <avri@acm.org> wrote: Hi, Makes sense to me.
avri On 28-Feb-15 18:43, Chris Disspain wrote:
On that basis I wonder whether we would not be better served by accepting the current status quo and building a mechanism for review and negotiated changes to those service levels that could be employed immediately after transition and on an ongoing basis. Thoughts?
---------- This email has been checked for viruses by Avast antivirus software. <http://www.avast.com/>www.avast.com
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org <https://mm.icann.org/mailman/listinfo/cwg-stewardship>https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- Jordan Carter
Chief Executive InternetNZ
04 495 2118 (office) | <tel:%2B64%2021%20442%20649>+64 21 442 649 (mob) jordan@internetnz.net.nz Skype: jordancarter
A better world through a better Internet
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org <https://mm.icann.org/mailman/listinfo/cwg-stewardship>https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org <https://mm.icann.org/mailman/listinfo/cwg-stewardship>https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- Jordan Carter Chief Executive, InternetNZ
+64-21-442-649 | jordan@internetnz.net.nz
Sent on the run, apologies for brevity _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org <https://mm.icann.org/mailman/listinfo/cwg-stewardship>https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- Jordan Carter Chief Executive, InternetNZ
+64-21-442-649 | <mailto:jordan@internetnz.net.nz>jordan@internetnz.net.nz
Sent on the run, apologies for brevity
Alan,
I do have a problem with requirement which would force internal changes within IANA at the same time as the transition is going on. That violates the rule of making as few changes as possible in parallel.
Apologies for being repetitive, but just to be sure, one more time with emphasis: Internal changes at IANA _must_ occur with the transition because NTIA is integrated into IANA operations. The process and possibly the code by which root zone updates are made _must_ change. This _may_ impact the SLEs as specified in C.4.2 of the current IANA Function Contract and hence could impact the outcome of the Design Team. It may be appropriate to minimize the internal changes required within IANA during the transition, but there already exists a requirement for some change. Regards, -drc
Yes David, of course! If it was not clear, I meant changes that are not required by the transition itself. Alan At 01/03/2015 06:00 PM, David Conrad wrote:
Alan,
I do have a problem with requirement which would force internal changes within IANA at the same time as the transition is going on. That violates the rule of making as few changes as possible in parallel.
Apologies for being repetitive, but just to be sure, one more time with emphasis:
Internal changes at IANA _must_ occur with the transition because NTIA is integrated into IANA operations.
The process and possibly the code by which root zone updates are made _must_ change. This _may_ impact the SLEs as specified in C.4.2 of the current IANA Function Contract and hence could impact the outcome of the Design Team.
It may be appropriate to minimize the internal changes required within IANA during the transition, but there already exists a requirement for some change.
Regards, -drc
Hi David,
Internal changes at IANA _must_ occur with the transition because NTIA is integrated into IANA operations.
I agree and it is that area that I believe the design team should concentrate on in consultation with IANA staff rather than undertaking a full blown study, review and re-vamp of current service levels etc. How would you recommend that those changes that must occur are dealt with? Cheers, Chris On 2 Mar 2015, at 10:00 , David Conrad <david.conrad@icann.org> wrote:
Alan,
I do have a problem with requirement which would force internal changes within IANA at the same time as the transition is going on. That violates the rule of making as few changes as possible in parallel.
Apologies for being repetitive, but just to be sure, one more time with emphasis:
Internal changes at IANA _must_ occur with the transition because NTIA is integrated into IANA operations.
The process and possibly the code by which root zone updates are made _must_ change. This _may_ impact the SLEs as specified in C.4.2 of the current IANA Function Contract and hence could impact the outcome of the Design Team.
It may be appropriate to minimize the internal changes required within IANA during the transition, but there already exists a requirement for some change.
Regards, -drc
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Chris, On Mar 1, 2015, at 6:45 PM, Chris Disspain <ceo@auda.org.au> wrote:
How would you recommend that those changes that must occur are dealt with?
First, the potential areas of change need to be identified. There are three obvious ones: 1) NTIA's "Root Zone Administrator" role: authorizing changes to the root before they are made: a) Changes to the root zone registration database data (i.e., "Whois"); and b) Proposed changes submitted to the Root Zone Maintainer (Verisign) for implementation. 2) NTIA's role in vetting/approving/gating systemic changes (e.g., approving the DNSSEC-signing of the root zone). 3) NTIA's role in specifying/accepting reporting of actions taken by IANA. There may be others -- my knowledge of IANA is dated and it is possible there are other actions now being performed by NTIA that need to be addressed in the post-NTIA world. Once the areas of change are identified, specific decisions need to be made by the community about how best the IANA Function Operator will be able to move forward without NTIA. For example (following the three I mention above): 1) The Root Zone Administrator role could go away, could be replaced by a single entity, or could be dealt with some other way. Given NTIA has never rejected a change request, I'd argue the role should simply go away, but I may be seen as biased on the topic. 2) Some mechanism will need to be defined by which the IANA Function Operator can be authorized to make systemic changes. There are a myriad possible ways in which this can be done, but my recommendation would be something that would focus on an efficient/timely way to ensure both technical correctness and abiding by the "do no harm" principle. 3) Similarly, some mechanism needs to be defined in which the information that needs to be provided to the community can be identified and presented in a useful way. Every piece of data that is collected and presented has a cost, either in money, time, or resources, so care must be taken to not over-burden IANA staff with information requests or folks should be prepared for increases in costs and/or delays. My recommendation would be to review the information NTIA currently demands and throw out the stuff no one cares about and not add anything new unless it can be shown to have direct benefit to the IANA Function Operator's accountability. I am happy to volunteer to participate in a design team on this topic, however since I am ICANN staff, I'm unsure whether my participation would be permitted. Regards, -drc
Thanks David. Personally, I’d be delighted if you helped out with this work. Not my decision though. Cheers, Chris On 2 Mar 2015, at 13:49 , David Conrad <david.conrad@icann.org> wrote:
Chris,
On Mar 1, 2015, at 6:45 PM, Chris Disspain <ceo@auda.org.au> wrote:
How would you recommend that those changes that must occur are dealt with?
First, the potential areas of change need to be identified. There are three obvious ones:
1) NTIA's "Root Zone Administrator" role: authorizing changes to the root before they are made: a) Changes to the root zone registration database data (i.e., "Whois"); and b) Proposed changes submitted to the Root Zone Maintainer (Verisign) for implementation.
2) NTIA's role in vetting/approving/gating systemic changes (e.g., approving the DNSSEC-signing of the root zone).
3) NTIA's role in specifying/accepting reporting of actions taken by IANA.
There may be others -- my knowledge of IANA is dated and it is possible there are other actions now being performed by NTIA that need to be addressed in the post-NTIA world.
Once the areas of change are identified, specific decisions need to be made by the community about how best the IANA Function Operator will be able to move forward without NTIA. For example (following the three I mention above):
1) The Root Zone Administrator role could go away, could be replaced by a single entity, or could be dealt with some other way. Given NTIA has never rejected a change request, I'd argue the role should simply go away, but I may be seen as biased on the topic.
2) Some mechanism will need to be defined by which the IANA Function Operator can be authorized to make systemic changes. There are a myriad possible ways in which this can be done, but my recommendation would be something that would focus on an efficient/timely way to ensure both technical correctness and abiding by the "do no harm" principle.
3) Similarly, some mechanism needs to be defined in which the information that needs to be provided to the community can be identified and presented in a useful way. Every piece of data that is collected and presented has a cost, either in money, time, or resources, so care must be taken to not over-burden IANA staff with information requests or folks should be prepared for increases in costs and/or delays. My recommendation would be to review the information NTIA currently demands and throw out the stuff no one cares about and not add anything new unless it can be shown to have direct benefit to the IANA Function Operator's accountability.
I am happy to volunteer to participate in a design team on this topic, however since I am ICANN staff, I'm unsure whether my participation would be permitted.
Regards, -drc
David, IMHO, Your involvement and engagement is most welcome, and would be a great addition to one or more of the design teams. regards Robert -- Robert Guerra Phone: +1 416-893-0377 Twitter: twitter.com/netfreedom Email: rguerra@privaterra.org PGP Keys : https://keybase.io/rguerra On 2 Mar 2015, at 1:24, Chris Disspain wrote:
Thanks David.
Personally, I’d be delighted if you helped out with this work. Not my decision though.
Cheers,
Chris
On 2 Mar 2015, at 13:49 , David Conrad <david.conrad@icann.org> wrote:
Chris,
On Mar 1, 2015, at 6:45 PM, Chris Disspain <ceo@auda.org.au> wrote:
How would you recommend that those changes that must occur are dealt with?
First, the potential areas of change need to be identified. There are three obvious ones:
1) NTIA's "Root Zone Administrator" role: authorizing changes to the root before they are made: a) Changes to the root zone registration database data (i.e., "Whois"); and b) Proposed changes submitted to the Root Zone Maintainer (Verisign) for implementation.
2) NTIA's role in vetting/approving/gating systemic changes (e.g., approving the DNSSEC-signing of the root zone).
3) NTIA's role in specifying/accepting reporting of actions taken by IANA.
There may be others -- my knowledge of IANA is dated and it is possible there are other actions now being performed by NTIA that need to be addressed in the post-NTIA world.
Once the areas of change are identified, specific decisions need to be made by the community about how best the IANA Function Operator will be able to move forward without NTIA. For example (following the three I mention above):
1) The Root Zone Administrator role could go away, could be replaced by a single entity, or could be dealt with some other way. Given NTIA has never rejected a change request, I'd argue the role should simply go away, but I may be seen as biased on the topic.
2) Some mechanism will need to be defined by which the IANA Function Operator can be authorized to make systemic changes. There are a myriad possible ways in which this can be done, but my recommendation would be something that would focus on an efficient/timely way to ensure both technical correctness and abiding by the "do no harm" principle.
3) Similarly, some mechanism needs to be defined in which the information that needs to be provided to the community can be identified and presented in a useful way. Every piece of data that is collected and presented has a cost, either in money, time, or resources, so care must be taken to not over-burden IANA staff with information requests or folks should be prepared for increases in costs and/or delays. My recommendation would be to review the information NTIA currently demands and throw out the stuff no one cares about and not add anything new unless it can be shown to have direct benefit to the IANA Function Operator's accountability.
I am happy to volunteer to participate in a design team on this topic, however since I am ICANN staff, I'm unsure whether my participation would be permitted.
Regards, -drc
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
I am happy to volunteer to participate in a design team on this topic, however since I am ICANN staff, I'm unsure whether my participation would be permitted.
I for one would hope that we treat any suitably qualified people who volunteer in an area equally regardless of who their employer is, considering the work output of a DT comes back to the CWG as a whole I don't see any overt conflict of interest. ICANN staff are stakeholders here too. -----Original Message----- From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of David Conrad Sent: Monday, March 02, 2015 2:50 AM To: ceo@auda.org.au Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Service Level Expectations Design Team Template Chris, On Mar 1, 2015, at 6:45 PM, Chris Disspain <ceo@auda.org.au> wrote:
How would you recommend that those changes that must occur are dealt with?
First, the potential areas of change need to be identified. There are three obvious ones: 1) NTIA's "Root Zone Administrator" role: authorizing changes to the root before they are made: a) Changes to the root zone registration database data (i.e., "Whois"); and b) Proposed changes submitted to the Root Zone Maintainer (Verisign) for implementation. 2) NTIA's role in vetting/approving/gating systemic changes (e.g., approving the DNSSEC-signing of the root zone). 3) NTIA's role in specifying/accepting reporting of actions taken by IANA. There may be others -- my knowledge of IANA is dated and it is possible there are other actions now being performed by NTIA that need to be addressed in the post-NTIA world. Once the areas of change are identified, specific decisions need to be made by the community about how best the IANA Function Operator will be able to move forward without NTIA. For example (following the three I mention above): 1) The Root Zone Administrator role could go away, could be replaced by a single entity, or could be dealt with some other way. Given NTIA has never rejected a change request, I'd argue the role should simply go away, but I may be seen as biased on the topic. 2) Some mechanism will need to be defined by which the IANA Function Operator can be authorized to make systemic changes. There are a myriad possible ways in which this can be done, but my recommendation would be something that would focus on an efficient/timely way to ensure both technical correctness and abiding by the "do no harm" principle. 3) Similarly, some mechanism needs to be defined in which the information that needs to be provided to the community can be identified and presented in a useful way. Every piece of data that is collected and presented has a cost, either in money, time, or resources, so care must be taken to not over-burden IANA staff with information requests or folks should be prepared for increases in costs and/or delays. My recommendation would be to review the information NTIA currently demands and throw out the stuff no one cares about and not add anything new unless it can be shown to have direct benefit to the IANA Function Operator's accountability. I am happy to volunteer to participate in a design team on this topic, however since I am ICANN staff, I'm unsure whether my participation would be permitted. Regards, -drc
I would agree with James: this discussion should be informed by the implications on, and operation of, the IANA functions. MB -----Original Message----- From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of James Gannon Sent: 02 March 2015 10:15 To: David Conrad; ceo@auda.org.au Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Service Level Expectations Design Team Template
I am happy to volunteer to participate in a design team on this topic, however since I am ICANN staff, I'm unsure whether my participation would be permitted.
I for one would hope that we treat any suitably qualified people who volunteer in an area equally regardless of who their employer is, considering the work output of a DT comes back to the CWG as a whole I don't see any overt conflict of interest. ICANN staff are stakeholders here too. -----Original Message----- From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of David Conrad Sent: Monday, March 02, 2015 2:50 AM To: ceo@auda.org.au Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Service Level Expectations Design Team Template Chris, On Mar 1, 2015, at 6:45 PM, Chris Disspain <ceo@auda.org.au> wrote:
How would you recommend that those changes that must occur are dealt with?
First, the potential areas of change need to be identified. There are three obvious ones: 1) NTIA's "Root Zone Administrator" role: authorizing changes to the root before they are made: a) Changes to the root zone registration database data (i.e., "Whois"); and b) Proposed changes submitted to the Root Zone Maintainer (Verisign) for implementation. 2) NTIA's role in vetting/approving/gating systemic changes (e.g., approving the DNSSEC-signing of the root zone). 3) NTIA's role in specifying/accepting reporting of actions taken by IANA. There may be others -- my knowledge of IANA is dated and it is possible there are other actions now being performed by NTIA that need to be addressed in the post-NTIA world. Once the areas of change are identified, specific decisions need to be made by the community about how best the IANA Function Operator will be able to move forward without NTIA. For example (following the three I mention above): 1) The Root Zone Administrator role could go away, could be replaced by a single entity, or could be dealt with some other way. Given NTIA has never rejected a change request, I'd argue the role should simply go away, but I may be seen as biased on the topic. 2) Some mechanism will need to be defined by which the IANA Function Operator can be authorized to make systemic changes. There are a myriad possible ways in which this can be done, but my recommendation would be something that would focus on an efficient/timely way to ensure both technical correctness and abiding by the "do no harm" principle. 3) Similarly, some mechanism needs to be defined in which the information that needs to be provided to the community can be identified and presented in a useful way. Every piece of data that is collected and presented has a cost, either in money, time, or resources, so care must be taken to not over-burden IANA staff with information requests or folks should be prepared for increases in costs and/or delays. My recommendation would be to review the information NTIA currently demands and throw out the stuff no one cares about and not add anything new unless it can be shown to have direct benefit to the IANA Function Operator's accountability. I am happy to volunteer to participate in a design team on this topic, however since I am ICANN staff, I'm unsure whether my participation would be permitted. Regards, -drc _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Dear all, We have no objection to David's involvement, it is important to have as much knowledge as possible gathered in the teams (without the team becoming too big). Best, Jonathan and Lise -----Oprindelig meddelelse----- Fra: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] På vegne af David Conrad Sendt: 2. marts 2015 03:50 Til: ceo@auda.org.au Cc: cwg-stewardship@icann.org Emne: Re: [CWG-Stewardship] Service Level Expectations Design Team Template Chris, On Mar 1, 2015, at 6:45 PM, Chris Disspain <ceo@auda.org.au> wrote:
How would you recommend that those changes that must occur are dealt with?
First, the potential areas of change need to be identified. There are three obvious ones: 1) NTIA's "Root Zone Administrator" role: authorizing changes to the root before they are made: a) Changes to the root zone registration database data (i.e., "Whois"); and b) Proposed changes submitted to the Root Zone Maintainer (Verisign) for implementation. 2) NTIA's role in vetting/approving/gating systemic changes (e.g., approving the DNSSEC-signing of the root zone). 3) NTIA's role in specifying/accepting reporting of actions taken by IANA. There may be others -- my knowledge of IANA is dated and it is possible there are other actions now being performed by NTIA that need to be addressed in the post-NTIA world. Once the areas of change are identified, specific decisions need to be made by the community about how best the IANA Function Operator will be able to move forward without NTIA. For example (following the three I mention above): 1) The Root Zone Administrator role could go away, could be replaced by a single entity, or could be dealt with some other way. Given NTIA has never rejected a change request, I'd argue the role should simply go away, but I may be seen as biased on the topic. 2) Some mechanism will need to be defined by which the IANA Function Operator can be authorized to make systemic changes. There are a myriad possible ways in which this can be done, but my recommendation would be something that would focus on an efficient/timely way to ensure both technical correctness and abiding by the "do no harm" principle. 3) Similarly, some mechanism needs to be defined in which the information that needs to be provided to the community can be identified and presented in a useful way. Every piece of data that is collected and presented has a cost, either in money, time, or resources, so care must be taken to not over-burden IANA staff with information requests or folks should be prepared for increases in costs and/or delays. My recommendation would be to review the information NTIA currently demands and throw out the stuff no one cares about and not add anything new unless it can be shown to have direct benefit to the IANA Function Operator's accountability. I am happy to volunteer to participate in a design team on this topic, however since I am ICANN staff, I'm unsure whether my participation would be permitted. Regards, -drc
Dear Colleagues, I fully support direct staff involvement into this DT. May I also suggest, as one non exhaustive input, to request Icann staff to disclose what metrics it relies on ? Icann has been recognized as "committed to excellence" in sept 13 following the EFQM framework (https://www.icann.org/news/blog/iana-technical-operations-department-recogni...). I am quite familiar with this quality framework and I am certain they have a set of existing metrics in terms of service to customers, as well as targets for these metrics. Best Mathieu Le 02/03/2015 12:22, Lise Fuhr a écrit :
Dear all,
We have no objection to David's involvement, it is important to have as much knowledge as possible gathered in the teams (without the team becoming too big).
Best, Jonathan and Lise
-----Oprindelig meddelelse----- Fra: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] På vegne af David Conrad Sendt: 2. marts 2015 03:50 Til: ceo@auda.org.au Cc: cwg-stewardship@icann.org Emne: Re: [CWG-Stewardship] Service Level Expectations Design Team Template
Chris,
On Mar 1, 2015, at 6:45 PM, Chris Disspain <ceo@auda.org.au> wrote:
How would you recommend that those changes that must occur are dealt with? First, the potential areas of change need to be identified. There are three obvious ones:
1) NTIA's "Root Zone Administrator" role: authorizing changes to the root before they are made: a) Changes to the root zone registration database data (i.e., "Whois"); and b) Proposed changes submitted to the Root Zone Maintainer (Verisign) for implementation.
2) NTIA's role in vetting/approving/gating systemic changes (e.g., approving the DNSSEC-signing of the root zone).
3) NTIA's role in specifying/accepting reporting of actions taken by IANA.
There may be others -- my knowledge of IANA is dated and it is possible there are other actions now being performed by NTIA that need to be addressed in the post-NTIA world.
Once the areas of change are identified, specific decisions need to be made by the community about how best the IANA Function Operator will be able to move forward without NTIA. For example (following the three I mention above):
1) The Root Zone Administrator role could go away, could be replaced by a single entity, or could be dealt with some other way. Given NTIA has never rejected a change request, I'd argue the role should simply go away, but I may be seen as biased on the topic.
2) Some mechanism will need to be defined by which the IANA Function Operator can be authorized to make systemic changes. There are a myriad possible ways in which this can be done, but my recommendation would be something that would focus on an efficient/timely way to ensure both technical correctness and abiding by the "do no harm" principle.
3) Similarly, some mechanism needs to be defined in which the information that needs to be provided to the community can be identified and presented in a useful way. Every piece of data that is collected and presented has a cost, either in money, time, or resources, so care must be taken to not over-burden IANA staff with information requests or folks should be prepared for increases in costs and/or delays. My recommendation would be to review the information NTIA currently demands and throw out the stuff no one cares about and not add anything new unless it can be shown to have direct benefit to the IANA Function Operator's accountability.
I am happy to volunteer to participate in a design team on this topic, however since I am ICANN staff, I'm unsure whether my participation would be permitted.
Regards, -drc
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- ***************************** Mathieu WEILL AFNIC - directeur général Tél: +33 1 39 30 83 06 mathieu.weill@afnic.fr Twitter : @mathieuweill *****************************
-----Original Message----- I am happy to volunteer to participate in a design team on this topic, however since I am ICANN staff, I'm unsure whether my participation would be permitted.
Under what rule or principle would it not be permitted? I am not aware of any. Probably best if you are not the DT leader, but participation should be permitted. Like other stakeholders, ICANN has conflicts of interest, or more accurately self-interest concerns, on particular issues or decisions, but so does everyone else (except, of course, for the entirely innocent and pure noncommercial stakeholders group). If you are perceived as straying over the line and advocating for your employer's interest be prepared for people to respond accordingly, but otherwise I think we need and want participation and expertise from people knowledgeable about IANA operations.
It seems fairly clear that changes *necessitated* by the transition (because the NTIA is gone) will need to be made. It would be good to be clear on what those are. David, do you have some examples? Do we need to check in with the IANA staff to clarify what pieces will be missing that must lead to internal changes at IANA? Making necessary changes should not be too controversial, although *what* the change might be could be controversial. But first we need to identify those points where change is inevitable. I agree with Chris that the Design Team should concentrate on determining what needs to change within IANA as a result of this transition, not what could be changed, so long as we are doing this transition thing. Additional changes that are good for everybody should be fairly non-controversial as well, except for workload considerations (which lead to time considerations). Given our time sensitivity, those considerations cannot be easily dismissed. Some type of "cost/benefit" analysis might be helpful here (with "time" and "effort" being the primary costs -- unless there are dollar costs involved as well, which could be an even bigger issue). There may also be additional changes that are viewed positively by the direct customers but not so positively by other stakeholders in the names community. I don't have any examples off the top of my head, but if they do occur, they should be parked until after the transition. If there's a feeling that additional changes (beyond those necessitated by the facts of the transition) need to be made now because stakeholders have "leverage," or its the "one bite at the apple," then that is troubling for a bigger reason. That means that some believe we will not achieve a goal of long-term accountability by the managers of the IANA function to the names community in general, and the direct customers specifically. (Alternatively, it means people are pushing stuff through now that would never be acceptable later, and that's even more troubling.) I agree with Andrew that it is much important (and much more in scope) to design a system where evolutionary change in IANA operations can reasonably be expected to occur, and where stakeholder concerns will reasonably be able to drive change, than it is to effect a non-transition-essential change just because the time seems ripe. I am not as inalterably opposed to considering some such changes as Andrew appears to be, but I am highly prejudiced against them because of their ability to slow us down and throw us off course. Greg On Sun, Mar 1, 2015 at 6:00 PM, David Conrad <david.conrad@icann.org> wrote:
Alan,
I do have a problem with requirement which would force internal changes within IANA at the same time as the transition is going on. That violates the rule of making as few changes as possible in parallel.
Apologies for being repetitive, but just to be sure, one more time with emphasis:
Internal changes at IANA _must_ occur with the transition because NTIA is integrated into IANA operations.
The process and possibly the code by which root zone updates are made _must_ change. This _may_ impact the SLEs as specified in C.4.2 of the current IANA Function Contract and hence could impact the outcome of the Design Team.
It may be appropriate to minimize the internal changes required within IANA during the transition, but there already exists a requirement for some change.
Regards, -drc
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- *Gregory S. Shatan **ï* *Abelman Frayne & Schwab* *Partner* *| IP | Technology | Media | Internet* *666 Third Avenue | New York, NY 10017-5621* *Direct* 212-885-9253 *| **Main* 212-949-9022 *Fax* 212-949-9190 *|* *Cell *917-816-6428 *gsshatan@lawabel.com <gsshatan@lawabel.com>* *ICANN-related: gregshatanipc@gmail.com <gregshatanipc@gmail.com>* *www.lawabel.com <http://www.lawabel.com/>*
Greg,
It seems fairly clear that changes necessitated by the transition (because the NTIA is gone) will need to be made. It would be good to be clear on what those are. David, do you have some examples? Do we need to check in with the IANA staff to clarify what pieces will be missing that must lead to internal changes at IANA?
See my response to Chris. I would strongly recommend checking with IANA staff.
I agree with Chris that the Design Team should concentrate on determining what needs to change within IANA as a result of this transition, not what could be changed, so long as we are doing this transition thing.
Just to be clear, my understanding was that the Design Team proposed by Paul Kane was going to focus on service level expectations of existing services, not identifying what needs to be done operationally to transition to a post-NTIA world.
If there's a feeling that additional changes (beyond those necessitated by the facts of the transition) need to be made now because stakeholders have "leverage," or its the "one bite at the apple," then that is troubling for a bigger reason.
Yes. Regards, -drc
David Conrad writes:
<SNIP>
Just to be clear, my understanding was that the Design Team proposed by Paul Kane was going to focus on service level expectations of existing services, not identifying what needs to be done operationally to transition to a post-NTIA world.
That has been my understanding as well. During that stock taking, there might ne identification of things needed to be changed because NTIA falls out the (operational) loop. Observation: I see about 20 messages speculating about a possible undesirable outcome. Discussiong the outcome while the DT hasn't been formed nor started seems premature to me. In the end this group can always throw away the proposals whether it is from an "official" DT or not. jaap
Greg, On Mar 1, 2015, at 6:58 PM, Greg Shatan <gregshatanipc@gmail.com> wrote:
It seems fairly clear that changes necessitated by the transition (because the NTIA is gone) will need to be made. It would be good to be clear on what those are. David, do you have some examples? Do we need to check in with the IANA staff to clarify what pieces will be missing that must lead to internal changes at IANA?
I'm sure some number of us could provide examples, but discussing with IANA staff and customers is the clearest and most reliable path to getting all of the details right. The example David already offered, of processes and software already deployed with the assumption that the NTIA change authorization step is critical to root zone changes, is probably the most prominent.
Making necessary changes should not be too controversial, although what the change might be could be controversial. But first we need to identify those points where change is inevitable.
I agree with Chris that the Design Team should concentrate on determining what needs to change within IANA as a result of this transition, not what could be changed, so long as we are doing this transition thing.
Yes.
Additional changes that are good for everybody should be fairly non-controversial as well, except for workload considerations (which lead to time considerations). Given our time sensitivity, those considerations cannot be easily dismissed. Some type of "cost/benefit" analysis might be helpful here (with "time" and "effort" being the primary costs -- unless there are dollar costs involved as well, which could be an even bigger issue).
I believe David, Chris, Andrew, etc. are arguing against exactly this, and I have to say I agree with them. We need to make sure that there is provision in IANA's processes during and after the transition such that "changes that are good for everybody" *can* be made. It does seem unwise, however, to add potential changes that might not be specifically necessary to the workload of an effort that's already behind schedule and having difficulty focusing. Changes that we *must* have are relatively easily identified, and we know what success looks like-- we're no worse off in terms of security, stability, resilience, etc. Changes that are "good for everybody" will be much harder to identify or design, and it will be much harder to tell when we're done.
There may also be additional changes that are viewed positively by the direct customers but not so positively by other stakeholders in the names community. I don't have any examples off the top of my head, but if they do occur, they should be parked until after the transition.
+1
If there's a feeling that additional changes (beyond those necessitated by the facts of the transition) need to be made now because stakeholders have "leverage," or its the "one bite at the apple," then that is troubling for a bigger reason. That means that some believe we will not achieve a goal of long-term accountability by the managers of the IANA function to the names community in general, and the direct customers specifically.
+lots, and it seems to me that these are exactly the concerns that belong in the CCWG-Accountability. I would suggest we're concerned here with making sure IANA carries out its instructions quickly and accurately. Making sure its instructions are proper-- that some failure of oversight of or by ICANN doesn't interfere with IANA getting proper instructions from customers, or executing them-- seems closer to the CCWG's remit. As a concrete example: Currently, IANA has some fairly extensive processes for determining who is authorized to request changes to the root zone, and what changes they're allowed to request. IANA staff being told to make a change outside of those processes by anyone, even a customer, should always result in a refusal of the request, and IANA staff must be held accountable for any other result. ICANN as the operator is responsible for preventing such things (and there are extensive processes for reducing the risk already in place). As far as I'm aware, this is the part of the operation that "just works" today, and needs to continue to "just work" even after the changes that will be forced by NTIA stepping aside. However, if ICANN as the root zone management operator decides, as a result of capture of the oversight of IANA by governments or anyone else, to alter IANA processes so that, for example, someone besides the TLD manager is allowed to make changes to TLD root zone data, this is a problem with ICANN accountability. In the first kind of failure, disciplining the responsible staff and fixing the process seems like the right remedy. In the second case, disciplining the staff is pointless and even moving the responsibility for carrying out those orders somewhere else seems secondary to the problem that they were given at all. I'm happy to contribute to this part of the work if that's acceptable. I'll also be asking if other RSSAC members would like to volunteer, as many have experience with multiple aspects of IANA operations. (Renewing the disclaimer: personal opinions only.) best, Suzanne
Greg
On Sun, Mar 1, 2015 at 6:00 PM, David Conrad <david.conrad@icann.org> wrote: Alan,
I do have a problem with requirement which would force internal changes within IANA at the same time as the transition is going on. That violates the rule of making as few changes as possible in parallel.
Apologies for being repetitive, but just to be sure, one more time with emphasis:
Internal changes at IANA _must_ occur with the transition because NTIA is integrated into IANA operations.
The process and possibly the code by which root zone updates are made _must_ change. This _may_ impact the SLEs as specified in C.4.2 of the current IANA Function Contract and hence could impact the outcome of the Design Team.
It may be appropriate to minimize the internal changes required within IANA during the transition, but there already exists a requirement for some change.
Regards, -drc
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- Gregory S. Shatan ï Abelman Frayne & Schwab Partner | IP | Technology | Media | Internet 666 Third Avenue | New York, NY 10017-5621 Direct 212-885-9253 | Main 212-949-9022 Fax 212-949-9190 | Cell 917-816-6428 gsshatan@lawabel.com ICANN-related: gregshatanipc@gmail.com www.lawabel.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
participants (12)
-
Alan Greenberg -
Chris Disspain -
David Conrad -
Greg Shatan -
Jaap Akkerhuis -
James Gannon -
Lise Fuhr -
Martin Boyle -
Mathieu Weill -
Milton L Mueller -
Robert Guerra -
Suzanne Woolf