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

[john.loughney at nokia.com]

Hi Harald.

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

Reformating is fine with me. As a meta-comment - I have been growing a little
more frustrated by this mailing list. I'm wondering if it is more useful
to spend my time getting real work done instead, but anyhow, responses in line:

> 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)

Rewriting the above, in terms of what I was thinking, I get:

problem: RFC 2026 has some ambiguity.
problem: RFC 2026 is not always followed, and it's not when it is not followed
		(possibly pointing to more training needed by WG chairs, IESG, etc.)
problem: The areas of ambiguity in RFC 2026 are sometimes interpreted differently,
		creating confusion.

As evidence, I point to the "Last Call: IP over MIME to Proposed Standard" thread.
It seems that people don't like it, but are raising 'boogey-man' fears.  It is
much easier & better (IMO) to simply say, it violates section A of RFC xyz.

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

Actually, I don't worry about this problem. I generally work recursively.  I think
no matter what, the core mission of the IETF has changed in the last 10 years and
probably will continue changing.  If we document how the IETF SHOULD (in a 2119 
sense of the word) work, that's a good thing.  When there are corner cases not 
covered, then we update our docs.

> > - 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

Probably both, but maybe a third:

Problem: Design team membership; document editorship selection is not
		always 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?

I think you captured it well.

> >  If we had all of these, we probably would
> > be about 80% done (in my opinion).
> 
> Maybe.... or we might have an easier time figuring out what 
> the rest of the problem is....

Perhaps ... 

John