Subject: IONs, RFC 4693, Core Process Documents, and BCPs

From: John C Klensin <[email-masked]>
Date: Fri, 07 Mar 2008 16:07:12 -0500

Hi.

After reading both the "IONs and discuss..." thread and last
month's discussion about the ION Experiment and RFC 4693, I want
to repeat something that at least some of us discussed
extensively during the NEWTRK period (and maybe the POISSON
period before that).  Part of this has been said in the last few
days, but bears repeating in the current context.

Several of us have observed that the IETF is not very good at
writing precise procedural rules.   Some of us would even claim
that history shows that we are fairly poor.  Part of this is a
phenomenon often called "fighting the last war" -- we tend to
see a particular problem occur and then change the rules to deal
with that problem, even if the odds of its recurring are low.
Cumulatively, that results in procedures that have so many
specific cases that no one really understands them.  Worse, we
can never anticipate all future cases that might need special
handling, so we either need to be continually revising any
precise rules or we need to tolerate simply ignoring them when
they seem inappropriate.   None of those situations is good,
especially since cycles spent dealing with procedural issues are
generally cycles that are wasted (and not recoverable) as far as
the real work of the IETF is concerned.

Our best way out of the trap posed by our difficulties with
writing exact procedural documents and our inability to foresee
the future is to give the IESG a lot of discretion but, to use
Ted's language, hold them accountable.    What I think I learned
during the NEWTRK work is that this means, in practice, that...

	* Any update to 2026 or other core documents should
	limit itself to principles, not procedures.  We could
	probably use a better statement of principles about the
	general conditions under which the IESG is expected, or
	permitted, to hold up a document.  Getting down to the
	"what is a DISCUSS and how they are administered" is
	much too far into the procedural area.
	
	* The community should expect that the IESG will figure
	out procedural rules that work for it, that they will
	announce those rules to the community, and that they
	will be receptive to input about them.  
	
	* Whatever those rules are, the IESG may change them at
	its discretion, but should be prepared for input to the
	effect that the ADs must have better things to do with
	their time.   The things the IESG is not permitted to do
	are to change the rules without telling the community or
	to ignore the rules it has set.  To borrow from specific
	POISSON and NEWTRK discussions, games of "Gotcha" based
	on "we know the rules and aren't going to tell you
	enough that you can make predictions" are not a
	legitimate activity.
	
	* While one would hope that the IESG would be receptive
	to informal community input and calibration, choices of
	procedures can be appealed if necessary and exceptional
	demonstrations of bad judgment are legitimate subjects
	for discussion with Nomcoms and/or Recalls.   Similarly,
	once the IESG says "we do things this way" and gets
	community consensus that the procedure is reasonable
	(even if that consensus is interpreted from bored
	silence), doing things in a different way is subject to
	appeal.

	* The community should never tolerate repeated
	demonstrations of bad judgment.  While such things have
	been rare in the history of the IESG, community
	tolerance for it tends to be interpreted as approval and
	often causes things to get worse.

If we can't trust the IESG that much, or can't get people onto
the IESG who are of sufficient caliber that we _can_ trust them
that much.

What is interesting about all of this in the context of recent
discussions is that it makes little difference how the
procedural rules are stated or the medium in which they are
published.  I would expect the IESG and appeals bodies to take a
statement about how the IESG intends to work seriously whether
it is shouted from the rooftops, embedded in an ION, turned into
a BCP, or chiseled in large letters on stone tablets.  If that
is not the case, I think we have worse problems than an ION
versus BCP debate.   Moreover, if the IESG were to go back to
whispering about policy changes, or even shouting them from
rooftops, rather than publishing things in some place
accessible, I would hope that the community would take serious
exception to that approach.

Some of this points out, once again, that BCPs are probably the
wrong mechanism for reaching consensus on and publishing process
documents, regardless of what we do with IONs.

Should we keep IONs and, if so, should we keep them in their
present form or so some tuning?   Frankly, I don't care about
the specifics.  But, if we get rid of them and the price is
either (i) to try to give BCP status to relatively informal
statements about interpretation of principles or (ii) to
encourage the IESG to keep its real procedures secret because
there is no place to put them, I think those would be
significant steps in the wrong direction.

best,
   john

_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 08 Mar 2008 18:13:19 +0100

> significant steps in the wrong direction.
I agree fully with the statements I quote above.

(quibble - I call the BCPs that describe the principles for the process 
"process" documents, so I'd say that BCPs are probably the wrong 
mechanism for reaching consensus on and publishing *procedure* documents 
- and the DISCUSS procedure is a procedure. But I think we're in 
fundamental agreement.)

                 Harald

---

From: John C Klensin <[email-masked]>
Date: Sat, 08 Mar 2008 13:29:56 -0500

--On Saturday, 08 March, 2008 18:13 +0100 Harald Tveit
Alvestrand <[email-masked]> wrote:

