Subject: RE: [mpowr] Mailing List Management

From: [email-masked]
Date: Tue, 23 Dec 2003 19:18:45 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpowr

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 23 Dec 2003 20:12:20 -0600

No one asked my opinion, of course, but when I read Margaret's last
paragraph, I did wonder why we don't assume that the working group
will produce useful specifications in a timely fashion, and then
manage by exception for working groups that don't.

If it was the IESG's role to make sure that the bottom twenty percent
of our documents never see the light of day as RFCs, ADs would have
more time to figure out which documents needed to be blocked.

Spencer

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, December 23, 2003 6:18 PM
Subject: RE: [mpowr] Mailing List Management

[deleted down to]

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Dec 2003 00:13:51 -0500

--On Tuesday, 23 December, 2003 19:18 -0500 
[email-masked] wrote:

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

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

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

>> 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.
>
> 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? :-(

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

> needed and determine a prudent and careful plan to make them

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

> 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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 24 Dec 2003 00:29:53 -0800

changing the subject, since this has gone far away from list management...

> 	process requires a formal vote and writeup.   Is this

corrections:

1) as far as I remember, the rfc editor never did anything when the timeout 
expired. not even when it was 2 weeks.
2) the IESG approval mechanism at the moment is "one (shepherding) AD has 
to have read the document and put it on the IESG agenda, no objection must 
be raised when he does".
3) no formal writeup is needed for approval.

the appearance of "ballots" for these items in the tracker recently is 
because it's easier to reuse the mechanism than to be sure we remember who 
had the objection and why, not because we wish to add more formality or 
delay to the process.

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Dec 2003 08:27:10 -0500

--On Wednesday, 24 December, 2003 00:29 -0800 Harald Tveit 
Alvestrand <[email-masked]> wrote:

> 1) as far as I remember, the rfc editor never did anything
> when the timeout expired. not even when it was 2 weeks.

If the RFC Editor is following this list, I'll let them respond. 
But my recollection is that  "never did anything" was the result 
of a clear understanding that the IESG would be very irritated 
if they did so and, perhaps, would even attempt to retaliate.

> 2) the IESG approval mechanism at the moment is "one
> (shepherding) AD has to have read the document and put it on
> the IESG agenda, no objection must be raised when he does".

My apologies for misunderstanding this.  I have been told, by 
different ADs at different times, that the document had not been 
put on the ballot because he or she hadn't gotten around to 
doing a writeup for said ballot and/or that the clearance hadn't 
gone back to the RFC Editor because no one had gotten around to 
writing up the approval note.  Perhaps I misunderstood.

At the same time, it would be far more consistent with the 
letter of 2026 that, if the IESG does not succeed in doing a 
review within some fixed period of time, the RFC Editor takes 
that as acceptance and goes ahead and publishes.   How would 
today's IESG feel about the RFC Editor doing that?

