From bernie@ietf.hoeneisen.ch Sat Feb 6 04:24:26 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 599EC3A6C04 for ; Sat, 6 Feb 2010 04:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CloWUEqR42-Q for ; Sat, 6 Feb 2010 04:24:25 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 44A823A6BF8 for ; Sat, 6 Feb 2010 04:24:21 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1Ndjiq-0001x5-41 for e2md@ietf.org; Sat, 06 Feb 2010 13:25:12 +0100 Date: Sat, 6 Feb 2010 13:25:11 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "E.164 To MetaData BOF discussion list" Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Subject: [e2md] What has been discussed so far... X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2010 12:24:26 -0000 Dear E2MD subscriber First of all, a warm welcome to the IETF E2MD (E.164 To MetaData) BOF discussion list! For your convenience I extracted an index to the recent discussions about E2MD (E2M) from the IETF dispatch and enum mailing list archives. Please find this hand-made index on: http://ucom.ch/ietf/e2md-arch/ Enjoy your weekend! cheers, Bernie Hoeneisen -- http://ucom.ch/ Tech Consulting for Internet Standardization From bernie@ietf.hoeneisen.ch Sat Feb 6 04:36:10 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8B9A3A709D for ; Sat, 6 Feb 2010 04:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cgx+jzZdYFbG for ; Sat, 6 Feb 2010 04:36:10 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id C8D593A6D4C for ; Sat, 6 Feb 2010 04:36:09 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NdjuI-00020N-76 for e2md@ietf.org; Sat, 06 Feb 2010 13:37:02 +0100 Date: Sat, 6 Feb 2010 13:37:02 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "E.164 To MetaData BOF discussion list" Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="37663318-1246822034-1265459822=:6667" X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Subject: [e2md] I-D Action:draft-hoeneisen-e164-to-metadata-02.txt (fwd) X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2010 12:36:11 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --37663318-1246822034-1265459822=:6667 Content-Type: TEXT/PLAIN; CHARSET=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE FYI (an update of the basis document) ---------- Forwarded message ---------- From: Date: Sat, Feb 6, 2010 at 12:15 PM Subject: I-D Action:draft-hoeneisen-e164-to-metadata-02.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : E.164= to MetaData (E2MD) Dynamic Delegation Discovery System (DDDS) Application =C2=A0 =C2=A0 =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 : B. Hoeneisen =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-hoen= eisen-e164-to-metadata-02.txt =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 14 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = 2010-02-06 This document proposes a new Dynamic Delegation Discovery System (DDDS) Application to map E.164 numbers to metadata. It discusses the use of the Domain Name System (DNS) for resolving E.164 numbers into metadata to provide information about E.164 numbers in cases where E.164 Number to URI Mapping (ENUM) can not be used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoeneisen-e164-to-metadata-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --=20 http://ucom.ch/ Tech Consulting for Internet Standardization --37663318-1246822034-1265459822=:6667-- From bernie@ietf.hoeneisen.ch Mon Feb 8 12:45:51 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2C4728C116 for ; Mon, 8 Feb 2010 12:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Tppb3LTZF1j for ; Mon, 8 Feb 2010 12:45:51 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id F146B28C10B for ; Mon, 8 Feb 2010 12:45:50 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NeaVR-00022J-Fz for e2md@ietf.org; Mon, 08 Feb 2010 21:46:53 +0100 Date: Mon, 8 Feb 2010 21:46:53 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "E.164 To MetaData BOF discussion list" Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Subject: [e2md] Request for input on market need evidence for E2MD X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 20:45:51 -0000 Hi, Again, welcome to the E2MD mailing list! Looking at the subscriber's list I am positively surprised how many people are interested in this topic. Now the hard work starts... I have requested a BoF for IETF-77 in Anaheim. http://trac.tools.ietf.org/bof/trac/wiki#RAI If we want this BoF to be successful, some questions need to be addressed before Anaheim. The most important one is: We need clear evidence on this mailing list that there is a real market need for E2MD (E.164 To MetaData). (!) So, please send your needs, use cases, requirements, implementation intentions, experiences or whatever helps demonstrating the market need for E2MD to this mailing list now! I am looking forward to your input! cheers, Bernie From pp3129@att.com Mon Feb 8 13:44:09 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E3C53A72A0 for ; Mon, 8 Feb 2010 13:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrlaWAOdLAL9 for ; Mon, 8 Feb 2010 13:44:08 -0800 (PST) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id 8F1903A68AC for ; Mon, 8 Feb 2010 13:44:07 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-14.tower-121.messagelabs.com!1265665509!31364008!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 17549 invoked from network); 8 Feb 2010 21:45:09 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-14.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Feb 2010 21:45:09 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o18Lj1I7014943 for ; Mon, 8 Feb 2010 16:45:02 -0500 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o18LivsN014876 for ; Mon, 8 Feb 2010 16:44:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAA907.F9911F68" x-cr-hashedpuzzle: Aqvf BC+C Bs+Y Coaf E+Cz FOU8 F6FZ GkMb G/ax HKYG HzUA ImXw IzuL JL2o JvGu Kbs1; 1; ZQAyAG0AZABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {D737B663-3D79-44B4-9B4A-81578E8FE721}; cABwADMAMQAyADkAQABhAHQAdAAuAGMAbwBtAA==; Mon, 08 Feb 2010 21:45:02 GMT; cgBlACAARQAyAE0ARAAgAHUAcwBlACAAYwBhAHMAZQBzAA== x-cr-puzzleid: {D737B663-3D79-44B4-9B4A-81578E8FE721} Content-class: urn:content-classes:message Date: Mon, 8 Feb 2010 16:45:02 -0500 Message-ID: <35FE871E2B085542A35726420E29DA6B034FFF14@gaalpa1msgusr7a.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: re E2MD use cases Thread-Index: AcqpB/fhVJYk6rmnR3COhDIByinKgA== From: "PFAUTZ, PENN L (ATTCORP)" To: Subject: [e2md] re E2MD use cases X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 21:44:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAA907.F9911F68 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Bernie: I won't be able to attend the BOF (sigh) but have heard of one use case that might be of interest: =20 Some carriers have expressed an interest in being able to make (least cost) routing decisions based on certain characteristics associated with a number. They might, for example, choose a different route based on its ability to support certain features a call might invoke. A cheaper route might be chosen if it were determined those features aren't supported on that number anyway. Getting this kind of info about a number is not something that the E2U URI scheme supports well and something that E2MD might. =20 Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Bernie Hoeneisen Sent: Monday, February 08, 2010 3:47 PM To: E.164 To MetaData BOF discussion list Subject: [e2md] Request for input on market need evidence for E2MD =20 Hi, =20 Again, welcome to the E2MD mailing list! Looking at the subscriber's list=20 I am positively surprised how many people are interested in this topic. =20 Now the hard work starts... =20 I have requested a BoF for IETF-77 in Anaheim. =20 http://trac.tools.ietf.org/bof/trac/wiki#RAI =20 If we want this BoF to be successful, some questions need to be=20 addressed before Anaheim. The most important one is: =20 We need clear evidence on this mailing list that there is a real market need for E2MD (E.164 To MetaData). (!) =20 So, please send your needs, use cases, requirements, implementation=20 intentions, experiences or whatever helps demonstrating the market need=20 for E2MD to this mailing list now! =20 =20 I am looking forward to your input! =20 cheers, Bernie =20 _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md =20 =20 Penn Pfautz AT&T Access Management +1-732-420-4962 ------_=_NextPart_001_01CAA907.F9911F68 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Bernie:

I won't be able to attend the BOF (sigh) but = have heard of one use case that might be of interest:

 

Some carriers have expressed an interest in = being able to make (least cost) routing decisions based on certain characteristics = associated with a number. They might, for example, choose a different route based = on its ability to support certain features a call might invoke. A cheaper route = might be chosen  if it were determined those features aren't supported on = that number anyway.

Getting this kind of info about a number is not = something that the E2U URI scheme supports well and something that E2MD = might.

 

Penn Pfautz

AT&T Access Management

+1-732-420-4962

-----Original Message-----

From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Bernie = Hoeneisen

Sent: Monday, February 08, 2010 3:47 = PM

To: E.164 To MetaData BOF discussion = list

Subject: [e2md] Request for input on market need = evidence for E2MD

 

Hi,

 

Again, welcome to the E2MD mailing list! Looking = at the subscriber's list

I am positively surprised how many people are = interested in this topic.

 

Now the hard work starts...

 

I have requested a BoF for IETF-77 in = Anaheim.

 

   http://trac.tools.i= etf.org/bof/trac/wiki#RAI

 

If we want this BoF to be successful, some = questions need to be

addressed before Anaheim. The most important one = is:

 

   We need clear evidence on this = mailing list that there is

   a real market need for E2MD (E.164 = To MetaData). (!)

 

So, please send your needs, use cases, = requirements, implementation

intentions, experiences or whatever helps = demonstrating the market need

for E2MD to this mailing list = now!

 

 

I am looking forward to your = input!

 

cheers,

  Bernie

 

_______________________________________________=

e2md mailing list

e2md@ietf.org

https://www.ietf.org/= mailman/listinfo/e2md

 

 

Penn Pfautz

AT&T Access Management

+1-732-420-49= 62

