Re: Call for review of proposed IESG Statement on Examples

[Magnus Westerlund <[e-mail]>]

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
> <[e-mail]> 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 [phone]
Färögatan 6                | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------
_______________________________________________
Ietf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf