RE: Call for review of proposed IESG Statement on Examples

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]