ietf
[Top] [All Lists]

RE: Call for review of proposed IESG Statement on Examples

2008-09-19 14:50:25
Pasi,

--On Friday, 19 September, 2008 12:34 +0300
Pasi(_dot_)Eronen(_at_)nokia(_dot_)com 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf