"trouble maker"

[Hallam-Baker, Phillip]

> > Pointing out that the spec was broken resulted in numerous 
> atempts to
> > intimidate me by 'reporting me to my management' as a 
> 'trouble maker'. Like
> > get a clue, who do you think had asked me to push for the 
> protocol changes
> > in the first place?
> [...]
> 
> I think the last sentence is interesting and troubling, at 
> the same time.

Why don't you get disturbed by the sentence that proceeded it?

If it is fair game to attempt to attack people by reporting them to
management then why not regard the ADs as fair game in the same way?


> One doesn't interest the interests of the employer/management 
> in the IETF.

My employer wants to deploy DNSSEC and other protocols. That is why they
paid the airfare and hotel bill for me to attend. Same for every other
person who attends on their employer's expenses.

In this case there was a serious issue that affected my employer. We want to
deploy DNSSEC. The specs as written are unnecessarily expensive to deploy,
this unnecessary expense can be removed with a small protocol change that it
is agreed that the group reached consensus on.

What you are trying to say here is that there SHOULD be NO WAY for a company
that happens to be affected by a protocol issue in a serious way to be able
to raise it in the process.

What this comes down to is trying to level the playing field so only the
establishment get to speak from authority. 

In the real world I don't need the support of the IETF, I need the support
of companies such as Microsoft, IBM, CISCO, Sun, etc. Getting a standards
body endorsement is a means to an end. I have no interest in excluding other
parties, there is always a place for ideas and particularly requirements.
The paranoia that seems to seize the IETF that the big companies might
realize their strength and exclude the small guy. So to prevent this the top
down establishment was created to enforce control and the myth of creative
anarchy was created to prevent people noticing.


So lets drop DNS for a moment, lets consider the failure to secure BGP. This
is going to become a major issue soon, spam senders have been hijacking
unused IP blocks for years, there will soon be incentives for them to hijack
unused blocks.

A not unreasonable issue for the ISP/backbone providers is how to deploy any
solution using legacy infrastructure. It should be fairly clear that
expecting them to upgrade every router to run BGP over IPSEC is going to
have limited take up. This is even more so when you consider how much
security you get from link layer security in that application.

The way I would approach this problem is to get a bunch of the major
ISP/backbone providers together into a room with the IP address issuers and
a bunch of security consultants. I would then run through the same security
requirements analysis process that I would work through with any other
client.

The IETF route seems to have been open the architecture document and try to
slam IPSEC onto them. Thump! Here comes the answer from on high.


		Phill