Subject: RE: NOT "inciting to riot" (was: Last Call: IP over MIME toProposed Standard)

From: <[email-masked]>
Date: Mon, 26 May 2003 07:20:39 +0300

Hi Spencer,

> Yes, precisely - there were two subthreads, one subthread that I would
> expect during Last Call ("you have normative references that aren't
> standards-track") and one that I would have hoped would NOT be
> taking place during Last Call ("this is dumb, not useful, ..."). It was
> not at all clear to me what language we would point to (2026 or otherwise)
> to support a decision not to standardize "IP over MIME", so we're
> left with jawing back and forth to see whether we really standarize it or
> not,

This points to a thought I have had recently.  What we need to do is come
up with clear rules how things progress (and perhaps what is & is not
appropriate for IETF standardization); a simple and straightforward 
way to resolve disputes; transparent leadership selection process and
transparent decision making.  If we had all of these, we probably would
be about 80% done (in my opinion).

John

---

From: Keith Moore <[email-masked]>
Date: Mon, 26 May 2003 00:29:30 -0400

> What we need to do is come

I think it's more like 30%.  The thing that we really need to do most is
to fix how working groups operate.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 26 May 2003 10:31:45 +0200

> Hi Spencer,

John,
trying to recast your "need to do" in terms of "problems"..... apologizing 
for reformatting your mail so much.... am I understanding you correctly?

> up with
> - clear rules how things progress

one or more of:
problem: RFC 2026 is not clear enough to say how things should progress
problem: RFC 2026 is not followed, and it's not clear what is
problem: RFC 2026 does not specify the procedures it should have
(here I think I have to ask you what you think, since the meaning of "clear 
rules" changes according to which alternative(s) you pick)

> - (and perhaps what is & is not appropriate for IETF standardization)

problem: the IETF does not know its core mission. That's on the list :-)

> - a simple and straightforward way to resolve disputes

problem: we don't have (and I agree - consensus is neither simple nor 
straightforward in polarized situations)

> - transparent leadership selection process and

I take it this is one or both of:
problem: the nomcom process is not transparent
problem: the WG selection process (general) is not transparent

> - transparent decision making.

one or both of:
problem: the community does not understand how/why a WG makes decisions
problem: the community does not understand how/why the IESG makes decisions

am I misunderstanding you?

>  If we had all of these, we probably would

Maybe.... or we might have an easier time figuring out what the rest of the 
problem is....

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 26 May 2003 10:38:01 -0700

>to fix how working groups operate.

I would have to agree 100% with this.

I see two major problems with working group operations.

Well, the first, I guess is the mis-conception held by some that
you need a WG to develop a standard track document.  Some of
the most successful standard track documents we have were
developed on an individual basis.  SASL is a good example here
(we're now revising it within a WG, but the original work was
done individually).

The second is the tendency of WG not to thoroughly consider
alternatives offered to them, especially alternatives which are
fundamentally different in design.  This, I think, is due to
WG not addressing discussing fundamentals (what's the problem,
what are possible solutions, what applications do we serve,
what are their requirements, etc.) early on.  We often like to
jump right into solutions.  That's fine if there is implicit
agreement on fundamentals but its bad if there isn't.

Note that I am not a fan of requirement documents... but
I do think it is wise for working groups to have some list
discussions on fundamentals early on.  (Guess that's a third).

Kurt