[Top] [All Lists]

Re: IESG approval status of rfc2821bis

2008-06-05 14:44:26

John C Klensin wrote:
The problem is an outstanding DISCUSS about changing all of the
examples that do not use RFC 2606 (e.g., "" and friends)
names to use that convention, with the possible exception of those
that point to ISI or USC.

Just fix it and be done with it.  For obvious reasons they'd be
in a shaky position if they let it pass depending on the name of
the author.

2606 (the only consensus document on the subject) says things
like "can be used" and does not even express an explicit 
preference for them.

RFC 2606 needs to be updated.  RFC 3330 for IPv4 examples and an
RFC for IPv6 examples exist, maybe there's also another RFC for
example telephone numbers - I forgot the details, but the theory
is very simple, stay away from "real" examples unless you have a
very good excuse, e.g., the consent of the affected parties.

"Never ever publish e-mail addresses unless you are ready to deal
with tons of spam" is simply common practice - it would be odd if
2821bis ignores the issue, readers could ask if the IETF is aware
of the spam problem, or if it's still living in the 20th century.

the IESG has been enforcing the use of 2606 names as a firm rule
for "at least five years".

That's what they do, in fact it's the only style I know, because I
had no idea what "IETF" really is before MARID and an unscheduled
USEFOR boot camp organized by Bruce in 2004.  Thinking about it,
it won't surprise me if he he's one the inventors of this "rule".

I do not believe that "the IESG has been doing this for years" 
constitutes evidence that the community has approved of the
IESG's doing so.

As always TINW, I think the rule makes sense, but it would be nice
to note it in 2606bis.  While at it adding the 11 IDN test TLDs to
2606bis would be also good...

initiate an update to 2606 that changes "can be used" into
"MUST be used unless the IESG grants a waiver".

...yes, adding it elsewhere (idnits, idguidelines) can then simply
follow when the editors of these tools / documents want it.

excerpting from RFC 2026, Section 6.5.3

IMO that is for things that are *worse* than the RFC 4406 scandal,
it is the level of "ISO 29500" or open corruption.  Section 6.5.3
is for cases where ISOC needs to decide if it wishes to shut down
the IETF.  

The one issue that _is_ specific to 2821bis (and 2821) is that
DRUMS explicitly considered the question of what to do about
the 821 examples. 

Whenever somebody said "DRUMS" in the last two years it was as
an exccuse for an utter dubious decision years ago, where they
didn't wish to discuss what the DRUMS participants were smoking.
Just my personal impression as somebody who read only the DRUMS
output, not the list archive.

I would rewrite the Acknowledgments to explicitly point to
Jon's role and examples and clear the text with this list

Without a WG only the IESG is supposed to judge the "consensus",
but I say there was strong support for keeping Jon's address in
examples "as is" here.  Adding something about this decision in
the Acknowledgements is a good idea, maybe link to RFC 2468 (?)

 [just fix it]
To me, that is equivalent to agreeing that it is ok for the
IESG to have essentially-secret rules, developed without
community consensus and undocumented in any description for
I-D requirements, and then impose those rules using permanent
blocking DISCUSS positions after Last Call.

The (undocumented) rule was no secret for me, it was completely
unnecessary that I forgot to get the explicit prior consent for
a violation of this rule in the news-URI memo (fixed meanwhile).

What's wrong here is the "undocumented", not the rule.  I don't
see the point of involving the IAB in this issue (by an appeal),
let's just admit that 2606 has to be fixed.  Most likely the IAB
would also pick this as solution.

e.g., selection to the IESG is equivalent to anointment as a
member of a group with imperial powers and divine right.

Dunno, in a case like RFC 4406, where an entity known as Redmond
in essence tried to steal the work of an entity known as openSPF
endorsed by the IESG I'd share your concern, but for "addresses
in examples" I think it's slightly exaggerated.  

There is also the question of "do (un)documented rules depend on
the name of the author".  To some degree they do, it's only fair,
but they can't do this too obviously, everybody could later say
"but RFC 5821 also did this".

What is your pleasure?

Let's fix RFC 2606.  If you are sufficiently angry we could move
RFC 3710 to historic, it clearly violates RFC 2418.