Proposals.

[James Seng]

I think there are some pretty good suggestions on the improvement.

It would be even moe useful if you can point out which problem (as 
listed in problem-statement) these solutions aims to solve.

If the problem is missing from the doc, we probably should document it. 
Of course, you have to convience the group that it is indeed broken.

-James Seng

Hallam-Baker, Phillip wrote:
> 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
> 
>