I agree with you, IETF should consider policies for designing protocols/technologies for the public user community in all regions with diversity and fareness. If the IETF still does not know how to solve attacks on the internet/design/practice, so why will it allow separting related IANA functions. The first message in the thread suggests the motivation is to protect IETF but what about protecting the Internet users in the world. AB On 1/6/14, John Curran <jcurran@xxxxxxxxxx> wrote: > On Jan 6, 2014, at 2:58 PM, Phillip Hallam-Baker <hallam@xxxxxxxxx> 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. > >