John C Klensin wrote:
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
Hi John, I'm not very interested in fights about trivial IDnits.
AFAIK the IESG has no problem with using a full 2119 boilerlate,
or a boilerplate truncated to the actually used 2199 terminology,
i.e. what I called "Bruce's style" (with a reason, see below).
Truncation requires more attention by authors, it would be wrong
to define only SHOULD, but actually use MUST. The "IDnits tool"
is a stupid script, it can check that you use 2119 terms without
boilerplate. It can identify the full boilerplate. It emits a
warning for a truncated boilerplate, because it does not check
if you use MUST without definition. That's all, quite harmless,
no fight and no issue an IESG review.
Last year you feared that you "MUST" have "I18N considerations"
in a memo that's about I18N starting with the abstract and ending
with the Acknowledgements. The author of this rule in RFC 2277
and others talked you out of this, it is *NOT* required when it
makes no sense (as in a document about EAI, pure I18N). Rules
must make sense. Not talking about I18N without obvious reason
would be wrong.
As expected your memo without "I18N considerations" was approved
without any problems.
Just for fun also the opposite case, Bruce didn't believe that
his style is nicer and better readable, as I did. He believed
that his style is REQUIRED, and submitted errata when documents
used the full 2119-boilerplate without using all key words. IMO
that was nonsense, and his editorial errata should be summarily
rejected (for this issue, not everything he reported). So if
there was a fight, it was his fight, and I think Bruce lost it.
A different issue are "IANA considerations", they are used as a
flag for IANA to signal "nothing to do", after that they can be
removed in AUTH48. That makes sense, of course it might be odd
for folks who authored RFCs before that convention was invented.
But it's nothing to fight about, "security considerations" are
also required, even if they end up to repeat what is already
said elsewhere in a memo. Actually the presence indicates that
the authors tried their best to find potential security issues.
In practice that might not work as expected, but just removing
this requirement because authors could cheat is no good idea.
And for me the 2606 recommendation also makes sense. Not for
a fight, I wouldn't appeal the publication of 2821bis for the
high crime of using foo.bar in 19 examples or similar nits.
For a fight I'd want big and evil enemies, as in the various
MARID fights. Or the ooXML fights elsewhere, affecting the
IETF only remotely with the broken wannabe-pack: URI scheme.
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.
ACK. I'm far from sure that "we" (as the IPR WG) managed that
with the new IPR rules, but I still hope "we" at least managed
to make this not worse than it is (with the current rules).
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.
That's why we don't agree about this. I think this *is* the
problem with using made-up "real" addresses and domains in
examples (without consent of their owners or future owners).
You can certainly tune this in various directions, as long
as readers understand that they are not supposed to make up
similar examples only because 2821bis did it for historical
reasons. The old examples in 2821 are anyway "burnt", they
are no part of the problem. Taking FOO + BAR as funny, and
based on that trying something else, say SUN + JCK, could be
a problem.
In odd senses, "why is there an ad for SUN, but not for IBM",
or straight forward, address harvester adds JCK to its list.
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.
Your gateway appeal back in 2005 certainly influenced one to
three later technical appeals, as you might have guessed. :-)
I suggest that the process is working.
If they improve the I-D Checklist and maybe tune the tracker.
They could also forget this if more pressing actual events
(IPv6 issues, DNS issues, IDN "fights", ...) distract them.
Frank