ietf
[Top] [All Lists]

Re: Split the IANA functions?

2014-01-06 14:51:37
On Jan 6, 2014, at 2:58 PM, Phillip Hallam-Baker <hallam(_at_)gmail(_dot_)com> 
wrote:

I am not suggesting changing the operation of the registry or taking it away 
from ICANN which is what I would see as 'blowing the bolts'.

I am suggesting painting a new sign for the protocol side of the functions.

The closest analogy I have is that in Vermont during hunting season it is 
very common to find a cow with 'COW' painted on the side in big white 
letters. The reason for this is that there is a particular type of 'hunter' 
who comes up from the city once a year with his mates, a large quantity of 
beer and an injudicious quantity of firearms and ammunition. They are liable 
shoot anything that moves. Labeling the livestock is the best way to mitigate 
the losses.
...

It is admirable goal, i.e. setup things so that the IETF is truly doing just 
technical coordination, 
and thus does not attract any government/policy attention... However, it does 
sort of presume 
that the "protocol development side" stays away from such public policy 
matters, does it not?

Alas, the success of the Internet actually preempts any reasonable chance of 
creating competing 
protocols and approaches that will achieve similar success - basic network 
economies make 
interoperability with (and therefore adoption of) IETF-specified protocols a 
near absolute 
requirement for successful global deployment.  For example, if the IETF decides 
that certain 
protocol should be encrypted by default, then governments have to live with 
that outcome;
 i.e. arguing that there is any meaningful workaround is specious.

What happens when the IETF makes a decision that particular "public policy" 
requirements 
are _to be considered_ (perpass), or specifically _not to be considered_ (RFC 
2804) in protocol
development?   Such is the equivalent of exercising a "control point" (your 
term) on the Internet, 
and one that's entirely with respect to protocol development matters (not names 
or numbers).  
The fact that there is not an "enforcement mechanism" doesn't preclude the 
control point aspects; 
i.e. if there's an IETF consensus (quite appropriately) that pervasive 
surveillance activities are
"a technical attack that should be mitigated in the design of IETF protocols", 
then governments
are impacted by that public policy decision of the IETF. 

The vulnerability is to folk whose knowledge of the IETF and IANA is 
equivalent to the weekend hunter types. It is important to take the issue off 
the table.

See above.  The IETF would also need to truly be neutral (and not imbed publicl 
policy values
into protocol requirements) in order to take the issue off the table.  Trying 
to separate the IANA 
tasks with the theoretical goal of technical purity thus would mean not 
advancing some fairly
important social values, and these already put the IETF into the cross-hairs 
due to the control
aspects.

/John

Disclaimer: My views alone.


<Prev in Thread] Current Thread [Next in Thread>