RE: [mpowr] Mailing List Management

Hi John,

> And I repeat, the IESG has ignored or modified, without notice
> to the community, far more specific rules. 

Yes, I understand that the IESG has developed several procedures
that have severely bent, if not actually broken, the existing
rules.  I pointed this out rather frequently before I was 
appointed to the IESG, and (because I was not subjected to a
brain transplant when I joined the IESG) I continue to believe
that it is true.  I also think that the steady accumulation of 
process hurdles and IESG control points has been damaging to 
the IETF.

> If the AD wants to
> delegate that authority, while retaining responsibility, the
> spirit of the rules is certainly met.   I agree that, if this is
> tried more often and seems to work, it would be good to
> eventually fix 2418.

If RFC 2418 said that approval of the responsible AD was needed,
then I would feel comfortable granting a blanket approval to my 
WG chairs.  However, it says that IESG approval is needed.
Perhaps we should discuss this at an IESG meeting and see if
the IESG is willing to grant such a blanket approval for a
period of experimentation (say 3-to-6 months) after which, if
things have worked well, we could update RFC 2418.  Would that
make sense to you?

I don't think that it makes sense for the IESG to grant a 
permanent blanket approval, because I don't think it is
a good thing when our actual procedures differ substantially
from our document ones.  And, yes, I do know that there
are several other ways in which they already do. 

> But the IESG can't have it both ways: either it is within your
> authority (and I do mean "authority" here) to authorize
> arrangements like the one I outlined, or you need to recind,
> immediately, a long series of violations and changes to very
> explicit rules that the IESG has made for its convenience or in
> order to increase its involvement in various decisions.  There
> is only one significant distinction between what I've proposed
> and the dozens of "more control, and more work, for the IESG"
> policy/ procedural decisions made over the last several years:
> this suggestion involves the IESG less in a decision, while
> every other case I can recall increases IESG involvement and
> workload.

Personally, I think that there is a big difference between 
these two things...

I think that it is fine and healthy for the IESG to delegate the 
authority that the IESG has been granted by the community (with 
the IESG retaining accountability for the results), but I think 
it is unhealthy and damaging for the IESG to assume authority that 
hasn't been granted to the IESG by the community.

However, there are a lot of shades of gray here... You and I
may not agree about which IESG rules and procedures violate 
the BCPs, and I am certain that there is no clear agreement
about that amongst IESG members or the IETF at large.

I also don't think that we should make rapid, sweeping changes 
to processes that have grown up over many years.  I think that
we need, as a community, to decide what changes we think are
needed and determine a prudent and careful plan to make them
over time.

I know that you have your personal pet peeves about our
current process, and I have mine.  For example, I still 
think that the default action should be approval of WG 
documents, and that it should take consensus (or at least
a majority) of the IESG to block a document.  But, I am 
not sure that view is in the majority in any segment of 
the IETF, and I certainly don't think that we have consensus 
that such a change would be beneficial.

Margaret

_______________________________________________
mpowr mailing list
mpowr@ietf.org
https://www1.ietf.org/mailman/listinfo/mpowr