[CWG-Stewardship] Update on the Integrated model.

[Andrew Sullivan]

Greetings,

On Wed, Feb 18, 2015 at 02:09:28PM -0500, Avri Doria wrote:
> 
> The working draft, which is still a work in progress and remains open
> for comment can be found at:
> https://docs.google.com/document/d/1SvKDEIaeHdre3BQXHNe1K3hCA95dsFWqWAz2Kg5YZCU/edit?usp=sharing
> 

I've read this.  I want to thank the contributors for a serious and
earnest effort.  It's good to be talking about specific text.

> In the draft we present three possible configurations for the model. 
> The authors believe that Shared Service Arrangement (page 6) is the
> preferred configuration, as it offers the most accountability for the
> least amount of change or complexity.

I can see why that might be the authors' preference, but I have pretty
grave doubts that it is an achievable configuration.  In particular,

> It should be noted that this model would require a minimal amount of
> accommodation by the Protocols and Number communities

at least for the protocol parameters community, I disagree pretty
strongly that the accommodation is "minimal".

Right now, the IETF has a simple system: it runs the policy, and it
outsources the entire operation of the registry to ICANN.  The IETF
has to process the service statistics from IANA, and once a year
there's some effort on SLAs, but this is a pretty low-overhead,
outsourced-operator approach.  The model in the document, particularly
in the "shared service arrangement" configuration, requires
significantly more effort on the part of the IETF.  It's a little hard
for me to see why the IETF would go for this: more work for no more
benefit is always harder to sell, and the IETF has been quite clear
that it is happy with the arrangements as they are.  Moreover, the
proposal seems to work from the assumption that the IETF's ability to
leave and go elsewhere is a thing to be "mitigated", but the IETF
appears to like that arrangement.

I wonder, however, whether the model might not be modified slightly to
deliver most of the same benefits, while still not upsetting the
existing arrangements between ICANN and the RIRs or ICANN and the
IETF.  (This really is wondering: in the interests of getting a
reaction out quickly, I haven't allowed this to bake.)

In order to do this, one would start with the ICANN subsidiary
configuration.  But instead of changing the MOU & SLAs from the RIRs
and from the IETF, those just remain with ICANN.  In other words, the
non-names communities see no difference.

ICANN, however, would (sub)contract all IANA functions to the PTI
subsidiary.  Since ICANN would be the only customer, the governance of
PTI could be undertaken by a board appointed by a nomcom rather than
appointed by the three communities.  This might well mitigate some of
the worries about ICANN accountability that are listed as issues with
the "subsidiary" configuration.  It automatically provides a
structural separation because ICANN's policy function remains firmly
inside ICANN, and would put ICANN in the position of having to
negotiate its agreement, SLAs, and so on with PTI.  (Presumably, these
negotiations would be driven by the GNSO and ccNSO, but I think that's
a detail to be worked out if this approach seems promising.)  The IAP,
if needed, would I think be relevant to policy disputes in ICANN but
not necessarily relevant to the PTI (since the latter has a
nomcom-appointed board, and that could function as the appeal
mechanism).

A significant benefit to this approach is that it drastically
minimizes changes.  Indeed, for two of the three affected communities,
the effect is practically nothing.  The names community of course has
more work to do, but it is the community has the most confused current
arrangements, so this only clarifies the arrangements in the case
where they need it.  Because it puts IANA into a different
organization that ICANN, it requires an agreement between the policy
authority (or authorities) for names (within ICANN) and the IANA
operator strictly construed.  Presumably ICANN would also need to
contract with PTI for the SLAs to satisfy ICANN's obligations to the
IETF and RIRs, but I am assuming for these purposes that would be easy
to do.

What do people think of this somewhat more modest approach?

Best regards,

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com