RE: [mpowr] Mailing List Management

[John C Klensin <[e-mail]>]

--On Tuesday, 23 December, 2003 19:18 -0500 
[e-mail] wrote:

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

Yes, we agree.

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

Yes.

More generally, this is an aspect of a point I've been trying to 
make, although obviously not successfully, and perhaps not 
clearly enough.  There are a number of proposals for change 
floating around for which we have good theorizing, but no 
operational experience and no good way to predict the absence 
(or nature) of unexpected and unintended consequences.   So, if 
we can possibly figure out a way to do so, I'd like to see us 
try them with a minimum of fuss and without trying to formally 
change the procedures and get all of the little details right by 
using a mixture of speculation and nit-picking.   Once we find 
something that works, and preferably have gone through a round 
or two of tuning as needed, that is the right time to reflect 
that knowledge and experience, to the extent really needed, in 
formal procedures.

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

And I challenge the IESG to either move ahead with some of these 
"experiments" or, if it concludes that would be unwise given a 
careful reading of the written procedures, to eliminate every 
instance in which it has adopted procedures or practices at 
variance with the documented procedures.

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

Ah.  So the IESG won't do the things that I --and others-- have 
suggested and which you consider relatively benign, but feels 
free to do the things that you consider "unhealthy and 
damaging"?  Ok, I agree with your conclusion.  Are you going to 
tell us who needs recalling? :-(

> 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'd be happy to supply a short list of candidate items if you 
and others think that would be helpful.   I don't believe that I 
can generate a comprehensive list, but incremental progress 
would be very helpful here, IMO.

> 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 would suggest, in line with your "unhealthy and damaging" 
analysis above, that the IESG has made far more radical and 
sweeping changes in the last several years, on its own 
initiative and without any attempt at explicit community 
approval, than anything that has been seriously proposed here 
(or on the Solutions list, etc.).

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

I agree that guessing about consensus on that one is a tough 
problem.   Let me try out some easy problems, as an introduction 
to the list posited above:

	* If a WG asks for an IETF Last Call on a document, do
	you think that the relevant AD is, or should be,
	authorized to hold it up indefinitely while going
	through a personal review process?  I note that, at the
	time 2026 was written, when a WG asked for a Last Call,
	the Last Call generally went out -- if the AD was not
	familiar with the document, he or she could review it in
	parallel with the rest of the community.  Is this
	progress?
	
	* At the time 2026 was written, the RFC Editor timeout
	for IESG review of an independent submission document
	was two weeks.  If the IESG needed more time, it was
	required to ask for it from the RFC Editor, typically
	specifying a reason.  And the IESG approval mechanism
	was a call for objections with an internal timeout.
	Now, the timeout is four weeks, the IESG apparently
	routinely simply ignores that timeout, and the approval
	process requires a formal vote and writeup.   Is this
	progress?
	
	* At the time 2026 (and 2418) were written, most IANA
	allocations of port and protocol numbers were done at
	IANA's own discretion and initiative, with IANA asking
	questions when needed (and selecting whom to ask).  Now,
	a large fraction of those require either IESG approval,
	or approval of experts appointed by the IESG.  In both
	cases the reviews are apparently done on a "when we get
	around to it" basis, with no timeouts or quality
	control: if some AD doesn't push for something to get
	done, it may take a _very_ long time.  Now, given the
	changed circumstances at IANA, some additional (and more
	formal) review and technical input is certainly
	justified in many of these circumstances.  But I can
	find nothing in 2026 or 2418 that assigns authority to
	IESG to decide how these things should be handled, put
	itself in the loop, etc., without going back to the
	community for authorization.  Do you think the IESG
	actions and assertions of authority in this case are
	appropriate?  Do you think they are healthy for the
	community given that some of the tasks, once created and
	assumed, don't get done in a timely fashion?

I understand that you are not the source of these problems, but 
perhaps the examples above make my point more clear.

     john



_______________________________________________
mpowr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mpowr