------_=_NextPart_001_01CAA907.F9911F68-- From kcartwright@tnsi.com Mon Feb 8 16:12:51 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4020A3A74CF for ; Mon, 8 Feb 2010 16:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blsnqOFtmVmi for ; Mon, 8 Feb 2010 16:12:50 -0800 (PST) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 5D8EF3A74CE for ; Mon, 8 Feb 2010 16:12:48 -0800 (PST) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.40372543; Mon, 08 Feb 2010 19:13:30 -0500 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 8 Feb 2010 19:13:30 -0500 From: "Cartwright, Kenneth" To: Bernie Hoeneisen , E.164 To MetaData BOF discussion list Date: Mon, 8 Feb 2010 19:13:28 -0500 Thread-Topic: [e2md] Request for input on market need evidence for E2MD Thread-Index: Acqo/+aEetWcqkEWRgqZcNl9Rz1h+gAG3WSk Message-ID: <754963199212404AB8E9CFCA6C3D0CDA0D873D9DB0@TNS-MAIL-NA.win2k.corp.tnsi.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [e2md] Request for input on market need evidence for E2MD X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 00:12:51 -0000 Hi Bernie, Thanks for coordinating activities related to E2M(D). Some examples of dat= a elements that some organizations are provisioning and/or querying for tod= ay include (some of which are for non-CC1 numbers): Payment Type: PrePaid | PostPaid Network Type: TDMA | GSM Region Code: A numeric value indicating a region within a country. Service Provider Name: The name of the current service provider. SPID: A string of characters identifying the current service provider. Not yet sure if I will be able to attend IETF, but will at least participat= e on-line. Ken ________________________________________ From: e2md-bounces@ietf.org [e2md-bounces@ietf.org] On Behalf Of Bernie Hoe= neisen [bernie@ietf.hoeneisen.ch] Sent: Monday, February 08, 2010 3:46 PM To: E.164 To MetaData BOF discussion list Subject: [e2md] Request for input on market need evidence for E2MD Hi, Again, welcome to the E2MD mailing list! Looking at the subscriber's list I am positively surprised how many people are interested in this topic. Now the hard work starts... I have requested a BoF for IETF-77 in Anaheim. http://trac.tools.ietf.org/bof/trac/wiki#RAI If we want this BoF to be successful, some questions need to be addressed before Anaheim. The most important one is: We need clear evidence on this mailing list that there is a real market need for E2MD (E.164 To MetaData). (!) So, please send your needs, use cases, requirements, implementation intentions, experiences or whatever helps demonstrating the market need for E2MD to this mailing list now! I am looking forward to your input! cheers, Bernie _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From jay@nzrs.net.nz Tue Feb 9 02:10:02 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B26703A7271 for ; Tue, 9 Feb 2010 02:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5exPZlzfXFrl for ; Tue, 9 Feb 2010 02:10:01 -0800 (PST) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 4F4F23A72B5 for ; Tue, 9 Feb 2010 02:10:01 -0800 (PST) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 473A52EAD4F; Tue, 9 Feb 2010 23:11:05 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHAV-tNoCGou; Tue, 9 Feb 2010 23:11:03 +1300 (NZDT) Received: from [192.168.1.4] (121-73-184-74.dsl.telstraclear.net [121.73.184.74]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTP id A5DDF2EA079; Tue, 9 Feb 2010 23:11:02 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: Date: Tue, 9 Feb 2010 23:11:00 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Bernie Hoeneisen X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Request for input on market need evidence for E2MD X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 10:10:02 -0000 On 9/02/2010, at 9:46 AM, Bernie Hoeneisen wrote: > So, please send your needs, use cases, requirements, implementation = intentions, experiences or whatever helps demonstrating the market need = for E2MD to this mailing list now! e2md is an absolute requirement if we are ever to achieve global carrier = enum in the public DNS. The two main reasons that carriers will not do that now are: 1. They don't want to publish details of the endpoints publicly and = have any idiot attempt to connect to them, even if those endpoints are = on private networks and unreachable from the Internet. 2. They want to have bilateral interconnection agreements that are = entirely private between the two parties with others not even knowing of = their existence. The only way to achieve those two goals is for global carrier enum to be = implemented as an e2md tree not an e2u tree: - each carrier publishes e2md data for the number blocks they are = assigned with e2md records that point to virtual endpoints - carriers then enter into bilateral agreements and exchange private = infrastructure plans, which map virtual endpoints to real endpoints. = Each private infrastructure plan a carrier issues bilaterally can be = unique if they wish. They can even seed them to detect leakage. =20 - if a carrier wishes to allow public interconnection then they can go = so far as to publish a public infrastructure plan. To be fair there is a third reason carriers don't want global carrier = enum 3. they don't wanting people knowing what numbers they have=20 but that is being eroded in other ways. Block allocation data is = readily available in many countries and ported number data is one step = further away. Another way of putting it, which I'm still not sure about but will posit = anyway, is that e2u is too direct to deliver on its promise *in public = carrier trees* and needs a level of indirection, as provided by e2md, to = overcome this. Or better still e2u=3Dprivate, e2md=3Dpublic. kind regards Jay --=20 Jay Daley Chief Executive .nz Registry Services desk: +64 4 931 6977 mobile: +64 21 678840 From pkyzivat@cisco.com Tue Feb 9 06:54:40 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E5563A73B6 for ; Tue, 9 Feb 2010 06:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.548 X-Spam-Level: X-Spam-Status: No, score=-10.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 766U1DkhC-V3 for ; Tue, 9 Feb 2010 06:54:39 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 9824A3A7315 for ; Tue, 9 Feb 2010 06:54:39 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIsGcUtAZnwM/2dsb2JhbADCGJgRhFQE X-IronPort-AV: E=Sophos;i="4.49,436,1262563200"; d="scan'208";a="211614251" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by sj-iport-3.cisco.com with ESMTP; 09 Feb 2010 14:55:45 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o19EtjtS026272; Tue, 9 Feb 2010 14:55:45 GMT Message-ID: <4B717771.9050705@cisco.com> Date: Tue, 09 Feb 2010 09:55:45 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jay Daley References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bernie Hoeneisen , "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Request for input on market need evidence for E2MD X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 14:54:40 -0000 Can I paraphrase this as: The PUBLIC Carriers don't want the PUBLIC to have information about PUBLIC phone numbers, because that information is PRIVATE. ??? Jay Daley wrote: > On 9/02/2010, at 9:46 AM, Bernie Hoeneisen wrote: > >> So, please send your needs, use cases, requirements, implementation intentions, experiences or whatever helps demonstrating the market need for E2MD to this mailing list now! > > > e2md is an absolute requirement if we are ever to achieve global carrier enum in the public DNS. > > The two main reasons that carriers will not do that now are: > > 1. They don't want to publish details of the endpoints publicly and have any idiot attempt to connect to them, even if those endpoints are on private networks and unreachable from the Internet. > > 2. They want to have bilateral interconnection agreements that are entirely private between the two parties with others not even knowing of their existence. > > > The only way to achieve those two goals is for global carrier enum to be implemented as an e2md tree not an e2u tree: > > - each carrier publishes e2md data for the number blocks they are assigned with e2md records that point to virtual endpoints > > - carriers then enter into bilateral agreements and exchange private infrastructure plans, which map virtual endpoints to real endpoints. Each private infrastructure plan a carrier issues bilaterally can be unique if they wish. They can even seed them to detect leakage. > > - if a carrier wishes to allow public interconnection then they can go so far as to publish a public infrastructure plan. > > > To be fair there is a third reason carriers don't want global carrier enum > > 3. they don't wanting people knowing what numbers they have > > but that is being eroded in other ways. Block allocation data is readily available in many countries and ported number data is one step further away. > > > Another way of putting it, which I'm still not sure about but will posit anyway, is that e2u is too direct to deliver on its promise *in public carrier trees* and needs a level of indirection, as provided by e2md, to overcome this. Or better still e2u=private, e2md=public. > > kind regards > Jay > From HKaplan@acmepacket.com Tue Feb 9 07:11:50 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D01E528C0E0 for ; Tue, 9 Feb 2010 07:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nv+-iTQOfLit for ; Tue, 9 Feb 2010 07:11:49 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 30CF73A6C7F for ; Tue, 9 Feb 2010 07:11:48 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 9 Feb 2010 10:12:53 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 9 Feb 2010 10:12:53 -0500 From: Hadriel Kaplan To: Paul Kyzivat , Jay Daley Date: Tue, 9 Feb 2010 10:12:52 -0500 Thread-Topic: [e2md] Request for input on market need evidence for E2MD Thread-Index: AcqpmAM/NmMNCeOrTBy0SJEdgTj6YAAAZa/g Message-ID: <430FC6BDED356B4C8498F634416644A917E5E0E629@mail> References: <4B717771.9050705@cisco.com> In-Reply-To: <4B717771.9050705@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bernie Hoeneisen , "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Request for input on market need evidence for E2MD X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 15:11:51 -0000 Or you could paraphrase it as: The NATIONAL PUBLIC Carriers don't want their and their customers' PRIVATE = information to be available to the GLOBAL PUBLIC, because that information = is PRIVATE. (e.g., the IP Address:port of the Carrier's Cable/DSL-Modem's VoIP interfac= e for your phone number is really no business of the PUBLIC) -hadriel > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Tuesday, February 09, 2010 9:56 AM > To: Jay Daley > Cc: Bernie Hoeneisen; E.164 To MetaData BOF discussion list > Subject: Re: [e2md] Request for input on market need evidence for E2MD >=20 > Can I paraphrase this as: >=20 > The PUBLIC Carriers don't want the PUBLIC to have information about > PUBLIC phone numbers, because that information is PRIVATE. >=20 > ??? >=20 > Jay Daley wrote: > > On 9/02/2010, at 9:46 AM, Bernie Hoeneisen wrote: > > > >> So, please send your needs, use cases, requirements, implementation > intentions, experiences or whatever helps demonstrating the market need > for E2MD to this mailing list now! > > > > > > e2md is an absolute requirement if we are ever to achieve global carrie= r > enum in the public DNS. > > > > The two main reasons that carriers will not do that now are: > > > > 1. They don't want to publish details of the endpoints publicly and > have any idiot attempt to connect to them, even if those endpoints are on > private networks and unreachable from the Internet. > > > > 2. They want to have bilateral interconnection agreements that are > entirely private between the two parties with others not even knowing of > their existence. > > > > > > The only way to achieve those two goals is for global carrier enum to b= e > implemented as an e2md tree not an e2u tree: > > > > - each carrier publishes e2md data for the number blocks they are > assigned with e2md records that point to virtual endpoints > > > > - carriers then enter into bilateral agreements and exchange private > infrastructure plans, which map virtual endpoints to real endpoints. Eac= h > private infrastructure plan a carrier issues bilaterally can be unique if > they wish. They can even seed them to detect leakage. > > > > - if a carrier wishes to allow public interconnection then they can go > so far as to publish a public infrastructure plan. > > > > > > To be fair there is a third reason carriers don't want global carrier > enum > > > > 3. they don't wanting people knowing what numbers they have > > > > but that is being eroded in other ways. Block allocation data is > readily available in many countries and ported number data is one step > further away. > > > > > > Another way of putting it, which I'm still not sure about but will posi= t > anyway, is that e2u is too direct to deliver on its promise *in public > carrier trees* and needs a level of indirection, as provided by e2md, to > overcome this. Or better still e2u=3Dprivate, e2md=3Dpublic. > > > > kind regards > > Jay > > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From richard@shockey.us Tue Feb 9 07:12:10 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E238F3A73DC for ; Tue, 9 Feb 2010 07:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUtQrRFpJiez for ; Tue, 9 Feb 2010 07:12:08 -0800 (PST) Received: from outbound-mail-348.bluehost.com (outbound-mail-348.bluehost.com [66.147.249.9]) by core3.amsl.com (Postfix) with SMTP id 7ADC63A6C7F for ; Tue, 9 Feb 2010 07:12:08 -0800 (PST) Received: (qmail 29423 invoked by uid 0); 9 Feb 2010 15:13:13 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy7.bluehost.com.bluehost.com with SMTP; 9 Feb 2010 15:13:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-language:X-Identified-User; b=cKNBqHX0N7iJnFXJx0v7xjHSIwfFzjr5CUfOnXUmVw4kwmWvhIOx6e5rcg+Fhepe9+VxkbfSFsK4ADorq2Ehw312RWJD/WWhuRfGrGIRzeSXwrkXzwLI6NLMiFdI8DeN; Received: from pool-96-241-62-33.washdc.fios.verizon.net ([96.241.62.33] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nerm4-0007rt-13; Tue, 09 Feb 2010 08:13:12 -0700 From: "Richard Shockey" To: "'Paul Kyzivat'" , "'Jay Daley'" References: <4B717771.9050705@cisco.com> In-Reply-To: <4B717771.9050705@cisco.com> Date: Tue, 9 Feb 2010 10:13:07 -0500 Message-ID: <009001caa99a$64147340$2c3d59c0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqpl/dwlKHIf3sOT0aHSXcVyY9tvwAAc7Aw Content-language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.62.33 authed with richard@shockey.us} Cc: 'Bernie Hoeneisen' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Request for input on market need evidence for E2MD X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 15:12:10 -0000 But Paul this has nothing to do with Public ENUM. It has everything to do with Private instantiations of ENUM and the use of RFC 3761 to cache phone number data locally in carrier networks. The IP Service Control Point so to speak. SIP redirect is not a good vehicle for PSTN metadata and that is the market this proposal addresses. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Tuesday, February 09, 2010 9:56 AM To: Jay Daley Cc: Bernie Hoeneisen; E.164 To MetaData BOF discussion list Subject: Re: [e2md] Request for input on market need evidence for E2MD Can I paraphrase this as: The PUBLIC Carriers don't want the PUBLIC to have information about PUBLIC phone numbers, because that information is PRIVATE. ??? Jay Daley wrote: > On 9/02/2010, at 9:46 AM, Bernie Hoeneisen wrote: > >> So, please send your needs, use cases, requirements, implementation intentions, experiences or whatever helps demonstrating the market need for E2MD to this mailing list now! > > > e2md is an absolute requirement if we are ever to achieve global carrier enum in the public DNS. > > The two main reasons that carriers will not do that now are: > > 1. They don't want to publish details of the endpoints publicly and have any idiot attempt to connect to them, even if those endpoints are on private networks and unreachable from the Internet. > > 2. They want to have bilateral interconnection agreements that are entirely private between the two parties with others not even knowing of their existence. > > > The only way to achieve those two goals is for global carrier enum to be implemented as an e2md tree not an e2u tree: > > - each carrier publishes e2md data for the number blocks they are assigned with e2md records that point to virtual endpoints > > - carriers then enter into bilateral agreements and exchange private infrastructure plans, which map virtual endpoints to real endpoints. Each private infrastructure plan a carrier issues bilaterally can be unique if they wish. They can even seed them to detect leakage. > > - if a carrier wishes to allow public interconnection then they can go so far as to publish a public infrastructure plan. > > > To be fair there is a third reason carriers don't want global carrier enum > > 3. they don't wanting people knowing what numbers they have > > but that is being eroded in other ways. Block allocation data is readily available in many countries and ported number data is one step further away. > > > Another way of putting it, which I'm still not sure about but will posit anyway, is that e2u is too direct to deliver on its promise *in public carrier trees* and needs a level of indirection, as provided by e2md, to overcome this. Or better still e2u=private, e2md=public. > > kind regards > Jay > _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From kcartwright@tnsi.com Tue Feb 9 09:05:58 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A74003A7428 for ; Tue, 9 Feb 2010 09:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xkdg4INZkakf for ; Tue, 9 Feb 2010 09:05:57 -0800 (PST) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 552CC3A73A8 for ; Tue, 9 Feb 2010 09:05:57 -0800 (PST) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.40401398; Tue, 09 Feb 2010 12:06:39 -0500 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Tue, 9 Feb 2010 12:06:39 -0500 From: "Cartwright, Kenneth" To: Richard Shockey , 'Paul Kyzivat' , 'Jay Daley' Date: Tue, 9 Feb 2010 12:06:38 -0500 Thread-Topic: [e2md] Request for input on market need evidence for E2MD Thread-Index: Acqpl/dwlKHIf3sOT0aHSXcVyY9tvwAAc7AwAAI5/pw= Message-ID: <754963199212404AB8E9CFCA6C3D0CDA0D873D9DB5@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4B717771.9050705@cisco.com>,<009001caa99a$64147340$2c3d59c0$@us> In-Reply-To: <009001caa99a$64147340$2c3d59c0$@us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Bernie Hoeneisen' , discussion list' , 'E.164 Subject: Re: [e2md] Request for input on market need evidence for E2MD X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 17:05:58 -0000 Right. E2MD should not be viewed as a solution designed to adress some con= cerns about public vs private of E2U data. imo, both E2U and E2M(D) protoc= ols can be / are being used in either "private" or "public" installations. = iow, I do not think that the use of E2M(D) is more or less likely to be us= ed in "public" or "private" installations than E2U. So I do not underestan= d how/why E2M(D) is thought to address concerns related to private data bei= ng visible to the public. We need to be careful to *not* have E2M(D) do th= e things that E2U should be doing. iow, if some improvements in the data a= ccess/visibility controls, or improvements to the way that AORs or SBCs are= identified, which is what I hear when I read Paul's email, then we are pot= entially doing things that should perhaps be covered within E2U instead. Ken ________________________________________ From: e2md-bounces@ietf.org [e2md-bounces@ietf.org] On Behalf Of Richard Sh= ockey [richard@shockey.us] Sent: Tuesday, February 09, 2010 10:13 AM To: 'Paul Kyzivat'; 'Jay Daley' Cc: 'Bernie Hoeneisen'; 'E.164 To MetaData BOF discussion list' Subject: Re: [e2md] Request for input on market need evidence for E2MD But Paul this has nothing to do with Public ENUM. It has everything to do with Private instantiations of ENUM and the use of RFC 3761 to cache phone number data locally in carrier networks. The IP Service Control Point so to speak. SIP redirect is not a good vehicle for PSTN metadata and that is the market this proposal addresses. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Pau= l Kyzivat Sent: Tuesday, February 09, 2010 9:56 AM To: Jay Daley Cc: Bernie Hoeneisen; E.164 To MetaData BOF discussion list Subject: Re: [e2md] Request for input on market need evidence for E2MD Can I paraphrase this as: The PUBLIC Carriers don't want the PUBLIC to have information about PUBLIC phone numbers, because that information is PRIVATE. ??? Jay Daley wrote: > On 9/02/2010, at 9:46 AM, Bernie Hoeneisen wrote: > >> So, please send your needs, use cases, requirements, implementation intentions, experiences or whatever helps demonstrating the market need for E2MD to this mailing list now! > > > e2md is an absolute requirement if we are ever to achieve global carrier enum in the public DNS. > > The two main reasons that carriers will not do that now are: > > 1. They don't want to publish details of the endpoints publicly and have any idiot attempt to connect to them, even if those endpoints are on privat= e networks and unreachable from the Internet. > > 2. They want to have bilateral interconnection agreements that are entirely private between the two parties with others not even knowing of their existence. > > > The only way to achieve those two goals is for global carrier enum to be implemented as an e2md tree not an e2u tree: > > - each carrier publishes e2md data for the number blocks they are assigne= d with e2md records that point to virtual endpoints > > - carriers then enter into bilateral agreements and exchange private infrastructure plans, which map virtual endpoints to real endpoints. Each private infrastructure plan a carrier issues bilaterally can be unique if they wish. They can even seed them to detect leakage. > > - if a carrier wishes to allow public interconnection then they can go so far as to publish a public infrastructure plan. > > > To be fair there is a third reason carriers don't want global carrier enu= m > > 3. they don't wanting people knowing what numbers they have > > but that is being eroded in other ways. Block allocation data is readily available in many countries and ported number data is one step further away= . > > > Another way of putting it, which I'm still not sure about but will posit anyway, is that e2u is too direct to deliver on its promise *in public carrier trees* and needs a level of indirection, as provided by e2md, to overcome this. Or better still e2u=3Dprivate, e2md=3Dpublic. > > kind regards > Jay > _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From bernie@ietf.hoeneisen.ch Sat Feb 20 08:51:06 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5310A3A8184 for ; Sat, 20 Feb 2010 08:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6DDg4GLpjgx for ; Sat, 20 Feb 2010 08:51:05 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 6F22D3A7DE4 for ; Sat, 20 Feb 2010 08:51:05 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NisZa-0005pZ-MH for e2md@ietf.org; Sat, 20 Feb 2010 17:52:54 +0100 Date: Sat, 20 Feb 2010 17:52:54 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "E.164 To MetaData BOF discussion list" Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Subject: [e2md] Summary of Use Cases X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2010 16:51:06 -0000 Dear e2md list, After soliciting input on market need evidence for e2md, I can provide you with a list of use cases to be considered for e2md: Legacy use cases: - cnam - unused/void - send-n Penn Pfautz - information for routing decisions based on certain characteristics associated with a number Kenneth Cartwright - Payment Type: PrePaid | PostPaid - Network Type: TDMA | GSM - Region Code: A numeric value indicating a region within a country. - Service Provider Name: The name of the current service provider. - SPID: A string of characters identifying the current service provider. And some other thoughts that have crossed my mind (for illustrative purposes only as I have not verified the usefulness of the following use cases): - Charging information (useful for premium rate numbers) - Assignee address information for premium rate numbers (abuse, complaints) - Number Portability information (partly overlaps with Service Provider Name, SPID and an existing Enumservice) - Service hours for a certain numbers - Location Information - PSAP (Public Safety Answering Point) associated with a fixed phone number (depending on the content this might be an ENUM use case instead) These are 15 (potential) use cases! Did I forget anything? Please drop a note to this list, in case you know about more use cases. Thanks a lot to those of you who answered my request! cheers, Bernie From richard@shockey.us Sat Feb 20 12:22:19 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9E13A8268 for ; Sat, 20 Feb 2010 12:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzzBhKe8hMCW for ; Sat, 20 Feb 2010 12:22:16 -0800 (PST) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 0A7343A8261 for ; Sat, 20 Feb 2010 12:22:16 -0800 (PST) Received: (qmail 17903 invoked by uid 0); 20 Feb 2010 19:57:28 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 20 Feb 2010 19:57:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=nD7MrP0TWAWrzWqbVPcorbocM4cbVLnp7GlK8ZMCJL2Sz40VHtoPyTUt7nDtbDFxSEFCNTyzpsopN/U7Uo+SVk8DcJckmtqvR5mnaIZbrNrAglaKMkARyEB2klNkgAZ1; Received: from pool-96-241-62-33.washdc.fios.verizon.net ([96.241.62.33] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NivSB-0007tq-Ph; Sat, 20 Feb 2010 12:57:28 -0700 From: "Richard Shockey" To: "'Bernie Hoeneisen'" , "'E.164 To MetaData BOF discussion list'" References: In-Reply-To: Date: Sat, 20 Feb 2010 14:57:24 -0500 Message-ID: <003c01cab266$ec61c840$c52558c0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqyTSgwGF/4l9DBSwa4B6TEfGzp+QAFhDuw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.62.33 authed with richard@shockey.us} Cc: drinks@ietf.org, enum@ietf.org Subject: Re: [e2md] Summary of Use Cases X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2010 20:22:19 -0000 SPID and CNAM right now are the poster childs for E2M ..or SPN ( Service Provider Network ) aka TN to Operator in modern ITU SG2 terms. DRINKS has a liaison from ITU-T specifically asking that fields for this code be reserved in any provisioning protocol developed by DRINKS. It's currently the principal result of LUF in numerous private commercial ENUM applications though it does not fully address the use case for MVNO's where some form alt-SPID is required as well to distinguish between the retail service provider and the underlying network operator. In ENUM terms this means that the result of the LUF is not the end point destination or transit network gateway but only the portability corrected operator of record based on authoritative national numbering databases. The data associated with the LRF is then presumed to be a private data exchange between bilateral transit partners and is the result of the E2M translation is performed by a secondary step. All of these parameters are used in private closed carrier ENUM applications for SMS MMS and Voice routing or in SIP location look ups, though how SIP deals with metadata is IMHO a long standing issue and is another WG in and of itself. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Bernie Hoeneisen Sent: Saturday, February 20, 2010 11:53 AM To: E.164 To MetaData BOF discussion list Subject: [e2md] Summary of Use Cases Dear e2md list, After soliciting input on market need evidence for e2md, I can provide you with a list of use cases to be considered for e2md: Legacy use cases: - cnam - unused/void - send-n Penn Pfautz - information for routing decisions based on certain characteristics associated with a number Kenneth Cartwright - Payment Type: PrePaid | PostPaid - Network Type: TDMA | GSM - Region Code: A numeric value indicating a region within a country. - Service Provider Name: The name of the current service provider. - SPID: A string of characters identifying the current service provider. And some other thoughts that have crossed my mind (for illustrative purposes only as I have not verified the usefulness of the following use cases): - Charging information (useful for premium rate numbers) - Assignee address information for premium rate numbers (abuse, complaints) - Number Portability information (partly overlaps with Service Provider Name, SPID and an existing Enumservice) - Service hours for a certain numbers - Location Information - PSAP (Public Safety Answering Point) associated with a fixed phone number (depending on the content this might be an ENUM use case instead) These are 15 (potential) use cases! Did I forget anything? Please drop a note to this list, in case you know about more use cases. Thanks a lot to those of you who answered my request! cheers, Bernie _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From bernie@ietf.hoeneisen.ch Wed Feb 24 05:58:42 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFA3028C162 for ; Wed, 24 Feb 2010 05:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2iRxd9xq9Mc for ; Wed, 24 Feb 2010 05:58:41 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 6B6CD28C148 for ; Wed, 24 Feb 2010 05:58:41 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NkHnC-0003ZO-FT for e2md@ietf.org; Wed, 24 Feb 2010 15:00:46 +0100 Date: Wed, 24 Feb 2010 15:00:46 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "E.164 To MetaData BOF discussion list" Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="37663318-1922192837-1267020046=:10552" X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Subject: [e2md] charter discussion kick-off X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 13:58:42 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --37663318-1922192837-1267020046=:10552 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Hi, After we have collected the use cases, the e2md work continues with the charter. To ensure we have no (unknown) open issues with the charter during the BoF, we kindly ask you to review the proposal for the e2md charter. The latest version can be found on: http://ucom.ch/ietf/e2md-bof/e2md-proposed-charter.txt For your convenience I attached the current version to this email. Please send any feedback, issues and other comments concerning the proposed e2md charter to by the end of this month (Feb 2010). cheers, Bernie -- http://ucom.ch/ Tech Consulting for Internet Standardization --37663318-1922192837-1267020046=:10552 Content-Type: TEXT/plain; name=e2md-proposed-charter.txt Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=e2md-proposed-charter.txt RS4xNjQgdG8gTWV0YURhdGEgKEUyTUQpIChwcm9wb3NlZCBjaGFydGVyKQ0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkxhc3QgTW9kaWZpZWQ6IDIw MTAtMDItMjQNCg0KQWRkaXRpb25hbCBpbmZvcm1hdGlvbiBpcyBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmcvd2cvZTJtZA0KW25vdCB5ZXQgaW4gdXNl XQ0KDQoNCkNoYWlyKHMpOg0KDQogICAgKiBUQkENCg0KUmVhbC10aW1lIEFw cGxpY2F0aW9ucyBhbmQgSW5mcmFzdHJ1Y3R1cmUgQXJlYSBEaXJlY3Rvcihz KToNCg0KICAgICogUm9iZXJ0IFNwYXJrcyA8cmpzcGFya3NAbm9zdHJ1bS5j b20+DQogICAgKiBDdWxsZW4gSmVubmluZ3MgPGZsdWZmeUBjaXNjby5jb20+ DQoNClJlYWwtdGltZSBBcHBsaWNhdGlvbnMgYW5kIEluZnJhc3RydWN0dXJl IEFyZWEgQWR2aXNvcjoNCg0KICAgICogQ3VsbGVuIEplbm5pbmdzIDxmbHVm ZnlAY2lzY28uY29tPg0KDQoNCk1haWxpbmcgTGlzdHM6DQoNCkdlbmVyYWwg RGlzY3Vzc2lvbjogZTJtZEBpZXRmLm9yZw0KTGlzdGluZm86IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZTJtZA0KVG8gU3Vic2Ny aWJlOiBlMm1kLXJlcXVlc3RAaWV0Zi5vcmcNCkluIEJvZHk6IHN1YnNjcmli ZQ0KQXJjaGl2ZTogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL2UybWQvaW5kZXguaHRtbA0KDQoNCg0KRGVzY3JpcHRpb24gb2YgV29y a2luZyBHcm91cDoNCg0KQWJzdHJhY3QNCg0KICAgRS4xNjQgdG8gTWV0YURh dGEgKEUyTUQpIHdpbGwgdXNlIG9mIHRoZSBEb21haW4gTmFtZSBTeXN0ZW0g KEROUykNCiAgIGZvciByZXNvbHZpbmcgRS4xNjQgbnVtYmVycyBpbnRvIG1l dGFkYXRhIHRvIHByb3ZpZGUgaW5mb3JtYXRpb24NCiAgIGFib3V0IEUuMTY0 IG51bWJlcnMgaW4gY2FzZXMgd2hlcmUgRS4xNjQgTnVtYmVyIHRvIFVSSSBN YXBwaW5nDQogICAoRU5VTSkgY2FuIG5vdCBiZSB1c2VkLg0KDQoNCkJhY2tn cm91bmQNCg0KICAgRU5VTSBwcm92aWRlcyBhbiBpZGVudGlmaWVyIG1hcHBp bmcgbWVjaGFuaXNtIHRvIG1hcCBFLjE2NCBudW1iZXJzDQogICB0byBVbmlm b3JtIFJlc291cmNlIElkZW50aWZpZXJzIChVUklzKSB1c2luZyB0aGUgRE5T Lg0KDQogICBUaHVzLCBFTlVNIGNhbiBiZSB1c2VkIHRvIGxvb2sgdXAgdGhl IHNlcnZpY2VzIGFzc29jaWF0ZWQgd2l0aCBhbg0KICAgRS4xNjQgbnVtYmVy LiAgSG93ZXZlciwgaXQgaXMgY29udHJvdmVyc2lhbCB3aGV0aGVyIG9yIG5v dCB0aGUgcmVzdWx0DQogICBvZiBhbiBFTlVNIGxvb2t1cCBzaG91bGQgYWx3 YXlzIGJlIGludGVuZGVkIHRvIGVzdGFibGlzaCBhDQogICBjb21tdW5pY2F0 aW9ucyBzZXNzaW9uIHVzaW5nIHRoZSBVUkkgZm91bmQgaW4gdGhlIGNvcnJl c3BvbmRpbmcNCiAgIE5hbWluZyBBdXRob3JpdHkgUG9pbnRlciAoTkFQVFIp IEROUyBSZXNvdXJjZSBSZWNvcmQgKFJSKS4NCg0KDQpQcm9ibGVtIFN0YXRl bWVudA0KDQogICBTZXZlcmFsIHByb3Bvc2FscyBmb3IgRW51bXNlcnZpY2Ug cmVnaXN0cmF0aW9ucyBkbyBub3QgZnVsZmlsbCB0aGUNCiAgIGFib3ZlIG1l bnRpb25lZCBpbnRlcnByZXRhdGlvbiwgd2hpY2ggc3VnZ2VzdHMgdGhhdCBh biBFTlVNIGxvb2t1cA0KICAgc2hvdWxkIGFsd2F5cyBiZSBpbnRlbmRlZCB0 byByZXN1bHQgaW4gYSBjb21tdW5pY2F0aW9ucyBzZXNzaW9uLg0KICAgVGhl c2UgcHJvcG9zYWxzIGFyZSB0aGVyZWZvcmUgdmlydHVhbGx5IGxvY2tlZCBp biB0aGUgcHJvY2Vzcy4NCiAgIFN1Y2ggcHJvcG9zYWxzIGluY2x1ZGUgKGJ1 dCBhcmUgbm90IGxpbWl0ZWQgdG8pIEVudW1zZXJ2aWNlcyBmb3INCiAgICdj bmFtJyB0byBwcm92aWRlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjYWxsaW5n IHBhcnR5IG5hbWUsDQogICAndW51c2VkJyB0byBwcm92aWRlIGEgaGludCB0 aGF0IGEgbnVtYmVyIGlzIG5vdCBpbiB1c2UsIGFuZA0KICAgJ3NlbmQtbicg dG8gZGVzY3JpYmUgdGhlIHN0cnVjdHVyZSBvZiBhbiBFTlVNIHRyZWUuDQoN CiAgIEFub3RoZXIgaXNzdWUgaXMgdGhhdCB0aGUgcmVzdWx0IG9mIGFuIEVO VU0gKEUyVSkgbG9va3VwIGFsd2F5cw0KICAgbmVlZHMgdG8gYmUgYW4gVVJJ LCB3aGljaCB1bm5lY2Vzc2FyaWx5IGNvbXBsaWNhdGVzIHNpbXBsZSBtYXBw aW5ncy4NCg0KICAgVGhlIGF1dGhvcnMgb2Ygc3VjaCBFbnVtc2VydmljZSBw cm9wb3NhbHMgdHJpZWQgdG8gY2lyY3VtdmVudCB0aGUNCiAgIGlzc3VlcyBi eSBpbnRyb2R1Y2luZyB0aGUgJ2RhdGEnIFVSSSBzY2hlbWUgb3IgaW52ZW50 aW5nIGNvbXBsZXRlbHkNCiAgIG5ldyBVUkkgc2NoZW1lcywgd2l0aCBsaW1p dGVkIHN1Y2Nlc3MgaG93ZXZlci4gIFRoZSBtYWluIG9iamVjdGlvbg0KICAg cmVtYWluZWQgdGhhdCBhbiBFTlVNIGxvb2t1cCBzaG91bGQgYWx3YXlzIHJl c3VsdCBpbiBhIFVSSSBpbnRlbmRlZA0KICAgdG8gZXN0YWJsaXNoIGEgY29t bXVuaWNhdGlvbnMgc2Vzc2lvbi4NCg0KUHJvcG9zYWwNCg0KICAgVGhlIEUy TUQgV29ya2luZyBHcm91cCBpcyBjaGFydGVyZWQgdG8gZGV2ZWxvcCBhIG5l dyBEeW5hbWljDQogICBEZWxlZ2F0aW9uIERpc2NvdmVyeSBTeXN0ZW0gKERE RFMpIGFwcGxpY2F0aW9uIEUyTUQsIHdoaWNoIGNhbiBiZQ0KICAgdXNlZCB3 aXRoIEROUyBOQVBUUiBSUnMgZm9yIHJlc29sdmluZyBFLjE2NCBudW1iZXJz IGludG8gbWV0YWRhdGEuDQogICBUaGUgcmVzdWx0aW5nIG1ldGFkYXRhIGNh biBiZSB1c2VkIChmb3IgZXhhbXBsZSkgdG8gcHJvdmlkZSBoaW50cw0KICAg YWJvdXQgcHJvcGVydGllcyBvZiBjZXJ0YWluIEVOVU0gZG9tYWlucyBvciB0 byBwcm92aWRlIGluZm9ybWF0aW9uDQogICB0aGF0IGNhbiBiZSB1c2VkIGFz IGF0dHJpYnV0ZXMgb2YgYW4gRS4xNjQgbnVtYmVyLg0KDQogICBFMk1EIHdp bGwgcHJvdmlkZSB0aGUgbWVhbnMgZm9yIHNlcnZpY2VzIHJlbGF0ZWQgdG8g RS4xNjQgbnVtYmVycw0KICAgdGhhdCBkbyBub3QgZml0IGludG8gdGhlIGNv bmNlcHQgb2YgRU5VTSAoRTJVKSwgYW5kIHRodXMgYQ0KICAgd2F5IGZvcndh cmQgZm9yIHN1Y2ggZXhpc3RpbmcgRU5VTSBXRyBkb2N1bWVudHMgaW4gdGhl IHF1ZXVlLg0KDQogICBBbG9uZyB3aXRoIHRoZSBFMk1EIERERFMgYXBwbGlj YXRpb24gYSBuZXcgSUFOQSByZWdpc3RyeSB3aWxsIGJlDQogICBzcGVjaWZp ZWQgZm9yIHJlZ2lzdHJhdGlvbiBvZiBFMk1EIHNlcnZpY2VzLiBUaGUgcmVn aXN0cmF0aW9uIHBvbGljeQ0KICAgc2hhbGwgYmUgRXhwZXJ0IFJldmlldyBh bmQgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCAoc2VlIFJGQyA1MjI2KSwNCiAg IHNpbWlsYXJseSBhcyBzcGVjaWZpZWQgZm9yIEVudW1zZXJ2aWNlIHJlZ2lz dHJhdGlvbnMuDQoNCiAgIFRoZSBFMk1EIHNwZWNpZmljYXRpb25zIHNoYWxs IHJldXNlIGEgbXVjaCBhcyBwb3NzaWJsZSBmcm9tIHRoZSBFTlVNDQogICBE RERTIGFuZCBpdHMgSUFOQSByZWdpc3RyeSBzcGVjaWZpY2F0aW9uLg0KDQog ICBUaGUgRTJNRCBXb3JraW5nIEdyb3VwIG1heSB0YWtlIG9uIGZ1cnRoZXIg cHJvcG9zYWxzIGZvciBFMk1EIHNlcnZpY2UNCiAgIHJlZ2lzdHJhdGlvbnMg KGUuZy4gc2VuZC1uKSB1bnRpbCB0aGUgSUFOQSByZWdpc3RyYXRpb24gZm9y IEUyTUQNCiAgIHNlcnZpY2VzIGlzIGFwcHJvdmVkIGJ5IHRoZSBJRVNHLg0K DQoNCk91dC1PZi1TY29wZQ0KDQogICBFMk1EIHNoYWxsIG5vdCBiZSBzcGVj aWZpZWQgYXMgYSBnZW5lcmFsIHB1cnBvc2UgbG9va3VwIG5vciBhcyBidWxr DQogICB0cmFuc2ZlciBwcm90b2NvbCwgYnV0IHJhdGhlciBmb2N1cyBvbiBj bGVhciB1c2UgY2FzZXMgcmVsYXRlZCB0bw0KICAgRS4xNjQgbnVtYmVycy4N Cg0KDQpHb2FscyBhbmQgTWlsZXN0b25lczoNCg0KICAgQXVnIDIwMTAgIFN1 Ym1pdCBJbnRlcm5ldCBEcmFmdChzKSBmb3IgdGhlIEUyTUQgREREUyBhcHBs aWNhdGlvbiBhbmQNCiAgICAgICAgICAgICBpdHMgSUFOQSByZWdpc3RyeSBz cGVjaWZpY2F0aW9uDQoNCiAgIERlYyAyMDEwICBTdWJtaXQgJ2NuYW0nIGFu ZCAndW51c2VkJyBhcyBFMk1EIHNlcnZpY2UgcmVnaXN0cmF0aW9ucw0KICAg ICAgICAgICAgIChJbmZvcm1hdGlvbmFsKQ0KDQogICBYWFggMjAxMSAgQ2xv c2UgdGhlIEUyTUQgV29ya2luZyBHcm91cCAob3IgcmVjaGFydGVyKQ0KDQoN CkludGVybmV0LURyYWZ0czoNCg0KICAgaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaG9lbmVpc2VuLWUxNjQtdG8tbWV0YWRhdGEtMDINCiAg IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZW51bS11 bnVzZWQtMDQNCiAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtZW51bS1jbmFtLTA4DQogICAoaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtYmVsbGlzLWVudW0tc2VuZC1uLTAyKQ0KDQoNClJlcXVl c3QgRm9yIENvbW1lbnRzOg0KDQogICBOb25lDQoNCg== --37663318-1922192837-1267020046=:10552-- From A.Hoenes@TR-Sys.de Wed Feb 24 09:08:37 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DC7628C0EB for ; Wed, 24 Feb 2010 09:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.395 X-Spam-Level: * X-Spam-Status: No, score=1.395 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8RiDyIET5ka for ; Wed, 24 Feb 2010 09:08:36 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 282E43A8544 for ; Wed, 24 Feb 2010 09:08:34 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA180361388; Wed, 24 Feb 2010 18:09:48 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA03246; Wed, 24 Feb 2010 18:09:46 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201002241709.SAA03246@TR-Sys.de> To: bernie@ietf.hoeneisen.ch Date: Wed, 24 Feb 2010 18:09:45 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 24 Feb 2010 09:56:06 -0800 Cc: e2md@ietf.org Subject: Re: [e2md] [DNSOP] charter discussion kick-off (fwd) X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 17:08:37 -0000 Bernie, thanks for the heads-up on DNSOP. As you know, I already had reviewed (at least once) all the drafts listed on the draft E2MD charter, most recently the -01 version of your e164-to-metadata draft. The idea to split off properly unrelated stuff from ENUM makes much sense, from a DNS perspective as well, but it should perhaps be followed one step farther than your draft proposal would take us: The utility of NAPTR RRs suffers from the existence of an 'internal' selector (the service field), so they cannot be selected specifically by a DNS query -- unless the owner names are different (cf. RFC 5507). This has unfortunate consequences on the DNS response message size with all the consequences currently discussed in DNSEXT and elsewhere (due to similar pressure on response message size arising from increasing deployment of DNSSEC). Of course, this feature of NAPTR RRs has benefits as well -- it allows the client to obtain with one query "all that's out there", and make the local selection of the entries best matching its local requirements afterwards (and then try differents paths of service location and access until success). However, the general purpose of the lookup should remain confined for not running too rapidly into DNS response truncation or IP fragmentation issues, and so the splitoff of E2MD from ENUM makes perfect sense from the DNS operational perspective. The proposal creates a new DDDS application, and it seems good practice to separate the DNS namespaces of different DDDS applications. Therefore, it should be seriously considered to define a naming convention for E2MD records that keeps ENUM and E2MD NAPTR RRs in different RRsets. One possibility to do that would be to prefix the 'canonical' ENUM owner names with a specific 'undersore label' (for instance, "_E2MD"); other possibilities to 'splice' the DNS naming tree higher up in the tree seem inappropriate due to subdomain delegation and management concerns. Only clients specifically interested in E2MD NAPTRs would thus look them up and get them; if necessary, E2MD and ENUM NAPTRs could be looked up concurrently, thus giving comparable response performance as in a the combined case (unless the aforementioned size limitations start to hit). The general text of the draft charter seems reasonable, but it might make sense to add a short note indicating the DNS protocol considerations (as sketched above) and tasking the WG specifically to take these into account. A few nits: - "Proposal", 4th para: s/reuse a much as possible/reuse as much as possible/ ^ ^^ - "Goals and Milestones": "submit" is ambiguous; you might better use "Submit to the IESG" or "Request publication of". Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From Ray.Bellis@nominet.org.uk Thu Feb 25 00:28:59 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6EE728C2D2 for ; Thu, 25 Feb 2010 00:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.248 X-Spam-Level: X-Spam-Status: No, score=-5.248 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ub8L16QGNDba for ; Thu, 25 Feb 2010 00:28:58 -0800 (PST) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 4B7C728C2CB for ; Thu, 25 Feb 2010 00:28:57 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=NVm8vAK+VgHhZqrVgq1Mv7K38CVZysUzONucK1aoqK8ah268M2z8aDKy js/dHrY40OITtf2Od84m9w/DWw7YXdYhZAUqu9MaloWqs2xIgjiFHyJ1H +1U93WU0w2GfcZ5; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1267086668; x=1298622668; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20charter=20discussion=20kick-off=20(fwd)|Date:=20Thu, =2025=20Feb=202010=2008:31:05=20+0000|Message-ID:=20|To:=20Alfred=20=3D?ISO-8859-1?Q?H=3DF6nes? =3D=20|Cc:=20e2md@ietf.org|MIME-Version:=20 1.0|In-Reply-To:=20<201002241709.SAA03246@TR-Sys.de> |References:=20<201002241709.SAA03246@TR-Sys.de>; bh=8813gpDyBwo7FvwK0CvW3en17u0ZuS/7kgLRzEDnlGI=; b=qLPn8EztUC0nk+gCD+NGcEPL5AfDybsHCoMwwSLMF5hgt7hT7jCZVyMt g9e0PkVEvnf90dxD4y/7JCbQk8lBn0eQExW7ZF3B91y0j9m++X71OwC4+ VS57wqY0IUAQPR7; X-IronPort-AV: E=Sophos;i="4.49,537,1262563200"; d="scan'208";a="16576813" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 25 Feb 2010 08:31:06 +0000 In-Reply-To: <201002241709.SAA03246@TR-Sys.de> References: <201002241709.SAA03246@TR-Sys.de> To: Alfred =?ISO-8859-1?Q?H=F6nes?= MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 25 Feb 2010 08:31:05 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 25/02/2010 08:31:06 AM, Serialize complete at 25/02/2010 08:31:06 AM Content-Type: multipart/alternative; boundary="=_alternative 002ECA99802576D5_=" Cc: e2md@ietf.org Subject: Re: [e2md] charter discussion kick-off (fwd) X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 08:28:59 -0000 This is a multipart message in MIME format. --=_alternative 002ECA99802576D5_= Content-Type: text/plain; charset="US-ASCII" > Therefore, it should be seriously considered to define a naming > convention for E2MD records that keeps ENUM and E2MD NAPTR RRs > in different RRsets. One possibility to do that would be to > prefix the 'canonical' ENUM owner names with a specific > 'undersore label' (for instance, "_E2MD"); other possibilities > to 'splice' the DNS naming tree higher up in the tree seem > inappropriate due to subdomain delegation and management concerns. > > Only clients specifically interested in E2MD NAPTRs would thus look > them up and get them; if necessary, E2MD and ENUM NAPTRs could be > looked up concurrently, thus giving comparable response performance > as in a the combined case (unless the aforementioned size > limitations start to hit). There are also good reasons _not_ to do this. With my Send-N draft, for example, it's specifically intended that those results be returned _instead_ of normal E2U records when querying for nodes that are not leaf nodes. The whole point with Send-N is that the client has no prior knowledge of which to expect[*] and the results of Send-N give a hint to the client of how many more digits must be dialled before leaf nodes might be found. Ray [*] technically these would be two separate DDDS applications, so the actual DDDS algorithm should be run twice, but ideally the DNS only queried once. --=_alternative 002ECA99802576D5_= Content-Type: text/html; charset="US-ASCII"
> Therefore, it should be seriously considered to define a naming
> convention for E2MD records that keeps ENUM and E2MD NAPTR RRs
> in different RRsets.  One possibility to do that would be to
> prefix the 'canonical' ENUM owner names with a specific
> 'undersore label' (for instance, "_E2MD"); other possibilities
> to 'splice' the DNS naming tree higher up in the tree seem
> inappropriate due to subdomain delegation and management concerns.
>
> Only clients specifically interested in E2MD NAPTRs would thus look
> them up and get them; if necessary, E2MD and ENUM NAPTRs could be
> looked up concurrently, thus giving comparable response performance
> as in a the combined case (unless the aforementioned size
> limitations start to hit).
There are also good reasons _not_ to do this.

