Pasi, --On Friday, 19 September, 2008 12:34 +0300 Pasi.Eronen@xxxxxxxxx wrote: > John C Klensin wrote: > >> > 1) Spam: apparently valid email addresses in an RFC are >> > widely believed to have been harvested and included in Spam >> > lists. The domain may receive spam at mailboxes other than >> > the one used in the example email address, if the domain >> > name is used in common name or brute force attacks. >> >> Please note that a careful reading of this paragraph would >> either ban or discourage the appearance of author email >> addresses in RFCs. Yet such addresses have been a firm >> requirement for many years (if I recall, since before there >> was an IETF). Questions: >> >> (i) Does the IESG intend to change the requirement for >> email addresses? > > BTW, > http://www.rfc-editor.org/rfc-editor/instructions2authors.txt > does not absolutely require including an email address (if you > give some other contact method, such as postal address or > telephone number), and there are RFCs that don't include it > (e.g RFC 3718 from 2004; perhaps others exist, too). Others probably do exist, and I was aware of the language of the requirement. However, for standards track documents, I am aware of IESG pressure on authors to, in fact, include email addresses. I suggest that, in practice, we can't really have it both ways. >> (ii) Does the IESG believe that the appearance of a >> domain name in an email address in an example is somehow >> more harmful or likely to draw the attention of spammers >> than one in an "Author's Address" section? If not, >> could you explain your reasoning? > If you're an author, you have presumably given your permission > to being listed in the Author's Address section, and can > choose what address to put there. But you may not have explicit permission from the holder of the domain in that address to expose them to additional traffic, including traffic that uses dictionary methods or sequentially-generated local-parts. I apologize for being difficult here, but I think the IESG really should be pushing for "more exercise of good sense" rather than "more rules". If the desire is really "more rules", then (1) I'm going to feel obligated to point out just how difficult it is to get such rules right, how much time it takes --from both the IESG and the community-- and to question whether that is the best use of resources, even as compared with the IESG having to spend a little more time evaluating special cases (a task that this statement clearly does not eliminate, since it includes provision for such special cases). (2) I suggest that the Nomcom, as part of its activity of trying to determine the sense of the community that feeds into the selection process, consider whether the community prefers that more time be spent on rule-making (or, worse, the enforcement of rules that exist only in the minds of the IESG) and then make selections consistent with that community preference. To be more blunt about that, unless the community really wants more rules and priority given to the time that they might take, the Nomcom should be, IMO, seriously considering whether IESG incumbents or candidates who prefer more rule might better serve the community in other ways. With regard to email addresses specifically, I very much agree with what Pekka wrote: >> FWIW, IMHO, any spam argument seems bogus. Anyone actively >> participating is already leaving such an email address >> footprint all over the net (including elsewhere in the IETF) >> that a) they already need protection mechanisms, and b) >> obfuscation methods (if used) should be reasonable. But that is not the main point... > IMHO the crux of the proposed text is that since using email > addresses (and domains, etc.) belonging to someone else can > potentially cause harm (although usually not very serious), > it's better if the owner of the address (instead of IESG) > decides whether the potential harm is acceptable or not -- and > this should be opt-in (instead of assuming that lack of > complaints means its OK). Ok. We agree on the principle. Moreover, if I haven't said it already, I very much appreciate the efforts of the IESG to bring this issue out in the open and to promote discussion of it, rather than expecting people to deduce what is expected and then see documents held up at a late stage if their deductions are not correct. I also note that "get permission" is an odd business. Domain names change. For example, people change jobs, email providers, and other arrangements. Several prominent members of this community have dropped domain names that were in use for many years and switched to new ones after various combinations of pressure and financial inducements. I'm not likely to give up "jck.com", largely because I'm a little pig-headed about the "market" that creates the offers, but it probably wouldn't take a very large incentive for me to stop finding the use of "bogus.domain.name" amusing enough to justify (and I think I have used it in IETF-related examples). I believe "nokia.com" is probably stable under current management and policies, but, at one stage, I would have made equally strong predictions about "univac.com", "apollo.com", and even "dg.com". The RIRs believe that address allocations (at least address allocations since they came into being) are on loan and that, under various circumstances, they could be repossessed. Even without that, many people expect that the future of IPv4 will involve a good deal of migration of responsibility for address blocks. Probably identifiers that are actually allocated under IESG supervision are more stable, but we can't count on even those if the relevant registries start running out of space. SO, while I'm sympathetic to the "permission" concept, I think it is often meaningless in the long term (unless one expects new acquirers of domain names or addresses to do due diligence on prior uses and accept the consequences... and the IESG has already rejected the argument that such a requirement is reasonable. However, I also agree with your observation that the "harm" is not very serious, a subject on which several people commented at length during the last IETF list discussion on this subject. I believe that more rules have costs to the community, even if only as encouragement and nutrition for those who consider nit-picking a more valuable activity than producing standards (especially Proposed Standards). Consequently, unless serious harm can be demonstrated, I'd rather see fewer rules and discussion of them and more good sense backed up with general guidance. > (There may be exceptional cases when something else needs to be > done, though.) Of course, there will always be such cases. The question is whether, given that they exist, this sort of effort is worthwhile. I continue to believe that the IESG could do something much easier and much more effective by issuing, not a collection of new rules, but a simple statement requiring that people either use suitably-reserved and dedicated identifiers or that they explain, explicitly and subject to community review, why not. Since good sense suggests using these identifiers when there is not a plausible reason to do something else and general laziness (and the desire to avoid last-minute debates about the usually-trivial) is likely to encourage the use of such identifiers unless there really is a reason why not. Given that, let's stop there and not try to anticipate all of the possible reasons or create lengthy new sets of rules and procedures. best, john _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf