Subject: "trouble maker"

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 24 Jun 2003 11:24:00 -0700

Scott writes

"If the chair hisses when someone stands up to speak that's more than
just being "politically incorrect".  However, that kind of lack of
training in chairs is already covered."

It should not require training for someone to realize that this type of
behavior is unacceptable.

Given that the chair in question is a current member of the IESG it seems
more likely that he would be choosen to give any training that might occur
than attend or take notice of it.

The problem is the lack of effective accountability of the chairs to the
working groups. The IETF pretends to be open but is an entirely top down
organization. There is no accountability of a WG chair to the working group.

Even when a sizable proportion of a WG call for the resignation of a chair
on the list (and I presume like myself confer with the AD) nothing happens,
not even a comment from the AD to the list to state that the concerns have
been noted.

Of course in this particular case the chair was also a member of the IESG so
there was possibly an in built reluctance to challenge a fellow AD, but the
result is no effective recourse and no effective appeal.

The superficial problem could be addressed through a strict requirement that
an AD MUST NOT be a WG chair, even in a different area. But that would not
address the fundamental inconsistency of top down authoritarian control in
an organization trying to be open and inclusive.

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 24 Jun 2003 13:45:57 -0700

Keith,

	At what point do you believe I made the process closed?

When the chair hissed at me the first time I spoke in a DNSEXT meeting?

That is the point at which I formed the opinion the process was closed. 

Perhaps that may have affected my later actions. 

Maybee it was at the second DNSEXT meeting when I pointed out that the
ability to deploy a DNS spec in dotCOM or the other large zones might be
considered an important criteria?

When the OPT-IN proposal was diverted into the 'DNS Directorate' and I
complained that the process was not open?

When the second last call went by with no objections and the chair decided
that the fact I had been SILENT was now to be used against me?

Bascially the whole process was a farce. People kept teling me be quiet,
don't rock the boat. And every single time I took that advice it was
immediately followed by a fresh abuse of process.

What I should have done is to use the appeals process immediately following
the DNS Directorate detour. 

		Phill

> -----Original Message-----
> From: Keith Moore [mailto:[email-masked]]
> Sent: Tuesday, June 24, 2003 4:20 PM
> To: Hallam-Baker, Phillip
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: "trouble maker"
> 
> 
> > At this point making noise about the failure of the IETF is
> > empirically more productive than actually participating in 
> the broken
> > process.
> 
> Phill, you should stop complaining about a lack of openness 
> when you're
> deliberately making the process closed to you.
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 27 Jun 2003 07:51:33 -0700

> > 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