[discuss] discuss Digest, Vol 4, Issue 145

Sat Mar 22 05:34:19 UTC 2014

On Mar 22, 2014, at 10:13 AM, Alejandro Pisanty <apisanty at gmail.com> wrote:

> Keith,
> 
> yep, things get even more interesting with nuance.
> 
> Conditioning funding to IANA cost is another of those paradoxes: those who complain that IANA should be mostly about stewardship and trust create a pay-per-service model. Luckily ICANN didn't bite that piece of bait. 

Alejandro - 

  The IANA functions are technical tasks that need to be performed in accordance with 
  respective community-developed policy.   If there is a reason that such services cannot
  be provided on a cost-recovery basis, I am not aware of it, and would welcome being 
  educated on same.

  There are other aspects of ICANN (e.g. its overall organizational structure and global 
  "coordination and accountability" role with respect to the Internet identifier system)
  which likely must be considered a necessary embedded cost to be shared among all 
  of the participating organizations in the system, and probably cannot be reasonably 
  allocated.

  Note that all of the above costs were to be borne by the Supporting Organizations in 
  the original ICANN model; ICANN having a direct relationship (contractual/financial)
  with each and every DNS registry & registrar was actually an interesting "innovation" 
  on the model which has come to dominant to entire organization structure and budget.

At present, ICANN handles many tasks:

  1) Overall coordination of Internet identifier system
  2) DNS root zone registry operations 
  3) Internet Protocol central registry operations
  4) Protocol parameter registries operations
  5) DNS Policy Development
  6) DNS Policy Implementation and Administration

Some of these have the IETF as the direct customer, some have the RIRs as the 
direct customer, some have the DNS Registries/Registrars as the direct customer, 
and one has the entire Internet as its identified beneficiary.

That's quite a few tasks in one organization, with very different customers and very
different cost drivers.

> So this resonates with the principles of Reciprocity and Simplicity put forward by the Strategy Panel on ICANN's Role in the Internet Governance Ecosystem. What do you know, no surprise there, right?

Indeed, on Simplicity -

'Yet, ICANN should not be satisfied with the complexity and ICANN should constantly and proactively iterate, validate, simplify its own processesparticularly as a mechanism to encourage the participation of others that aren’t within the ecosystem. Nothing should be considered to be sacrosanct, and the organization should seek to iterate and validate its own evolution. As the system becomes more complex, the organization should constantly seek simpler solutions so long as they comply with all other principles.'

and Loose-Coupling - 

'The term “loose coupling” means that interactions among the components of the Internet governance ecosystem are based on knowledge of relevant information stemming from different components as well as foresight for their impact, but not in a strictly mandated coordination except when and where indispensable. By loosely coupling the relationships, robustness is more likely because the actors are not bound by any artificial constraints. Loose coupling embraces complexity and provides better tools for response to complexity and for adaptation to changes than a topheavy, inflexible and strictly mandated construct.'

Would the above principles argue that, given all of ICANN diverse roles, it should 
strategically examine its tasks and customers to see if its structures are as simple
as possible, and further aim to leverage loose-coupling where possible to aid that
evolution?

> I agree that designs of a future ICANN - or the more-constrained issue of substitution of the NTIA's functions - should protect against parties going rogue. "Follow the money" and "look who has some turf to defend" would be good guidelines to spot the riskiest ones. These are good design constraints because they induce a careful, rational risk analysis. Other variables in the Panel's report respond to this as well. 

Agreed.
/John

Disclaimer:  My views alone.