Magnus Westerlund wrote:
I have tried to write a statement that allows the IESG to use common
sense. However, the problem I have seen several times when the IESG
tries to use common sense in issues that comes up regularly is that some
people complains about not knowing about this and that we can't enforce
it because there are no written rules.
No matter what you do, there will be complaints.
It's the nature of interesting social processes like the IETF.
So the fact that "some people" complain needs to be run through a dual-function
filter. The first is whether the complaint makes sense or is merely serving as
an unfortunate form of entertainment for the complainer. In the former case, is
"makes sense" obvious and compelling?
The other filter is community concern. If the complaint gets no serious support
from others in the community and isn't otherwise compelling, then it's noise.
Noise can be ignored. Or rather, for a system as noisy as the IETF community
is, noise MUST be ignored.
I'll predict that the more serious issue underlying real complaints about "not
knowing" has to do with predictability.
If folks can't predict what the IESG will take exception to, they have a right
to complain. And making an infinite list of fine-grained details doesn't solve
this... as we have now seen.
For the exemplar that triggered the current round of effort, an established bit
of documentation, for a long-standing and popular standard, was being required
to make a change where no specific problem had been documented.
That there is a general truth to the general tendency to have some possible
problems with poorly chosen names doesn't change the fact that this particular
case had no history of any reported problems, after 20 years. Or 10, depending
on you count. One decade or two.
This made the IESG demand significantly unpredictable. And please note that the
presence of detailed rules didn't help, since the IESG citation was for rules
that didn't substantiate the demand. The rules were written as guidance, not
inflexible, normative requirement.
So it didn't help to have lots of rules and it didn't help that the IESG was
paying attention to a legitimate problem... legitimate in the general case.
What was missing was a deeper consideration of the particular situation. And
writing fine-grained rules won't fix that.
Thus the draft statement is an
attempt to satisfy several different requirements:
- Provide motivation why there are issues with examples
- Provide some guidance on how to handle situations which aren't clear cut
- Be clear that this is something IESG do look at and authors need to
think about.
- Prevent complaints about late surprise and heavy hands when we are
applying what we think are common sense.
This is an excellent list. Really.
The problem is not with the goals, but how these goals are being pursued.
If you have a suggestion on how this better can be written up I am
interested.
When it comes to harm, I think we clearly have some cases where examples
can have really serious effects,
Correct. However please note how you phrased this:
Some cases.
Examples.
That form of statement will tend to hold true for any rule or decision that
isn't patently silly. In complex systems, there is certain to be an "example"
of almost any problematic case one can imagine.
Notice that you didn't say things like:
Usually, or always
and
Significant problem
These decisions by the IESG need to present some sort of cost/benefit statement,
where the cost is not based on a mere existence proof that a problem has been
seen sometimes, but a basis for knowing that there is a real and substantial
problem... in the current real situation.
In other words, the problem is clearly serious and clearly applicable to the
current case.
And please note that an analysis like this will a) not require fine-grained
rules to be documented, and b) will stand up against stray complaints.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf