> WRITTEN IN MY ROLE AS FORMER IMPP CHAIR
harold - as indicated in my previous note, here is a reply!
although i'm the only address listed on the "From:" line, that's a
limitation of the mail client i'm using. please consider this a note
from Marshall and Dave.
so, we'll start at the end of your reply, because that's more direct.
> My conclusions:
>
> The working group has suffered from very slow document updates, a bad error
> in judgment (mine) re charter update, and repeated re-raising of old closed
> issues (for instance, at Atlanta in November 2002, Dave Crocker could be
> heard re-raising the issue of the need for loop control, which the group
> had discussed and decided in December 2000, choosing hopcount as the
> preferred mechanism in March 2001).
>
> However, I find the criticisms raised against the process leading to the
> forwarding of these documents to the IESG to be very much off target.
we confess that we're a bit disappointed with your response. we spent
considerable effort laying out a detailed complaint, and even included a
table of contents, viz.,
> > 1. PROCESS FAILURES
> > 1.1. Lack of participation and constituency
> > 1.2. Out of scope with charter
> > 1.3. Failure to resolve issues raised in the working group
> >
> > 2. TECHNICAL FAILURES
> > 2.1. Confused and conflicting goals
> > 2.2. Incomplete and unclear specifications.
but you addressed the least interesting of these.
perhaps issue 2.2 can be handled by applying some engineering and
editing. yet they weren't, when they were raised in the working group.
as things stand, the document is simply not viable on its own.
the other issue you addressed is issue 1.3, while we might quibble with
your timeline, we think you're missing the big picture, which is bleak.
the work has no serious constituency. it cannot perform the task it
describes for itself, as a gateway between heterogeneous services. few
people created the work. few are interested in using it.
in other words, issues 1.1, 1.2, and 2.1 are fatal. they're also
essentially un-arguable. (or rather, no one's popped up to argue with us
over them and it's been a month, eh?)
issue 2.1 tells us that the documents are going to be a failure in
theory, and issue 1.1 tells us that the documents are going to be a
failure in practice.
finally, issue 1.2 tell us that we're not even following our own rules.
charters matter. otherwise, why have them? sanctity of the charter is
perhaps the single most "sacred" aspect of the way we do things.
we confess, if the work were "good", we could look the other way on the
process problems. but, let's face it, no one is arguing that we're
talking about a quality work product here. in fact, no one is even
arguing that the work product is going to see any meaningful use in
production.
for the life of us, we can't figure out why anyone would want to defend
this work...
/mtr
ps: secondary to the fatal problems with the specification, your note
cited other process issues. you claim that a working group meeting was
not held due to failures of the document's editor to revise the document
between february and november, 2001. presumably you mean the cpim main
document, rather than the msgfmt, pidf or datetime documents that were
revised during that time. fortunately, your former co-chair's
"(Un)updated todos" note of 14 oct and the cpim document editor's note
of 29 oct make clear that the real reasons for not holding a meeting,
which has nothing to do with the editor...