John C Klensin wrote: > The problem is an outstanding DISCUSS about changing all of the > examples that do not use RFC 2606 (e.g., "example.com" 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. Frank
