Re: Grievances - Wide

I am not quite as aggrieved as some people appear to be, but
I think there are several procedural issues that we need to
address.  In some cases, even if we don't all agree that the
current procedures are broken, I think we should all agree
that as long as a substantial number of people are unhappy
about the procedures, that in itself is a problem.

Shel lists these issues:
    (a) the big changes to the spec do not seem to mirror the
    conversation on the working group mailing list, or even to follow
    the process described by Roy.

    (b) issues that have been brought up repeatedly in the working
    group are not resolved by the spec.

    (c) by ignoring things like Netscape's cookies, the working group
    stands in danger of simply being bypassed by the market.

Daniel DuBois listed others, including (if I may paraphrase)
    (d) it may be a mistake to introduce a large set of new
    issues in the form of a monolithic I-D for the whole spec.

I would translate these concerns into specific recommendations
("constructive criticism"):

(1) Like it or not, some of us cannot attend IETF or WWW meetings in
person.  The mailing list MUST remain the document of record.  This
means that, while it makes a lot of sense to discuss things in
face-to-face meetings, those "owning" a specific and significant aspect
of the spec are duty-bound to summarize the discussions for the mailing
list in a timely manner.

What's the point of building the global Internet if we don't use it to
get our own work done?

(2) Someone in the "working group management" MUST maintain a list of
unresolved issues, preferrably as Web page so that people can check the
current status.  I'm willing to let the WG chair(s) decide whether an
issue is resolved or not; that's necessary for forward progress as long
as they don't abuse this power.

(3) Major additions and major changes to the spec MUST be discussed
individually.  In some cases, a separate I-D might be the best approach
(we can combine several I-Ds into a complete spec later on).  In other
cases, simply describing the addition/change in a distinct email
message to the mailing list should suffice.

(4) To the extent that the spec involves both principles (such as
caching or anti-byte-deluge, for example) and specific implementations
of these principles, we SHOULD agree on the principles BEFORE
fighting over the specifics.

(5) Proposed additions and changes to the spec MUST be accompanied by a
written rationale, and SHOULD be accompanied by at least an attempt to
analyze the proposal with respect to possible alternatives.  I would
like to see brief summaries of these rationales and analyses included
in the spec itself, since this would aid implementors in understanding
the spec, and would probably avoid some future arguments.

-Jeff

Received on Thursday, 7 December 1995 13:53:07 UTC