[CWG-Stewardship] Service Level Expectations Design Team Template

[Suzanne Woolf]

Greg,


On Mar 1, 2015, at 6:58 PM, Greg Shatan <gregshatanipc at 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 at 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 at 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 at lawabel.com
> ICANN-related: gregshatanipc at gmail.com
> www.lawabel.com
> _______________________________________________
> CWG-Stewardship mailing list
> CWG-Stewardship at icann.org
> https://mm.icann.org/mailman/listinfo/cwg-stewardship

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150302/5497fbab/attachment-0001.html>