Last call results - process document

[Spencer Dawkins]

I know I've slept since Minneapolis, but I thought the sense of the
room in Minneapolis was that the process document was running behind
the response to the problem statement document, and that we were
basically punting on trying to come up with a process in this working
group - what we were publishing was the freeze-dried state of the
process discussion, prior to punting.

If I thought the IESG, or the rest of the IETF, was sitting waiting
for the process document so they would know what to do next, heck yes
we should be trying to get it right. They aren't. We're starting
mailing lists to chew on these problems at the rate of two a day (for
one sample this past week).

I think the choices are to publish the document as Informational or to
junk it.

Spencer

----- Original Message ----- 
From: "Melinda Shore" <mshore at cisco.com>
To: "Alex Conta" <aconta at txc.com>
Cc: <problem-statement at alvestrand.no>
Sent: Friday, December 12, 2003 11:04 AM
Subject: Re: Last call results - process document


> On Friday, December 12, 2003, at 11:48 AM, Alex Conta wrote:
> > As a reminder, a document like this, supposed to help address
problems
> > is not to be exclusive, or selective in problems that it lists,
since
> > the very purpose of it was to gather and document ALL the
problems, as
> > they were perceived in IETF.
>
> First, this working group was chartered to produce two documents,
one
> describing the IETF's problems and the second making recommendations
for
> a process or set of processes to address the problems identified in
the
> first document.  The document that just completed WG last call is
the
> second document.  It documents *no* problems.  Although it does
> reference
> problems identified in the first document, the problems described in
it
> must not be considered "normative" - that's not its function.
>
> Second, it was agreed at the outset that given the nature of what
> we were trying to do we could neither expect consensus on everything
> in the problem description document nor could we expect it to be
> comprehensive.  We are asking, however, whether or not we can
operate
> in the spirit of consensus in getting these documents through last
call.
> That means distinguishing between things that we might not like but
we
> can live with on the one hand and things that we think are so
profoundly
> flawed that they do need to be fixed on the other.
>
> Thanks,
>
> Melinda
>