With my Send-N draft, for example, it's specifically intended that those results be returned _instead_ of normal E2U records when querying for nodes that are not leaf nodes.  The whole point with Send-N is that the client has no prior knowledge of which to expect[*] and the results of Send-N give a hint to the client of how many more digits must be dialled before leaf nodes might be found.

Ray

[*] technically these would be two separate DDDS applications, so the actual DDDS algorithm should be run twice, but ideally the DNS only queried once.


--=_alternative 002ECA99802576D5_=-- From A.Hoenes@TR-Sys.de Thu Feb 25 05:36:29 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AFDE28C0F2 for ; Thu, 25 Feb 2010 05:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.42 X-Spam-Level: * X-Spam-Status: No, score=1.42 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ml5A9F0X2+SY for ; Thu, 25 Feb 2010 05:36:28 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id DC5963A8491 for ; Thu, 25 Feb 2010 05:36:27 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA185965098; Thu, 25 Feb 2010 14:38:18 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id OAA06181; Thu, 25 Feb 2010 14:38:16 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201002251338.OAA06181@TR-Sys.de> To: Ray.Bellis@nominet.org.uk Date: Thu, 25 Feb 2010 14:38:16 +0100 (MEZ) In-Reply-To: from "Ray.Bellis@nominet.org.uk" at Feb "25, " 2010 "08:31:05" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: e2md@ietf.org Subject: Re: [e2md] charter discussion kick-off (fwd) X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 13:36:29 -0000 In response to my DNS related arguments, Ray Bellis wrote: >> Therefore, it should be seriously considered to define a naming >> convention for E2MD records that keeps ENUM and E2MD NAPTR RRs >> in different RRsets. One possibility to do that would be to >> prefix the 'canonical' ENUM owner names with a specific >> 'undersore label' (for instance, "_E2MD"); other possibilities >> to 'splice' the DNS naming tree higher up in the tree seem >> inappropriate due to subdomain delegation and management concerns. >> >> Only clients specifically interested in E2MD NAPTRs would thus look >> them up and get them; if necessary, E2MD and ENUM NAPTRs could be >> looked up concurrently, thus giving comparable response performance >> as in a the combined case (unless the aforementioned size >> limitations start to hit). > > There are also good reasons _not_ to do this. > > With my Send-N draft, for example, it's specifically intended that those > results be returned _instead_ of normal E2U records when querying for > nodes that are not leaf nodes. The whole point with Send-N is that the > client has no prior knowledge of which to expect[*] and the results of > Send-N give a hint to the client of how many more digits must be dialled > before leaf nodes might be found. Agreed, that's another argument. Upon solicitation, I gave a DNS perspective, and I did not say that those argument should win; I said they (and RFC 5507) need to be _considered_ seriously, and having that layer-8 requirement in the charter might be a good idea: >> The general text of the draft charter seems reasonable, but it >> might make sense to add a short note indicating the DNS protocol >> considerations (as sketched above) and tasking the WG specifically >> to take these into account. > Ray > > [*] technically these would be two separate DDDS applications, so the > actual DDDS algorithm should be run twice, but ideally the DNS only > queried once. (Local DNS caching actually should do the former job for you.) Kind regards, Alfred. From bernie@ietf.hoeneisen.ch Thu Feb 25 06:35:24 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E302B28C18D for ; Thu, 25 Feb 2010 06:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H253SN54n7fH for ; Thu, 25 Feb 2010 06:35:24 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id EB40628C141 for ; Thu, 25 Feb 2010 06:35:23 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NkeqJ-0000jq-SL; Thu, 25 Feb 2010 15:37:31 +0100 Date: Thu, 25 Feb 2010 15:37:31 +0100 (CET) From: bernie@ietf.hoeneisen.ch X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Alfred H?nes In-Reply-To: <201002241709.SAA03246@TR-Sys.de> Message-ID: References: <201002241709.SAA03246@TR-Sys.de> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] [DNSOP] charter discussion kick-off (fwd) X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 14:35:25 -0000 Hi Alfred Thanks for your thoughts on this. As you might remember, the DNS packet size limitation issue was being discussed earlier in ENUM. There was a heavy debate on whether or not EDNS0 should be compulsary for DNS servers running ENUM. AFAICR there was no consensus to make this a requirement. That might be seen differently nowadays. As you know there is a similar debate now in DNSEXT in the context of DNSsec: Mandating TCP with EDNS0 and friends... I am not sure whether this issue should be solved on application layer. I am actually hoping (rather sooner than later) the DNS can cope with this problem (at the source of it)... [ I vote for SCTP... :-) ] However, we could add a such requirement to the E2MD charter. How about something along the lines of: "Limitations of the DNS (e.g. packet size) are to be considered while defining the protocol." cheers, Bernie On Wed, 24 Feb 2010, Alfred H?nes wrote: > Bernie, > thanks for the heads-up on DNSOP. > > As you know, I already had reviewed (at least once) all the drafts > listed on the draft E2MD charter, most recently the -01 version > of your e164-to-metadata draft. > > The idea to split off properly unrelated stuff from ENUM makes > much sense, from a DNS perspective as well, but it should perhaps > be followed one step farther than your draft proposal would take us: > The utility of NAPTR RRs suffers from the existence of an 'internal' > selector (the service field), so they cannot be selected specifically > by a DNS query -- unless the owner names are different (cf. RFC 5507). > This has unfortunate consequences on the DNS response message size > with all the consequences currently discussed in DNSEXT and elsewhere > (due to similar pressure on response message size arising from > increasing deployment of DNSSEC). > Of course, this feature of NAPTR RRs has benefits as well -- it > allows the client to obtain with one query "all that's out there", > and make the local selection of the entries best matching its local > requirements afterwards (and then try differents paths of service > location and access until success). > However, the general purpose of the lookup should remain confined > for not running too rapidly into DNS response truncation or IP > fragmentation issues, and so the splitoff of E2MD from ENUM makes > perfect sense from the DNS operational perspective. > The proposal creates a new DDDS application, and it seems good practice > to separate the DNS namespaces of different DDDS applications. > Therefore, it should be seriously considered to define a naming > convention for E2MD records that keeps ENUM and E2MD NAPTR RRs > in different RRsets. One possibility to do that would be to > prefix the 'canonical' ENUM owner names with a specific > 'undersore label' (for instance, "_E2MD"); other possibilities > to 'splice' the DNS naming tree higher up in the tree seem > inappropriate due to subdomain delegation and management concerns. > > Only clients specifically interested in E2MD NAPTRs would thus look > them up and get them; if necessary, E2MD and ENUM NAPTRs could be > looked up concurrently, thus giving comparable response performance > as in a the combined case (unless the aforementioned size > limitations start to hit). > > > The general text of the draft charter seems reasonable, but it > might make sense to add a short note indicating the DNS protocol > considerations (as sketched above) and tasking the WG specifically > to take these into account. > > > A few nits: > > - "Proposal", 4th para: > s/reuse a much as possible/reuse as much as possible/ > ^ ^^ > - "Goals and Milestones": "submit" is ambiguous; you might better > use "Submit to the IESG" or "Request publication of". > > > Kind regards, > Alfred H?nes. > > -- > > +------------------------+--------------------------------------------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | > | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | > +------------------------+--------------------------------------------+ > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From lconroy@insensate.co.uk Thu Feb 25 09:50:20 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DB383A86EA for ; Thu, 25 Feb 2010 09:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Agf6rnQqYwXE for ; Thu, 25 Feb 2010 09:50:19 -0800 (PST) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 6B0FF3A84FE for ; Thu, 25 Feb 2010 09:50:15 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 46B4A10FA56; Thu, 25 Feb 2010 17:52:25 +0000 (GMT) References: <201002241709.SAA03246@TR-Sys.de> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: <098A3F1D-3A1A-4BF8-9553-7A01C7BB5FB2@insensate.co.uk> Content-Transfer-Encoding: quoted-printable From: Lawrence Conroy Date: Thu, 25 Feb 2010 17:52:24 +0000 To: bernie@ietf.hoeneisen.ch X-Mailer: Apple Mail (2.1077) Cc: Alfred H?nes , "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] [DNSOP] charter discussion kick-off (fwd) X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 17:50:20 -0000 Hi Bernie, Alfred, folks, Strictly, we DID work on the EDN0-unaware size limitations. Jim Reid and I produced a Draft back in 2006 -- Alfred mailed me in 2007 on this to suggest that fragment support could be an issue :). AFAICT, we were told by our AD that this is a general issue, so it would await a DNSEXT or DNSOP draft; fair enough. This is always going to be tricky, but maybe we could list the assumptions we make on typical RRSet sizes? Anything more may well be a waste. There were versions of "the Experiences draft" (a.k.a. RFC 5483) that had such values, and "Experiences" DID include the "SHOULD support EDNS0" text at one point. These were removed later on in the process -- in favour first of a separate doc, and then it was stopped, as DNSEXT was going to produce the definitive doc. It's not just EDNS0, of course; people are free to provision RRSets that will go over typically advertised ENDS0 buffer sizes, so TCP is normally a MUST. I note that nampedroppers has been active there as well :). all the best, Lawrence On 25 Feb 2010, at 14:37, bernie@ietf.hoeneisen.ch wrote: > Hi Alfred >=20 > Thanks for your thoughts on this. >=20 > As you might remember, the DNS packet size limitation issue was being = discussed earlier in ENUM. There was a heavy debate on whether or not = EDNS0 should be compulsary for DNS servers running ENUM. AFAICR there = was no consensus to make this a requirement. That might be seen = differently nowadays. As you know there is a similar debate now in = DNSEXT in the context of DNSsec: Mandating TCP with EDNS0 and friends... >=20 > I am not sure whether this issue should be solved on application = layer. I am actually hoping (rather sooner than later) the DNS can cope = with this problem (at the source of it)... [ I vote for SCTP... :-) ] >=20 > However, we could add a such requirement to the E2MD charter. > How about something along the lines of: >=20 > "Limitations of the DNS (e.g. packet size) are to be considered while > defining the protocol." >=20 > cheers, > Bernie >=20 >=20 >=20 > On Wed, 24 Feb 2010, Alfred H?nes wrote: >=20 >> Bernie, >> thanks for the heads-up on DNSOP. >>=20 >> As you know, I already had reviewed (at least once) all the drafts >> listed on the draft E2MD charter, most recently the -01 version >> of your e164-to-metadata draft. >>=20 >> The idea to split off properly unrelated stuff from ENUM makes >> much sense, from a DNS perspective as well, but it should perhaps >> be followed one step farther than your draft proposal would take us: >> The utility of NAPTR RRs suffers from the existence of an 'internal' >> selector (the service field), so they cannot be selected specifically >> by a DNS query -- unless the owner names are different (cf. RFC = 5507). >> This has unfortunate consequences on the DNS response message size >> with all the consequences currently discussed in DNSEXT and elsewhere >> (due to similar pressure on response message size arising from >> increasing deployment of DNSSEC). >> Of course, this feature of NAPTR RRs has benefits as well -- it >> allows the client to obtain with one query "all that's out there", >> and make the local selection of the entries best matching its local >> requirements afterwards (and then try differents paths of service >> location and access until success). >> However, the general purpose of the lookup should remain confined >> for not running too rapidly into DNS response truncation or IP >> fragmentation issues, and so the splitoff of E2MD from ENUM makes >> perfect sense from the DNS operational perspective. >> The proposal creates a new DDDS application, and it seems good = practice >> to separate the DNS namespaces of different DDDS applications. >> Therefore, it should be seriously considered to define a naming >> convention for E2MD records that keeps ENUM and E2MD NAPTR RRs >> in different RRsets. One possibility to do that would be to >> prefix the 'canonical' ENUM owner names with a specific >> 'undersore label' (for instance, "_E2MD"); other possibilities >> to 'splice' the DNS naming tree higher up in the tree seem >> inappropriate due to subdomain delegation and management concerns. >>=20 >> Only clients specifically interested in E2MD NAPTRs would thus look >> them up and get them; if necessary, E2MD and ENUM NAPTRs could be >> looked up concurrently, thus giving comparable response performance >> as in a the combined case (unless the aforementioned size >> limitations start to hit). >>=20 >>=20 >> The general text of the draft charter seems reasonable, but it >> might make sense to add a short note indicating the DNS protocol >> considerations (as sketched above) and tasking the WG specifically >> to take these into account. >>=20 >>=20 >> A few nits: >>=20 >> - "Proposal", 4th para: >> s/reuse a much as possible/reuse as much as possible/ >> ^ ^^ >> - "Goals and Milestones": "submit" is ambiguous; you might better >> use "Submit to the IESG" or "Request publication of". >>=20 >>=20 >> Kind regards, >> Alfred H?nes. >>=20 >> --=20 >>=20 >> = +------------------------+--------------------------------------------+ >> | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. = | >> | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 = | >> | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de = | >> = +------------------------+--------------------------------------------+ >>=20 >> _______________________________________________ >> e2md mailing list >> e2md@ietf.org >> https://www.ietf.org/mailman/listinfo/e2md > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From A.Hoenes@TR-Sys.de Thu Feb 25 13:59:02 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE70428C451 for ; Thu, 25 Feb 2010 13:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.412 X-Spam-Level: * X-Spam-Status: No, score=1.412 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehot2sTe4obY for ; Thu, 25 Feb 2010 13:59:00 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 035BE28C435 for ; Thu, 25 Feb 2010 13:58:58 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA188785250; Thu, 25 Feb 2010 23:00:50 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id XAA07138; Thu, 25 Feb 2010 23:00:49 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201002252200.XAA07138@TR-Sys.de> To: bernie@ietf.hoeneisen.ch Date: Thu, 25 Feb 2010 23:00:48 +0100 (MEZ) In-Reply-To: from "bernie@ietf.hoeneisen.ch" at Feb "25, " 2010 "03:37:31" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: e2md@ietf.org Subject: Re: [e2md] [DNSOP] charter discussion kick-off X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 21:59:02 -0000 > Hi Alfred > > Thanks for your thoughts on this. > > As you might remember, the DNS packet size limitation issue was being > discussed earlier in ENUM. There was a heavy debate on whether or not > EDNS0 should be compulsary for DNS servers running ENUM. AFAICR there was > no consensus to make this a requirement. That might be seen differently > nowadays. As you know there is a similar debate now in DNSEXT in the > context of DNSsec: Mandating TCP with EDNS0 and friends... Indeed. > > I am not sure whether this issue should be solved on application layer. > I am actually hoping (rather sooner than later) the DNS can cope with > this problem (at the source of it)... [ I vote for SCTP... :-) ] Hmmm. Voting doesn't help much. :-) The main problem is not the DNS protocols itself. The maximum DNS packet size is 64k. It's the BSD-{adam&eve}.0 motivated restriction on 512-octet UDP payloads built upon the tiny IPv4 minimum link MTU that unfortunately has not been overcome in the DNS-over-IPv6 specs, for the sake of seemless switching between v4 and v6 transport. One of the biggest problem is the lack of transparency in practice. Middleboxes and firewalls block ICMP (making rapid Path MTU discovery impossible) and IP fragments (making full use of EDNS0 troublesome or impossible); home gateways with nonsensically poor "DNS Proxies" (see RFC 5625) prohibit making proper use of EDNS0 and DNS over TCP. I know, there are many substantial security considerations as well. Given the barriers to actual use of decade-old protocols it is very likely that a switch to SCTP would encounter even worse obstacles. But it should also be noted that SCTP is not a panacea; even strong stakeholders of SCTP admit that the burden in RTTs (delay) and server load would not be much different from TCP; yet SCTP deployment lurks and NAT support for SCTP is is its infancy. TCP (and perhaps SCTP) would best be used with long-lived, persistent connections that amortize the connection setup/teardown penalty over many transactions, but the current practice of rather flat hierarchies and huge 'fan-out' in DNS implementation and use make it difficult to achieve that. DNSEXT now has chartered work items for DNS transport, but trouble in related WGs makes cooperation difficult. Transport folks seem to prefer the PoV of "We provide a service that shall survive under all circumstances, and this comes with drawbacks for user. Applications must decide how they make best use of the service." Existing legacy APIs also to some degree contribute to inefficient use, which makes it difficult for DNS software (traditionally not developed by OS vendors) to make better use of the transport. The application from the transport PoV is the DNS. Thus the engineering problems need to be solved at the DNS level, indeed. a) The draft that reinforces that that the requirement for the implementation of DNS over TCP is in WGLC. (STD 13 and STD 3 hat spelled that out in pre-RFC2119 language, and implementers seing lowercase 'should' and 'must' did not recognize the age of these RFCs and did not follow the spirit of the words there.) b) A document on TCP tuning and best implementation practices has been conceived and will likely emerge as a BCP. c) There are proposals for new transports; at least one brought to DNSEXT recently, others being developed outside the IETF currently. Since the development of a sound standard in this area will take time (much time!), and deployment in any case will be slow and not universal, this is not a short-term perspective for any 'new' application of the DNS. Transition and gracefull fallback strategies will be serious issues, and users suffering of related delays (due to timeouts) will further cause disincentives for deployment. DNSEXT is chartered to take on such work, on the longer term. Long elaborations, short conclusion ... > > However, we could add a such requirement to the E2MD charter. > How about something along the lines of: > > "Limitations of the DNS (e.g. packet size) are to be considered while > defining the protocol." May I suggest: "Limitations of deployed DNS transport (e.g. packet size restrictions) are to be considered while defining the protocol." > > cheers, > Bernie Kind regards, Alfred. From lconroy@insensate.co.uk Thu Feb 25 14:23:43 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDD1428C232 for ; Thu, 25 Feb 2010 14:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0Ehe-2VqTok for ; Thu, 25 Feb 2010 14:23:43 -0800 (PST) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id ED99B28C254 for ; Thu, 25 Feb 2010 14:23:39 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 211E510FD77; Thu, 25 Feb 2010 22:25:51 +0000 (GMT) References: <201002252200.XAA07138@TR-Sys.de> In-Reply-To: <201002252200.XAA07138@TR-Sys.de> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 Message-Id: <03BCDEFE-47AE-49E2-829F-60693E8F5064@insensate.co.uk> Content-Transfer-Encoding: quoted-printable From: Lawrence Conroy Date: Thu, 25 Feb 2010 22:25:51 +0000 To: =?iso-8859-1?Q?Alfred_H=CEnes?= X-Mailer: Apple Mail (2.1077) Cc: bernie@ietf.hoeneisen.ch, e2md@ietf.org Subject: Re: [e2md] [DNSOP] charter discussion kick-off X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 22:23:43 -0000 Hi Alfred, Bernie, folks, As usual, Alfred's suggestions are good ones. +1 ... with the slight clarification that this statement should encourage = folk NOT to generate long/verbose strings, rather than to state that if = something can't fit in 512 bytes, then it MUST NOT be done. In passing, ISTR that the then TSV ADs jointly ran the BOF for what = would become SCTP. It was intended originally to be something "between" = TCP and UDP (at least, that's what I recall Scott Bradner saying at the = time). IMHO, SCTP has the major *benefit* that it is unknown to Firewall/Home = Gateways, so they don't think they know about it, and so don't try to = proxy//break it :). atb, Lawrence On 25 Feb 2010, at 22:00, Alfred H=CEnes wrote: > May I suggest: >=20 > "Limitations of deployed DNS transport (e.g. packet size = restrictions) > are to be considered while defining the protocol." From jim@rfc1035.com Fri Feb 26 02:13:03 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97BA53A86B1 for ; Fri, 26 Feb 2010 02:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[AWL=-0.760, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LijhSy357ffl for ; Fri, 26 Feb 2010 02:13:02 -0800 (PST) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id C6DDA3A866D for ; Fri, 26 Feb 2010 02:12:57 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 27A83154208B; Fri, 26 Feb 2010 10:15:09 +0000 (GMT) Message-Id: <340CB4CD-1816-48E8-9ECC-3DDFEAB83B1A@rfc1035.com> From: Jim Reid To: Lawrence Conroy In-Reply-To: <03BCDEFE-47AE-49E2-829F-60693E8F5064@insensate.co.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 26 Feb 2010 10:15:08 +0000 References: <201002252200.XAA07138@TR-Sys.de> <03BCDEFE-47AE-49E2-829F-60693E8F5064@insensate.co.uk> X-Mailer: Apple Mail (2.936) Cc: e2md@ietf.org, bernie@ietf.hoeneisen.ch Subject: [e2md] Is SCTP the answer? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 10:13:03 -0000 On 25 Feb 2010, at 22:25, Lawrence Conroy wrote: > IMHO, SCTP has the major *benefit* that it is unknown to Firewall/ > Home Gateways, so they don't think they know about it, and so don't > try to proxy//break it :). It would be most unwise to use this as a starting assumption. Or expect that situation never changes. If/when SCTP usage becomes significant, we can be sure that CPE vendors will update their firmware to make it do creative things to those packets. I would not be surprised too if lots of the installed base of these devices today simply drop SCTP traffic. And as you know Lawrence, the idiocy of CPE vendors is something that has been making my life miserable recently. From Ray.Bellis@nominet.org.uk Fri Feb 26 02:20:11 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886313A7FB0 for ; Fri, 26 Feb 2010 02:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.448 X-Spam-Level: X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQWNJyeHAj5h for ; Fri, 26 Feb 2010 02:20:10 -0800 (PST) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 10C533A8621 for ; Fri, 26 Feb 2010 02:20:09 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=PpuXw6a1VLbchiypZ3ZrVlLSmkedTize8zwPp3QPiovdUd7dLeMNjNQ9 4PuLIINBdP4UkYhcpUfvwKwSXdyiJNQ/u6qjjZEFw0LKbM3qWdLBgGWE0 WCWQFr7aHsRG26O; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1267179744; x=1298715744; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20Is=20SCTP=20the=20answer?|Date:=20Fri,=2026=20Feb=202 010=2010:22:21=20+0000|Message-ID:=20 |To:=20Jim=20Reid=20|Cc:=20e2md@ietf.org |MIME-Version:=201.0|In-Reply-To:=20<340CB4CD-1816-48E8-9 ECC-3DDFEAB83B1A@rfc1035.com>|References:=20<201002252200 .XAA07138@TR-Sys.de>=09<03BCDEFE-47AE-49E2-829F-60693E8F5 064@insensate.co.uk>=20<340CB4CD-1816-48E8-9ECC-3DDFEAB83 B1A@rfc1035.com>; bh=PRSUPotPpSZQYv1cnQu2y3bQGkTVB9ThKDe54wSJ+8E=; b=VMEQnoTyztQJKHNC7HtjHaFI5E+GMtDZihZQEoO0EZrIF1Xre+Wn8Ba6 0RinVkaCH7DxKBUgyd0NsMaTTJZFyEnbXPK+Keu4T29HMFbqCaU4d+qyk g6DLCZOSYulrEOJ; X-IronPort-AV: E=Sophos;i="4.49,545,1262563200"; d="scan'208";a="22091195" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 26 Feb 2010 10:22:22 +0000 In-Reply-To: <340CB4CD-1816-48E8-9ECC-3DDFEAB83B1A@rfc1035.com> References: <201002252200.XAA07138@TR-Sys.de> <03BCDEFE-47AE-49E2-829F-60693E8F5064@insensate.co.uk> <340CB4CD-1816-48E8-9ECC-3DDFEAB83B1A@rfc1035.com> To: Jim Reid MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 26 Feb 2010 10:22:21 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 26/02/2010 10:22:22 AM, Serialize complete at 26/02/2010 10:22:22 AM Content-Type: multipart/alternative; boundary="=_alternative 0038FA61802576D6_=" Cc: e2md@ietf.org Subject: Re: [e2md] Is SCTP the answer? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 10:20:11 -0000 This is a multipart message in MIME format. --=_alternative 0038FA61802576D6_= Content-Type: text/plain; charset="US-ASCII" > It would be most unwise to use this as a starting assumption. Or > expect that situation never changes. If/when SCTP usage becomes > significant, we can be sure that CPE vendors will update their > firmware to make it do creative things to those packets. I would not > be surprised too if lots of the installed base of these devices today > simply drop SCTP traffic. Indeed, I'm sure many CPE devices simply don't know what to do with an IP packet that isn't UDP or TCP, and would drop it by default. For a start, how do you NAT or firewall an SCTP flow if you don't know how to handle the protocol's innards. I have seen firewalls that allow you to specify rules for "unknown" IP protocols, particularly to allow things like GRE tunnels. However they tend to be "all or nothing" and wouldn't let you (for example) configure it to only allow through HTTP over SCTP, because they don't know about the contents of the SCTP header. > And as you know Lawrence, the idiocy of CPE vendors is something that > has been making my life miserable recently. Do please tell, if you're able :) [this thread should of course migrate to HomeGate] Ray --=_alternative 0038FA61802576D6_= Content-Type: text/html; charset="US-ASCII"
> It would be most unwise to use this as a starting assumption. Or  
> expect that situation never changes. If/when SCTP usage becomes  
> significant, we can be sure that CPE vendors will update their  
> firmware to make it do creative things to those packets. I would not  
> be surprised too if lots of the installed base of these devices today  
> simply drop SCTP traffic.

Indeed, I'm sure many CPE devices simply don't know what to do with an IP packet that isn't UDP or TCP, and would drop it by default.

For a start, how do you NAT or firewall an SCTP flow if you don't know how to handle the protocol's innards.  I have seen firewalls that allow you to specify rules for "unknown" IP protocols, particularly to allow things like GRE tunnels.  However they tend to be "all or nothing" and wouldn't let you (for example) configure it to only allow through HTTP over SCTP, because they don't know about the contents of the SCTP header.

> And as you know Lawrence, the idiocy of CPE vendors is something that  
> has been making my life miserable recently.
Do please tell, if you're able :)

[this thread should of course migrate to HomeGate]

Ray
--=_alternative 0038FA61802576D6_=-- From bernie@ietf.hoeneisen.ch Fri Feb 26 02:22:02 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BA4D3A867D for ; Fri, 26 Feb 2010 02:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5elA+ZqtgtUp for ; Fri, 26 Feb 2010 02:22:01 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 9F3EA3A8672 for ; Fri, 26 Feb 2010 02:22:01 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NkxMk-0005re-8K; Fri, 26 Feb 2010 11:24:14 +0100 Date: Fri, 26 Feb 2010 11:24:14 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Alfred H?nes In-Reply-To: <201002252200.XAA07138@TR-Sys.de> Message-ID: References: <201002252200.XAA07138@TR-Sys.de> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] [DNSOP] charter discussion kick-off X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 10:22:02 -0000 Hi Alfred On Thu, 25 Feb 2010, Alfred H?nes wrote: >> I am not sure whether this issue should be solved on application layer. >> I am actually hoping (rather sooner than later) the DNS can cope with >> this problem (at the source of it)... [ I vote for SCTP... :-) ] > > Hmmm. Voting doesn't help much. :-) I never claimed that voting helps, but it can contribute to the fun... ;-) > The main problem is [...] Thanks for your insight into the DNS transport problem space. It was very interesting. However, I won't comment it further on this mailing-list as that problem space is out-of-scope for e2md. > DNSEXT is chartered to take on such work, on the longer term. Exactly as you say, DNSEXT is the venue for that discussion. >> However, we could add a such requirement to the E2MD charter. >> How about something along the lines of: >> >> "Limitations of the DNS (e.g. packet size) are to be considered while >> defining the protocol." > > May I suggest: > > "Limitations of deployed DNS transport (e.g. packet size restrictions) > are to be considered while defining the protocol." I tried to keep this requirement on high level, as opposed to your proposal, that gets rather specific. How about something as the following: "Limitations of the DNS are to be considered while defining the protocol; in particular packet size restrictions of deployed DNS transport." cheers, Bernie From bernie@ietf.hoeneisen.ch Fri Feb 26 02:31:22 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5834928C106 for ; Fri, 26 Feb 2010 02:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWqr8H6uCxYv for ; Fri, 26 Feb 2010 02:31:21 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 7F85C28C153 for ; Fri, 26 Feb 2010 02:31:21 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NkxVj-0005uF-SD; Fri, 26 Feb 2010 11:33:31 +0100 Date: Fri, 26 Feb 2010 11:33:31 +0100 (CET) From: bernie@ietf.hoeneisen.ch X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Lawrence Conroy In-Reply-To: <03BCDEFE-47AE-49E2-829F-60693E8F5064@insensate.co.uk> Message-ID: References: <201002252200.XAA07138@TR-Sys.de> <03BCDEFE-47AE-49E2-829F-60693E8F5064@insensate.co.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: e2md@ietf.org Subject: Re: [e2md] [DNSOP] charter discussion kick-off X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 10:31:22 -0000 Hi Lawrence On Thu, 25 Feb 2010, Lawrence Conroy wrote: >> "Limitations of deployed DNS transport (e.g. packet size restrictions) >> are to be considered while defining the protocol." > > As usual, Alfred's suggestions are good ones. > +1 > > ... with the slight clarification that this statement should encourage > folk NOT to generate long/verbose strings, rather than to state that if > something can't fit in 512 bytes, then it MUST NOT be done. I consider such an additon not suitable to be included to the charter. However, I am happy to discuss this later for inclusion into the base spec of e2md. Does this work for you? cheers, Bernie From A.Hoenes@TR-Sys.de Fri Feb 26 03:07:21 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0C13A832E for ; Fri, 26 Feb 2010 03:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.408 X-Spam-Level: * X-Spam-Status: No, score=1.408 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SK-u8XBaWgnr for ; Fri, 26 Feb 2010 03:07:20 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id A8DEA3A7C0A for ; Fri, 26 Feb 2010 03:07:19 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA192982552; Fri, 26 Feb 2010 12:09:12 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id MAA08003; Fri, 26 Feb 2010 12:09:11 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201002261109.MAA08003@TR-Sys.de> To: bernie@ietf.hoeneisen.ch Date: Fri, 26 Feb 2010 12:09:11 +0100 (MEZ) In-Reply-To: from Bernie Hoeneisen at Feb "26, " 2010 "11:24:14" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: e2md@ietf.org Subject: Re: [e2md] [DNSOP] charter discussion kick-off X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 11:07:21 -0000 Bernie, thans again for your response. > ... > > I tried to keep this requirement on high level, as opposed to your > proposal, that gets rather specific. How about something as the following: > > "Limitations of the DNS are to be considered while defining the > protocol; in particular packet size restrictions of deployed DNS > transport." Agreed. > cheers, > Bernie BR, Alfred. P.S.: Sorry for the long elaborations in this phase, for a short conclusion. These can be re-visited when the topic is actually going to be discussed. From lconroy@insensate.co.uk Fri Feb 26 04:16:20 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B067C3A878B for ; Fri, 26 Feb 2010 04:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKuR8Kt3C-8K for ; Fri, 26 Feb 2010 04:16:19 -0800 (PST) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 2979228C1AE for ; Fri, 26 Feb 2010 04:16:14 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id AB3F710FF7C; Fri, 26 Feb 2010 12:18:20 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Lawrence Conroy In-Reply-To: <201002261109.MAA08003@TR-Sys.de> Date: Fri, 26 Feb 2010 12:18:20 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <77B06688-96A2-4AA2-99F1-FF480279C9F0@insensate.co.uk> References: <201002261109.MAA08003@TR-Sys.de> To: bernie@ietf.hoeneisen.ch X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] [DNSOP] charter discussion kick-off X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 12:16:20 -0000 Hi Bernie, Alfred, folks, Your formulation works for me. The only concern I had was that some folks might get very "XML-like" and = insist on verbose strings regardless of the transport -- as this is = machine-processed anyway, that's pointless (IMHO). Your phrase just gives guidance, and covers that concern. Remember, it's not clear in which Area this would end up, and there are = some spectacularly inefficient ways of sending very little useful = information. Let's not do that :). all the best, Lawrence On 26 Feb 2010, at 11:09, Alfred H=CEnes wrote: > Bernie, > thans again for your response. >=20 >> ... >>=20 >> I tried to keep this requirement on high level, as opposed to your >> proposal, that gets rather specific. How about something as the = following: >>=20 >> "Limitations of the DNS are to be considered while defining the >> protocol; in particular packet size restrictions of deployed DNS >> transport." >=20 > Agreed. >=20 >> cheers, >> Bernie >=20 > BR, > Alfred. >=20 >=20 > P.S.: Sorry for the long elaborations in this phase, for a short > conclusion. These can be re-visited when the topic is > actually going to be discussed. >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md