Subject: [Enum] I-D ACTION:draft-ietf-enum-msg-02.txt

From: [email-masked]
Date: Thu, 24 Jun 2004 12:49:14 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Telephone Number Mapping Working Group of the IETF.

	Title		: IANA Registration for ENUMservices email, fax, mms, ems and sms
	Author(s)	: R. Brandner, et al.
	Filename	: draft-ietf-enum-msg-02.txt
	Pages		: 19
	Date		: 2004-6-23
	
This document registers the 'ENUMservices' [6] 'email', 'fax', 'sms',
   'ems' and 'mms' using the URI schemes 'tel:', 'mailto:', 'sip:' and
   'sips:' as per the IANA registration process defined in the ENUM
   specification RFC3761 [6].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-msg-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request at ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-enum-msg-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv at ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-enum-msg-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<ftp://ftp.ietf.org/internet-drafts/draft-ietf-enum-msg-02.txt>

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jeff Williams <[email-masked]>
Date: Fri, 25 Jun 2004 02:15:22 -0400

All,

  Well as we have been discussing it seems that the concerns regarding
privacy were not adequately addressed in this draft as the so called
rough consensus doctrine of the IETF seems to desire to adhere to.
Draft referenced below:
 http://www.ietf.org/internet-drafts/draft-ietf-enum-msg-02.txt

Sections with weak security and privacy provisions are as follows:

Security Considerations:

   An e-mail address is a canonical address by which a user is known.
   Placing this address in ENUPM is comparable to placing a SIP or
   H.323 address in the DNS.

   DNS does not make any policy decisions about the records that it
   shares with an inquirer.  All DNS records must be assumed to be
   available to all inquirers at all times.  The information provided
   within an ENUM NAPTR resource record must therefore be considered to
   be open to the public, which is a cause for some privacy
   considerations.

   Therefore ENUM Subscribers should be made aware of this risk.  Since
   it is within the responsibility of the ENUM Subscriber which data is
   entered in ENUM, it is within the ENUM Subscribers control if he
   enters e-mail addresses:
   1.  allowing inference of private data e.g.  his first and last name
   2.  at all

   It should also be considered that it is the purpose of public
   communication identifiers to be publicly known.  To reduce spam and
   other unwanted communication other means should be made available.

And.....

6.  Security Considerations

   DNS, as used by ENUM, is a global, distributed database.  Thus any
   information stored there is visible to anyone anonymously.  Whilst
   this is not qualitatively different from publication in a Telephone
   Directory, it does open the data subject to having "their"
   information collected automatically without any indication that this
   has been done or by whom.

   Such data harvesting by third parties is often used to generate lists
   of targets for unrequested information; in short, they are used to
   address "spam".  Anyone who uses a Web-archived mailing list is aware
   that the volume of "spam" email they are sent increases when they
   post to the mailing list; publication of a telephone number in ENUM
   is no different, and may be used to send "junk faxes" or "junk SMS"
   for example.

   Many mailing list users have more than one email address and use
   "sacrificial" email accounts when posting to such lists to help
   filter out unrequested emails sent to them.  This is not so easy with
   published telephone numbers; the PSTN E.164 number assignment process
   is much more involved and usually a single E.164 number (or a fixed
   range of numbers) is associated with each PSTN access.  Thus
   providing a "sacrificial" phone number in any publication is not
   possible.

   Due to the implications of publishing data on a globally accessible
   database, as a principle the data subject MUST give their explicit
   informed consent to data being published in ENUM.

   In addition, they should be made aware that, due to storage of such
   data during harvesting by third parties, removal of the data from
   publication will not remove any copies that have been taken; in
   effect, any publication may be permanent.

   However, regulations in many regions will require that the data
   subject can at any time request that the data is removed from
   publication, and that their consent for its publication is explicitly
   confirmed at regular intervals.

   When placing a fax call via the PSTN or a sending a message via the
   Public Land Mobile Network, the sender may be charged for this
   action.  In both kinds of network, calling or messaging to some
   numbers is more expensive than sending to others; both networks have
   "premium rate" services that can charge considerably more than a
   "normal" call or message destination.  As such, it is important that
   the end user be asked to confirm sending the message, and that the
   destination number be presented to them.  It is the originating

Brandner, et al.       Expires December 20, 2004               [Page 14]

Internet-Draft    IANA Registration for Message ENUMservices   June 2004

   user's choice on whether or not to send a message to this destination
   number, but they SHOULD be shown the destination number so that they
   can make this decision.

   An analysis of threats specific to the dependence of ENUM on the DNS,
   and the applicability of DNSSEC [19] to these, is provided in RFC3761
   [6].

=========== End of referenced sections ===============

 So shall we again discuss and consider alternative or more appropriate
language and or provisions to this draft that closer matches the "Rough
Consensus" of interested parties and/or stakeholders/users?

> implementation to automatically retrieve the ASCII version of the

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1 at ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827