On Mon, Jan 6, 2014 at 3:51 PM, John Curran <jcurran(_at_)istaff(_dot_)org>
wrote:
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?
No, I am very aware of the public policy dimension in my protocol work. I
am in the security area, I remember the cryptowars.
The question that should be asked is why the IETF gets targeted in the way
W3C and OASIS do not. I think that the confusion of the IETF role in all
things ICANN is the main reason.
W3C and OASIS also do crypto work and the security area is actually rather
more likely than others to 'go walkabout'. There is no point in a
government trying to capture our standards forum because we can always
create another.
The much bigger problem has been the effect of governments trying to
promote security protocols inside IETF that are designed to meet government
security needs at the expense of the general good. I really don't care if
fixing OCSP would require the DoD to upgrade the certificate server they
use despite the fact that the supplier went out of business a decade ago.
As an industry we already get together and rewrite specifications that we
think are nonsense. PKIX says that name constraints MUST be marked
critical, the industry consensus and running code says that they are not.
--
Website: http://hallambaker.com/