--On Friday, 18 July, 2008 06:55 +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
John C Klensin wrote:
[(1) + (2) +]
(3) Move the 2119 boilerplate from 2.3 to 1.5.
Right, define terms before they are used. You could switch it
to "Bruce Lilly style" if you like that better, i.e. enumerate
only tems used in 11: MAY, MUST, MUST NOT, SHOULD, SHOULD NOT.
No upper case SHALL NOT RECOMMENDED OPTIONAL anywhere. IDnits
doesn't support Bruce's style, ignore the warning if you do it.
Frank, as you know, I'm not a big fan of 2119. I've mostly lost
that argument. But, while appreciating Dave's comment about
underlying disease, I think there are fights that are worth
having and fights that aren't. Changes that don't accomplish
much of anything and that risk getting things wrong (either in
the document or in pointers to it) are, IMO, worth fighting.
Changes that can be interpreted as punishment or or petty "we
need to get the last word" retaliation may be worth fighting.
If the IESG wants to see 2119 invoked via some specific sentence
if it is invoked at all, what difference does that make that is
worth a fight, especially given the tendency to turn IDNits
suggestions or warnings into firm rules (that tendency may be
worth fighting, but the text, IMO, is not).
If you, or anyone else, believe that the IESG has gone too far
over toward rules and assertions of their own authority
vis-a-vis the community, tell it to the Nomcom and hope that
helps. Given motivation, the Nomcom should be able to extract
the names of the people on the IESG who are exerting the worst
judgment in this area even if the rest of us cannot, and to deal
with them appropriately. Speaking personally, I believe that
the IESG must have broad discretion in order to do its job and
to keep the rest of us from getting bogged down in even more
mechanistic rules that we have to follow even if it violates
good technical judgment. But that discretion has to be
accompanied with continuous application of care and good
judgment. And, again, if you don't see that happening, tell it
to the Nomcom. If you think that the current models of what the
IESG is about and how it operates have become the cause of the
problem rather than its cure, then it is time to start looking
seriously at process reform, whether the IESG favors those
reforms or not. If the community doesn't care enough to do
that, then we have the process we deserve.
| Because this document has a long history and to avoid
| the risk of various errors and of confusing readers and
| documents that point to this one, most examples and the
| domain names they contain are preserved from RFC 2821.
So far it's clear...
| Readers are cautioned that these are illustrative
| examples that should not actually be used in either
| code or configuration files.
OK?
...the second part misses the point. Readers putting these
examples in code (e.g. try to spam foo.com) or configuration
files (e.g. try to buy foo.com) are hopeless. Telling them
that they should get a grip is a waste of time.
Actually, that was precisely the point, "missing the point,
hopelessness, and wasting time" included. And that is, IMO,
exactly what make this a reasonable proposal.
Address the real problem:
| Readers are cautioned to use examples as described in
| RFC 2606 in their texts to avoid the various problems
| with real or potential domains in examples as explained
| in the security considerations of this BCP.
I don't believe that there is sufficient consensus in this group
that there are actually problems the use of bogus domains in
actual examples or few-time tests. I don't believe that there
is sufficient consensus that the use of non-2606 examples in
non-IETF examples is actually harmful or that the disadvantages
of doing so outweigh the possible advantages of more clarity
through careful choices of names. As I understand it, the
sticking point for the IESG is a subject on which there is
probably at least weak consensus here, which is the code, config
files, MIBs, and similar structures. 2821bis doesn't contain
any of those things, which, I assume, is at least part of what
causes you to say "missing the point, hopelessness, and wasting
time". From my point of view, that sentence could easily be
prefixed by "Just in case you, dear reader, are fool enough to
need to have this explained to you", but that would be rude as
well as unnecessarily provocative.
Because it is related to the meta-points above...
--On Friday, 18 July, 2008 11:19 +0200 Alessandro Vesely
<vesely(_at_)tana(_dot_)it> wrote:
I think that kind of danger may become actual harm in the
absence of suitable expedients, as e.g. in the MARID case that
Frank recently recalled
(http://www.imc.org/ietf-smtp/mail-archive/msg05068.html).
And I think there _are_ suitable and adequate expedients. They
may be more painful than we might like in a perfect world, but
the are there. We don't even have evidence that they don't
cause learning if pursued carefully enough and with sufficient
determination.
In particular, I believe that another reason we get the process
we have (and may deserve) is that we have too few appeals on
substantive matters that affect standards-track documents.
Appeals by relatively sensible people protesting apparently poor
and badly-documented decisions and asking that the IESG go back,
review them again, and either change their minds or at least
document their reasoning are an important check on the process.
When the majority of the appeals that the IESG receives are from
people whom they perceive as fringe contributors or
non-contributors trying to protect, e.g., their right to be
disruptive, the tendency --and I think it is normal human nature
-- is to see any appeal as an attack on the IESG. If we had a
larger percentage of them that addressed substantive issues and
asked for reconsideration, maybe responses would be more
constructive and less defensive.
But, in this case, while it has required some patience from both
the list and the IESG, and my personal opinion is that we should
not have needed even the first appeal (but that is true almost
by definition), I suggest that the process is working.
john