--On Monday, 22 September, 2008 11:40 +0200 Magnus Westerlund
<magnus.westerlund at ericsson.com> wrote:
Hi John,
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.
Magnus, Spencer's note does a fairly good job of summarizing
most of my concerns. Let me address a few things that he does
not, but please read his note along with this one.
First of all, I see a huge difference among three categories
that your note, and the draft statement, seem to roll together:
(i) The class of things that the IPR WG might think of
as "code", here including MIBs, configuration files,
tables, and code excerpts that implementers are expected
to copy, either verbatim or with simple, template-like,
modifications.
(ii) Test scripts and similar things, written in a form
in which they will obviously be copied, perhaps modified
slightly, and then executed repeatedly (with fairly high
multiples of "repeatedly").
(iii) Simple, illustrative examples that, even if
executed, are not likely to be executed more than once
by a given implementer.
One might draw the boundaries in other ways, but they are
different enough that saying "the cases in the first group are
harmful, therefore the cases in the third are harmful enough to
require extensive rules" is just bogus.
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.
One can make extensive rules or one can apply common sense. The
pushback when this came up was because of a perception that
common sense was _not_ being applied. This document does not
somehow instantiate common sense, what it does it to transform
the rigid rule that was undocumented into the rigid rule that
is. And, while "undocumented" makes things much worse, the real
objection is to the rigid rule, especially against the backdrop
of a concern that it will take far too much time and energy to
get such a rule right and that there will _still_ be exception
cases.
In general, any time you write a page of rules and case analysis
when a sentence of guidance would do, I (and perhaps others) are
going to object. Keeping things simple is of significant and
substantive importance.
If you have a suggestion on how this better can be written up
I am interested.
Yes. I've made that suggestion several times. It was actually
in my previous note (see Pasi's comment). Don't try to
delineate every case and build a rule on that basis. Just
indicate that you expect safe/protected/reserved names (or
codepoints or other identifiers), to be used, especially when
they occur in situations in which copying and repeated execution
are likely and that, if the author believes otherwise, that must
be explained in a comment (in the document or wherever else you
would like it) that is clear enough that the community can
comment on the justification during Last Call. If you want to
say something about the difference between new and revised
documents, I would, based on recent experience, appreciate it,
but I don't think even that is necessary.
When it comes to harm, I think we clearly have some cases
where examples can have really serious effects, configurations
being what comes to mind. When it comes to email addresses
they are primarily an annoyance, but I think any one of us
would be might irritated to learn that the suddenly started
receive spam in large quantities because someone published
their address in example in an internet draft or RFC. I think
that this is as far as this goes and something any contributor
to the IETF unfortunately have to pay for their contribution
in an open organization with open access to its documents.
See Spencer's note about spam and the comment above about
conflating "configurations" with "email addresses in a purely
illustrative example".
regards,
john