> (quibble - I call the BCPs that describe the principles for
> the process "process" documents, so I'd say that BCPs are
> probably the wrong mechanism for reaching consensus on and
> publishing *procedure* documents - and the DISCUSS procedure
> is a procedure. But I think we're in fundamental agreement.)

We may be in slight disagreement because, using your
terminology...

(1) I believe that BCPs are the wrong mechanism for reaching
consensus on and publishing "process" documents.  I think there
has been a clear track record of problems, that we continue to
get snarled with the facts that they are rarely "current
practice" when published and that applying "best" to them is
self-congratulatory and self-serving.  They are simply the
process documents we have chosen to use.   The argument for
using a different document structure --more like standing
documents that may change in an orderly way-- is probably also
stronger (or at least different) for them than for Technical
BCPs or Standards-Track materials.

(2) I believe that BCPs are seriously and strongly the wrong
mechanism for reaching consensus on and publishing "procedure"
documents.  We agree on that, and agree that using BCPs for
procedural documents and issues is even worse than using them
for more formal process principles and definition.

And, incidentally, I can argue that your application of those
words is backwards.  We need some better terminology in this
area, but that is again, a very separate issue from what we do
with IONs (or "process" BCPs).

     john

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 9 Mar 2008 04:39:21 +0100

John C Klensin wrote:
 
> that history shows that we are fairly poor.

You could say roughly the same about the IETF not being as good
as it should at producing valid ABNF, or giving correct examples
in RFCs as soon as this involves to determine say an MD5.  

Sooner or later issues are reported, e.g., as errata, and fixed.
For technical problems because it is the only way to get from PS
to DS and beyond, for procedural problems because somebody cares
to try it.  It can be as simple as s/member/participant/g in a
"procedural" draft I'm interested in.  Correct terminology can
be very important, no matter if it is about "members" or "bounce 
addresses".

> this is a phenomenon often called "fighting the last war"

Yes, and that is not necessarily futile if it boils down to fix
known issues or to document lessons learned.

> specific cases that no one really understands them.

When that happens it is time to replace whatever it is by a KISS
solution.  This is not limited to "procedures", it also affects
technical specifications like say Digest-MD5.   
 
> Any update to 2026 or other core documents should limit itself
> to principles, not procedures.

There are very precise procedures in 2026 like the STD 1 rules.
IMHO it is no waste of time to fix rules that are "obviously"
ignored.  What might be a waste of time is to burden simple
fixes with philosophical principles about DISCUSS or NOMCOM.

Please do not reject simple fixes, please use the same overall
design principles for IONs and "PUFI" as you would use for say
IDNA and SMTP.  

> Getting down to the "what is a DISCUSS and how they are 
> administered" is much too far into the procedural area.

Yes, that is in essence the idea of IONs.  If IONs are judged
to be too much work going back to shaky "procedural BCPs" is
the only reliable solution for "O" participants.

> The things the IESG is not permitted to do are to change the
> rules without telling the community or to ignore the rules it
> has set.

That is also a part of the ION concept:  *Public*, *documented*,
and *binding* rules without the need to track down obscure IAB
pages, IESG minutes, or recent change patrol in a wgchairs wiki.

> exceptional demonstrations of bad judgment are legitimate
> subjects for discussion with Nomcoms and/or Recalls.

NOMCOM and recalls are for "P" participants, and no way to clear
a DISCUSS, or to decide wich parts of a NOMCOM questionnaire are
confidential wrt the IAB.  By design almost anything related to
NOMCOM and recalls excludes "O" participants, "O" participants
are not entitled to spend the money of paying "P" participants.

> once the IESG says "we do things this way" and gets community
> consensus that the procedure is reasonable (even if that 
> consensus is interpreted from bored silence), doing things in
> a different way is subject to appeal.

In theory (until the I* find a trick to adjust their killfiles
without saying so) anything can be appealed, silly examples, why
do we still use binary bits when "ternary bits" are better, or
why does IETF 71 use US "summer time" before spring in winter.

But a real appeal based on "John posted on the general list that
xyz is IETF consensus by bored silence" would be rather shaky.

While the IAB might think that "precedence" is a legal concept
in parts of the world, it is no legal concept in other parts of
the world, back to the times of Napoloeon (maybe, IANAL).

> The community should never tolerate repeated demonstrations of
> bad judgment.  While such things have been rare in the history
> of the IESG, community tolerance for it tends to be interpreted
> as approval and often causes things to get worse.

Some judgement calls are tricky.  I could argue that the IAB has
no business to overrule NOMCOM, and after I managed to convince
enough folks that this is consensus I could "sell" the IETF to
anybody wishing to spend about two years and 20,000,000 USD for
the purpose of getting an RFC number for ECMA 376 or similar :-|

> I think we have worse problems than an ION versus BCP debate.

Likely, but finding enough folks to agree on the same definition
of "worse" would be a challenge.  

> BCPs are probably the wrong mechanism for reaching consensus
> on and publishing process documents, regardless of what we do
> with IONs.

s/probably/likely often/ and s/regardless of/also depending on/,
in context very near to a NAK.  After all a BCP is supposed to
be a kind of consensus at the time it was approved.  An example
is RFC 2418 chapter 4 beating RFC 3710 chapter 4.3 from my POV.
The latter or both could be IONs - I'd prefer it if RFC 2418 is
not replaced by an ION.

> if we get rid of them and the price is either (i) to try to 
> give BCP status to relatively informal statements about 
> interpretation of principles or (ii) to encourage the IESG to 
> keep its real procedures secret because there is no place to put
> them, I think those would be significant steps in the wrong
> direction.

+1 for your conclusion: 

 Frank

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 13 Mar 2008 18:00:14 -0400

> pages, IESG minutes, or recent change patrol in a wgchairs wiki.

I agree with the desire, and we have discussed achieving that without
IONs, by carefully choosing between Web pages, IESG statements
and RFCs (possibly BCPs).  Right now it's difficult to find anything in
the IESG Web site -- and I strongly believe that too many categories
adds to the confusion -- but Pasi has started to tackle Web site
navigation (way to hit the ground running) and I hope to help him.

Lisa