And you will note that I didn't raise the problem of IESG review 
going far beyond the "conflict with existing IETF WG activity" 
and "harm to the Internet" criteria set out in 2026.  This time 
:-(

> the appearance of "ballots" for these items in the tracker
> recently is because it's easier to reuse the mechanism than to
> be sure we remember who had the objection and why, not because
> we wish to add more formality or delay to the process.

Again, I picked up the "ballot" terminology from a couple of 
different ADs, not directly from the categories in the tracker. 
But, again, sorry for any misunderstanding.

I suspect this again illustrates the importance of the IESG's 
being much more clear to the community about the procedures it 
has adopted and is following.

regards,
      john

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 24 Dec 2003 10:55:27 -0800

--On 24. desember 2003 08:27 -0500 John C Klensin <[email-masked]> wrote:

>
>
> --On Wednesday, 24 December, 2003 00:29 -0800 Harald Tveit Alvestrand
> <[email-masked]> wrote:
>
> If the RFC Editor is following this list, I'll let them respond. But my
> recollection is that  "never did anything" was the result of a clear
> understanding that the IESG would be very irritated if they did so and,
> perhaps, would even attempt to retaliate.

I hope we have a more cooperative environment now.....

> My apologies for misunderstanding this.  I have been told, by different
> ADs at different times, that the document had not been put on the ballot
> because he or she hadn't gotten around to doing a writeup for said ballot
> and/or that the clearance hadn't gone back to the RFC Editor because no
> one had gotten around to writing up the approval note.  Perhaps I
> misunderstood.

different things .... "writeup not done" is a problem with standards-track 
documents, not RFC-Editor ones.
The other one - "approval note" - can be a problem. Often, the IESG will 
approve a document but ask for an IESG note to be added. In that case, 
someone has to type up the note. That sometimes causes delay - search for 
documents in state "Approved - Announcement to be sent" with substate 
"Point raised - writeup needed".

> At the same time, it would be far more consistent with the letter of 2026
> that, if the IESG does not succeed in doing a review within some fixed
> period of time, the RFC Editor takes that as acceptance and goes ahead
> and publishes.   How would today's IESG feel about the RFC Editor doing
> that?
>
> And you will note that I didn't raise the problem of IESG review going
> far beyond the "conflict with existing IETF WG activity" and "harm to the
> Internet" criteria set out in 2026.  This time :-(
>
> Again, I picked up the "ballot" terminology from a couple of different
> ADs, not directly from the categories in the tracker. But, again, sorry
> for any misunderstanding.

In fact we just added use of "ballots"  for Informational documents in 
general, as an administrative tool, not because we want to raise the bar. 
So you WILL hear the terminology.
>
> I suspect this again illustrates the importance of the IESG's being much
> more clear to the community about the procedures it has adopted and is
> following.

It does.
And being clear to the community requires writing down the procedures, 
which most often means making them more rigid and harder to change.
Nothing's perfect....

---

From: Allison Mankin <[email-masked]>
Date: Wed, 24 Dec 2003 14:23:55 -0800

John,

Harald looked at your RFC Editor question, but there's still your 
other two.

First I'd like to say something about the overall point -  there 
are degrees here: one person's bending the process even severely,
as Margaret says, or warping it through seizing authority, as John
says, is another person's management of a situation during overload, 
with a lot of process checks in place.  

We're here in these mailing lists looking at the overall set of
problems, as a community, looking at questions of overload,
flow of work, ensuring enough review, differentiating functions... 
let's be careful not to get too tracked onto the power topic.  The
IESG's efforts here to get discussions to take form and see if 
we all can find solutions around WG/AD responsibilities and better 
review structures (the icar mailing list) have everything to do 
with the whole community's ownership and with process.

Taking the first one (I've put the other in separate message):

If the AD holds the document up *indefinitely*, this is a serious
problem, beyond just overload, agreed.  But, sometimes the AD needs to
turn the document back to the WG before Last Call because it has
showstopping cross-area flaws or failure to match the charter.  Documents
would have fewer of these if we had less shortage of early review and
early cross-area review, and if ADs had more cycles to do the early
cross-area review.  This is one problem we're here (or, we're in icar) 
to work on.  RFC 2418 supports rejecting Last Calls with this language:

   a Last-Call is intended as a brief, final check with the
   Internet community, to make sure that no important concerns have been
   missed or misunderstood. The Last-Call should not serve as a more
   general, in-depth review.

The AD is a check and balance for charter/cross-area issues the WG/WG
Chairs may have missed in requesting the Last Call.  The AD's
determination that the document is ready for Last Call need not be a
long review (depending on how hard the WG is to convince, should there
be a showstopping problem).  But you may also be able to see why the 2418 
language can lead to an interpretation of full AD review before approval
of Last Call on some folks' part?  This is why we need to work on the
earlier review problem (looking at big picture).  Personally I consider 
it quite reasonable to have a split: a short AD check that the draft go 
ahead to Last Call or be sent back, and if it goes ahead, any additional
AD review take place during the Last Call period.

Allison

---

From: Allison Mankin <[email-masked]>
Date: Wed, 24 Dec 2003 14:55:37 -0800

In this case, there's a question about what degree of process people
consider enough.  It's true that RFC 2026 doesn't discuss the
relationship with the IANA.  But routinely, assignment processes and
interactions with IANA are written by document editors into BCPs or
standards track RFCs, which get IETF Last Call, after WG review, and
therefore have community authorization to the same extent that any
WG-advanced standard does.  IANA also consents to the IANA contents of
the documents - that this is not formalized is another part of the big
picture functions discussion we are all trying to have, and part of the
procedure point you and Harald exchanged earlier today.  IANA negative
reviews and remedies can be seen in the tracker for specific documents,
but the procedures in use today are not clearly documented.

The use of Expert Review appointments by IESG (when requested by WG
documents) was approved by the community in RFC 2434, BCP 26.  So
again this process was authorized by the IETF.  

Are there a bunch of overload problems in the IANA processing system,
on all sides (IANA too).  Resounding yes.  Many arise in the steps
having to do with the IANA processing for the approved documents,
which is not the issue in your comment, but should resonate for many
document editors.  ADs play hastener on these, rather than roadblock.

The big picture is to take on a structured review of such functions
and their overloads, but saying that the IESG seized IANA-related
functions without community process doesn't present the history, 
because the community has supported the BCPs.

There are questions related to the symptoms of a number of the
functional problems in these points John raised.  There's a structured
discussion here -- a working group discussion?  Perhaps we should get
back to the charter discussion, and perhaps the charter to be
discussed is shaping up differently than first proposed.

My non-vacation Dec 24 is over, happy holiday everyone!

Allison

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Dec 2003 22:42:22 -0800

On Wed, 24 Dec 2003 08:27:10 -0500, John C Klensin wrote:
> > >  =09* At the time 2026 was written, the RFC Editor timeout  
> > >  =09for IESG review of an independent submission document  
> > >  =09was two weeks. 
> >
> >  1) as far as I remember, the rfc editor never did anything  when
> >  the timeout expired. not even when it was 2 weeks.
>
>  If the RFC Editor is following this list, I'll let them respond. But
>  my recollection is that  "never did anything" was the result of a
>  clear understanding that the IESG would be very irritated if they
>  did so and, perhaps, would even attempt to retaliate.

This thread is missing some fairly basic underpinnings that were true 
during the 1989-1993 period that I was an AD, which I generally call the 
start of the "modern" IETF:

1.  The RFC Editor operation was independent of the IETF, although it of 
course had a number of substantial points of coordination.

2. The IESG did not get to do a pocket veto on any documentfor which 
there was no serious claim it impacted existing IETF work or would 
likely have significant, negative impact on Internet operation.

In other words, folks, the RFC Editor engaged in a number of courtesies 
with the IETF, via the IESG, but was entirely free to exercise its own 
judgments about documents that did not originate in the IETF and did not 
seek standards status.

This has changed in recent years, much to the detriment of the open 
publication policy that used to hold true for the RFC series.  Now, it 
appears that the IESG gets a complete veto over any RFC, no matter its 
source or desired status.

d/