Hi John,
Thanks for the comments. Please see inline.
John C Klensin skrev:
> A brief comment on this... I may have more to say later on...
>
> --On Thursday, 18 September, 2008 10:07 -0700 The IESG
> <iesg@xxxxxxxx> wrote:
>
>> The IESG has received the attached text for a proposed IESG
>> Statement: IESG Statement on the Usage of Assignable
>> Codepoints in Specification Examples
>> ...
>>
>> = = = = = = Text of Proposed IESG Statement = = = = = = =
>> ...
>
>> 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?
No, that has not been the intention. I also don't think the statement
say anything that explicitly changes that.
>
> (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?
No, I don't think there is a difference from a spam perspective. From my
point of view it is quite clear that the moment I stuck my email address
in a internet draft I started receiving spam volumes several magnitudes
larger than before. So as an author using your own address in an example
may not make much difference from a spam perspective. However, it make
more difference for other reasons, like if it is a test script you are
putting in your email address in. If you are putting someone else email
address into your document you may increase there volume of spam.
>
> (iii) Does the IESG intend to pursue the idea, discussed
> many times, of creating a reserved mail domain and
> assigning all RFC authors mailboxes or aliases in it?
We haven't discussed this at all at this point in time. I don't see how
applicable this is to the general intention of the IESG statement to
cover all type of codepoints, including domain names, email addresses,
and media types. So if we want to continue any discussion on this topic,
can we please that that in a separate thread.
>
> I note with interest that this statement does not appear to
> apply (or at least does not appear to offer justification for
> applying) these rules to domain names that do not appear in
> email addresses (or in configuration files, etc.).
The statement intendeds to provide examples why using real domain names
or other types of code points can be harmful. Reasons will vary with
protocol and the type of "codepoint". And there will be cases where
there will be no impact, maybe other than us being a little rude and
using someone else domain name. Which I think is a good enough reason
unless there some real counter reason while this particular name is so
good for the example and can't be illustrated with another. And as the
statement says, in those cases, please ask the owner before going ahead.
I note with
> even more interest that reservation of "codepoints" for example
> or other documentation purposes would violate existing IESG
> statements and rules about conservation of scarce resources
> (where scarcity is an issue) or would require negotiation with
> other bodies.
>
Which IESG statements are you referring to? I can't find any on that
topic, but I may be missing one.
There clearly are tradeoffs between assigning code-points and the
possible scarcity or unavailability of them. Then one simple have to use
another option of ensuring that this usage has minimal impact. Including
using assigned values with the owners approval. It also include the
consideration of the impact.
Maybe there are some text clarification that could help make this
clearer. Adding something to the following bullet ", unless prevented by
scarcity or other registration considerations."
- The specification itself can request further values or codepoints to
be assigned.
I do like to point out that the goal with the statement is to have
people think about these issues. Be aware that IESG will consider them
and may object to certain usages unless reasonably motivated.
Cheers
Magnus Westerlund
IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Färögatan 6 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx
----------------------------------------------------------------------
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf