[Top] [All Lists]

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

2008-03-08 20:38:06
John C Klensin wrote:
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.

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 

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.

Cumulatively, that results in procedures that have so many
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

+1 for your conclusion: 


IETF mailing list

<Prev in Thread] Current Thread [Next in Thread>