Proposals.

[Hallam-Baker, Phillip]

I have been asked if all I intend to do is complain. I would much prefer to
be discussing solutions, but this is PROBLEM...

Since you ask, I want to see the following changes:


1) Working Group chairs must be accountable to their working groups.

* All vacancies for working group chairs to be advertised three weeks in
advance.
* All appointments of working group chairs to be of limited duration (e.g.
two years) with the possibility of reappointment
* All appointments to be ratified by the working groups concerned.

Here I am also concerned about the propensity of groups to become standing
committees. For example CAT was effectively a standing committee for over
ten years. PKIX is in a similar situation. 

There is something of a problem when a successful group does not close but
just keeps taking on new work. It means that people have to keep attending
the group just to stop people using it as a convenient lever for forcing
implementation of some scheme. I have no objection to the IETF creating an
SCVP protocol that largely duplicates the functionality of XKMS. But I do
think it a problem that it is doing so with the implicit endorsement of the
PKI vendors who have endorsed PKIX protocols in the past - particularly when
they have explicitly declined to endorse.


2) Try to get the IESG out of the loop in approving specs.

* If you really like the NOMCON process that much use it to pick people to
review specs, the same way Slashdot chooses moderators. People sign up to
review one spec choosen at random a month. 
* Change from an IESG approvals process to an objections process. Default
action is it gets out the door.

While a large number of IETF specs reach the IESG in an unsatisfactory state
I don't see that this is the most profitable use of IESG time. If a group
wants to do shoddy work let them. It is a situation that will right itself
soon enough.

The effect I see is similar to that of US politics wrt civil rights. A lot
of voters don't think civil rights are an issue because they can rely on the
supreme court and the constitution to protect them. As a result people get
complacent and when the supreme court makes a real mistake the consequences
are serious.

By the time a spec has been primped to a sufficient level to become an RFC
the implementations are long out of the door. Perhaps vendors will upgrade
later, probably not. The IETF process means that by the time IESG input is
heard it is usually too late.


What I would like to see comming from a body like the IESG is commentary on
requirements that cut across standards. IESG objections should highlight
issues with the spec of the form 'Security - this will create problems for
other protocols' or 'Scalability - this won't work for the Internet on a
global scale'.


3) Employ structured communications processes.

* Abolish the RFC series, in future all documents to be identified by the WG
that originates them.
* Separate requirements and defects processing from the proposed solutions.
* Abolish DRAFT standard status it is confusing and unnecessary.
* Replace the RFC editor process with an XML based document processing
system.

ISOC states that it spends $800,000 running the RFC editorship a year. That
seems an inordinate waste of money for a process that can be readily
automated using commercial tools. 

The RFC process was intended to be completely informal, requests for
comments. It has become a hodge podge of proposals, standards, proprietary
specs pretending to be standards and so on. The documents take an inordinate
amount of time to create considering the primitive typography that they
employ.

Then people started to equate RFC with some sort of standard and all sorts
of barriers get thrown up. Avoid the problem, get rid of the problem of
specious credibility by getting making it clear that this is on autopilot.

Going through the engineering dept I regularly find an engineer who is
writing code from a secondary source rather than try to decipher a poorly
formatted RFC. It appears that this is the norm. The engineers point out
that secondary sources are frequently more reliable guides to achieving
interoperable implementation than the RFC. That in my view is a problem.


I think decoupling the requirements process would have had a positive effect
on the DNSEXT situation. There was no process by which I could force the
following question to be addressed by the IESG - "Should the ability to
efficiently deploy the DNSSEC specification in large zones be a protocol
requirement?"

That is the appeal I want to make but at present there is simply no way I
can get that on the IESG agenda. I believe that the question should have
preceeded the WG attempts to address the problem. 

Instead we spent three years and a considerable amount of engineering
resources answering questions that turned out to be irrelevant and
re-writing a draft that was going to be ignored.


The DRAFT issue may sound minor but nobody outside the IETF can understand
the difference between internet draft and draft standard, particularly since
for some reason draft is more advanced than proposed.

Get rid of the DRAFT step in the standards process and you reduce the IESG
workload in two ways, first review the drafts fewer times, second the groups
can close rather than hanging arround.


		Phill