From HKaplan@acmepacket.com Thu Apr 1 06:46: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 5F8273A6808 for ; Thu, 1 Apr 2010 06:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.704 X-Spam-Level: X-Spam-Status: No, score=0.704 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 JNNIfQHCEpYh for ; Thu, 1 Apr 2010 06:46:25 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id DBC653A6868 for ; Thu, 1 Apr 2010 06:46:24 -0700 (PDT) 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; Thu, 1 Apr 2010 09:46:51 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 1 Apr 2010 09:46:50 -0400 From: Hadriel Kaplan To: E.164 To MetaData BOF discussion list Date: Thu, 1 Apr 2010 09:46:48 -0400 Thread-Topic: Doodle poll for E2MD conf call Thread-Index: AcrRocbdMLaqyE8NTrCTgd8fdAcbiQ== Message-ID: <430FC6BDED356B4C8498F634416644A91A79E92ECC@mail> 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: [e2md] Doodle poll for E2MD conf call 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, 01 Apr 2010 13:46:26 -0000 Howdy, I created a doodle poll page for figuring out a possible common time for a = conference call. If you are interested in discussing the issues, options a= nd way forward on a conference call, please go to the following link and in= dicate the times you can make it. =20 http://www.doodle.com/mbxby6vdryqwgtgr Times on the poll page are in Eastern US Daylight Savings Time, although yo= u should be able to change it for your view when you go to it.=20 There are people from Europe, NZ, and Western US, so I'm not sure a common = business-hours time is really possible. :( -hadriel From kcartwright@tnsi.com Thu Apr 1 07:01:00 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 B16AC3A682B for ; Thu, 1 Apr 2010 07:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.093 X-Spam-Level: * X-Spam-Status: No, score=1.093 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 SZxPe1ANACNf for ; Thu, 1 Apr 2010 07:00:59 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 6EA193A680D for ; Thu, 1 Apr 2010 07:00:59 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42118242; Thu, 01 Apr 2010 10:01:08 -0400 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; Thu, 1 Apr 2010 10:01:08 -0400 From: "Cartwright, Kenneth" To: Jay Daley Date: Thu, 1 Apr 2010 10:01:06 -0400 Thread-Topic: [e2md] Alternative to source URI Thread-Index: AcrREXB6T9gP6o9VRKeVVbC9DAIZbAAkK9ew Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F69675D2E@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <430FC6BDED356B4C8498F634416644A91A79E92953@mail> <430FC6BDED356B4C8498F634416644A91A79E92982@mail> <30A5CA73-90EF-416C-8C15-BAF3B4593E28@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E92ABE@mail> <1DD1342F-8CCA-4D7B-B688-C2F691D55B8B@nzrs.net.nz> <754963199212404AB8E9CFCA6C3D0CDA1F6952A756@TNS-MAIL-NA.win2k.corp.tnsi.com> <106E39D6-65AF-4A53-A3F5-633D5F32A936@nzrs.net.nz> In-Reply-To: <106E39D6-65AF-4A53-A3F5-633D5F32A936@nzrs.net.nz> 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: E.164, list Subject: Re: [e2md] Alternative to source URI 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, 01 Apr 2010 14:01:00 -0000 I think the disconnect in our common understandings is this statement you y= ou've made: "That is achieved by deciding to whom to give what private data." I think the statement presumes that we are *pushing* a private data set *do= wn/out* to the organization that wants/isAllowedTo to see that private data= set. The solution cannot be predicated on that operational model. With re= spect to the location of the "private" data as you call it, there are two m= odels: 1) Shared/Central Resolution Server Model: The private data sets are not p= ushed down to the organization that has visibility to that private data, bu= t instead sits in a common location where access and visibility into the da= ta is controlled. Under many circumstances it is not permissible from a bu= siness model, and/or privacy, and/or scalability perspective to push the "p= rivate" data down to each individual organization that wants to query it. 2) Private/Local Resolution Server Model: The private views into the large= r data set are created, updated, and pushed down to local resolution server= s owned/operated/hosted by the organization that has visibility into that v= iew. The solution needs to support both of these models. Ken -----Original Message----- From: Jay Daley [mailto:jay@nzrs.net.nz] Sent: Wednesday, March 31, 2010 4:33 PM To: Cartwright, Kenneth Cc: Hadriel Kaplan; E.164 To MetaData BOF discussion list Subject: Re: [e2md] Alternative to source URI On 1/04/2010, at 4:54 AM, Cartwright, Kenneth wrote: > Source based responses can be selected at three levels of granularity (de= pending on the policy driven need of the given use case): thanks, this is very helpful. > 1) Source Organization (done today through non-standard means such as a d= ifferent root domain to the same DNS server) That is achieved by deciding to whom to give what private data. > 2) Source Node/IP (done today through non-standardized means such as sour= ce IP address of the DNS query) This is presumably an indirect mechanism for a different form of source bas= ed filtering - in other words it is not the IP that actually matters but wh= o is using that IP? If is actually the IP then that is achieved by the contents of the private = data. > 3) Source Person/Identity (done today via non-standardized means such as = the callers SIP URI) That is achieved by the contents of the private data. > Does what you propose directly support all three, directly support a subs= et of the three, get in the way of any of the three, ignore any of the thre= e, etc? Granted I've not had the time to follow all of these emails, but i= t's not clear to me that it supports 2 and 3. Sorry if I missed something = in a previous email. If so please just point me at that email and I will r= ead/reread it. I think it does support all three but I need to understand the purpose of 2= a bit better to be sure, assuming you think I have explained 1 and 3 well = enough. Can you provide more detail? thanks Jay > > Ken > > > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of J= ay Daley > Sent: Wednesday, March 31, 2010 12:02 AM > To: Hadriel Kaplan > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] Alternative to source URI > > > On 31/03/2010, at 5:15 AM, Hadriel Kaplan wrote: > >>> Assuming the proxy is "allowed" to know this then they either have two >>> sets of private data, one for the source carrier that services 67890 an= d >>> one for the source carrier that services 88888. Or if the originating >>> carrier is the same then just one set of private data that identifies t= he >>> source within it: >>> >>> meta-endpoint -> source -> actual-endpoint >> >> It is the same source carrier for both calls originating from 77777 and = 88888, hence the rub - even if the destination carrier says "meta-endpoint"= , the source carrier needs to do a lookup (somewhere) that takes the source= number into account. In other words *someone* has to do a source-based lo= okup, and that someone could/would use source-uri. > > I might be being thick here but I don't get why you think the only soluti= on is source-uri. What effect is achieved by source-uri that is not achiev= ed by the scheme I'm suggesting? As far as I can tell they achieve exactly= the same thing. > > cheers > Jay > > >> >> -hadriel > > > -- > Jay Daley > Chief Executive > .nz Registry Services (New Zealand Domain Name Registry Limited) > desk: +64 4 931 6977 > mobile: +64 21 678840 > > _______________________________________________ > 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 m= ay > contain confidential and privileged information of Transaction Network Se= rvices. > Any unauthorised review, use, disclosure or distribution is prohibited. I= f you > are not the intended recipient, please contact the sender by reply e-mail= and destroy all copies of the original message. > -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 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 Thu Apr 1 07:04:47 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 38C703A67B6 for ; Thu, 1 Apr 2010 07:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.109 X-Spam-Level: * X-Spam-Status: No, score=1.109 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 JpeatlIEH06V for ; Thu, 1 Apr 2010 07:04:46 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 5B8FA3A679C for ; Thu, 1 Apr 2010 07:04:46 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NxL1J-000803-Q4; Thu, 01 Apr 2010 16:05:17 +0200 Date: Thu, 1 Apr 2010 16:05:17 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Hadriel Kaplan In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E92ECC@mail> Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79E92ECC@mail> 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: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Doodle poll for E2MD conf call 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, 01 Apr 2010 14:04:47 -0000 Hi Hadriel The only time that really works for all of us is 19 hours UT, in NZ (Jay) it's 7 a.m. http://www.timeanddate.com/worldclock/meetingtime.html?day=5&month=4&year=2010&p1= 136&p2=268&p3=137&p4=264 If NZ participants can make it at 6 a.m. local time, we could also meet at 18 hours UT. Thus, none of your suggested dates is confortable for NZ participanets. cheers, Bernie On Thu, 1 Apr 2010, Hadriel Kaplan wrote: > Howdy, > I created a doodle poll page for figuring out a possible common time for a conference call. If you are interested in discussing the issues, options and way forward on a conference call, please go to the following link and indicate the times you can make it. > > http://www.doodle.com/mbxby6vdryqwgtgr > > Times on the poll page are in Eastern US Daylight Savings Time, although you should be able to change it for your view when you go to it. > > There are people from Europe, NZ, and Western US, so I'm not sure a common business-hours time is really possible. :( > > -hadriel > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > From HKaplan@acmepacket.com Thu Apr 1 07:34:56 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 6E8133A6901 for ; Thu, 1 Apr 2010 07:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.712 X-Spam-Level: X-Spam-Status: No, score=0.712 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 m520d5oiXu95 for ; Thu, 1 Apr 2010 07:34:55 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 2B0D93A6829 for ; Thu, 1 Apr 2010 07:34:55 -0700 (PDT) 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; Thu, 1 Apr 2010 10:35:20 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 1 Apr 2010 10:35:20 -0400 From: Hadriel Kaplan To: Bernie Hoeneisen Date: Thu, 1 Apr 2010 10:35:19 -0400 Thread-Topic: [e2md] Doodle poll for E2MD conf call Thread-Index: AcrRpFPGaQOg46K4SX+PDzColb5S7gABCGVg Message-ID: <430FC6BDED356B4C8498F634416644A91A79E92F04@mail> References: <430FC6BDED356B4C8498F634416644A91A79E92ECC@mail> 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 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Doodle poll for E2MD conf call 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, 01 Apr 2010 14:34:56 -0000 I didn't think folks in Europe would be ok with that late, but I'll add it. -hadriel > -----Original Message----- > From: Bernie Hoeneisen [mailto:bernie@hoeneisen.ch] > Sent: Thursday, April 01, 2010 10:05 AM > To: Hadriel Kaplan > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] Doodle poll for E2MD conf call >=20 > Hi Hadriel >=20 > The only time that really works for all of us is 19 hours UT, in NZ > (Jay) it's 7 a.m. >=20 >=20 > http://www.timeanddate.com/worldclock/meetingtime.html?day=3D5&month=3D4&= year=3D > 2010&p1=3D136&p2=3D268&p3=3D137&p4=3D264 >=20 > If NZ participants can make it at 6 a.m. local time, we could also meet a= t > 18 hours UT. >=20 > Thus, none of your suggested dates is confortable for NZ participanets. >=20 > cheers, > Bernie >=20 >=20 > On Thu, 1 Apr 2010, Hadriel Kaplan wrote: >=20 > > Howdy, > > I created a doodle poll page for figuring out a possible common time fo= r > a conference call. If you are interested in discussing the issues, > options and way forward on a conference call, please go to the following > link and indicate the times you can make it. > > > > http://www.doodle.com/mbxby6vdryqwgtgr > > > > Times on the poll page are in Eastern US Daylight Savings Time, althoug= h > you should be able to change it for your view when you go to it. > > > > There are people from Europe, NZ, and Western US, so I'm not sure a > common business-hours time is really possible. :( > > > > -hadriel > > _______________________________________________ > > e2md mailing list > > e2md@ietf.org > > https://www.ietf.org/mailman/listinfo/e2md > > From bernie@ietf.hoeneisen.ch Thu Apr 1 07:35: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 0E6FD3A6821 for ; Thu, 1 Apr 2010 07:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[AWL=1.281, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 piJ5omf+A1Wz for ; Thu, 1 Apr 2010 07:35:49 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 292A03A6829 for ; Thu, 1 Apr 2010 07:35:49 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NxLVK-00084g-Jd; Thu, 01 Apr 2010 16:36:18 +0200 Date: Thu, 1 Apr 2010 16:36:18 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Hadriel Kaplan In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E92E15@mail> Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79E92E15@mail> 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: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD virtual interim meeting 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, 01 Apr 2010 14:35:50 -0000 Hi Hadriel As Dean said, we are no longer BoF chairs by now. The only roles left in the e2md group are mailing-list moderators (Ray and myself), and of course the RAI ADs. For the time being I'll continue coordinating the e2md group on need basis. In particular, I'll continue to serve as a "liaison" between the e2md group and the ADs, should e.g. any kind of AD action/involvement be required by the e2md group. Thus, everybody is free to arrange meetings or discussions of any kind. (Such meetings are to be covered by the "Note Well"; announcements and minutes are expected on the e2md mailing list.) So, just go ahead! cheers, Bernie On Wed, 31 Mar 2010, Hadriel Kaplan wrote: > To the BOF chairs: > I think email is not a good way to discuss some of this, and is getting in the way. > I propose we have a virtual interim meeting, with slides and voice. And I can host it (via WebEx) if the IETF cannot. > > -hadriel > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > From HKaplan@acmepacket.com Thu Apr 1 10:20: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 7C7813A6A28 for ; Thu, 1 Apr 2010 10:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.719 X-Spam-Level: X-Spam-Status: No, score=0.719 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 BGUpu9s2+zbG for ; Thu, 1 Apr 2010 10:20:20 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 8D8623A686D for ; Thu, 1 Apr 2010 10:19:58 -0700 (PDT) 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; Thu, 1 Apr 2010 13:20:22 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 1 Apr 2010 13:20:20 -0400 From: Hadriel Kaplan To: E.164 To MetaData BOF discussion list Date: Thu, 1 Apr 2010 13:20:19 -0400 Thread-Topic: Doodle poll for E2MD conf call Thread-Index: AcrRocbdMLaqyE8NTrCTgd8fdAcbiQACOLAg Message-ID: <430FC6BDED356B4C8498F634416644A91A79E92F87@mail> References: <430FC6BDED356B4C8498F634416644A91A79E92ECC@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E92ECC@mail> 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] Doodle poll for E2MD conf call 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, 01 Apr 2010 17:20:21 -0000 FYI, the poll has been updated with more times. > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Hadriel Kaplan > Sent: Thursday, April 01, 2010 9:47 AM > To: E.164 To MetaData BOF discussion list > Subject: [e2md] Doodle poll for E2MD conf call >=20 > Howdy, > I created a doodle poll page for figuring out a possible common time for = a > conference call. If you are interested in discussing the issues, options > and way forward on a conference call, please go to the following link and > indicate the times you can make it. >=20 > http://www.doodle.com/mbxby6vdryqwgtgr >=20 > Times on the poll page are in Eastern US Daylight Savings Time, although > you should be able to change it for your view when you go to it. >=20 > There are people from Europe, NZ, and Western US, so I'm not sure a commo= n > business-hours time is really possible. :( >=20 > -hadriel > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From HKaplan@acmepacket.com Fri Apr 2 11:35: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 8FCB83A6AE9 for ; Fri, 2 Apr 2010 11:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.72 X-Spam-Level: X-Spam-Status: No, score=0.72 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 t4DsB+QgQFOS for ; Fri, 2 Apr 2010 11:35:57 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 60EC13A6AE5 for ; Fri, 2 Apr 2010 11:14:00 -0700 (PDT) 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; Fri, 2 Apr 2010 14:14:30 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 2 Apr 2010 14:14:30 -0400 From: Hadriel Kaplan To: E.164 To MetaData BOF discussion list Date: Fri, 2 Apr 2010 14:14:30 -0400 Thread-Topic: E2MD conf call on Tuesday April 6th 18:00 UTC Thread-Index: AcrRocbdMLaqyE8NTrCTgd8fdAcbiQA7Xtfw Message-ID: <430FC6BDED356B4C8498F634416644A91A79E931D5@mail> References: <430FC6BDED356B4C8498F634416644A91A79E92ECC@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E92ECC@mail> 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: [e2md] E2MD conf call on Tuesday April 6th 18:00 UTC 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, 02 Apr 2010 18:35:58 -0000 Based on the Doodle-poll, it looks like Tuesday the 6th from 2-3pm EDT (18-= 19:00 UTC) is the one which everyone can make except Ray (who's out for the= week). I will send out meeting info (URL, dial-in) - as soon as I figure out what = they are. :) -hadriel > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Hadriel Kaplan > Sent: Thursday, April 01, 2010 9:47 AM > To: E.164 To MetaData BOF discussion list > Subject: [e2md] Doodle poll for E2MD conf call >=20 > Howdy, > I created a doodle poll page for figuring out a possible common time for = a > conference call. If you are interested in discussing the issues, options > and way forward on a conference call, please go to the following link and > indicate the times you can make it. >=20 > http://www.doodle.com/mbxby6vdryqwgtgr >=20 > Times on the poll page are in Eastern US Daylight Savings Time, although > you should be able to change it for your view when you go to it. >=20 > There are people from Europe, NZ, and Western US, so I'm not sure a commo= n > business-hours time is really possible. :( >=20 > -hadriel > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From jay@nzrs.net.nz Mon Apr 5 16:30:33 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 BFB003A67C1 for ; Mon, 5 Apr 2010 16:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 TPThCsnie91N for ; Mon, 5 Apr 2010 16:30:28 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id D2BC63A67B1 for ; Mon, 5 Apr 2010 16:30:27 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 702BB2DA554; Tue, 6 Apr 2010 11:22:59 +1200 (NZST) 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 d7UROxPDcsYh; Tue, 6 Apr 2010 11:22:59 +1200 (NZST) Received: from [192.168.22.175] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id C7B812DA277; Tue, 6 Apr 2010 11:22:58 +1200 (NZST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E931D5@mail> Date: Tue, 6 Apr 2010 11:22:58 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <3DD5CC32-FC1A-424C-B0A2-F87B32E95AE3@nzrs.net.nz> References: <430FC6BDED356B4C8498F634416644A91A79E92ECC@mail> <430FC6BDED356B4C8498F634416644A91A79E931D5@mail> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1078) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD conf call on Tuesday April 6th 18:00 UTC 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, 05 Apr 2010 23:30:34 -0000 On 3/04/2010, at 7:14 AM, Hadriel Kaplan wrote: >=20 > Based on the Doodle-poll, it looks like Tuesday the 6th from 2-3pm EDT = (18-19:00 UTC) is the one which everyone can make except Ray (who's out = for the week). I've been away for a long weekend and only just completed the doodle. = Daylight savings time has just finished here so this is 6am not 7am for = me, but i should still be able to make it. Jay >=20 > I will send out meeting info (URL, dial-in) - as soon as I figure out = what they are. :) >=20 > -hadriel >=20 >> -----Original Message----- >> From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf = Of >> Hadriel Kaplan >> Sent: Thursday, April 01, 2010 9:47 AM >> To: E.164 To MetaData BOF discussion list >> Subject: [e2md] Doodle poll for E2MD conf call >>=20 >> Howdy, >> I created a doodle poll page for figuring out a possible common time = for a >> conference call. If you are interested in discussing the issues, = options >> and way forward on a conference call, please go to the following link = and >> indicate the times you can make it. >>=20 >> http://www.doodle.com/mbxby6vdryqwgtgr >>=20 >> Times on the poll page are in Eastern US Daylight Savings Time, = although >> you should be able to change it for your view when you go to it. >>=20 >> There are people from Europe, NZ, and Western US, so I'm not sure a = common >> business-hours time is really possible. :( >>=20 >> -hadriel >> _______________________________________________ >> 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 --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From HKaplan@acmepacket.com Mon Apr 5 16:34:34 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 47BED3A63D3 for ; Mon, 5 Apr 2010 16:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.419 X-Spam-Level: * X-Spam-Status: No, score=1.419 tagged_above=-999 required=5 tests=[AWL=-1.881, BAYES_99=3.5, GB_I_INVITATION=-2, J_CHICKENPOX_56=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_74=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 2ihOEkUc+5el for ; Mon, 5 Apr 2010 16:34:32 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 073003A67B1 for ; Mon, 5 Apr 2010 16:34:32 -0700 (PDT) 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; Mon, 5 Apr 2010 19:34:28 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 5 Apr 2010 19:34:27 -0400 From: Hadriel Kaplan To: E.164 To MetaData BOF discussion list Date: Mon, 5 Apr 2010 19:34:26 -0400 Thread-Topic: E2MD discussion conf call and web meeting info Thread-Index: AcrVF4axlrvpcu8QTCmoTbEi1XP4NQAAFxhA Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3CCF1@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_430FC6BDED356B4C8498F634416644A91A79F3CCF1mail_" MIME-Version: 1.0 Subject: [e2md] E2MD discussion conf call and web meeting info 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, 05 Apr 2010 23:34:34 -0000 --_002_430FC6BDED356B4C8498F634416644A91A79F3CCF1mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please follow the steps below to join this meeting, using Intercall Web Mee= ting. Please note: The moderator may have included a calendar invite (.VC= S file) with this invitation. If so, you can open the attachment to save it= in your calendar. =09 =09 (+)CONFERENCE SUMMARY =09 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =09 Title: E2MD discussion =09 - - - - - - - - - - - - - - - - - - - - - - - - - =09 Date: April 6, 2010 =09 Start Time: 02:00 PM US/Eastern =09 Duration: 60 minutes =09 Presenter: (not provided) =09 =09 =09 (+)CONFERENCE DESCRIPTION =09 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =09 This is an E2MD/ENUM discussion conference call/web-meeting =09 =09 =09 (+)INSTRUCTIONS TO JOIN =09 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =09 (1) Pre-install =09 - - - - - - - - - - - - - - - - - =09 Pre-install the full version of Intercall Web Meeting now if you will be sh= aring documents, browsers or video during the meeting: =09 https://acmepacket.on.intercall.com/confmgr/clientPreinstall.jsp =09 =09 Or, join this web meeting at the scheduled start time without installation = by choosing the Light Version when prompted. The light version is ideal if = you will not be sharing visuals and video, are on a Mac(R) or do not have a= high-bandwidth connection. =09 =09 =09 (2) Join the Online Conference =09 - - - - - - - - - - - - - - - - - =09 Use the link below to join the web meeting at its scheduled start time: =09 https://acmepacket.on.intercall.com/confmgr/join_as_tempuser.jsp?eventId= =3D104577&invitationId=3D1307784&user=3Dhadriel =09 * Click the "Login" link located in the upper right-hand corner of the page= . =09 * Enter hadriel in the Conference ID/Username field. =09 * Please note: You will not be able to join the meeting until the moderator= has started it. =09 =09 =09 (3) Listen to the Audio Conference =09 If the service does not automatically dial your phone number or prompt you = to join an audio broadcast, use the information below to join the audio con= ference: =09 =09 - - - - - - - - - - - - - - - - - =09 Once you have joined the online conference, use the information below to jo= in the audio portion of the conference: =09 =09 Toll-free number: United States 8667589299 =09 International toll number: +1 4803662753 =09 Audio Conference ID: 1337084 =09 =09 International Toll-Free Dial-In Number(s): =20 Argentina Dial-in # : 08003330711 =20 Australia Dial-in # : 1800635054 =20 Austria Dial-in # : 0800296166 =20 Bahamas Dial-in # : 18002054782 =20 Belarus Dial-in # : 8800114 (SAC Code 5136) =20 Belgium Dial-in # : 080074091 =20 Bolivia Dial-in # : 800100103 (SAC Code 5129) =20 Brazil *SITF* Dial-in # : 08008916311 =20 Bulgaria Dial-in # : 008001100203 =20 Chile Dial-in # : 12300206931 =20 China N (China Netcom) Dial-in # : 108007130776 =20 China S (China Telecom) Dial-in # : 108001300744 =20 Colombia Dial-in # : 018009134022 =20 Costa Rica Dial-in # : 08000131036 =20 Croatia (Hrvatska) Dial-in # : 0800222650 =20 Cyprus Dial-in # : 80094945 =20 Czech Republic Dial-in # : 800142297 =20 Denmark Dial-in # : 80886120 =20 Dominican Republic Dial-in # : 18887518389 =20 Egypt Dial-in # : 23640083 (SAC Code 5139) =20 El Salvador Dial-in # : 8006375 =20 Finland Dial-in # : 0800112720 =20 France Dial-in # : 0800905437 =20 Germany Dial-in # : 08001821592 =20 Greece Dial-in # : 0080018092024132 =20 Hong Kong Dial-in # : 800901136 =20 Hungary Dial-in # : 0680018610 =20 Iceland Dial-in # : 8008083 =20 India *SITF* Dial-in # : 180030702200 =20 India *SITF* BSNL & MTNL Dial-in # : 0008001006245 =20 Indonesia Dial-in # : 0018030152021817 =20 Ireland Dial-in # : 1800559980 =20 Israel Dial-in # : 1809245950 =20 Italy Dial-in # : 800870179 =20 Jamaica Dial-in # : 18664255996 =20 Japan Dial-in # : 00531160597 =20 Kenya Dial-in # : 0800220115 (SAC Code 5139) =20 Korea (South) Dial-in # : 00308131716 =20 Lithuania Dial-in # : 880030328 =20 Luxembourg Dial-in # : 80025977 =20 Malaysia Dial-in # : 1800812568 =20 Mexico Dial-in # : 0018887579483 =20 Monaco Dial-in # : 80093352 =20 Netherlands Dial-in # : 08000226187 =20 New Zealand Dial-in # : 0800446292 =20 Nicaragua Dial-in # : 18000551 (SAC Code 5105) =20 Norway Dial-in # : 80015566 =20 Panama Dial-in # : 0018002024405 =20 Peru Dial-in # : 080053332 =20 Philippines *By Request* Dial-in # : 180011100963 =20 Poland Dial-in # : 008001113741 =20 Portugal Dial-in # : 800813478 =20 Romania Dial-in # : 0808035030 (SAC Code 5105) =20 Russian Federation Dial-in # : 81080025511012 =20 Saint Kitts and Nevis Dial-in # : 18007449305 =20 Singapore Dial-in # : 8001011804 =20 Slovak Republic Dial-in # : 0800042139 =20 South Africa Dial-in # : 0800980259 =20 Spain Dial-in # : 900941729 =20 Sweden Dial-in # : 020797609 =20 Switzerland Dial-in # : 0800561650 =20 Taiwan Dial-in # : 00801148742 =20 Thailand Dial-in # : 001800132024591 =20 Trinidad and Tobago Dial-in # : 18002024620 =20 Ukraine Dial-in # : 000180 (SAC Code 5139) =20 United Kingdom Dial-in # : 08082348621 =20 Uruguay Dial-in # : 00040190132 =20 Venezuela Dial-in # : 8001627195 =20 Local Dial-In Numbers Dial-In # =20 Australia Sydney - Dial-in # : 0-282239877=20 Austria Vienna - Dial-in # : 019281063=20 Belgium Antwerp - Dial-in # : 034000310=20 Belgium Brussels - Dial-in # : 024003531=20 Czech Republic Prague - Dial-in # : 239014953=20 Denmark Copenhagen - Dial-in # : 032714405=20 Finland Helsinki - Dial-in # : 358972519302=20 France Lyon - Dial-in # : 0426031129=20 France Marseille - Dial-in # : 0486060057=20 France Paris - Dial-in # : 0176748990=20 France Toulouse - Dial-in # : 0567804153=20 Germany Berlin - Dial-in # : 030590024927=20 Germany Frankfurt - Dial-in # : 06922221674=20 Germany Hamburg - Dial-in # : 040809020734=20 Hong Kong Hong Kong - Dial-in # : 0-30114603=20 Hungary Budapest - Dial-in # : 017779843=20 Ireland Dublin - Dial-in # : 012475629=20 Italy Milan - Dial-in # : 0236049233=20 Italy Rome - Dial-in # : 0645230543=20 Japan Tokyo - Dial-in # : 357674029=20 Luxembourg Luxembourg - Dial-in # : 24871233=20 Netherlands Amsterdam - Dial-in # : 0207075552=20 Netherlands Rotterdam - Dial-in # : 0107114853=20 Norway Oslo - Dial-in # : 22310519=20 Portugal Lisbon - Dial-in # : 01211201028=20 Singapore Singapore - Dial-in # : 66221028=20 Spain Barcelona - Dial-in # : 0934923275=20 Spain Madrid - Dial-in # : 914142527=20 Sweden Stockholm - Dial-in # : 0850619596=20 Switzerland Geneva - Dial-in # : 0225803308=20 Switzerland Zurich - Dial-in # : 0445807165=20 United Kingdom London - Dial-in # : 02031070236 =09 (+)TECHNICAL SUPPORT: =09 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =09 If you experience any issues joining this web meeting, please contact techn= ical support at: =09 =09 + U.S. and Canada: 877.549.2051, +1.303.928.3014 or webmeetingsupport@inter= call.com =09 + EMEA: +44 1452 556 226 or visual@intercalleurope.com =09 + APAC: 1800 468 225, +61 2 8295 9000 or profservices@intercallapac.com =09 =09 OR =09 http://www.intercall.com/customer-center/techSupport.php --_002_430FC6BDED356B4C8498F634416644A91A79F3CCF1mail_ Content-Type: text/plain; name="Online Conference Information.vcs" Content-Description: Online Conference Information.vcs Content-Disposition: attachment; filename="Online Conference Information.vcs"; size=3660; creation-date="Mon, 05 Apr 2010 19:27:15 GMT"; modification-date="Mon, 05 Apr 2010 19:27:15 GMT" Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VkVW RU5UDQpBVFRFTkRFRTtDTj0iSGFkcmllbCI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UlNWUD1UUlVF Ok1BSUxUTzpoa2FwbGFuQGFjbWVwYWNrZXQuY29tDQpBVFRFTkRFRTtDTj0iSGFkcmllbEthcGxh biI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UlNWUD1UUlVFOk1BSUxUTzpoa2FwbGFuQGFjbWVwYWNr ZXQuY29tDQpPUkdBTklaRVI6TUFJTFRPOmhrYXBsYW5AYWNtZXBhY2tldC5jb20NCkRUU1RBUlQ6 MjAxMDA0MDZUMTgwMDAwWg0KRFRFTkQ6MjAxMDA0MDZUMTkwMDAwWg0KTE9DQVRJT046DQpUUkFO U1A6T1BBUVVFDQpTRVFVRU5DRTowDQpVSUQ6MTA0NTc3QFJBSU5EQU5DRQ0KRFRTVEFNUDoyMDEw MDQwNVQyMzIwNTNaDQpERVNDUklQVElPTjpEZWFyIEhhZHJpZWwsXG5cblBsZWFzZSBmb2xsb3cg dGhlIHN0ZXBzIGJlbG93IHRvIGpvaW4gdGhpcyBtZWV0aW5nLCBob3N0ZWQgYnkgSGFkcmllbCBL YXBsYW4gZnJvbSBBY21lIFBhY2tldCwgdXNpbmcgSW50ZXJjYWxsIFdlYiBNZWV0aW5nLiAgUGxl YXNlIG5vdGU6ICBUaGUgbW9kZXJhdG9yIG1heSBoYXZlIGluY2x1ZGVkIGEgY2FsZW5kYXIgaW52 aXRlICguVkNTIGZpbGUpIHdpdGggdGhpcyBpbnZpdGF0aW9uLiBJZiBzbywgeW91IGNhbiBvcGVu IHRoZSBhdHRhY2htZW50IHRvIHNhdmUgaXQgaW4geW91ciBjYWxlbmRhci5cblxuICgrKUNPTkZF UkVOQ0UgU1VNTUFSWVxuPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT1cbiAgVGl0bGU6IEUyTUQgZGlzY3Vzc2lvblxuICAtIC0gLSAtIC0gLSAtIC0g LSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtXG4gIERhdGU6ICAgICAgICAgICAgICAg ICAgIEFwcmlsIDYsIDIwMTBcbiAgU3RhcnQgVGltZTogICAgICAgICAgICAgMDI6MDAgUE0gVVMv RWFzdGVyblxuICBEdXJhdGlvbjogICAgICAgICAgICAgICA2MCBtaW51dGVzXG4gIFByZXNlbnRl cjogICAgICAgICAgICAgIChub3QgcHJvdmlkZWQpXG4gICAgXG4JXG4gKCspQ09ORkVSRU5DRSBE RVNDUklQVElPTlxuPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0gXG5UaGlzIGlzIGEgRTJNRC9FTlVNIGRpc2N1c3Npb24gY29uZmVyZW5jZSBjYWxs L3dlYi1tZWV0aW5nXG5cblxuICgrKUlOU1RSVUNUSU9OUyBUTyBKT0lOXG49PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PVxuICgxKSBQcmUtaW5zdGFs bFxuICAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC1cblByZS1pbnN0YWxsIHRoZSBm dWxsIHZlcnNpb24gb2YgSW50ZXJjYWxsIFdlYiBNZWV0aW5nIG5vdyBpZiB5b3Ugd2lsbCBiZSBz aGFyaW5nIGRvY3VtZW50cywgYnJvd3NlcnMgb3IgdmlkZW8gZHVyaW5nIHRoZSBtZWV0aW5nOlxu IGh0dHBzOi8vYWNtZXBhY2tldC5vbi5pbnRlcmNhbGwuY29tL2NvbmZtZ3IvY2xpZW50UHJlaW5z dGFsbC5qc3BcblxuT3IsIGpvaW4gdGhpcyB3ZWIgbWVldGluZyBhdCB0aGUgc2NoZWR1bGVkIHN0 YXJ0IHRpbWUgd2l0aG91dCBpbnN0YWxsYXRpb24gYnkgY2hvb3NpbmcgdGhlIExpZ2h0IFZlcnNp b24gd2hlbiBwcm9tcHRlZC4gVGhlIGxpZ2h0IHZlcnNpb24gaXMgaWRlYWwgaWYgeW91IHdpbGwg bm90IGJlIHNoYXJpbmcgdmlzdWFscyBhbmQgdmlkZW8sIGFyZSBvbiBhIE1hYyhSKSBvciBkbyBu b3QgaGF2ZSBhIGhpZ2gtYmFuZHdpZHRoIGNvbm5lY3Rpb24uIFxuXG5cbiAoMikgSm9pbiB0aGUg T25saW5lIENvbmZlcmVuY2VcbiAgLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtXG5V c2UgdGhlIGxpbmsgYmVsb3cgdG8gam9pbiB0aGUgd2ViIG1lZXRpbmcgYXQgaXRzIHNjaGVkdWxl ZCBzdGFydCB0aW1lOlxuIGh0dHBzOi8vYWNtZXBhY2tldC5vbi5pbnRlcmNhbGwuY29tL2NvbmZt Z3Ivam9pbl9hc190ZW1wdXNlci5qc3A/ZXZlbnRJZD0xMDQ1NzcmaW52aXRhdGlvbklkPTEzMDc3 ODQmdXNlcj1oYWRyaWVsIFxuXG4qIENsaWNrIHRoZSAiTG9naW4iIGxpbmsgbG9jYXRlZCBpbiB0 aGUgdXBwZXIgcmlnaHQtaGFuZCBjb3JuZXIgb2YgdGhlIHBhZ2UuIFxuKiBFbnRlciBoYWRyaWVs IGluIHRoZSBDb25mZXJlbmNlIElEL1VzZXJuYW1lIGZpZWxkLCBhbG9uZyB3aXRoIHlvdXIgUElO L1Bhc3N3b3JkLlxuKiBQbGVhc2Ugbm90ZTogWW91IHdpbGwgbm90IGJlIGFibGUgdG8gam9pbiB0 aGUgbWVldGluZyB1bnRpbCB0aGUgbW9kZXJhdG9yIGhhcyBzdGFydGVkIGl0LlxuXG5cbiAoMykg TGlzdGVuIHRvIHRoZSBBdWRpbyBDb25mZXJlbmNlXG5JZiB0aGUgc2VydmljZSBkb2VzIG5vdCBh dXRvbWF0aWNhbGx5IGRpYWwgeW91ciBwaG9uZSBudW1iZXIgb3IgcHJvbXB0IHlvdSB0byBqb2lu IGFuIGF1ZGlvIGJyb2FkY2FzdCwgdXNlIHRoZSBpbmZvcm1hdGlvbiBiZWxvdyB0byBqb2luIHRo ZSBhdWRpbyBjb25mZXJlbmNlOlxuXG4gIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0g LVxuT25jZSB5b3UgaGF2ZSBqb2luZWQgdGhlIG9ubGluZSBjb25mZXJlbmNlLCB1c2UgdGhlIGlu Zm9ybWF0aW9uIGJlbG93IHRvIGpvaW4gdGhlIGF1ZGlvIHBvcnRpb24gb2YgdGhlIGNvbmZlcmVu Y2U6XG5cbiAgVG9sbC1mcmVlIG51bWJlcjogICAgICAgICAgICAgICAgVW5pdGVkIFN0YXRlcyA4 NjY3NTg5Mjk5XG4gIEludGVybmF0aW9uYWwgdG9sbCBudW1iZXI6ICArMSA0ODAzNjYyNzUzXG4g IEF1ZGlvIENvbmZlcmVuY2UgSUQ6ICAgICAgICAgICAxMzM3MDg0XG5cblNwZWNpYWwgSW5zdHJ1 Y3Rpb25zOiAgICAgICAgICAgICAgICAgICAgICAgICA8YnIvPiAgICAgICAgICAgICAgICAgICAg ICAgIFxuXG4JXG4JCSBcbiAoKylURUNITklDQUwgU1VQUE9SVDpcbj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09XG5JZiB5b3UgZXhwZXJpZW5jZSBh bnkgaXNzdWVzIGpvaW5pbmcgdGhpcyB3ZWIgbWVldGluZywgcGxlYXNlIGNvbnRhY3QgdGVjaG5p Y2FsIHN1cHBvcnQgYXQ6IFxuXG4rIFUuUy4gYW5kIENhbmFkYTogODc3LjU0OS4yMDUxLCArMS4z MDMuOTI4LjMwMTQgb3Igd2VibWVldGluZ3N1cHBvcnRAaW50ZXJjYWxsLmNvbVxuKyBFTUVBOiAr NDQgMTQ1MiA1NTYgMjI2IG9yIHZpc3VhbEBpbnRlcmNhbGxldXJvcGUuY29tXG4rIEFQQUM6IDE4 MDAgNDY4IDIyNSwgKzYxIDIgODI5NSA5MDAwIG9yIHByb2ZzZXJ2aWNlc0BpbnRlcmNhbGxhcGFj LmNvbSBcbiBcbk9SXG5odHRwOi8vd3d3LmludGVyY2FsbC5jb20vY3VzdG9tZXItY2VudGVyL3Rl Y2hTdXBwb3J0LnBocFxuXG5cblxuVGhhbmsgeW91LlxuXG5cblxuDQpTVU1NQVJZOllvdXIgSW5m b3JtYXRpb24gdG8gSm9pbiBhIFdlYiBNZWV0aW5nIC0gIkUyTUQgZGlzY3Vzc2lvbiINClBSSU9S SVRZOjUNCkNMQVNTOlBVQkxJQw0KQkVHSU46VkFMQVJNDQpUUklHR0VSOi1QVDE1TQ0KQUNUSU9O OkRJU1BMQVkNCkRFU0NSSVBUSU9OOlJlbWluZGVyDQpFTkQ6VkFMQVJNDQpFTkQ6VkVWRU5UDQpF TkQ6VkNBTEVOREFS --_002_430FC6BDED356B4C8498F634416644A91A79F3CCF1mail_-- From lconroy@insensate.co.uk Tue Apr 6 05:32: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 488FC3A68AA for ; Tue, 6 Apr 2010 05:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.5 X-Spam-Level: * X-Spam-Status: No, score=1.5 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_INVITATION=-2] 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 FGJm99F444Cu for ; Tue, 6 Apr 2010 05:32:04 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id EFB3D3A6837 for ; Tue, 6 Apr 2010 05:32:03 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 1F4D4122B8C; Tue, 6 Apr 2010 13:32:00 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3CCF1@mail> Date: Tue, 6 Apr 2010 13:32:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <430FC6BDED356B4C8498F634416644A91A79F3CCF1@mail> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD discussion conf call and web meeting info 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, 06 Apr 2010 12:32:06 -0000 Hi Hadriel, folks, given that I don't do PCs, I'm puzzled. The full version download says it only works on Windoz. >> Or, join this web meeting at the scheduled start time without = installation by choosing the Light Version when prompted. The light = version is ideal if you will not be sharing visuals and video, are on a = Mac(R) or do not have a high-bandwidth connection. --------------------^^^^ So, is this going to be an audio conference only? Basically, what's the plan for any documents -- will these be mailed to = the list? all the best, Lawrence On 6 Apr 2010, at 00:34, Hadriel Kaplan wrote: > Please follow the steps below to join this meeting, using Intercall = Web Meeting. Please note: The moderator may have included a calendar = invite (.VCS file) with this invitation. If so, you can open the = attachment to save it in your calendar. =09 > =09 > (+)CONFERENCE SUMMARY =09 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =09 > Title: E2MD discussion =09 > - - - - - - - - - - - - - - - - - - - - - - - - - =09 > Date: April 6, 2010 =09 > Start Time: 02:00 PM US/Eastern =09 > Duration: 60 minutes =09 > Presenter: (not provided) =09 > =09 > =09 > (+)CONFERENCE DESCRIPTION =09 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =09 > This is an E2MD/ENUM discussion conference call/web-meeting =09 > =09 > =09 > (+)INSTRUCTIONS TO JOIN =09 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =09 > (1) Pre-install =09 > - - - - - - - - - - - - - - - - - =09 > Pre-install the full version of Intercall Web Meeting now if you will = be sharing documents, browsers or video during the meeting: =09 > https://acmepacket.on.intercall.com/confmgr/clientPreinstall.jsp =09 > =09 > Or, join this web meeting at the scheduled start time without = installation by choosing the Light Version when prompted. The light = version is ideal if you will not be sharing visuals and video, are on a = Mac(R) or do not have a high-bandwidth connection. =09 >=20 > =09 > =09 > (2) Join the Online Conference =09 > - - - - - - - - - - - - - - - - - =09 > Use the link below to join the web meeting at its scheduled start = time: =09 > = https://acmepacket.on.intercall.com/confmgr/join_as_tempuser.jsp?eventId=3D= 104577&invitationId=3D1307784&user=3Dhadriel >=20 > =09 > * Click the "Login" link located in the upper right-hand corner of the = page. =09 > * Enter hadriel in the Conference ID/Username field. =09 > * Please note: You will not be able to join the meeting until the = moderator has started it. =09 > =09 > =09 > (3) Listen to the Audio Conference =09 > If the service does not automatically dial your phone number or prompt = you to join an audio broadcast, use the information below to join the = audio conference: =09 > =09 > - - - - - - - - - - - - - - - - - =09 > Once you have joined the online conference, use the information below = to join the audio portion of the conference: =09 > =09 > Toll-free number: United States 8667589299 =09 > International toll number: +1 4803662753 =09 > Audio Conference ID: 1337084 =09 > =09 > International Toll-Free Dial-In Number(s): >=20 > Argentina Dial-in # : 08003330711 =20 > Australia Dial-in # : 1800635054 =20 > Austria Dial-in # : 0800296166 =20 > Bahamas Dial-in # : 18002054782 =20 > Belarus Dial-in # : 8800114 (SAC Code 5136) =20 > Belgium Dial-in # : 080074091 =20 > Bolivia Dial-in # : 800100103 (SAC Code 5129) =20 > Brazil *SITF* Dial-in # : 08008916311 =20 > Bulgaria Dial-in # : 008001100203 =20 > Chile Dial-in # : 12300206931 =20 > China N (China Netcom) Dial-in # : 108007130776 =20 > China S (China Telecom) Dial-in # : 108001300744 =20 > Colombia Dial-in # : 018009134022 =20 > Costa Rica Dial-in # : 08000131036 =20 > Croatia (Hrvatska) Dial-in # : 0800222650 =20 > Cyprus Dial-in # : 80094945 =20 > Czech Republic Dial-in # : 800142297 =20 > Denmark Dial-in # : 80886120 =20 > Dominican Republic Dial-in # : 18887518389 =20 > Egypt Dial-in # : 23640083 (SAC Code 5139) =20 > El Salvador Dial-in # : 8006375 =20 > Finland Dial-in # : 0800112720 =20 > France Dial-in # : 0800905437 =20 > Germany Dial-in # : 08001821592 =20 > Greece Dial-in # : 0080018092024132 =20 > Hong Kong Dial-in # : 800901136 =20 > Hungary Dial-in # : 0680018610 =20 > Iceland Dial-in # : 8008083 =20 > India *SITF* Dial-in # : 180030702200 =20 > India *SITF* BSNL & MTNL Dial-in # : 0008001006245 =20 > Indonesia Dial-in # : 0018030152021817 =20 > Ireland Dial-in # : 1800559980 =20 > Israel Dial-in # : 1809245950 =20 > Italy Dial-in # : 800870179 =20 > Jamaica Dial-in # : 18664255996 =20 > Japan Dial-in # : 00531160597 =20 > Kenya Dial-in # : 0800220115 (SAC Code 5139) =20 > Korea (South) Dial-in # : 00308131716 =20 > Lithuania Dial-in # : 880030328 =20 > Luxembourg Dial-in # : 80025977 =20 > Malaysia Dial-in # : 1800812568 =20 > Mexico Dial-in # : 0018887579483 =20 > Monaco Dial-in # : 80093352 =20 > Netherlands Dial-in # : 08000226187 =20 > New Zealand Dial-in # : 0800446292 =20 > Nicaragua Dial-in # : 18000551 (SAC Code 5105) =20 > Norway Dial-in # : 80015566 =20 > Panama Dial-in # : 0018002024405 =20 > Peru Dial-in # : 080053332 =20 > Philippines *By Request* Dial-in # : 180011100963 =20 > Poland Dial-in # : 008001113741 =20 > Portugal Dial-in # : 800813478 =20 > Romania Dial-in # : 0808035030 (SAC Code 5105) =20 > Russian Federation Dial-in # : 81080025511012 =20 > Saint Kitts and Nevis Dial-in # : 18007449305 =20 > Singapore Dial-in # : 8001011804 =20 > Slovak Republic Dial-in # : 0800042139 =20 > South Africa Dial-in # : 0800980259 =20 > Spain Dial-in # : 900941729 =20 > Sweden Dial-in # : 020797609 =20 > Switzerland Dial-in # : 0800561650 =20 > Taiwan Dial-in # : 00801148742 =20 > Thailand Dial-in # : 001800132024591 =20 > Trinidad and Tobago Dial-in # : 18002024620 =20 > Ukraine Dial-in # : 000180 (SAC Code 5139) =20 > United Kingdom Dial-in # : 08082348621 =20 > Uruguay Dial-in # : 00040190132 =20 > Venezuela Dial-in # : 8001627195 =20 > Local Dial-In Numbers Dial-In # =20 > Australia Sydney - Dial-in # : 0-282239877=20 > Austria Vienna - Dial-in # : 019281063=20 > Belgium Antwerp - Dial-in # : 034000310=20 > Belgium Brussels - Dial-in # : 024003531=20 > Czech Republic Prague - Dial-in # : 239014953=20 > Denmark Copenhagen - Dial-in # : 032714405=20 > Finland Helsinki - Dial-in # : 358972519302=20 > France Lyon - Dial-in # : 0426031129=20 > France Marseille - Dial-in # : 0486060057=20 > France Paris - Dial-in # : 0176748990=20 > France Toulouse - Dial-in # : 0567804153=20 > Germany Berlin - Dial-in # : 030590024927=20 > Germany Frankfurt - Dial-in # : 06922221674=20 > Germany Hamburg - Dial-in # : 040809020734=20 > Hong Kong Hong Kong - Dial-in # : 0-30114603=20 > Hungary Budapest - Dial-in # : 017779843=20 > Ireland Dublin - Dial-in # : 012475629=20 > Italy Milan - Dial-in # : 0236049233=20 > Italy Rome - Dial-in # : 0645230543=20 > Japan Tokyo - Dial-in # : 357674029=20 > Luxembourg Luxembourg - Dial-in # : 24871233=20 > Netherlands Amsterdam - Dial-in # : 0207075552=20 > Netherlands Rotterdam - Dial-in # : 0107114853=20 > Norway Oslo - Dial-in # : 22310519=20 > Portugal Lisbon - Dial-in # : 01211201028=20 > Singapore Singapore - Dial-in # : 66221028=20 > Spain Barcelona - Dial-in # : 0934923275=20 > Spain Madrid - Dial-in # : 914142527=20 > Sweden Stockholm - Dial-in # : 0850619596=20 > Switzerland Geneva - Dial-in # : 0225803308=20 > Switzerland Zurich - Dial-in # : 0445807165=20 > United Kingdom London - Dial-in # : 02031070236 >=20 >=20 > =09 > (+)TECHNICAL SUPPORT: =09 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =09 > If you experience any issues joining this web meeting, please contact = technical support at: =09 > =09 > + U.S. and Canada: 877.549.2051, +1.303.928.3014 or = webmeetingsupport@intercall.com =09 > + EMEA: +44 1452 556 226 or visual@intercalleurope.com =09 > + APAC: 1800 468 225, +61 2 8295 9000 or = profservices@intercallapac.com =09 > =09 > OR =09 > http://www.intercall.com/customer-center/techSupport.php >=20 >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From dean.willis@softarmor.com Tue Apr 6 07:03:01 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 76B4F3A68AC for ; Tue, 6 Apr 2010 07:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_20=-0.74] 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 34dcijYJzAmP for ; Tue, 6 Apr 2010 07:03:00 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 57FA23A6808 for ; Tue, 6 Apr 2010 07:03:00 -0700 (PDT) Received: from localhost.localdomain (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o36E2qC4007775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Apr 2010 09:02:55 -0500 X-User-Agent: K-9 Mail for Android In-Reply-To: References: <430FC6BDED356B4C8498F634416644A91A79F3CCF1@mail> Content-Type: multipart/mixed; boundary="----WGAHAGXMCBE4004TMBET84C5AFISYV" MIME-Version: 1.0 From: Dean Willis Date: Tue, 06 Apr 2010 09:02:51 -0500 To: Lawrence Conroy , Hadriel Kaplan Message-ID: <996d8284-94d4-44d6-83e4-e55cbfbbd227@email.android.com> Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD discussion conf call and web meeting info 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, 06 Apr 2010 14:03:01 -0000 ------WGAHAGXMCBE4004TMBET84C5AFISYV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CiJMYXdyZW5jZSBDb25yb3kiIDxsY29ucm95QGluc2Vuc2F0ZS5jby51az4gd3JvdGU6Cgo+SGkg SGFkcmllbCwgZm9sa3MsCj4gZ2l2ZW4gdGhhdCBJIGRvbid0IGRvIFBDcywgSSdtIHB1enpsZWQu Cj5UaGUgZnVsbCB2ZXJzaW9uIGRvd25sb2FkIHNheXMgaXQgb25seSB3b3JrcyBvbiBXaW5kb3ou Cj4+PiBPciwgam9pbiB0aGlzIHdlYiBtZWV0aW5nIGF0IHRoZSBzY2hlZHVsZWQgc3RhcnQgdGlt ZSB3aXRob3V0IGluc3RhbGxhdGlvbiBieSBjaG9vc2luZyB0aGUgTGlnaHQgVmVyc2lvbiB3aGVu IHByb21wdGVkLiBUaGUgbGlnaHQgdmVyc2lvbiBpcyBpZGVhbCBpZiB5b3Ugd2lsbCBub3QgYmUg c2hhcmluZyB2aXN1YWxzIGFuZCB2aWRlbywgYXJlIG9uIGEgTWFjKFIpIG9yIGRvIG5vdCBoYXZl IGEgaGlnaC1iYW5kd2lkdGggY29ubmVjdGlvbi4KPi0tLS0tLS0tLS0tLS0tLS0tLS0tXl5eXgo+ U28sIGlzIHRoaXMgZ29pbmcgdG8gYmUgYW4gYXVkaW8gY29uZmVyZW5jZSBvbmx5Pwo+Cj5CYXNp Y2FsbHksIHdoYXQncyB0aGUgcGxhbiBmb3IgYW55IGRvY3VtZW50cyAtLSB3aWxsIHRoZXNlIGJl IG1haWxlZCB0byB0aGUgbGlzdD8KPgoKSSBiZWxpZXZlIHRoYXQgd2hlbiB0aGV5IHNheSAic2hh cmUiIHRoZXkgbWVhbiAicHJlc2VudCIuIExpdGUgY2FuIHZpZXcgYnV0IG5vdCBwcmVzZW50IHNs aWRlcy4KLS0gCkRlYW4gV2lsbGlz ------WGAHAGXMCBE4004TMBET84C5AFISYV-- From HKaplan@acmepacket.com Tue Apr 6 07:42: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 EBE433A691D for ; Tue, 6 Apr 2010 07:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.676 X-Spam-Level: X-Spam-Status: No, score=0.676 tagged_above=-999 required=5 tests=[AWL=-0.824, BAYES_99=3.5, GB_I_INVITATION=-2] 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 231d4+6C5+q2 for ; Tue, 6 Apr 2010 07:42:49 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 23FA33A685D for ; Tue, 6 Apr 2010 07:42:48 -0700 (PDT) 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, 6 Apr 2010 10:42:42 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 6 Apr 2010 10:42:42 -0400 From: Hadriel Kaplan To: Lawrence Conroy Date: Tue, 6 Apr 2010 10:42:23 -0400 Thread-Topic: [e2md] E2MD discussion conf call and web meeting info Thread-Index: AcrVhUov7qzDkIQuTmWHO20ICi4U8QADDWJQ Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3CDEB@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3CCF1@mail> 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 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD discussion conf call and web meeting info 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, 06 Apr 2010 14:42:51 -0000 You only need the full version if you are the one sharing/presenting a doc/= desktop, but Lite version can see them. I just confirmed with a Mac user t= hat it works fine for him. I do plan to create some slides just to help the discussion along, but noth= ing big. -hadriel > -----Original Message----- > From: Lawrence Conroy [mailto:lconroy@insensate.co.uk] > Sent: Tuesday, April 06, 2010 8:32 AM > To: Hadriel Kaplan > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] E2MD discussion conf call and web meeting info >=20 > Hi Hadriel, folks, > given that I don't do PCs, I'm puzzled. > The full version download says it only works on Windoz. > >> Or, join this web meeting at the scheduled start time without > installation by choosing the Light Version when prompted. The light > version is ideal if you will not be sharing visuals and video, are on a > Mac(R) or do not have a high-bandwidth connection. >=20 > --------------------^^^^ > So, is this going to be an audio conference only? >=20 > Basically, what's the plan for any documents -- will these be mailed to > the list? >=20 > all the best, > Lawrence >=20 > On 6 Apr 2010, at 00:34, Hadriel Kaplan wrote: > > Please follow the steps below to join this meeting, using Intercall Web > Meeting. Please note: The moderator may have included a calendar invite > (.VCS file) with this invitation. If so, you can open the attachment to > save it in your calendar. > > > > (+)CONFERENCE SUMMARY > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > Title: E2MD discussion > > - - - - - - - - - - - - - - - - - - - - - - - - - > > Date: April 6, 2010 > > Start Time: 02:00 PM US/Eastern > > Duration: 60 minutes > > Presenter: (not provided) > > > > > > (+)CONFERENCE DESCRIPTION > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > This is an E2MD/ENUM discussion conference call/web-meeting > > > > > > (+)INSTRUCTIONS TO JOIN > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > (1) Pre-install > > - - - - - - - - - - - - - - - - - > > Pre-install the full version of Intercall Web Meeting now if you will b= e > sharing documents, browsers or video during the meeting: > > https://acmepacket.on.intercall.com/confmgr/clientPreinstall.jsp > > > > Or, join this web meeting at the scheduled start time without > installation by choosing the Light Version when prompted. The light > version is ideal if you will not be sharing visuals and video, are on a > Mac(R) or do not have a high-bandwidth connection. > > > > > > > > (2) Join the Online Conference > > - - - - - - - - - - - - - - - - - > > Use the link below to join the web meeting at its scheduled start time: >=20 > > > https://acmepacket.on.intercall.com/confmgr/join_as_tempuser.jsp?eventId= =3D1 > 04577&invitationId=3D1307784&user=3Dhadriel > > > > > > * Click the "Login" link located in the upper right-hand corner of the > page. > > * Enter hadriel in the Conference ID/Username field. > > * Please note: You will not be able to join the meeting until the > moderator has started it. > > > > > > (3) Listen to the Audio Conference > > If the service does not automatically dial your phone number or prompt > you to join an audio broadcast, use the information below to join the > audio conference: > > > > - - - - - - - - - - - - - - - - - > > Once you have joined the online conference, use the information below t= o > join the audio portion of the conference: > > > > Toll-free number: United States 8667589299 > > International toll number: +1 4803662753 > > Audio Conference ID: 1337084 > > > > International Toll-Free Dial-In Number(s): > > > > Argentina Dial-in # : 08003330711 > > Australia Dial-in # : 1800635054 > > Austria Dial-in # : 0800296166 > > Bahamas Dial-in # : 18002054782 > > Belarus Dial-in # : 8800114 (SAC Code 5136) > > Belgium Dial-in # : 080074091 > > Bolivia Dial-in # : 800100103 (SAC Code 5129) > > Brazil *SITF* Dial-in # : 08008916311 > > Bulgaria Dial-in # : 008001100203 > > Chile Dial-in # : 12300206931 > > China N (China Netcom) Dial-in # : 108007130776 > > China S (China Telecom) Dial-in # : 108001300744 > > Colombia Dial-in # : 018009134022 > > Costa Rica Dial-in # : 08000131036 > > Croatia (Hrvatska) Dial-in # : 0800222650 > > Cyprus Dial-in # : 80094945 > > Czech Republic Dial-in # : 800142297 > > Denmark Dial-in # : 80886120 > > Dominican Republic Dial-in # : 18887518389 > > Egypt Dial-in # : 23640083 (SAC Code 5139) > > El Salvador Dial-in # : 8006375 > > Finland Dial-in # : 0800112720 > > France Dial-in # : 0800905437 > > Germany Dial-in # : 08001821592 > > Greece Dial-in # : 0080018092024132 > > Hong Kong Dial-in # : 800901136 > > Hungary Dial-in # : 0680018610 > > Iceland Dial-in # : 8008083 > > India *SITF* Dial-in # : 180030702200 > > India *SITF* BSNL & MTNL Dial-in # : 0008001006245 > > Indonesia Dial-in # : 0018030152021817 > > Ireland Dial-in # : 1800559980 > > Israel Dial-in # : 1809245950 > > Italy Dial-in # : 800870179 > > Jamaica Dial-in # : 18664255996 > > Japan Dial-in # : 00531160597 > > Kenya Dial-in # : 0800220115 (SAC Code 5139) > > Korea (South) Dial-in # : 00308131716 > > Lithuania Dial-in # : 880030328 > > Luxembourg Dial-in # : 80025977 > > Malaysia Dial-in # : 1800812568 > > Mexico Dial-in # : 0018887579483 > > Monaco Dial-in # : 80093352 > > Netherlands Dial-in # : 08000226187 > > New Zealand Dial-in # : 0800446292 > > Nicaragua Dial-in # : 18000551 (SAC Code 5105) > > Norway Dial-in # : 80015566 > > Panama Dial-in # : 0018002024405 > > Peru Dial-in # : 080053332 > > Philippines *By Request* Dial-in # : 180011100963 > > Poland Dial-in # : 008001113741 > > Portugal Dial-in # : 800813478 > > Romania Dial-in # : 0808035030 (SAC Code 5105) > > Russian Federation Dial-in # : 81080025511012 > > Saint Kitts and Nevis Dial-in # : 18007449305 > > Singapore Dial-in # : 8001011804 > > Slovak Republic Dial-in # : 0800042139 > > South Africa Dial-in # : 0800980259 > > Spain Dial-in # : 900941729 > > Sweden Dial-in # : 020797609 > > Switzerland Dial-in # : 0800561650 > > Taiwan Dial-in # : 00801148742 > > Thailand Dial-in # : 001800132024591 > > Trinidad and Tobago Dial-in # : 18002024620 > > Ukraine Dial-in # : 000180 (SAC Code 5139) > > United Kingdom Dial-in # : 08082348621 > > Uruguay Dial-in # : 00040190132 > > Venezuela Dial-in # : 8001627195 > > Local Dial-In Numbers Dial-In # > > Australia Sydney - Dial-in # : 0-282239877 > > Austria Vienna - Dial-in # : 019281063 > > Belgium Antwerp - Dial-in # : 034000310 > > Belgium Brussels - Dial-in # : 024003531 > > Czech Republic Prague - Dial-in # : 239014953 > > Denmark Copenhagen - Dial-in # : 032714405 > > Finland Helsinki - Dial-in # : 358972519302 > > France Lyon - Dial-in # : 0426031129 > > France Marseille - Dial-in # : 0486060057 > > France Paris - Dial-in # : 0176748990 > > France Toulouse - Dial-in # : 0567804153 > > Germany Berlin - Dial-in # : 030590024927 > > Germany Frankfurt - Dial-in # : 06922221674 > > Germany Hamburg - Dial-in # : 040809020734 > > Hong Kong Hong Kong - Dial-in # : 0-30114603 > > Hungary Budapest - Dial-in # : 017779843 > > Ireland Dublin - Dial-in # : 012475629 > > Italy Milan - Dial-in # : 0236049233 > > Italy Rome - Dial-in # : 0645230543 > > Japan Tokyo - Dial-in # : 357674029 > > Luxembourg Luxembourg - Dial-in # : 24871233 > > Netherlands Amsterdam - Dial-in # : 0207075552 > > Netherlands Rotterdam - Dial-in # : 0107114853 > > Norway Oslo - Dial-in # : 22310519 > > Portugal Lisbon - Dial-in # : 01211201028 > > Singapore Singapore - Dial-in # : 66221028 > > Spain Barcelona - Dial-in # : 0934923275 > > Spain Madrid - Dial-in # : 914142527 > > Sweden Stockholm - Dial-in # : 0850619596 > > Switzerland Geneva - Dial-in # : 0225803308 > > Switzerland Zurich - Dial-in # : 0445807165 > > United Kingdom London - Dial-in # : 02031070236 > > > > > > > > (+)TECHNICAL SUPPORT: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > If you experience any issues joining this web meeting, please contact > technical support at: > > > > + U.S. and Canada: 877.549.2051, +1.303.928.3014 or > webmeetingsupport@intercall.com > > + EMEA: +44 1452 556 226 or visual@intercalleurope.com > > + APAC: 1800 468 225, +61 2 8295 9000 or profservices@intercallapac.com >=20 > > > > OR > > http://www.intercall.com/customer-center/techSupport.php > > > > > > Information.vcs>_______________________________________________ > > e2md mailing list > > e2md@ietf.org > > https://www.ietf.org/mailman/listinfo/e2md From bernie@ietf.hoeneisen.ch Tue Apr 6 07:58:47 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 A2C253A68DB for ; Tue, 6 Apr 2010 07:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.5 X-Spam-Level: * X-Spam-Status: No, score=1.5 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_INVITATION=-2] 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 Fq440l+TOOgL for ; Tue, 6 Apr 2010 07:58:46 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 043233A6838 for ; Tue, 6 Apr 2010 07:58:45 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NzAEi-0002dB-Uo; Tue, 06 Apr 2010 16:58:41 +0200 Date: Tue, 6 Apr 2010 16:58:40 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Hadriel Kaplan In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3CDEB@mail> Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79F3CCF1@mail> <430FC6BDED356B4C8498F634416644A91A79F3CDEB@mail> 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: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD discussion conf call and web meeting info 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, 06 Apr 2010 14:58:47 -0000 Hi Hadriel How about Linux support? I intend to make some slides summarizing the "Divide and Conquer" approach, i.e. how the problem space could be split into a short and a long term solution, roughly what I proposed on the list recently. cheers, Bernie On Tue, 6 Apr 2010, Hadriel Kaplan wrote: > > You only need the full version if you are the one sharing/presenting a > doc/desktop, but Lite version can see them. I just confirmed with a Mac > user that it works fine for him. > > I do plan to create some slides just to help the discussion along, but > nothing big. > > -hadriel > >> -----Original Message----- >> From: Lawrence Conroy [mailto:lconroy@insensate.co.uk] >> Sent: Tuesday, April 06, 2010 8:32 AM >> To: Hadriel Kaplan >> Cc: E.164 To MetaData BOF discussion list >> Subject: Re: [e2md] E2MD discussion conf call and web meeting info >> >> Hi Hadriel, folks, >> given that I don't do PCs, I'm puzzled. >> The full version download says it only works on Windoz. >>>> Or, join this web meeting at the scheduled start time without >> installation by choosing the Light Version when prompted. The light >> version is ideal if you will not be sharing visuals and video, are on a >> Mac(R) or do not have a high-bandwidth connection. >> >> --------------------^^^^ >> So, is this going to be an audio conference only? >> >> Basically, what's the plan for any documents -- will these be mailed to >> the list? >> >> all the best, >> Lawrence >> >> On 6 Apr 2010, at 00:34, Hadriel Kaplan wrote: >>> Please follow the steps below to join this meeting, using Intercall Web >> Meeting. Please note: The moderator may have included a calendar invite >> (.VCS file) with this invitation. If so, you can open the attachment to >> save it in your calendar. >>> >>> (+)CONFERENCE SUMMARY >>> ===================================================== >>> Title: E2MD discussion >>> - - - - - - - - - - - - - - - - - - - - - - - - - >>> Date: April 6, 2010 >>> Start Time: 02:00 PM US/Eastern >>> Duration: 60 minutes >>> Presenter: (not provided) >>> >>> >>> (+)CONFERENCE DESCRIPTION >>> ===================================================== >>> This is an E2MD/ENUM discussion conference call/web-meeting >>> >>> >>> (+)INSTRUCTIONS TO JOIN >>> ===================================================== >>> (1) Pre-install >>> - - - - - - - - - - - - - - - - - >>> Pre-install the full version of Intercall Web Meeting now if you will be >> sharing documents, browsers or video during the meeting: >>> https://acmepacket.on.intercall.com/confmgr/clientPreinstall.jsp >>> >>> Or, join this web meeting at the scheduled start time without >> installation by choosing the Light Version when prompted. The light >> version is ideal if you will not be sharing visuals and video, are on a >> Mac(R) or do not have a high-bandwidth connection. >>> >>> >>> >>> (2) Join the Online Conference >>> - - - - - - - - - - - - - - - - - >>> Use the link below to join the web meeting at its scheduled start time: >> >>> >> https://acmepacket.on.intercall.com/confmgr/join_as_tempuser.jsp?eventId=1 >> 04577&invitationId=1307784&user=hadriel >>> >>> >>> * Click the "Login" link located in the upper right-hand corner of the >> page. >>> * Enter hadriel in the Conference ID/Username field. >>> * Please note: You will not be able to join the meeting until the >> moderator has started it. >>> >>> >>> (3) Listen to the Audio Conference >>> If the service does not automatically dial your phone number or prompt >> you to join an audio broadcast, use the information below to join the >> audio conference: >>> >>> - - - - - - - - - - - - - - - - - >>> Once you have joined the online conference, use the information below to >> join the audio portion of the conference: >>> >>> Toll-free number: United States 8667589299 >>> International toll number: +1 4803662753 >>> Audio Conference ID: 1337084 >>> >>> International Toll-Free Dial-In Number(s): >>> >>> Argentina Dial-in # : 08003330711 >>> Australia Dial-in # : 1800635054 >>> Austria Dial-in # : 0800296166 >>> Bahamas Dial-in # : 18002054782 >>> Belarus Dial-in # : 8800114 (SAC Code 5136) >>> Belgium Dial-in # : 080074091 >>> Bolivia Dial-in # : 800100103 (SAC Code 5129) >>> Brazil *SITF* Dial-in # : 08008916311 >>> Bulgaria Dial-in # : 008001100203 >>> Chile Dial-in # : 12300206931 >>> China N (China Netcom) Dial-in # : 108007130776 >>> China S (China Telecom) Dial-in # : 108001300744 >>> Colombia Dial-in # : 018009134022 >>> Costa Rica Dial-in # : 08000131036 >>> Croatia (Hrvatska) Dial-in # : 0800222650 >>> Cyprus Dial-in # : 80094945 >>> Czech Republic Dial-in # : 800142297 >>> Denmark Dial-in # : 80886120 >>> Dominican Republic Dial-in # : 18887518389 >>> Egypt Dial-in # : 23640083 (SAC Code 5139) >>> El Salvador Dial-in # : 8006375 >>> Finland Dial-in # : 0800112720 >>> France Dial-in # : 0800905437 >>> Germany Dial-in # : 08001821592 >>> Greece Dial-in # : 0080018092024132 >>> Hong Kong Dial-in # : 800901136 >>> Hungary Dial-in # : 0680018610 >>> Iceland Dial-in # : 8008083 >>> India *SITF* Dial-in # : 180030702200 >>> India *SITF* BSNL & MTNL Dial-in # : 0008001006245 >>> Indonesia Dial-in # : 0018030152021817 >>> Ireland Dial-in # : 1800559980 >>> Israel Dial-in # : 1809245950 >>> Italy Dial-in # : 800870179 >>> Jamaica Dial-in # : 18664255996 >>> Japan Dial-in # : 00531160597 >>> Kenya Dial-in # : 0800220115 (SAC Code 5139) >>> Korea (South) Dial-in # : 00308131716 >>> Lithuania Dial-in # : 880030328 >>> Luxembourg Dial-in # : 80025977 >>> Malaysia Dial-in # : 1800812568 >>> Mexico Dial-in # : 0018887579483 >>> Monaco Dial-in # : 80093352 >>> Netherlands Dial-in # : 08000226187 >>> New Zealand Dial-in # : 0800446292 >>> Nicaragua Dial-in # : 18000551 (SAC Code 5105) >>> Norway Dial-in # : 80015566 >>> Panama Dial-in # : 0018002024405 >>> Peru Dial-in # : 080053332 >>> Philippines *By Request* Dial-in # : 180011100963 >>> Poland Dial-in # : 008001113741 >>> Portugal Dial-in # : 800813478 >>> Romania Dial-in # : 0808035030 (SAC Code 5105) >>> Russian Federation Dial-in # : 81080025511012 >>> Saint Kitts and Nevis Dial-in # : 18007449305 >>> Singapore Dial-in # : 8001011804 >>> Slovak Republic Dial-in # : 0800042139 >>> South Africa Dial-in # : 0800980259 >>> Spain Dial-in # : 900941729 >>> Sweden Dial-in # : 020797609 >>> Switzerland Dial-in # : 0800561650 >>> Taiwan Dial-in # : 00801148742 >>> Thailand Dial-in # : 001800132024591 >>> Trinidad and Tobago Dial-in # : 18002024620 >>> Ukraine Dial-in # : 000180 (SAC Code 5139) >>> United Kingdom Dial-in # : 08082348621 >>> Uruguay Dial-in # : 00040190132 >>> Venezuela Dial-in # : 8001627195 >>> Local Dial-In Numbers Dial-In # >>> Australia Sydney - Dial-in # : 0-282239877 >>> Austria Vienna - Dial-in # : 019281063 >>> Belgium Antwerp - Dial-in # : 034000310 >>> Belgium Brussels - Dial-in # : 024003531 >>> Czech Republic Prague - Dial-in # : 239014953 >>> Denmark Copenhagen - Dial-in # : 032714405 >>> Finland Helsinki - Dial-in # : 358972519302 >>> France Lyon - Dial-in # : 0426031129 >>> France Marseille - Dial-in # : 0486060057 >>> France Paris - Dial-in # : 0176748990 >>> France Toulouse - Dial-in # : 0567804153 >>> Germany Berlin - Dial-in # : 030590024927 >>> Germany Frankfurt - Dial-in # : 06922221674 >>> Germany Hamburg - Dial-in # : 040809020734 >>> Hong Kong Hong Kong - Dial-in # : 0-30114603 >>> Hungary Budapest - Dial-in # : 017779843 >>> Ireland Dublin - Dial-in # : 012475629 >>> Italy Milan - Dial-in # : 0236049233 >>> Italy Rome - Dial-in # : 0645230543 >>> Japan Tokyo - Dial-in # : 357674029 >>> Luxembourg Luxembourg - Dial-in # : 24871233 >>> Netherlands Amsterdam - Dial-in # : 0207075552 >>> Netherlands Rotterdam - Dial-in # : 0107114853 >>> Norway Oslo - Dial-in # : 22310519 >>> Portugal Lisbon - Dial-in # : 01211201028 >>> Singapore Singapore - Dial-in # : 66221028 >>> Spain Barcelona - Dial-in # : 0934923275 >>> Spain Madrid - Dial-in # : 914142527 >>> Sweden Stockholm - Dial-in # : 0850619596 >>> Switzerland Geneva - Dial-in # : 0225803308 >>> Switzerland Zurich - Dial-in # : 0445807165 >>> United Kingdom London - Dial-in # : 02031070236 >>> >>> >>> >>> (+)TECHNICAL SUPPORT: >>> ===================================================== >>> If you experience any issues joining this web meeting, please contact >> technical support at: >>> >>> + U.S. and Canada: 877.549.2051, +1.303.928.3014 or >> webmeetingsupport@intercall.com >>> + EMEA: +44 1452 556 226 or visual@intercalleurope.com >>> + APAC: 1800 468 225, +61 2 8295 9000 or profservices@intercallapac.com >> >>> >>> OR >>> http://www.intercall.com/customer-center/techSupport.php >>> >>> >>> > Information.vcs>_______________________________________________ >>> 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 bmanning@karoshi.com Tue Apr 6 08:19:14 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 286D33A6984 for ; Tue, 6 Apr 2010 08:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_99=3.5, GB_I_INVITATION=-2, 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 tyQ8naaNOS4I for ; Tue, 6 Apr 2010 08:19:12 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 3C91B3A694A for ; Tue, 6 Apr 2010 08:19:06 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o36FIb58017944; Tue, 6 Apr 2010 15:18:39 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o36FIaSK017942; Tue, 6 Apr 2010 15:18:36 GMT Date: Tue, 6 Apr 2010 15:18:31 +0000 From: bmanning@vacation.karoshi.com To: Hadriel Kaplan Message-ID: <20100406151831.GB12993@vacation.karoshi.com.> References: <430FC6BDED356B4C8498F634416644A91A79F3CCF1@mail> <430FC6BDED356B4C8498F634416644A91A79F3CDEB@mail> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3CDEB@mail> User-Agent: Mutt/1.4.1i Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD discussion conf call and web meeting info 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, 06 Apr 2010 15:19:14 -0000 please post any slides that will be used. --bill On Tue, Apr 06, 2010 at 10:42:23AM -0400, Hadriel Kaplan wrote: > > You only need the full version if you are the one sharing/presenting a doc/desktop, but Lite version can see them. I just confirmed with a Mac user that it works fine for him. > > I do plan to create some slides just to help the discussion along, but nothing big. > > -hadriel > > > -----Original Message----- > > From: Lawrence Conroy [mailto:lconroy@insensate.co.uk] > > Sent: Tuesday, April 06, 2010 8:32 AM > > To: Hadriel Kaplan > > Cc: E.164 To MetaData BOF discussion list > > Subject: Re: [e2md] E2MD discussion conf call and web meeting info > > > > Hi Hadriel, folks, > > given that I don't do PCs, I'm puzzled. > > The full version download says it only works on Windoz. > > >> Or, join this web meeting at the scheduled start time without > > installation by choosing the Light Version when prompted. The light > > version is ideal if you will not be sharing visuals and video, are on a > > Mac(R) or do not have a high-bandwidth connection. > > > > --------------------^^^^ > > So, is this going to be an audio conference only? > > > > Basically, what's the plan for any documents -- will these be mailed to > > the list? > > > > all the best, > > Lawrence > > > > On 6 Apr 2010, at 00:34, Hadriel Kaplan wrote: > > > Please follow the steps below to join this meeting, using Intercall Web > > Meeting. Please note: The moderator may have included a calendar invite > > (.VCS file) with this invitation. If so, you can open the attachment to > > save it in your calendar. > > > > > > (+)CONFERENCE SUMMARY > > > ===================================================== > > > Title: E2MD discussion > > > - - - - - - - - - - - - - - - - - - - - - - - - - > > > Date: April 6, 2010 > > > Start Time: 02:00 PM US/Eastern > > > Duration: 60 minutes > > > Presenter: (not provided) > > > > > > > > > (+)CONFERENCE DESCRIPTION > > > ===================================================== > > > This is an E2MD/ENUM discussion conference call/web-meeting > > > > > > > > > (+)INSTRUCTIONS TO JOIN > > > ===================================================== > > > (1) Pre-install > > > - - - - - - - - - - - - - - - - - > > > Pre-install the full version of Intercall Web Meeting now if you will be > > sharing documents, browsers or video during the meeting: > > > https://acmepacket.on.intercall.com/confmgr/clientPreinstall.jsp > > > > > > Or, join this web meeting at the scheduled start time without > > installation by choosing the Light Version when prompted. The light > > version is ideal if you will not be sharing visuals and video, are on a > > Mac(R) or do not have a high-bandwidth connection. > > > > > > > > > > > > (2) Join the Online Conference > > > - - - - - - - - - - - - - - - - - > > > Use the link below to join the web meeting at its scheduled start time: > > > > > > > https://acmepacket.on.intercall.com/confmgr/join_as_tempuser.jsp?eventId=1 > > 04577&invitationId=1307784&user=hadriel > > > > > > > > > * Click the "Login" link located in the upper right-hand corner of the > > page. > > > * Enter hadriel in the Conference ID/Username field. > > > * Please note: You will not be able to join the meeting until the > > moderator has started it. > > > > > > > > > (3) Listen to the Audio Conference > > > If the service does not automatically dial your phone number or prompt > > you to join an audio broadcast, use the information below to join the > > audio conference: > > > > > > - - - - - - - - - - - - - - - - - > > > Once you have joined the online conference, use the information below to > > join the audio portion of the conference: > > > > > > Toll-free number: United States 8667589299 > > > International toll number: +1 4803662753 > > > Audio Conference ID: 1337084 > > > > > > International Toll-Free Dial-In Number(s): > > > > > > Argentina Dial-in # : 08003330711 > > > Australia Dial-in # : 1800635054 > > > Austria Dial-in # : 0800296166 > > > Bahamas Dial-in # : 18002054782 > > > Belarus Dial-in # : 8800114 (SAC Code 5136) > > > Belgium Dial-in # : 080074091 > > > Bolivia Dial-in # : 800100103 (SAC Code 5129) > > > Brazil *SITF* Dial-in # : 08008916311 > > > Bulgaria Dial-in # : 008001100203 > > > Chile Dial-in # : 12300206931 > > > China N (China Netcom) Dial-in # : 108007130776 > > > China S (China Telecom) Dial-in # : 108001300744 > > > Colombia Dial-in # : 018009134022 > > > Costa Rica Dial-in # : 08000131036 > > > Croatia (Hrvatska) Dial-in # : 0800222650 > > > Cyprus Dial-in # : 80094945 > > > Czech Republic Dial-in # : 800142297 > > > Denmark Dial-in # : 80886120 > > > Dominican Republic Dial-in # : 18887518389 > > > Egypt Dial-in # : 23640083 (SAC Code 5139) > > > El Salvador Dial-in # : 8006375 > > > Finland Dial-in # : 0800112720 > > > France Dial-in # : 0800905437 > > > Germany Dial-in # : 08001821592 > > > Greece Dial-in # : 0080018092024132 > > > Hong Kong Dial-in # : 800901136 > > > Hungary Dial-in # : 0680018610 > > > Iceland Dial-in # : 8008083 > > > India *SITF* Dial-in # : 180030702200 > > > India *SITF* BSNL & MTNL Dial-in # : 0008001006245 > > > Indonesia Dial-in # : 0018030152021817 > > > Ireland Dial-in # : 1800559980 > > > Israel Dial-in # : 1809245950 > > > Italy Dial-in # : 800870179 > > > Jamaica Dial-in # : 18664255996 > > > Japan Dial-in # : 00531160597 > > > Kenya Dial-in # : 0800220115 (SAC Code 5139) > > > Korea (South) Dial-in # : 00308131716 > > > Lithuania Dial-in # : 880030328 > > > Luxembourg Dial-in # : 80025977 > > > Malaysia Dial-in # : 1800812568 > > > Mexico Dial-in # : 0018887579483 > > > Monaco Dial-in # : 80093352 > > > Netherlands Dial-in # : 08000226187 > > > New Zealand Dial-in # : 0800446292 > > > Nicaragua Dial-in # : 18000551 (SAC Code 5105) > > > Norway Dial-in # : 80015566 > > > Panama Dial-in # : 0018002024405 > > > Peru Dial-in # : 080053332 > > > Philippines *By Request* Dial-in # : 180011100963 > > > Poland Dial-in # : 008001113741 > > > Portugal Dial-in # : 800813478 > > > Romania Dial-in # : 0808035030 (SAC Code 5105) > > > Russian Federation Dial-in # : 81080025511012 > > > Saint Kitts and Nevis Dial-in # : 18007449305 > > > Singapore Dial-in # : 8001011804 > > > Slovak Republic Dial-in # : 0800042139 > > > South Africa Dial-in # : 0800980259 > > > Spain Dial-in # : 900941729 > > > Sweden Dial-in # : 020797609 > > > Switzerland Dial-in # : 0800561650 > > > Taiwan Dial-in # : 00801148742 > > > Thailand Dial-in # : 001800132024591 > > > Trinidad and Tobago Dial-in # : 18002024620 > > > Ukraine Dial-in # : 000180 (SAC Code 5139) > > > United Kingdom Dial-in # : 08082348621 > > > Uruguay Dial-in # : 00040190132 > > > Venezuela Dial-in # : 8001627195 > > > Local Dial-In Numbers Dial-In # > > > Australia Sydney - Dial-in # : 0-282239877 > > > Austria Vienna - Dial-in # : 019281063 > > > Belgium Antwerp - Dial-in # : 034000310 > > > Belgium Brussels - Dial-in # : 024003531 > > > Czech Republic Prague - Dial-in # : 239014953 > > > Denmark Copenhagen - Dial-in # : 032714405 > > > Finland Helsinki - Dial-in # : 358972519302 > > > France Lyon - Dial-in # : 0426031129 > > > France Marseille - Dial-in # : 0486060057 > > > France Paris - Dial-in # : 0176748990 > > > France Toulouse - Dial-in # : 0567804153 > > > Germany Berlin - Dial-in # : 030590024927 > > > Germany Frankfurt - Dial-in # : 06922221674 > > > Germany Hamburg - Dial-in # : 040809020734 > > > Hong Kong Hong Kong - Dial-in # : 0-30114603 > > > Hungary Budapest - Dial-in # : 017779843 > > > Ireland Dublin - Dial-in # : 012475629 > > > Italy Milan - Dial-in # : 0236049233 > > > Italy Rome - Dial-in # : 0645230543 > > > Japan Tokyo - Dial-in # : 357674029 > > > Luxembourg Luxembourg - Dial-in # : 24871233 > > > Netherlands Amsterdam - Dial-in # : 0207075552 > > > Netherlands Rotterdam - Dial-in # : 0107114853 > > > Norway Oslo - Dial-in # : 22310519 > > > Portugal Lisbon - Dial-in # : 01211201028 > > > Singapore Singapore - Dial-in # : 66221028 > > > Spain Barcelona - Dial-in # : 0934923275 > > > Spain Madrid - Dial-in # : 914142527 > > > Sweden Stockholm - Dial-in # : 0850619596 > > > Switzerland Geneva - Dial-in # : 0225803308 > > > Switzerland Zurich - Dial-in # : 0445807165 > > > United Kingdom London - Dial-in # : 02031070236 > > > > > > > > > > > > (+)TECHNICAL SUPPORT: > > > ===================================================== > > > If you experience any issues joining this web meeting, please contact > > technical support at: > > > > > > + U.S. and Canada: 877.549.2051, +1.303.928.3014 or > > webmeetingsupport@intercall.com > > > + EMEA: +44 1452 556 226 or visual@intercalleurope.com > > > + APAC: 1800 468 225, +61 2 8295 9000 or profservices@intercallapac.com > > > > > > > > OR > > > http://www.intercall.com/customer-center/techSupport.php > > > > > > > > > > Information.vcs>_______________________________________________ > > > 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 HKaplan@acmepacket.com Tue Apr 6 08:20: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 9B79B3A6944 for ; Tue, 6 Apr 2010 08:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.74 X-Spam-Level: X-Spam-Status: No, score=0.74 tagged_above=-999 required=5 tests=[AWL=-0.760, BAYES_99=3.5, GB_I_INVITATION=-2] 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 zz22BGMW45Nv for ; Tue, 6 Apr 2010 08:20:21 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BF4873A6941 for ; Tue, 6 Apr 2010 08:20:20 -0700 (PDT) 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, 6 Apr 2010 11:20:16 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 6 Apr 2010 11:20:16 -0400 From: Hadriel Kaplan To: Bernie Hoeneisen Date: Tue, 6 Apr 2010 11:20:12 -0400 Thread-Topic: [e2md] E2MD discussion conf call and web meeting info Thread-Index: AcrVmbM/QZ2sphJhTbeHu6hix/8w8wAApxeQ Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3CE13@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3CCF1@mail> <430FC6BDED356B4C8498F634416644A91A79F3CDEB@mail> 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 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD discussion conf call and web meeting info 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, 06 Apr 2010 15:20:24 -0000 I don't think so - linux users should be able to view, but not be presenter= s. Does native WebEx support linux presenters? If so, I can switch to native = WebEx - I only did InterCall because it's a lot cheaper for us, but my IT d= epartment told me InterCall was just a front-end for WebEx. -hadriel > -----Original Message----- > From: Bernie Hoeneisen [mailto:bernie@ietf.hoeneisen.ch] > Sent: Tuesday, April 06, 2010 10:59 AM > To: Hadriel Kaplan > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] E2MD discussion conf call and web meeting info >=20 > Hi Hadriel >=20 > How about Linux support? >=20 > I intend to make some slides summarizing the "Divide and Conquer" > approach, i.e. how the problem space could be split into a short and a > long term solution, roughly what I proposed on the list recently. >=20 > cheers, > Bernie >=20 >=20 > On Tue, 6 Apr 2010, Hadriel Kaplan wrote: >=20 > > > > You only need the full version if you are the one sharing/presenting a > > doc/desktop, but Lite version can see them. I just confirmed with a Ma= c > > user that it works fine for him. > > > > I do plan to create some slides just to help the discussion along, but > > nothing big. > > > > -hadriel > > > >> -----Original Message----- > >> From: Lawrence Conroy [mailto:lconroy@insensate.co.uk] > >> Sent: Tuesday, April 06, 2010 8:32 AM > >> To: Hadriel Kaplan > >> Cc: E.164 To MetaData BOF discussion list > >> Subject: Re: [e2md] E2MD discussion conf call and web meeting info > >> > >> Hi Hadriel, folks, > >> given that I don't do PCs, I'm puzzled. > >> The full version download says it only works on Windoz. > >>>> Or, join this web meeting at the scheduled start time without > >> installation by choosing the Light Version when prompted. The light > >> version is ideal if you will not be sharing visuals and video, are on = a > >> Mac(R) or do not have a high-bandwidth connection. > >> > >> --------------------^^^^ > >> So, is this going to be an audio conference only? > >> > >> Basically, what's the plan for any documents -- will these be mailed t= o > >> the list? > >> > >> all the best, > >> Lawrence > >> > >> On 6 Apr 2010, at 00:34, Hadriel Kaplan wrote: > >>> Please follow the steps below to join this meeting, using Intercall > Web > >> Meeting. Please note: The moderator may have included a calendar > invite > >> (.VCS file) with this invitation. If so, you can open the attachment t= o > >> save it in your calendar. > >>> > >>> (+)CONFERENCE SUMMARY > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > >>> Title: E2MD discussion > >>> - - - - - - - - - - - - - - - - - - - - - - - - - > >>> Date: April 6, 2010 > >>> Start Time: 02:00 PM US/Eastern > >>> Duration: 60 minutes > >>> Presenter: (not provided) > >>> > >>> > >>> (+)CONFERENCE DESCRIPTION > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > >>> This is an E2MD/ENUM discussion conference call/web-meeting > >>> > >>> > >>> (+)INSTRUCTIONS TO JOIN > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > >>> (1) Pre-install > >>> - - - - - - - - - - - - - - - - - > >>> Pre-install the full version of Intercall Web Meeting now if you will > be > >> sharing documents, browsers or video during the meeting: > >>> https://acmepacket.on.intercall.com/confmgr/clientPreinstall.jsp > >>> > >>> Or, join this web meeting at the scheduled start time without > >> installation by choosing the Light Version when prompted. The light > >> version is ideal if you will not be sharing visuals and video, are on = a > >> Mac(R) or do not have a high-bandwidth connection. > >>> > >>> > >>> > >>> (2) Join the Online Conference > >>> - - - - - - - - - - - - - - - - - > >>> Use the link below to join the web meeting at its scheduled start > time: > >> > >>> > >> > https://acmepacket.on.intercall.com/confmgr/join_as_tempuser.jsp?eventId= =3D1 > >> 04577&invitationId=3D1307784&user=3Dhadriel > >>> > >>> > >>> * Click the "Login" link located in the upper right-hand corner of th= e > >> page. > >>> * Enter hadriel in the Conference ID/Username field. > >>> * Please note: You will not be able to join the meeting until the > >> moderator has started it. > >>> > >>> > >>> (3) Listen to the Audio Conference > >>> If the service does not automatically dial your phone number or promp= t > >> you to join an audio broadcast, use the information below to join the > >> audio conference: > >>> > >>> - - - - - - - - - - - - - - - - - > >>> Once you have joined the online conference, use the information below > to > >> join the audio portion of the conference: > >>> > >>> Toll-free number: United States 8667589299 > >>> International toll number: +1 4803662753 > >>> Audio Conference ID: 1337084 > >>> > >>> International Toll-Free Dial-In Number(s): > >>> > >>> Argentina Dial-in # : 08003330711 > >>> Australia Dial-in # : 1800635054 > >>> Austria Dial-in # : 0800296166 > >>> Bahamas Dial-in # : 18002054782 > >>> Belarus Dial-in # : 8800114 (SAC Code 5136) > >>> Belgium Dial-in # : 080074091 > >>> Bolivia Dial-in # : 800100103 (SAC Code 5129) > >>> Brazil *SITF* Dial-in # : 08008916311 > >>> Bulgaria Dial-in # : 008001100203 > >>> Chile Dial-in # : 12300206931 > >>> China N (China Netcom) Dial-in # : 108007130776 > >>> China S (China Telecom) Dial-in # : 108001300744 > >>> Colombia Dial-in # : 018009134022 > >>> Costa Rica Dial-in # : 08000131036 > >>> Croatia (Hrvatska) Dial-in # : 0800222650 > >>> Cyprus Dial-in # : 80094945 > >>> Czech Republic Dial-in # : 800142297 > >>> Denmark Dial-in # : 80886120 > >>> Dominican Republic Dial-in # : 18887518389 > >>> Egypt Dial-in # : 23640083 (SAC Code 5139) > >>> El Salvador Dial-in # : 8006375 > >>> Finland Dial-in # : 0800112720 > >>> France Dial-in # : 0800905437 > >>> Germany Dial-in # : 08001821592 > >>> Greece Dial-in # : 0080018092024132 > >>> Hong Kong Dial-in # : 800901136 > >>> Hungary Dial-in # : 0680018610 > >>> Iceland Dial-in # : 8008083 > >>> India *SITF* Dial-in # : 180030702200 > >>> India *SITF* BSNL & MTNL Dial-in # : 0008001006245 > >>> Indonesia Dial-in # : 0018030152021817 > >>> Ireland Dial-in # : 1800559980 > >>> Israel Dial-in # : 1809245950 > >>> Italy Dial-in # : 800870179 > >>> Jamaica Dial-in # : 18664255996 > >>> Japan Dial-in # : 00531160597 > >>> Kenya Dial-in # : 0800220115 (SAC Code 5139) > >>> Korea (South) Dial-in # : 00308131716 > >>> Lithuania Dial-in # : 880030328 > >>> Luxembourg Dial-in # : 80025977 > >>> Malaysia Dial-in # : 1800812568 > >>> Mexico Dial-in # : 0018887579483 > >>> Monaco Dial-in # : 80093352 > >>> Netherlands Dial-in # : 08000226187 > >>> New Zealand Dial-in # : 0800446292 > >>> Nicaragua Dial-in # : 18000551 (SAC Code 5105) > >>> Norway Dial-in # : 80015566 > >>> Panama Dial-in # : 0018002024405 > >>> Peru Dial-in # : 080053332 > >>> Philippines *By Request* Dial-in # : 180011100963 > >>> Poland Dial-in # : 008001113741 > >>> Portugal Dial-in # : 800813478 > >>> Romania Dial-in # : 0808035030 (SAC Code 5105) > >>> Russian Federation Dial-in # : 81080025511012 > >>> Saint Kitts and Nevis Dial-in # : 18007449305 > >>> Singapore Dial-in # : 8001011804 > >>> Slovak Republic Dial-in # : 0800042139 > >>> South Africa Dial-in # : 0800980259 > >>> Spain Dial-in # : 900941729 > >>> Sweden Dial-in # : 020797609 > >>> Switzerland Dial-in # : 0800561650 > >>> Taiwan Dial-in # : 00801148742 > >>> Thailand Dial-in # : 001800132024591 > >>> Trinidad and Tobago Dial-in # : 18002024620 > >>> Ukraine Dial-in # : 000180 (SAC Code 5139) > >>> United Kingdom Dial-in # : 08082348621 > >>> Uruguay Dial-in # : 00040190132 > >>> Venezuela Dial-in # : 8001627195 > >>> Local Dial-In Numbers Dial-In # > >>> Australia Sydney - Dial-in # : 0-282239877 > >>> Austria Vienna - Dial-in # : 019281063 > >>> Belgium Antwerp - Dial-in # : 034000310 > >>> Belgium Brussels - Dial-in # : 024003531 > >>> Czech Republic Prague - Dial-in # : 239014953 > >>> Denmark Copenhagen - Dial-in # : 032714405 > >>> Finland Helsinki - Dial-in # : 358972519302 > >>> France Lyon - Dial-in # : 0426031129 > >>> France Marseille - Dial-in # : 0486060057 > >>> France Paris - Dial-in # : 0176748990 > >>> France Toulouse - Dial-in # : 0567804153 > >>> Germany Berlin - Dial-in # : 030590024927 > >>> Germany Frankfurt - Dial-in # : 06922221674 > >>> Germany Hamburg - Dial-in # : 040809020734 > >>> Hong Kong Hong Kong - Dial-in # : 0-30114603 > >>> Hungary Budapest - Dial-in # : 017779843 > >>> Ireland Dublin - Dial-in # : 012475629 > >>> Italy Milan - Dial-in # : 0236049233 > >>> Italy Rome - Dial-in # : 0645230543 > >>> Japan Tokyo - Dial-in # : 357674029 > >>> Luxembourg Luxembourg - Dial-in # : 24871233 > >>> Netherlands Amsterdam - Dial-in # : 0207075552 > >>> Netherlands Rotterdam - Dial-in # : 0107114853 > >>> Norway Oslo - Dial-in # : 22310519 > >>> Portugal Lisbon - Dial-in # : 01211201028 > >>> Singapore Singapore - Dial-in # : 66221028 > >>> Spain Barcelona - Dial-in # : 0934923275 > >>> Spain Madrid - Dial-in # : 914142527 > >>> Sweden Stockholm - Dial-in # : 0850619596 > >>> Switzerland Geneva - Dial-in # : 0225803308 > >>> Switzerland Zurich - Dial-in # : 0445807165 > >>> United Kingdom London - Dial-in # : 02031070236 > >>> > >>> > >>> > >>> (+)TECHNICAL SUPPORT: > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > >>> If you experience any issues joining this web meeting, please contact > >> technical support at: > >>> > >>> + U.S. and Canada: 877.549.2051, +1.303.928.3014 or > >> webmeetingsupport@intercall.com > >>> + EMEA: +44 1452 556 226 or visual@intercalleurope.com > >>> + APAC: 1800 468 225, +61 2 8295 9000 or > profservices@intercallapac.com > >> > >>> > >>> OR > >>> http://www.intercall.com/customer-center/techSupport.php > >>> > >>> > >>> >> Information.vcs>_______________________________________________ > >>> 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 dean.willis@softarmor.com Tue Apr 6 10:45:34 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 DFA743A6841 for ; Tue, 6 Apr 2010 10:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=0.638, 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 IPCcNcqcCVMI for ; Tue, 6 Apr 2010 10:45:34 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1A32F3A67E7 for ; Tue, 6 Apr 2010 10:45:34 -0700 (PDT) Received: from [192.168.2.103] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o36HjKeL009939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 6 Apr 2010 12:45:22 -0500 Message-Id: <66EF5340-D76B-477E-82C1-CA002A712394@softarmor.com> From: Dean Willis To: Bernie Hoeneisen In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 6 Apr 2010 12:45:15 -0500 References: <430FC6BDED356B4C8498F634416644A91A79F3CCF1@mail> <430FC6BDED356B4C8498F634416644A91A79F3CDEB@mail> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD discussion conf call and web meeting info 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, 06 Apr 2010 17:45:35 -0000 Forward them to Hadriel and he can operate the "presenter". -- Dean From dean.willis@softarmor.com Tue Apr 6 10:46:08 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 885083A684D for ; Tue, 6 Apr 2010 10:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=0.547, 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 WUcw-dEorzBm for ; Tue, 6 Apr 2010 10:46:07 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id AFC2A3A67E7 for ; Tue, 6 Apr 2010 10:46:07 -0700 (PDT) Received: from [192.168.2.103] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o36HjKeM009939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 6 Apr 2010 12:46:05 -0500 Message-Id: <4213C363-86EC-4068-BA8D-36F54E90C984@softarmor.com> From: Dean Willis To: bmanning@vacation.karoshi.com, "E.164 To MetaData BOF discussion list" In-Reply-To: <20100406151831.GB12993@vacation.karoshi.com.> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 6 Apr 2010 12:46:04 -0500 References: <430FC6BDED356B4C8498F634416644A91A79F3CCF1@mail> <430FC6BDED356B4C8498F634416644A91A79F3CDEB@mail> <20100406151831.GB12993@vacation.karoshi.com.> X-Mailer: Apple Mail (2.936) Subject: Re: [e2md] E2MD discussion conf call and web meeting info 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, 06 Apr 2010 17:46:08 -0000 On Apr 6, 2010, at 10:18 AM, bmanning@vacation.karoshi.com wrote: > please post any slides that will be used. > If needed, I can make web space available for materials. About ten WGs already use my server. -- Dean From bernie@ietf.hoeneisen.ch Tue Apr 6 10:49: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 277083A6A16 for ; Tue, 6 Apr 2010 10:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.5 X-Spam-Level: * X-Spam-Status: No, score=1.5 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_INVITATION=-2] 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 bn8Tn5K0oaMf for ; Tue, 6 Apr 2010 10:49:09 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 5B8DC3A69E7 for ; Tue, 6 Apr 2010 10:48:58 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NzCtS-000327-93; Tue, 06 Apr 2010 19:48:54 +0200 Date: Tue, 6 Apr 2010 19:48:54 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Hadriel Kaplan In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3CE13@mail> Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79F3CCF1@mail> <430FC6BDED356B4C8498F634416644A91A79F3CDEB@mail> <430FC6BDED356B4C8498F634416644A91A79F3CE13@mail> 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: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD discussion conf call and web meeting info 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, 06 Apr 2010 17:49:11 -0000 Hi Hadriel My slides for today can be found on: http://ucom.ch/ietf/e2md-disc/divide_and_conquer.pdf In case it does not work out in Linux, you could share them. cheers, Bernie On Tue, 6 Apr 2010, Hadriel Kaplan wrote: > > I don't think so - linux users should be able to view, but not be presenters. > Does native WebEx support linux presenters? If so, I can switch to native WebEx - I only did InterCall because it's a lot cheaper for us, but my IT department told me InterCall was just a front-end for WebEx. > > -hadriel > > >> -----Original Message----- >> From: Bernie Hoeneisen [mailto:bernie@ietf.hoeneisen.ch] >> Sent: Tuesday, April 06, 2010 10:59 AM >> To: Hadriel Kaplan >> Cc: E.164 To MetaData BOF discussion list >> Subject: Re: [e2md] E2MD discussion conf call and web meeting info >> >> Hi Hadriel >> >> How about Linux support? >> >> I intend to make some slides summarizing the "Divide and Conquer" >> approach, i.e. how the problem space could be split into a short and a >> long term solution, roughly what I proposed on the list recently. >> >> cheers, >> Bernie >> >> >> On Tue, 6 Apr 2010, Hadriel Kaplan wrote: >> >>> >>> You only need the full version if you are the one sharing/presenting a >>> doc/desktop, but Lite version can see them. I just confirmed with a Mac >>> user that it works fine for him. >>> >>> I do plan to create some slides just to help the discussion along, but >>> nothing big. >>> >>> -hadriel >>> >>>> -----Original Message----- >>>> From: Lawrence Conroy [mailto:lconroy@insensate.co.uk] >>>> Sent: Tuesday, April 06, 2010 8:32 AM >>>> To: Hadriel Kaplan >>>> Cc: E.164 To MetaData BOF discussion list >>>> Subject: Re: [e2md] E2MD discussion conf call and web meeting info >>>> >>>> Hi Hadriel, folks, >>>> given that I don't do PCs, I'm puzzled. >>>> The full version download says it only works on Windoz. >>>>>> Or, join this web meeting at the scheduled start time without >>>> installation by choosing the Light Version when prompted. The light >>>> version is ideal if you will not be sharing visuals and video, are on a >>>> Mac(R) or do not have a high-bandwidth connection. >>>> >>>> --------------------^^^^ >>>> So, is this going to be an audio conference only? >>>> >>>> Basically, what's the plan for any documents -- will these be mailed to >>>> the list? >>>> >>>> all the best, >>>> Lawrence >>>> >>>> On 6 Apr 2010, at 00:34, Hadriel Kaplan wrote: >>>>> Please follow the steps below to join this meeting, using Intercall >> Web >>>> Meeting. Please note: The moderator may have included a calendar >> invite >>>> (.VCS file) with this invitation. If so, you can open the attachment to >>>> save it in your calendar. >>>>> >>>>> (+)CONFERENCE SUMMARY >>>>> ===================================================== >>>>> Title: E2MD discussion >>>>> - - - - - - - - - - - - - - - - - - - - - - - - - >>>>> Date: April 6, 2010 >>>>> Start Time: 02:00 PM US/Eastern >>>>> Duration: 60 minutes >>>>> Presenter: (not provided) >>>>> >>>>> >>>>> (+)CONFERENCE DESCRIPTION >>>>> ===================================================== >>>>> This is an E2MD/ENUM discussion conference call/web-meeting >>>>> >>>>> >>>>> (+)INSTRUCTIONS TO JOIN >>>>> ===================================================== >>>>> (1) Pre-install >>>>> - - - - - - - - - - - - - - - - - >>>>> Pre-install the full version of Intercall Web Meeting now if you will >> be >>>> sharing documents, browsers or video during the meeting: >>>>> https://acmepacket.on.intercall.com/confmgr/clientPreinstall.jsp >>>>> >>>>> Or, join this web meeting at the scheduled start time without >>>> installation by choosing the Light Version when prompted. The light >>>> version is ideal if you will not be sharing visuals and video, are on a >>>> Mac(R) or do not have a high-bandwidth connection. >>>>> >>>>> >>>>> >>>>> (2) Join the Online Conference >>>>> - - - - - - - - - - - - - - - - - >>>>> Use the link below to join the web meeting at its scheduled start >> time: >>>> >>>>> >>>> >> https://acmepacket.on.intercall.com/confmgr/join_as_tempuser.jsp?eventId=1 >>>> 04577&invitationId=1307784&user=hadriel >>>>> >>>>> >>>>> * Click the "Login" link located in the upper right-hand corner of the >>>> page. >>>>> * Enter hadriel in the Conference ID/Username field. >>>>> * Please note: You will not be able to join the meeting until the >>>> moderator has started it. >>>>> >>>>> >>>>> (3) Listen to the Audio Conference >>>>> If the service does not automatically dial your phone number or prompt >>>> you to join an audio broadcast, use the information below to join the >>>> audio conference: >>>>> >>>>> - - - - - - - - - - - - - - - - - >>>>> Once you have joined the online conference, use the information below >> to >>>> join the audio portion of the conference: >>>>> >>>>> Toll-free number: United States 8667589299 >>>>> International toll number: +1 4803662753 >>>>> Audio Conference ID: 1337084 >>>>> >>>>> International Toll-Free Dial-In Number(s): >>>>> >>>>> Argentina Dial-in # : 08003330711 >>>>> Australia Dial-in # : 1800635054 >>>>> Austria Dial-in # : 0800296166 >>>>> Bahamas Dial-in # : 18002054782 >>>>> Belarus Dial-in # : 8800114 (SAC Code 5136) >>>>> Belgium Dial-in # : 080074091 >>>>> Bolivia Dial-in # : 800100103 (SAC Code 5129) >>>>> Brazil *SITF* Dial-in # : 08008916311 >>>>> Bulgaria Dial-in # : 008001100203 >>>>> Chile Dial-in # : 12300206931 >>>>> China N (China Netcom) Dial-in # : 108007130776 >>>>> China S (China Telecom) Dial-in # : 108001300744 >>>>> Colombia Dial-in # : 018009134022 >>>>> Costa Rica Dial-in # : 08000131036 >>>>> Croatia (Hrvatska) Dial-in # : 0800222650 >>>>> Cyprus Dial-in # : 80094945 >>>>> Czech Republic Dial-in # : 800142297 >>>>> Denmark Dial-in # : 80886120 >>>>> Dominican Republic Dial-in # : 18887518389 >>>>> Egypt Dial-in # : 23640083 (SAC Code 5139) >>>>> El Salvador Dial-in # : 8006375 >>>>> Finland Dial-in # : 0800112720 >>>>> France Dial-in # : 0800905437 >>>>> Germany Dial-in # : 08001821592 >>>>> Greece Dial-in # : 0080018092024132 >>>>> Hong Kong Dial-in # : 800901136 >>>>> Hungary Dial-in # : 0680018610 >>>>> Iceland Dial-in # : 8008083 >>>>> India *SITF* Dial-in # : 180030702200 >>>>> India *SITF* BSNL & MTNL Dial-in # : 0008001006245 >>>>> Indonesia Dial-in # : 0018030152021817 >>>>> Ireland Dial-in # : 1800559980 >>>>> Israel Dial-in # : 1809245950 >>>>> Italy Dial-in # : 800870179 >>>>> Jamaica Dial-in # : 18664255996 >>>>> Japan Dial-in # : 00531160597 >>>>> Kenya Dial-in # : 0800220115 (SAC Code 5139) >>>>> Korea (South) Dial-in # : 00308131716 >>>>> Lithuania Dial-in # : 880030328 >>>>> Luxembourg Dial-in # : 80025977 >>>>> Malaysia Dial-in # : 1800812568 >>>>> Mexico Dial-in # : 0018887579483 >>>>> Monaco Dial-in # : 80093352 >>>>> Netherlands Dial-in # : 08000226187 >>>>> New Zealand Dial-in # : 0800446292 >>>>> Nicaragua Dial-in # : 18000551 (SAC Code 5105) >>>>> Norway Dial-in # : 80015566 >>>>> Panama Dial-in # : 0018002024405 >>>>> Peru Dial-in # : 080053332 >>>>> Philippines *By Request* Dial-in # : 180011100963 >>>>> Poland Dial-in # : 008001113741 >>>>> Portugal Dial-in # : 800813478 >>>>> Romania Dial-in # : 0808035030 (SAC Code 5105) >>>>> Russian Federation Dial-in # : 81080025511012 >>>>> Saint Kitts and Nevis Dial-in # : 18007449305 >>>>> Singapore Dial-in # : 8001011804 >>>>> Slovak Republic Dial-in # : 0800042139 >>>>> South Africa Dial-in # : 0800980259 >>>>> Spain Dial-in # : 900941729 >>>>> Sweden Dial-in # : 020797609 >>>>> Switzerland Dial-in # : 0800561650 >>>>> Taiwan Dial-in # : 00801148742 >>>>> Thailand Dial-in # : 001800132024591 >>>>> Trinidad and Tobago Dial-in # : 18002024620 >>>>> Ukraine Dial-in # : 000180 (SAC Code 5139) >>>>> United Kingdom Dial-in # : 08082348621 >>>>> Uruguay Dial-in # : 00040190132 >>>>> Venezuela Dial-in # : 8001627195 >>>>> Local Dial-In Numbers Dial-In # >>>>> Australia Sydney - Dial-in # : 0-282239877 >>>>> Austria Vienna - Dial-in # : 019281063 >>>>> Belgium Antwerp - Dial-in # : 034000310 >>>>> Belgium Brussels - Dial-in # : 024003531 >>>>> Czech Republic Prague - Dial-in # : 239014953 >>>>> Denmark Copenhagen - Dial-in # : 032714405 >>>>> Finland Helsinki - Dial-in # : 358972519302 >>>>> France Lyon - Dial-in # : 0426031129 >>>>> France Marseille - Dial-in # : 0486060057 >>>>> France Paris - Dial-in # : 0176748990 >>>>> France Toulouse - Dial-in # : 0567804153 >>>>> Germany Berlin - Dial-in # : 030590024927 >>>>> Germany Frankfurt - Dial-in # : 06922221674 >>>>> Germany Hamburg - Dial-in # : 040809020734 >>>>> Hong Kong Hong Kong - Dial-in # : 0-30114603 >>>>> Hungary Budapest - Dial-in # : 017779843 >>>>> Ireland Dublin - Dial-in # : 012475629 >>>>> Italy Milan - Dial-in # : 0236049233 >>>>> Italy Rome - Dial-in # : 0645230543 >>>>> Japan Tokyo - Dial-in # : 357674029 >>>>> Luxembourg Luxembourg - Dial-in # : 24871233 >>>>> Netherlands Amsterdam - Dial-in # : 0207075552 >>>>> Netherlands Rotterdam - Dial-in # : 0107114853 >>>>> Norway Oslo - Dial-in # : 22310519 >>>>> Portugal Lisbon - Dial-in # : 01211201028 >>>>> Singapore Singapore - Dial-in # : 66221028 >>>>> Spain Barcelona - Dial-in # : 0934923275 >>>>> Spain Madrid - Dial-in # : 914142527 >>>>> Sweden Stockholm - Dial-in # : 0850619596 >>>>> Switzerland Geneva - Dial-in # : 0225803308 >>>>> Switzerland Zurich - Dial-in # : 0445807165 >>>>> United Kingdom London - Dial-in # : 02031070236 >>>>> >>>>> >>>>> >>>>> (+)TECHNICAL SUPPORT: >>>>> ===================================================== >>>>> If you experience any issues joining this web meeting, please contact >>>> technical support at: >>>>> >>>>> + U.S. and Canada: 877.549.2051, +1.303.928.3014 or >>>> webmeetingsupport@intercall.com >>>>> + EMEA: +44 1452 556 226 or visual@intercalleurope.com >>>>> + APAC: 1800 468 225, +61 2 8295 9000 or >> profservices@intercallapac.com >>>> >>>>> >>>>> OR >>>>> http://www.intercall.com/customer-center/techSupport.php >>>>> >>>>> >>>>> >>> Information.vcs>_______________________________________________ >>>>> 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 >>> > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > From dean.willis@softarmor.com Tue Apr 6 10:53:17 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 9ED1C3A67B3 for ; Tue, 6 Apr 2010 10:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=0.479, 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 B-jh2h8xRvN3 for ; Tue, 6 Apr 2010 10:53:16 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A1D8528C0DC for ; Tue, 6 Apr 2010 10:52:46 -0700 (PDT) Received: from [192.168.2.103] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o36HqVeA010016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 6 Apr 2010 12:52:33 -0500 Message-Id: <9E58A0F5-5E5D-4CB8-A4FE-4CEAA49589C8@softarmor.com> From: Dean Willis To: Bernie Hoeneisen In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 6 Apr 2010 12:52:26 -0500 References: <430FC6BDED356B4C8498F634416644A91A79F3CCF1@mail> <430FC6BDED356B4C8498F634416644A91A79F3CDEB@mail> <430FC6BDED356B4C8498F634416644A91A79F3CE13@mail> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD discussion conf call and web meeting info 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, 06 Apr 2010 17:53:17 -0000 On Apr 6, 2010, at 12:48 PM, Bernie Hoeneisen wrote: > Hi Hadriel > > My slides for today can be found on: > > http://ucom.ch/ietf/e2md-disc/divide_and_conquer.pdf > > In case it does not work out in Linux, you could share them. Temporary web location for slides: http://www.softarmor.com/dwillis/e2md/ Anybody else needs to send some out, send me a copy and I'll drop them there. We'll work up a longer-term solution later. -- Dean From lconroy@insensate.co.uk Tue Apr 6 11:04: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 70B423A69E2 for ; Tue, 6 Apr 2010 11:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.751 X-Spam-Level: X-Spam-Status: No, score=0.751 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_50=0.001] 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 cktK1go21IPQ for ; Tue, 6 Apr 2010 11:04:47 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 8054B3A699D for ; Tue, 6 Apr 2010 11:04:41 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 99D9B123008 for ; Tue, 6 Apr 2010 19:04:38 +0100 (BST) From: Lawrence Conroy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Apr 2010 19:04:38 +0100 Message-Id: <4CE2930A-BA5C-4E52-AA61-31A55A34159D@insensate.co.uk> To: "E.164 To MetaData BOF discussion list" Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [e2md] conference ID? 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, 06 Apr 2010 18:04:51 -0000 Hi Folks, what is the conference id -- when trying to dial in, Digital Dorothy = insists I enter the magic number. all the best, Lawrence= From jay@nzrs.net.nz Tue Apr 6 11:06:45 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 CD4D73A69D2 for ; Tue, 6 Apr 2010 11:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 5poJE4ltYJ0z for ; Tue, 6 Apr 2010 11:06:45 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 435F128C0EA for ; Tue, 6 Apr 2010 11:06:40 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 5BB242DB2E0; Wed, 7 Apr 2010 06:06:37 +1200 (NZST) 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 TDv0WNZy2NYT; Wed, 7 Apr 2010 06:06:37 +1200 (NZST) Received: from [192.168.1.4] (121-73-182-97.dsl.telstraclear.net [121.73.182.97]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 9E9DB2DB15C; Wed, 7 Apr 2010 06:06:36 +1200 (NZST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <4CE2930A-BA5C-4E52-AA61-31A55A34159D@insensate.co.uk> Date: Wed, 7 Apr 2010 06:06:34 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CE2930A-BA5C-4E52-AA61-31A55A34159D@insensate.co.uk> To: Lawrence Conroy X-Mailer: Apple Mail (2.1078) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] conference ID? 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, 06 Apr 2010 18:06:45 -0000 1337084 On 7/04/2010, at 6:04 AM, Lawrence Conroy wrote: > Hi Folks, > what is the conference id -- when trying to dial in, Digital Dorothy = insists I enter the magic number. > all the best, > Lawrence > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From bernie@ietf.hoeneisen.ch Tue Apr 6 13:11: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 B4BC33A6968 for ; Tue, 6 Apr 2010 13:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.751 X-Spam-Level: X-Spam-Status: No, score=0.751 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_50=0.001] 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 HoR5jUF9-JNp for ; Tue, 6 Apr 2010 13:11:09 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 4EA493A68ED for ; Tue, 6 Apr 2010 13:11:09 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NzF73-0003JV-Dr for e2md@ietf.org; Tue, 06 Apr 2010 22:11:05 +0200 Date: Tue, 6 Apr 2010 22:11:05 +0200 (CEST) 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-1657208058-1270584665=:10704" 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] Can we declare the BoF minutes final? 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, 06 Apr 2010 20:11: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-1657208058-1270584665=:10704 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Hi, We made some adjustments in the Anaheim e2md BoF minutes. Can we declare=20 the version below final? We will do so and upload them to the tracker by=20 Thursday, April 8th, unless feedback indicates that we should still modify= =20 them. cheers, Dean & Bernie ---- Draft Minutes for E2MD at IETF 77 based on notes by John Elwell Jabber session scribed by Patrik F=E4ltstr=F6m edited by Bernie H=F6neisen, Dean Willis Meeting started approximately 10 minute late due to delay in room exit by prior group and equipment problems. Both chair's personal computers kernel-panicked on connecting to the projector, and an attendees' machine was pressed into service. Subsequently, the cord fell out of the main microphone. Chairs verbally reviewed "Note Well" and agenda, but did not present related slides due to equipment delay. Chair declared that the question for today's meeting was whether we should form a working group to solve the problems that will be discussed today using the general approach of a new DDDS based on ENUM. Chair noted prior guidance from the IESG is that such a specification would need to be written as if it were to be used on the public Internet, even though use in private networks is more common. AD Cullen Jennings declared that this was not necessarily the case, and the group should first decide what it wants to do. John Klensin suggested that if the work result is not intended for the public Internet then it should be renamed, because a name like E2MD implies a parallel to ENUM, which really was intended for the public Internet during its conceptualization phase. The chairs stated that the basic idea is similar to ENUM, but instead of mapping the E.164 number to a URI that identifies the resource labeled by the E.164 number, we are mapping the E.164 number to information about that phone number. Jon Peterson noted that there had been some discussion on the nature of the URI in ENUM, and that it identifies a resource but is not necessarily used for establishing a session with that resource. Topic: Problem Statement and Use Cases led by Bernie Hoeneisen Slides presented reviewed several use cases under discussion: * "unused" use case introduced by Bernie * "send-n" use case introduced by Ray Bellis * "cnam" use case introduced by Richard Shockey * "Global Service Provider Identifier" use case introduced by Bernie Noted that the ENUM working group agreed a draft on the CNAM use case, and that the DRINKS working group earlier this week had discussed mechanisms for provisioning a global service provider identifier. Jon Peterson asked: What is metadata? These 3 use cases are all rather different - is there really anything in common? Debate ensued, with the one commonality noted that all the data in question has in common that it is keyed by the E.164 number and might be needed either when starting or accepting a session using that E.164 number as its target or source. Bernie noted that ENUM had different kinds and classes of ENUM services, and had provided a classification mechanism as part of the IANA registration document. Ray Bellis responded, discussing the relationships between the send-n and unused cases with ENUM. Both send-n and unused are helpful in resolving ENUM lookups and need to be done in conjunction with the ENUM lookup, literally at the same time. John Klensin challenged the assumption that the DNS is a good place to keep this data, noting that we have a lot of other information that might be keyed by the phone number but that we do not store in the DNS. Further, storing data in the DNS with record types that lead to a potential for contradictions or unclear semantics gives a potential for abuse of the DNS. We will need to be able to say why each piece of metadata is important enough to put it into the DNS, Bernie noted that the DNS is a good way of distributing the responsibility, and that the delegation structures and relationships of the metadata in question are identical to those of ENUM. Dean reported that John's question had already been discussed on the mailing list, and the sense of mailing list was that we already have the phone number keyed structure from ENUM and we need the same hierarchical and caching characteristics, so any new protocol would need 90% functionality of DNS making it not worth inventing something new. Peter Koch noted that CNAM is rather different from the other use cases. For send-n, he doesn't believe that the problems with the proposal are removed by using E2MD rather than ENUM -- that it makes no difference what the string in NAPTR is. He suggested that killing the whole dependency on ENUM stuff and doing a roll-over not based on NAPTR may be a better approach. Olaf Kolkman agreed that the ENUM tree matches well with hierarchy, but wondered what form of query/search systems might be needed. For example, if we need to search for metadata with a specific number, it might be better to have a service just for that. He suggested that it might be good idea to look for different tools for this problems. (Note: Olaf followed up with email to the list that this perhaps was too strong of a statement and there are some problems, e.g. with +1 and the unknown delegation points in certain number plans.) Dean noted that this had come up in on-list discussion, and that the later discussion would touch on using E2MD to find a URI for a metadata service. Dean noted that the existing use cases had been debated on the list and that the list felt that DNS was a good match for these use cases, but that we would need to provide guidance on evaluating future use cases as. John Klensin noted that when we did the ENUM work, we mapped phone numbers to DNS for a a specific reason, but assumption that numbers were well matched to DNS would be wrong. The inverse ordering model creates a vast number of DNS hierarchy levels and is not particularly optimal. Richard Shockey responded that ENUM does work well, and is deployed in a number of trees. Practical experience shows that it would work equally well for other types of data. Jon Peterson noted that ENUM kept running into security properties, and the constraints in E2MD may prove to be even more restrictive. Richard Shockey noted that there are many successful ENUM deployments in private environments, and that this resolves most of the security issues. Andrew Sullivan suggested that the problem is that there is a tiny part of DNS that is not a good fit, but if that is an important part, then we should reconsider using DNS as the basis for E2MD. Topic: Issues from List led by Dean Willis Issue: DNS record size. List discussion agrees that the E2MD space in DNS is size constrained, and that each use case will have to be analyzed for suitability and unsuitable use cases rejected. further, the group agrees that they will have to produce guidance documents for future reviewers of use cases. Cullen challenged the group to scope this so it would be approvable, apparently asking for the review guidelines to be finalized before the work is done. He proposed a use case of putting a ring-tone into the DNS, and asked how we would evaluate it. Discussion ensued, with some participants maintaining that this is a valid use case, others suggesting that this was a bad idea and that it would perhaps be reasonable to insert a URI that indicates a ring tone. Lawrence Conroy noted (via remote) that an upper bound on size is probably 250 bytes. Issue: Is everything a NAPTR? Jon Peterson observed that this goes beyond just CNAM not being like the others. Why should we use NAPTR, if we have to do some kludge on the data just to make it fit into a NAPTR record Patrik F=E4ltstr=F6m noted that there had been a number of problems with NAPTR record with ENUM, so perhaps we shouldn't use it for this, in the same way we should not have for ENUM. Need to see what record types match and perhaps use a better choice, rather than just following ENUM. Jon noted that it is improbable that one RR type would fit all use cases, and that we would therefore have to look at each use case separately. This suggests that we do not need an overall framework for metadata, but should charter work for individual metadata use cases. Discussion moved onto response filtering and aggregation. Spencer suggested that having a profusion of reseource record types might be even scarier than everything being one NAPTR or one container. Dean noted that multiple RR types might be one approach, and that various other filtering techniques might be applied. For example, the underscore prefixing used with SRV records might give a clue to another possibility. Question: How large are the responses. Dean responded that with many use cases feeding into a NAPTR RR-set we might have very large responses. Dave Crocker observed that our current discussion is about low level implementation choices. We need to or might do lots of different things, but without very specific use cases as goals, we have no way to select an approach. He also berated the group for not having considered underscore prefixes as used in SRV records. Dean noted that we do have 4 specific use cases under discussion, with I-Ds on 3. Bernie stated that about 10 more have been proposed to the list. Jon asked what these use cases have in common? Dean responded that the information is indexed by the phone number and used when either setting up or answering a call, to which Jon disagreed without further explanation being recorded. David Schwartz noted that the common factor is not "has to do with call routing", since the CNAM proposal clearly doesn't. Issue: Registration Procedure Current document suggests Specification Required (with Expert Review procedures TBD). Cullen supposed that if ENUM were 1st come 1st served, we would not be having this BoF (we would have just done it in ENUM, with the implication that this would have been a Bad Thing). Richard Shockey noted that the proposed process follows ENUM as closely as possible, as the ENUM process has been shown to work. Conclusion: Polls of the Room Poll: Who thinks there is something worth looking it? A lot of people raised hands. Poll: Who thinks DNS is a suitable basis? Dave Crocker declared that since we don't have specific set of problems there is no rationale for deciding whether DNS is the right basis. Chair responded by moving to discussion of specifc use cases. Poll: Who agrees DNS is suitable for CNAM: 10 for, 3 against. Poll: (asked by Richard) We are debating solutions before we establish a charter.Is this a problem that we in IETF can solve, are there people who would like to fix problems? Response was mixed. Christer asked that if we assumes SIP is the main usage, can we solve CNAM with SIP OPTIONS? Dean responded that it is doable with a SIP event package, and that this approach had been previously suggested. Gonzalo suggested following up with questions from the "How to have a successful BOF" list such as "should a WG with the following charter be formed?" Poll: Who thinks the problem space has been clarified by the current drafts and proposed charter such that we understand the proposed scope? Mixed response. Poll: Are there people who want to solve problem: a fairly large number. Poll: Who has read the proposed charter? A large percentage responded. Poll: Who thinks the proposed charter is close to being usable? Response generally favored the negative. (Note: This was a close thing, with the responses being somewhat clustered in the room. Some observers reported an even split). Poll: Who thinks the proposed charter is too vague or proposes an untenable approach? Response generally disagreed that the charter was adequate. Gonzalo observed that we didn't really discuss the charter in this room, and we should have asked the question whether we want to propose a WG based on that charter. The chairs, who thought they had just asked that question, merely nodded in response. John Klensin suggested that we should ask who thinks proposed charter it not ready to go. The chair responded that the question had already been asked, and that more people thought it was not ready to go than thought it was ready to go. Chair's conclusion: The problem scope appears to be clearly defined, but the general solution model of defining an open-ended framework is problematic due to concerns about review and approval, and concerns about the general applicability of the ENUM process to encompass the larger metadata problem. Consequently, the proposed charter defines too large a scope. An approach that scales back to solving specific metadata issues one at a time may be more sustainable. Alternately, a solution that strongly revises (or replaces) ENUM might be better tolerated by the community. --37663318-1657208058-1270584665=:10704-- From jay@nzrs.net.nz Tue Apr 6 13:54:04 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 80CBA3A6980 for ; Tue, 6 Apr 2010 13:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.159 X-Spam-Level: X-Spam-Status: No, score=0.159 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_50=0.001, SARE_MILLIONSOF=0.315] 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 EK1o3O938-7s for ; Tue, 6 Apr 2010 13:54:03 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 2C3523A68ED for ; Tue, 6 Apr 2010 13:53:49 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id B595F2DA664 for ; Wed, 7 Apr 2010 08:53:45 +1200 (NZST) 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 6PCxdg8rLnVy for ; Wed, 7 Apr 2010 08:53:45 +1200 (NZST) Received: from [192.168.22.175] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 962D22DA3B9 for ; Wed, 7 Apr 2010 08:53:38 +1200 (NZST) From: Jay Daley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Apr 2010 08:53:35 +1200 Message-Id: <46BBDC13-D2A8-4F67-AE75-EF02A570E7AB@nzrs.net.nz> To: "E.164 To MetaData BOF discussion list" Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [e2md] First cut of requirements write up 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, 06 Apr 2010 20:54:04 -0000 Following this morning's (ahem!) call I've written up my notes on = requirements below. Due to a small child demanding I turn the TV on I = missed the fascinating bit that ended with a similarity being identified = between French and German carriers handling cross-border calls. If = anyone can fill that in then I would be grateful. Let me know what you think. Jay 1. Generic requirements 1.1 Access to data 1.1.1. Public and private use cases Each proposal has a public use case. That is to say there is a valid = requirement for that data to be published in public database = unencumbered by access control. Most proposals have a private use case. = That is to say there are valid requirements for that data to be subject = to access control. For example: - CNAM has an obvious private use case when the data personally = identifies a private individual. It also has a public use case, when = the CNAM refers to a company and local regulation exists that requires = companies to accurately identify themselves as the originator of = telephone calls. 1.1.2 Mechanisms for controlling access The alternate mechanisms for controlling access to data include: a. indirection - some data is made public but only acts as a key, = possibly along with other known data, into a private database. b. source differentiation - a public or private database that validates = the source that makes the requests and returns specific data for that = source c. private database - a wholly private database that access is only = granted to by contractual agreement and on which all the data is the = same (so no source differentiation). 1.1.3 Relationships between parties The relationships between the various parties that produce and consume = data, leading to access control requirements, are summarised as: a. A producer may choose to provide different information to different = consumers. b. A producer may choose to provide no usable information at all to = some consumers. c. A producers cannot expect a consumer to keep data secret from = itself. So if a consumer asks the same question of the producer and = receives two different answers, for whatever reason such as source = differentiation, then the consumer is trusted to use that data as the = producer intends, it is not a requirement for a mechanism to prevent the = consumer misusing that data. d. A producer may not wish for one consumer to know that it has = published different data to another consumer. So it may not want it = obvious to a consumer that there is other data that it does not have = access to. 1.2 Relevance There are two known relevancy domains for the data: - for originating a call - for receiving a call It is a requirement that the client that makes the lookup can separate = out the data for the relevancy domain that it is interested in. =20 1.2.1 Mechanisms for separating out relevancy domains This may be achieved by: - a single query only returning information from one relevancy = domain - the client filtering the returned values to extract those it = requires 1.3 Performance requirements The database needs the following performance characteristics: a. A real-time response (in the order of milliseconds). b. Scalable to hundreds of millions of keys. c. Scalable to millions of querying clients. d. Scalable to accommodate millions of changes per day. It does _not_ need the following performance characteristics: a. Deliver data greater that a few kilobytes in size. b. Guaranteed consistency. 2. DNS Protocol considerations 2.1 Access to data The various 'pure' DNS mechanisms for controlling access are: a. Private trees. b. Only publishing an indirect key in DNS. The various DNS+ mechanisms for controlling access are: a. Source-URI b. Replicating DNS on a different port and confining it to this data = [Is this really what that proposal is about?] 2.2 Relevancy The various mechanisms for separating out relevancy domains are: a. Private trees b. Different branches of the same tree. So e164m.arpa for data needed = to 'make' a call and e164r.arpa for data needed to 'receive' a call. c. Source-URI --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From dean.willis@softarmor.com Wed Apr 7 00:44:39 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 8EE0E3A689F for ; Wed, 7 Apr 2010 00:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 p5q-1s3mpi5H for ; Wed, 7 Apr 2010 00:44:38 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B849D3A679F for ; Wed, 7 Apr 2010 00:44:38 -0700 (PDT) Received: from [192.168.2.103] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o377iY47015841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 7 Apr 2010 02:44:36 -0500 Message-Id: From: Dean Willis To: "E.164 To MetaData BOF discussion list" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 7 Apr 2010 02:44:29 -0500 X-Mailer: Apple Mail (2.936) Subject: [e2md] Comment on requirements writeup: access control 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, 07 Apr 2010 07:44:39 -0000 1.1.2 Mechanisms for controlling access The alternate mechanisms for controlling access to data include: a. indirection - some data is made public but only acts as a key, possibly along with other known data, into a private database. b. source differentiation - a public or private database that validates the source that makes the requests and returns specific data for that source c. private database - a wholly private database that access is only granted to by contractual agreement and on which all the data is the same (so no source differentiation). We've also seen proposed: d. selective encryption - private records are encrypted with a key known to the authorized node. From bernie@ietf.hoeneisen.ch Wed Apr 7 13:52:14 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 0ECBD3A67B7 for ; Wed, 7 Apr 2010 13:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[AWL=1.800, 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 hVzgIGvdVGeM for ; Wed, 7 Apr 2010 13:52:13 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id B2E193A67FA for ; Wed, 7 Apr 2010 13:52:12 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NzcEI-00010W-JQ; Wed, 07 Apr 2010 22:52:06 +0200 Date: Wed, 7 Apr 2010 22:52:06 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Jay Daley In-Reply-To: <46BBDC13-D2A8-4F67-AE75-EF02A570E7AB@nzrs.net.nz> Message-ID: References: <46BBDC13-D2A8-4F67-AE75-EF02A570E7AB@nzrs.net.nz> 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: "E.164 To MetaData BOF discussion list" Subject: [e2md] New WiKi page for requirements (was: First cut of requirements write up) 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, 07 Apr 2010 20:52:14 -0000 Hi all To structure the E2MD work better I asked Henrik to provide us with a WiKi space for E2MD, and he immediately answered my request. I then created a WiKi page for E2MD requirements and included Jay's First-Cut (incl. Dean's addition) to this page. Please find it on: http://trac.tools.ietf.org/bof/e2md/trac/wiki/RequirementsList Please from now on edit directly this WiKi page to add or modify requirements. You need a login to edit the page: Your existing IETF login normally works. If you do not have an IETF login yet, just create one. If we are done, this WiKi page will be the source for an I-D to be submitted. cheers, Bernie PS: I intend to use the WiKi also to collect the "list of objections" as agreed on the conf call. More about this later. On Wed, 7 Apr 2010, Jay Daley wrote: > Following this morning's (ahem!) call I've written up my notes on > requirements below. Due to a small child demanding I turn the TV on I > missed the fascinating bit that ended with a similarity being identified > between French and German carriers handling cross-border calls. If > anyone can fill that in then I would be grateful. > > Let me know what you think. > > Jay > > > 1. Generic requirements [...] From kcartwright@tnsi.com Thu Apr 8 12:29: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 346B03A6AB8 for ; Thu, 8 Apr 2010 12:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[AWL=-2.781, BAYES_50=0.001, FB_IOW=3.333] 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 cBVCQfK6JH8C for ; Thu, 8 Apr 2010 12:29:54 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id C3CD73A6A8B for ; Thu, 8 Apr 2010 12:29:53 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42338813; Thu, 08 Apr 2010 15:28:37 -0400 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; Thu, 8 Apr 2010 15:28:37 -0400 From: "Cartwright, Kenneth" To: Bernie Hoeneisen , Jay Daley Date: Thu, 8 Apr 2010 15:28:35 -0400 Thread-Topic: [e2md] New WiKi page for requirements (was: First cut of requirements write up) Thread-Index: AcrWlDx0V1Fxdr/CSh24qi6qgkO8WwAvN3Bw Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F6982EB3A@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <46BBDC13-D2A8-4F67-AE75-EF02A570E7AB@nzrs.net.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_754963199212404AB8E9CFCA6C3D0CDA1F6982EB3ATNSMAILNAwin2_" MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] New WiKi page for requirements (was: First cut of requirements write up) 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, 08 Apr 2010 19:29:58 -0000 --_004_754963199212404AB8E9CFCA6C3D0CDA1F6982EB3ATNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are a few emails that I've sent over the past couple weeks, that conta= ins what might be called requirements of the overall approach we take, and = for the concept of source dependent responses. However, I did not write th= em with the intention that they would become part of a "requirements docume= nt". So they may need to be tightened up, etc, if that is the eventual int= ention. Ken -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Ber= nie Hoeneisen Sent: Wednesday, April 07, 2010 4:52 PM To: Jay Daley Cc: E.164 To MetaData BOF discussion list Subject: [e2md] New WiKi page for requirements (was: First cut of requireme= nts write up) Hi all To structure the E2MD work better I asked Henrik to provide us with a WiKi space for E2MD, and he immediately answered my request. I then created a WiKi page for E2MD requirements and included Jay's First-Cut (incl. Dean's addition) to this page. Please find it on: http://trac.tools.ietf.org/bof/e2md/trac/wiki/RequirementsList Please from now on edit directly this WiKi page to add or modify requirements. You need a login to edit the page: Your existing IETF login normally works. If you do not have an IETF login yet, just create one. If we are done, this WiKi page will be the source for an I-D to be submitted. cheers, Bernie PS: I intend to use the WiKi also to collect the "list of objections" as agreed on the conf call. More about this later. On Wed, 7 Apr 2010, Jay Daley wrote: > Following this morning's (ahem!) call I've written up my notes on > requirements below. Due to a small child demanding I turn the TV on I > missed the fascinating bit that ended with a similarity being identified > between French and German carriers handling cross-border calls. If > anyone can fill that in then I would be grateful. > > Let me know what you think. > > Jay > > > 1. Generic requirements [...] _______________________________________________ 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. --_004_754963199212404AB8E9CFCA6C3D0CDA1F6982EB3ATNSMAILNAwin2_ Content-Type: message/rfc822 Received: from tnsi.com (208.224.248.44) by MAIL-HUB-NA.win2k.corp.tnsi.com (172.17.7.231) with Microsoft SMTP Server id 8.1.393.1; Mon, 29 Mar 2010 16:37:23 -0400 Received: from ([64.170.98.32]) by relayus.tnsi.com with ESMTP id 4440551.42018317; Mon, 29 Mar 2010 16:37:19 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B10A73A68F9; Mon, 29 Mar 2010 13:36:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD2F73A65A6 for ; Mon, 29 Mar 2010 13:36:49 -0700 (PDT) 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 6zMxUlvnfBlF for ; Mon, 29 Mar 2010 13:36:39 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 2A0083A680F for ; Mon, 29 Mar 2010 13:36:38 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42018309; Mon, 29 Mar 2010 16:37:03 -0400 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, 29 Mar 2010 16:37:03 -0400 From: "Cartwright, Kenneth" To: Richard Shockey , 'Hadriel Kaplan' , 'Jay Daley' , 'Dean Willis' CC: 'E.164 To MetaData BOF discussion list' Sender: "e2md-bounces@ietf.org" Date: Mon, 29 Mar 2010 16:37:01 -0400 Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling Thread-Topic: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling Thread-Index: AcrPFlKdJXyGQl8XTWuNaGUMJCjnLwAXxkZQAAFQvzAAAMO3UA== Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F69529E7A@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> <01b101cacf7c$540357c0$fc0a0740$@us> List-Help: List-Subscribe: , List-Unsubscribe: , In-Reply-To: <01b101cacf7c$540357c0$fc0a0740$@us> Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: MAIL-HUB-NA.win2k.corp.tnsi.com X-MS-Has-Attach: yes X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: acceptlanguage: en-US x-esp: ESP<-44>= SHA:<0> SHA_FLAGS:<0> UHA:<9> ISC:<0> BAYES:<0> SenderID:<0> DKIM:<0> TS:<-54> SIG: DSC:<0> TRU_lotto_spam: <0> TRU_scam_spam: <0> TRU_playsites: <0> TRU_embedded_image_spam: <0> TRU_profanity_spam: <0> TRU_spam2: <0> TRU_freehosting: <0> TRU_stock_spam: <0> TRU_money_spam: <0> TRU_html_image_spam: <0> TRU_spam1: <0> URL Real-Time Signatures: <0> TRU_phish_spam: <0> TRU_watch_spam: <0> TRU_medical_spam: <0> TRU_ru_spamsubj: <0> TRU_legal_spam: <0> TRU_marketing_spam: <1> TRU_adult_spam: <0> TRU_misc_spam: <0> TRU_urllinks: <0> errors-to: e2md-bounces@ietf.org x-original-to: e2md@core3.amsl.com x-spam-level: ** x-spam-status: No, score=2.606 tagged_above=-999 required=5 tests=[AWL=-1.859, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FB_IOW=3.333, HTML_MESSAGE=0.001] x-virus-scanned: amavisd-new at amsl.com x-spam-flag: NO list-id: "E.164 To MetaData \(E2MD\) BOF discussion list" list-post: x-mailman-version: 2.1.9 x-beenthere: e2md@ietf.org list-archive: delivered-to: e2md@core3.amsl.com x-spam-score: 2.606 Content-Type: multipart/mixed; boundary="_002_754963199212404AB8E9CFCA6C3D0CDA1F69529E7ATNSMAILNAwin2_" MIME-Version: 1.0 --_002_754963199212404AB8E9CFCA6C3D0CDA1F69529E7ATNSMAILNAwin2_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Now that maybe we=92re back on track, here=92s a rough re-statement of what= one might like to see from this E2U/E2M infrastructure we are supposed to = be talking about, notice how similar it is to DDDS, plus some orthogonal ex= tensions: 1) Have a standard query data structure for E2U and E2M from a *framework*= perspective (DDDS and ENUM gives us this). 2) Have a standard query response structure for E2U and E2M from a *framew= ork* perspective (DDDS and ENUM gives us this). 3) Have a standard query data structure for each E2U and E2M service withi= n that framework (DDDS and ENUM gives us this). 4) Have a standard query response structure for each E2U and E2M service w= ithin that framework (DDDS and ENUM gives us this). 5) Have a standard way to identify the source of a query, both at the orga= nization level, and down to the "device/node" level within an organization = (Hadriel=92s proposal gives us this). 6) Have the *option* to return both E2U and E2M service responses in a sin= gle query response (I think the E2M proposal did not forbid this). 7) Continue to allow "Bind" to function as, at least, a proxy pass-through= client for queries. Iow, the base query request/response structure needs = to be backward compatible with "Bind" (DDDS and ENUM gives us this). 8) Continue to allow both UDP and TCP as the layer 3 protocol (DDDS and EN= UM gives us this). 9) Have a standard way for the querier to specify, per query, which E2U an= d/or E2M services it is interested in having in its query response (althoug= h this is less vital, this is already done to a lesser extent today, but vi= a non-standard means) (however, Hadriel=92s proposal might also give us thi= s). 10) There is of course more detail that can be added, but it just gets too= much for emails=85. As you can tell, I very much like the framework approach that DDDS embodies= , even though it has some shortcomings. This is because a significant numb= er of systems in existence today return data across multiple E2U and the pr= oposed E2M services. So using the same query/response framework greatly fa= cilitates that type of situation. So I'd like to see us stick with the fra= mework approach offered by DDDS. This question came up at the BOF (Should = we use a framework or develop a separate dedicated, RR Type for each type o= f meta-data). And as mentioned in previous emails, I've not really been a fan of the fact= that we turn TNs into domain names to look them up. In fact I think it=92= s pretty humorous. However, that is a more principled/theoretical issue, n= ot a practical one. If we were to move away from treating TNs as domain na= mes at this point, that would be too drastic a change, just to be able to l= ookup CNAM, unused, etc. Ken _____ From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Ric= hard Shockey Sent: Monday, March 29, 2010 4:14 PM To: 'Hadriel Kaplan'; 'Jay Daley'; 'Dean Willis' Cc: 'E.164 To MetaData BOF discussion list' Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling As for Dean ..No we should not shoot the messenger ..especially one that ha= s so many guns. I wish there was some focus here on what the problem is. H= ow do we help SIP network operators work better. There is a clear and demon= strable problem that needs to be addressed in SIP PSTN interworking. The d= iscussion is getting wrapped up in orthogonal arguments about what is and i= s not appropriate use of DNS technology. I almost got the sense in the BOF that folks thought ENUM itself was a mist= ake. I know John Klensin almost wishes he had never heard the word :) We = have a mechanism for translating E.164 keys into FOO and it works quite wel= l. We need a mechanism that translates E.164 numbers into other types of F= OO otherwise SIP does not work as well as it should. An alternate port IMHO solves a load of problems and I don=92t see any prob= lem with that. What I have a problem with is bashing up the proposed solut= ions here without understanding what problem we are trying to fix. This alternate use of DNS technology is well understood and widely deployed= . Gee we have split DNS right? From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Had= riel Kaplan Sent: Monday, March 29, 2010 3:40 PM To: Jay Daley; Dean Willis Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling _____ From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Jay= Daley Sent: Monday, March 29, 2010 4:02 AM To: Dean Willis On 29/03/2010, at 7:19 PM, Dean Willis wrote: 1. ENUM did not originate with carriers trying to pollute the Internet and= the IETF did not bend over backwards to put phone numbers onto the Interne= t. Quite the opposite. There was a lot of opposition to ENUM from ITU typ= es as they saw it as a cunning IETF plot to take over telephony. There are many public ENUM trees (at the country code level), it is hard to= see what is really more in the DNS than that. The success of ENUM in a pr= ivate context is surprising given the original hostility to ENUM from some = carriers, but is not an indication that this is a private protocol. Most carriers I=92ve talked to were not hostile to ENUM using DNS the proto= col =96 they were hostile to the data being put in The DNS. They actually = like the properties of the protocol, a lot. Carriers are not working against the best interests of the Internet, they a= re just trying to bring their experience, their values and their way of wor= king to the Internet. You might disagree with those but nobody holds the k= eys to the Internet, that is the whole point. I think you misunderstand Dean =96 he=92s being the messenger, not the sour= ce. That=92s part of his role as the BOF Chair. 3. I don't mean to be rude but I don't think you understand DNS at all. F= or a start we are not taking about making changes to the DNS at all because= NAPTR already exists. All we are talking about it a standard data repres= entation within NAPTR. Actually he=92s relaying the comments he got from other IETF folks, again a= s his role as BOF Chair and trying to help us move forward. And for some o= f the mechanisms we need for ENUM, some IETF members appear to feel it is a= change to The DNS. Not a change to the protocol, perhaps, but to the data= base. We=92ve heard it consistently for the past 2 years: =93this stuff do= esn=92t belong in The DNS=94. I and you and others feel there=92s nothing = wrong with putting the data we want into The DNS, but if we have to get eve= ry piece of data we want past a consensus call as well as the IESG, then we= should to listen to them. -hadriel _____ 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. --_002_754963199212404AB8E9CFCA6C3D0CDA1F69529E7ATNSMAILNAwin2_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Mon, 29 Mar 2010 16:37:24 GMT"; modification-date="Mon, 29 Mar 2010 16:37:24 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmUybWQgbWFp bGluZyBsaXN0DQplMm1kQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2UybWQNCg== --_002_754963199212404AB8E9CFCA6C3D0CDA1F69529E7ATNSMAILNAwin2_-- --_004_754963199212404AB8E9CFCA6C3D0CDA1F6982EB3ATNSMAILNAwin2_ Content-Type: message/rfc822 Received: from tnsi.com (208.224.248.44) by MAIL-HUB-NA.win2k.corp.tnsi.com (172.17.7.231) with Microsoft SMTP Server id 8.1.393.1; Wed, 31 Mar 2010 11:54:33 -0400 Received: from ([64.170.98.32]) by relayus.tnsi.com with ESMTP id 4440551.42085480; Wed, 31 Mar 2010 11:54:23 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5A883A6A22; Wed, 31 Mar 2010 08:53:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E800E3A69FC for ; Wed, 31 Mar 2010 08:53:50 -0700 (PDT) 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 39gEpSFXTATX for ; Wed, 31 Mar 2010 08:53:50 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id DFF053A69FB for ; Wed, 31 Mar 2010 08:53:49 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42085465; Wed, 31 Mar 2010 11:54:05 -0400 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; Wed, 31 Mar 2010 11:54:04 -0400 From: "Cartwright, Kenneth" To: Jay Daley , Hadriel Kaplan CC: E.164 To MetaData BOF discussion list Sender: "e2md-bounces@ietf.org" Date: Wed, 31 Mar 2010 11:54:02 -0400 Subject: Re: [e2md] Alternative to source URI Thread-Topic: [e2md] Alternative to source URI Thread-Index: AcrQjikUMuB4ZNrlQ6CUBC4jMtnh3QAWu+Bg Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F6952A756@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <430FC6BDED356B4C8498F634416644A91A79E92953@mail> <430FC6BDED356B4C8498F634416644A91A79E92982@mail> <30A5CA73-90EF-416C-8C15-BAF3B4593E28@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E92ABE@mail> <1DD1342F-8CCA-4D7B-B688-C2F691D55B8B@nzrs.net.nz> List-Help: List-Subscribe: , List-Unsubscribe: , In-Reply-To: <1DD1342F-8CCA-4D7B-B688-C2F691D55B8B@nzrs.net.nz> Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: MAIL-HUB-NA.win2k.corp.tnsi.com X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: acceptlanguage: en-US x-esp: ESP<-40>= SHA:<0> SHA_FLAGS:<0> UHA:<9> ISC:<0> BAYES:<0> SenderID:<0> DKIM:<0> TS:<-49> SIG: DSC:<0> TRU_lotto_spam: <0> TRU_scam_spam: <0> TRU_playsites: <0> TRU_embedded_image_spam: <0> TRU_profanity_spam: <0> TRU_spam2: <0> TRU_freehosting: <0> TRU_stock_spam: <0> TRU_money_spam: <0> TRU_html_image_spam: <0> TRU_spam1: <0> URL Real-Time Signatures: <0> TRU_phish_spam: <0> TRU_watch_spam: <0> TRU_medical_spam: <0> TRU_ru_spamsubj: <0> TRU_legal_spam: <0> TRU_marketing_spam: <0> TRU_adult_spam: <0> TRU_misc_spam: <0> TRU_urllinks: <0> errors-to: e2md-bounces@ietf.org x-original-to: e2md@core3.amsl.com x-spam-level: * x-spam-status: No, score=1.091 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] x-virus-scanned: amavisd-new at amsl.com x-spam-flag: NO list-id: "E.164 To MetaData \(E2MD\) BOF discussion list" list-post: x-mailman-version: 2.1.9 x-beenthere: e2md@ietf.org list-archive: delivered-to: e2md@core3.amsl.com x-spam-score: 1.091 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Source based responses can be selected at three levels of granularity (depe= nding on the policy driven need of the given use case): 1) Source Organization (done today through non-standard means such as a dif= ferent root domain to the same DNS server) 2) Source Node/IP (done today through non-standardized means such as source= IP address of the DNS query) 3) Source Person/Identity (done today via non-standardized means such as th= e callers SIP URI) Does what you propose directly support all three, directly support a subset= of the three, get in the way of any of the three, ignore any of the three,= etc? Granted I've not had the time to follow all of these emails, but it'= s not clear to me that it supports 2 and 3. Sorry if I missed something in= a previous email. If so please just point me at that email and I will rea= d/reread it. Ken -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Jay= Daley Sent: Wednesday, March 31, 2010 12:02 AM To: Hadriel Kaplan Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] Alternative to source URI On 31/03/2010, at 5:15 AM, Hadriel Kaplan wrote: >> Assuming the proxy is "allowed" to know this then they either have two >> sets of private data, one for the source carrier that services 67890 and >> one for the source carrier that services 88888. Or if the originating >> carrier is the same then just one set of private data that identifies th= e >> source within it: >> >> meta-endpoint -> source -> actual-endpoint > > It is the same source carrier for both calls originating from 77777 and 8= 8888, hence the rub - even if the destination carrier says "meta-endpoint",= the source carrier needs to do a lookup (somewhere) that takes the source = number into account. In other words *someone* has to do a source-based loo= kup, and that someone could/would use source-uri. I might be being thick here but I don't get why you think the only solution= is source-uri. What effect is achieved by source-uri that is not achieved= by the scheme I'm suggesting? As far as I can tell they achieve exactly t= he same thing. cheers Jay > > -hadriel -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 _______________________________________________ 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. _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md --_004_754963199212404AB8E9CFCA6C3D0CDA1F6982EB3ATNSMAILNAwin2_ Content-Type: message/rfc822 Received: from tnsi.com (208.224.248.44) by MAIL-HUB-NA.win2k.corp.tnsi.com (172.17.7.231) with Microsoft SMTP Server id 8.1.393.1; Thu, 1 Apr 2010 10:01:38 -0400 Received: from ([64.170.98.32]) by relayus.tnsi.com with ESMTP id 4440551.42118271; Thu, 01 Apr 2010 10:01:35 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D7943A6868; Thu, 1 Apr 2010 07:01:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B16AC3A682B for ; Thu, 1 Apr 2010 07:01:00 -0700 (PDT) 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 SZxPe1ANACNf for ; Thu, 1 Apr 2010 07:00:59 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 6EA193A680D for ; Thu, 1 Apr 2010 07:00:59 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42118242; Thu, 01 Apr 2010 10:01:08 -0400 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; Thu, 1 Apr 2010 10:01:08 -0400 From: "Cartwright, Kenneth" To: Jay Daley CC: "E.164@core3.amsl.com" , list Sender: "e2md-bounces@ietf.org" Date: Thu, 1 Apr 2010 10:01:06 -0400 Subject: Re: [e2md] Alternative to source URI Thread-Topic: [e2md] Alternative to source URI Thread-Index: AcrREXB6T9gP6o9VRKeVVbC9DAIZbAAkK9ew Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F69675D2E@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <430FC6BDED356B4C8498F634416644A91A79E92953@mail> <430FC6BDED356B4C8498F634416644A91A79E92982@mail> <30A5CA73-90EF-416C-8C15-BAF3B4593E28@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E92ABE@mail> <1DD1342F-8CCA-4D7B-B688-C2F691D55B8B@nzrs.net.nz> <754963199212404AB8E9CFCA6C3D0CDA1F6952A756@TNS-MAIL-NA.win2k.corp.tnsi.com> <106E39D6-65AF-4A53-A3F5-633D5F32A936@nzrs.net.nz> List-Help: List-Subscribe: , List-Unsubscribe: , In-Reply-To: <106E39D6-65AF-4A53-A3F5-633D5F32A936@nzrs.net.nz> Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: MAIL-HUB-NA.win2k.corp.tnsi.com X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: acceptlanguage: en-US x-esp: ESP<-40>= SHA:<0> SHA_FLAGS:<0> UHA:<9> ISC:<0> BAYES:<0> SenderID:<0> DKIM:<0> TS:<-49> SIG: DSC:<0> TRU_lotto_spam: <0> TRU_scam_spam: <0> TRU_playsites: <0> TRU_embedded_image_spam: <0> TRU_profanity_spam: <0> TRU_spam2: <0> TRU_freehosting: <0> TRU_stock_spam: <0> TRU_money_spam: <0> TRU_html_image_spam: <0> TRU_spam1: <0> URL Real-Time Signatures: <0> TRU_phish_spam: <0> TRU_watch_spam: <0> TRU_medical_spam: <0> TRU_ru_spamsubj: <0> TRU_legal_spam: <0> TRU_marketing_spam: <0> TRU_adult_spam: <0> TRU_misc_spam: <0> TRU_urllinks: <0> errors-to: e2md-bounces@ietf.org x-original-to: e2md@core3.amsl.com x-spam-level: * x-spam-status: No, score=1.093 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] x-virus-scanned: amavisd-new at amsl.com x-spam-flag: NO list-id: "E.164 To MetaData \(E2MD\) BOF discussion list" list-post: x-mailman-version: 2.1.9 x-beenthere: e2md@ietf.org list-archive: delivered-to: e2md@core3.amsl.com x-spam-score: 1.093 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 I think the disconnect in our common understandings is this statement you y= ou've made: "That is achieved by deciding to whom to give what private data." I think the statement presumes that we are *pushing* a private data set *do= wn/out* to the organization that wants/isAllowedTo to see that private data= set. The solution cannot be predicated on that operational model. With re= spect to the location of the "private" data as you call it, there are two m= odels: 1) Shared/Central Resolution Server Model: The private data sets are not p= ushed down to the organization that has visibility to that private data, bu= t instead sits in a common location where access and visibility into the da= ta is controlled. Under many circumstances it is not permissible from a bu= siness model, and/or privacy, and/or scalability perspective to push the "p= rivate" data down to each individual organization that wants to query it. 2) Private/Local Resolution Server Model: The private views into the large= r data set are created, updated, and pushed down to local resolution server= s owned/operated/hosted by the organization that has visibility into that v= iew. The solution needs to support both of these models. Ken -----Original Message----- From: Jay Daley [mailto:jay@nzrs.net.nz] Sent: Wednesday, March 31, 2010 4:33 PM To: Cartwright, Kenneth Cc: Hadriel Kaplan; E.164 To MetaData BOF discussion list Subject: Re: [e2md] Alternative to source URI On 1/04/2010, at 4:54 AM, Cartwright, Kenneth wrote: > Source based responses can be selected at three levels of granularity (de= pending on the policy driven need of the given use case): thanks, this is very helpful. > 1) Source Organization (done today through non-standard means such as a d= ifferent root domain to the same DNS server) That is achieved by deciding to whom to give what private data. > 2) Source Node/IP (done today through non-standardized means such as sour= ce IP address of the DNS query) This is presumably an indirect mechanism for a different form of source bas= ed filtering - in other words it is not the IP that actually matters but wh= o is using that IP? If is actually the IP then that is achieved by the contents of the private = data. > 3) Source Person/Identity (done today via non-standardized means such as = the callers SIP URI) That is achieved by the contents of the private data. > Does what you propose directly support all three, directly support a subs= et of the three, get in the way of any of the three, ignore any of the thre= e, etc? Granted I've not had the time to follow all of these emails, but i= t's not clear to me that it supports 2 and 3. Sorry if I missed something = in a previous email. If so please just point me at that email and I will r= ead/reread it. I think it does support all three but I need to understand the purpose of 2= a bit better to be sure, assuming you think I have explained 1 and 3 well = enough. Can you provide more detail? thanks Jay > > Ken > > > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of J= ay Daley > Sent: Wednesday, March 31, 2010 12:02 AM > To: Hadriel Kaplan > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] Alternative to source URI > > > On 31/03/2010, at 5:15 AM, Hadriel Kaplan wrote: > >>> Assuming the proxy is "allowed" to know this then they either have two >>> sets of private data, one for the source carrier that services 67890 an= d >>> one for the source carrier that services 88888. Or if the originating >>> carrier is the same then just one set of private data that identifies t= he >>> source within it: >>> >>> meta-endpoint -> source -> actual-endpoint >> >> It is the same source carrier for both calls originating from 77777 and = 88888, hence the rub - even if the destination carrier says "meta-endpoint"= , the source carrier needs to do a lookup (somewhere) that takes the source= number into account. In other words *someone* has to do a source-based lo= okup, and that someone could/would use source-uri. > > I might be being thick here but I don't get why you think the only soluti= on is source-uri. What effect is achieved by source-uri that is not achiev= ed by the scheme I'm suggesting? As far as I can tell they achieve exactly= the same thing. > > cheers > Jay > > >> >> -hadriel > > > -- > Jay Daley > Chief Executive > .nz Registry Services (New Zealand Domain Name Registry Limited) > desk: +64 4 931 6977 > mobile: +64 21 678840 > > _______________________________________________ > 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 m= ay > contain confidential and privileged information of Transaction Network Se= rvices. > Any unauthorised review, use, disclosure or distribution is prohibited. I= f you > are not the intended recipient, please contact the sender by reply e-mail= and destroy all copies of the original message. > -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 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. _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md --_004_754963199212404AB8E9CFCA6C3D0CDA1F6982EB3ATNSMAILNAwin2_-- From bernie@ietf.hoeneisen.ch Fri Apr 9 01:45: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 1B5123A69B3 for ; Fri, 9 Apr 2010 01:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.519 X-Spam-Level: X-Spam-Status: No, score=-1.519 tagged_above=-999 required=5 tests=[AWL=1.080, 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 NrVW6bZdi6DJ for ; Fri, 9 Apr 2010 01:45:38 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id E38C83A697B for ; Fri, 9 Apr 2010 01:45:37 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1O09qG-0002b1-Tj for e2md@ietf.org; Fri, 09 Apr 2010 10:45:32 +0200 Date: Fri, 9 Apr 2010 10:45:32 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "E.164 To MetaData BOF discussion list" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="37663318-1956696706-1270802732=:9360" 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] BoF Minutes declared final (was: Can we declare the BoF minutes final?) 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, 09 Apr 2010 08:45:40 -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-1956696706-1270802732=:9360 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE FYI: The minutes of e2md BoF in Anaheim have been declared final and uploaded=20 to the tracker. cheers, Your IETF-77 e2md BoF chairs (Dean & Bernie) On Tue, 6 Apr 2010, Bernie Hoeneisen wrote: > Hi, > > We made some adjustments in the Anaheim e2md BoF minutes. Can we declare = the=20 > version below final? We will do so and upload them to the tracker by=20 > Thursday, April 8th, unless feedback indicates that we should still modif= y=20 > them. > > cheers, > Dean & Bernie > > ---- > > Draft Minutes for E2MD at IETF 77 > based on notes by John Elwell > Jabber session scribed by Patrik F=E4ltstr=F6m > edited by Bernie H=F6neisen, Dean Willis > > > Meeting started approximately 10 minute late due to delay in room exit > by prior group and equipment problems. Both chair's personal computers > kernel-panicked on connecting to the projector, and an attendees' machine > was pressed into service. Subsequently, the cord fell out of the main > microphone. > > Chairs verbally reviewed "Note Well" and agenda, but did not present > related slides due to equipment delay. > > Chair declared that the question for today's meeting was whether we > should form a working group to solve the problems that will be > discussed today using the general approach of a new DDDS based on > ENUM. Chair noted prior guidance from the IESG is that such a > specification would need to be written as if it were to be used on the > public Internet, even though use in private networks is more > common. AD Cullen Jennings declared that this was not necessarily the > case, and the group should first decide what it wants to do. John > Klensin suggested that if the work result is not intended for the > public Internet then it should be renamed, because a name like E2MD > implies a parallel to ENUM, which really was intended for the public > Internet during its conceptualization phase. > > The chairs stated that the basic idea is similar to ENUM, but instead of > mapping the E.164 number to a URI that identifies the resource labeled > by the E.164 number, we are mapping the E.164 number to information > about that phone number. Jon Peterson noted that there had been some > discussion on the nature of the URI in ENUM, and that it identifies a > resource but is not necessarily used for establishing a session with that > resource. > > > > Topic: Problem Statement and Use Cases > led by Bernie Hoeneisen > > Slides presented reviewed several use cases under discussion: > > * "unused" use case introduced by Bernie > * "send-n" use case introduced by Ray Bellis > * "cnam" use case introduced by Richard Shockey > * "Global Service Provider Identifier" use case introduced by Bernie > > Noted that the ENUM working group agreed a draft on the CNAM use case, > and that the DRINKS working group earlier this week had discussed > mechanisms for provisioning a global service provider identifier. > > > Jon Peterson asked: What is metadata? These 3 use cases are all rather > different - is there really anything in common? Debate ensued, with > the one commonality noted that all the data in question has in common > that it is keyed by the E.164 number and might be needed either when > starting or accepting a session using that E.164 number as its target > or source. Bernie noted that ENUM had different kinds and classes of > ENUM services, and had provided a classification mechanism as part of > the IANA registration document. > > Ray Bellis responded, discussing the relationships between the send-n > and unused cases with ENUM. Both send-n and unused are helpful in > resolving ENUM lookups and need to be done in conjunction with the > ENUM lookup, literally at the same time. > > John Klensin challenged the assumption that the DNS is a good place to > keep this data, noting that we have a lot of other information that > might be keyed by the phone number but that we do not store in the > DNS. Further, storing data in the DNS with record types that lead to a > potential for contradictions or unclear semantics gives a potential > for abuse of the DNS. We will need to be able to say why each piece of > metadata is important enough to put it into the DNS, > > Bernie noted that the DNS is a good way of distributing the > responsibility, and that the delegation structures and relationships > of the metadata in question are identical to those of ENUM. > > Dean reported that John's question had already been discussed on the > mailing list, and the sense of mailing list was that we already have > the phone number keyed structure from ENUM and we need the same > hierarchical and caching characteristics, so any new protocol would > need 90% functionality of DNS making it not worth inventing something > new. > > Peter Koch noted that CNAM is rather different from the other use > cases. For send-n, he doesn't believe that the problems with the > proposal are removed by using E2MD rather than ENUM -- that it makes > no difference what the string in NAPTR is. He suggested that killing > the whole dependency on ENUM stuff and doing a roll-over not based on > NAPTR may be a better approach. > > Olaf Kolkman agreed that the ENUM tree matches well with hierarchy, > but wondered what form of query/search systems might be needed. For > example, if we need to search for metadata with a specific number, it > might be better to have a service just for that. He suggested that it > might be good idea to look for different tools for this problems. (Note: > Olaf followed up with email to the list that this perhaps was too > strong of a statement and there are some problems, e.g. with > +1 and the unknown delegation points in certain number plans.) > > Dean noted that this had come up in on-list discussion, and that the > later discussion would touch on using E2MD to find a URI for a > metadata service. > > Dean noted that the existing use cases had been debated on the list > and that the list felt that DNS was a good match for these use cases, > but that we would need to provide guidance on evaluating future use > cases as. > > John Klensin noted that when we did the ENUM work, we mapped phone > numbers to DNS for a a specific reason, but assumption that numbers > were well matched to DNS would be wrong. The inverse ordering model > creates a vast number of DNS hierarchy levels and is not particularly > optimal. > > Richard Shockey responded that ENUM does work well, and is deployed in > a number of trees. Practical experience shows that it would work > equally well for other types of data. > > Jon Peterson noted that ENUM kept running into security properties, and > the constraints in E2MD may prove to be even more restrictive. > > Richard Shockey noted that there are many successful ENUM deployments > in private environments, and that this resolves most of the security > issues. > > Andrew Sullivan suggested that the problem is that there is a tiny part > of DNS that is not a good fit, but if that is an important part, then we > should reconsider using DNS as the basis for E2MD. > > > > Topic: Issues from List > led by Dean Willis > > > Issue: DNS record size. > > List discussion agrees that the E2MD space in DNS is size constrained, > and that each use case will have to be analyzed for suitability and > unsuitable use cases rejected. further, the group agrees that they > will have to produce guidance documents for future reviewers of use > cases. > > Cullen challenged the group to scope this so it would be approvable, > apparently asking for the review guidelines to be finalized before the > work is done. He proposed a use case of putting a ring-tone into the > DNS, and asked how we would evaluate it. Discussion ensued, with some > participants maintaining that this is a valid use case, others > suggesting that this was a bad idea and that it would perhaps be > reasonable to insert a URI that indicates a ring tone. Lawrence Conroy > noted (via remote) that an upper bound on size is probably 250 bytes. > > > > Issue: Is everything a NAPTR? > > > Jon Peterson observed that this goes beyond just CNAM not being like > the others. Why should we use NAPTR, if we have to do some kludge on > the data just to make it fit into a NAPTR record > > Patrik F=E4ltstr=F6m noted that there had been a number of problems with > NAPTR record with ENUM, so perhaps we shouldn't use it for this, in the > same way we should not have for ENUM. Need to see what record types > match and perhaps use a better choice, rather than just following > ENUM. > > Jon noted that it is improbable that one RR type would fit all use > cases, and that we would therefore have to look at each use case > separately. This suggests that we do not need an overall framework for > metadata, but should charter work for individual metadata use cases. > > > Discussion moved onto response filtering and aggregation. > > > Spencer suggested that having a profusion of reseource record types > might be even scarier than everything being one NAPTR or one > container. > > Dean noted that multiple RR types might be one approach, and that > various other filtering techniques might be applied. For example, the > underscore prefixing used with SRV records might give a clue to > another possibility. > > > Question: How large are the responses. Dean responded that with many > use cases feeding into a NAPTR RR-set we might have very large > responses. > > Dave Crocker observed that our current discussion is about low level > implementation choices. We need to or might do lots of different > things, but without very specific use cases as goals, we have no way > to select an approach. He also berated the group for not having > considered underscore prefixes as used in SRV records. > > > Dean noted that we do have 4 specific use cases under discussion, with > I-Ds on 3. Bernie stated that about 10 more have been proposed to the > list. > > > Jon asked what these use cases have in common? Dean responded that the > information is indexed by the phone number and used when either > setting up or answering a call, to which Jon disagreed without further > explanation being recorded. > > > David Schwartz noted that the common factor is not "has to do with > call routing", since the CNAM proposal clearly doesn't. > > Issue: Registration Procedure > > Current document suggests Specification Required (with Expert Review > procedures TBD). Cullen supposed that if ENUM were 1st come 1st served, > we would not be having this BoF (we would have just done it in ENUM, > with the implication that this would have been a Bad Thing). > > Richard Shockey noted that the proposed process follows ENUM as > closely as possible, as the ENUM process has been shown to work. > > > > Conclusion: Polls of the Room > > Poll: Who thinks there is something worth looking it? A lot of people > raised hands. > > Poll: Who thinks DNS is a suitable basis? > > Dave Crocker declared that since we don't have specific set of > problems there is no rationale for deciding whether DNS is the right > basis. Chair responded by moving to discussion of specifc use cases. > > Poll: Who agrees DNS is suitable for CNAM: 10 for, 3 against. > > > > Poll: (asked by Richard) We are debating solutions before we establish > a charter.Is this a problem that we in IETF can solve, are there > people who would like to fix problems? Response was mixed. > > Christer asked that if we assumes SIP is the main usage, can we solve > CNAM with SIP OPTIONS? Dean responded that it is doable with a SIP > event package, and that this approach had been previously suggested. > > > Gonzalo suggested following up with questions from the "How to have a > successful BOF" list such as "should a WG with the following charter > be formed?" > > > Poll: Who thinks the problem space has been clarified by the current > drafts and proposed charter such that we understand the proposed > scope? Mixed response. > > Poll: Are there people who want to solve problem: a fairly large number. > > Poll: Who has read the proposed charter? A large percentage responded. > > Poll: Who thinks the proposed charter is close to being usable? > Response generally favored the negative. (Note: This was a close > thing, with the responses being somewhat clustered in the room. > Some observers reported an even split). > > Poll: Who thinks the proposed charter is too vague or proposes an > untenable approach? Response generally disagreed that the charter was > adequate. > > Gonzalo observed that we didn't really discuss the charter in this > room, and we should have asked the question whether we want to propose a > WG based on that charter. The chairs, who thought they had just asked > that question, merely nodded in response. > > John Klensin suggested that we should ask who thinks proposed charter > it not ready to go. The chair responded that the question had already > been asked, and that more people thought it was not ready to go > than thought it was ready to go. > > > Chair's conclusion: > > > The problem scope appears to be clearly defined, but the general > solution model of defining an open-ended framework is problematic due > to concerns about review and approval, and concerns about the general > applicability of the ENUM process to encompass the larger metadata > problem. Consequently, the proposed charter defines too large a > scope. An approach that scales back to solving specific metadata > issues one at a time may be more sustainable. Alternately, a solution > that strongly revises (or replaces) ENUM might be better tolerated by > the community. > > > --37663318-1956696706-1270802732=:9360-- From bernie@ietf.hoeneisen.ch Fri Apr 9 12:54: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 D69353A69B2 for ; Fri, 9 Apr 2010 12:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.900, 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 wOfN7qaHJN4d for ; Fri, 9 Apr 2010 12:54:19 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 8ACE23A67AD for ; Fri, 9 Apr 2010 12:51:32 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1O0KEh-0003eZ-5C for e2md@ietf.org; Fri, 09 Apr 2010 21:51:27 +0200 Date: Fri, 9 Apr 2010 21:51:27 +0200 (CEST) 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] unused: Interesting background info 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, 09 Apr 2010 19:54:19 -0000 Hi, I accidently stepped over some history of the "void" Enumservice, which is the predecessor of "unused": https://datatracker.ietf.org/doc/draft-ietf-enum-void/#ballot This might explain some of the concerns raised before and during the BoF. In particular I understand now better what Jon Peterson tried to explain about "usused", while convincing him to support e2md in the days before the BoF. I am not sure, which of the concerns expressed back then about "void" still hold with "unused" and which are obsolete by now. Does anybody know more about this? cheers, Bernie From lconroy@insensate.co.uk Fri Apr 9 14:18:01 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 ECA6F3A6924 for ; Fri, 9 Apr 2010 14:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.005 X-Spam-Level: X-Spam-Status: No, score=0.005 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_20=-0.74] 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 9GJs6CPo5t19 for ; Fri, 9 Apr 2010 14:18:00 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id C62803A69DB for ; Fri, 9 Apr 2010 14:17:38 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 50FF512464A; Fri, 9 Apr 2010 22:17:33 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: Date: Fri, 9 Apr 2010 22:17:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <188DB1C2-EF60-42A0-97EB-C4BF7C0297E7@insensate.co.uk> References: To: Bernie Hoeneisen X-Mailer: Apple Mail (2.1078) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] unused: Interesting background info 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, 09 Apr 2010 21:18:01 -0000 Hi Bernie, folks, This is curious. I'm watching "Groundhog Day" and this comes up. The one you picked out is an Oooooooold ballot and an old document. The doc went through many transformations over its extended (and renamed) lifetime, at any point of which you could pick out another ballot and another set of different issues. A general complaint was that we were trying to indicate the absence of a resource by using a record. [which is of course what you want to do -- this is a stop sign wrapped up as a arguably fake URI] We DID originally want to put in a link to the numbering authority for the particular block. However, that URI doesn't progress a session with the destination number -- rather because this record indicates that destination number is not in service. Thus that was not acceptable. The record itself works fine, does what's needed, and has been tested and used in real networks. It is, however, a looong stretch for ENUM. =3D> there are two issues -- this record indicates lack of a resource, and it doesn't generate a URI. Both of those should be ENUM-specific. Of this whole process, I do have one regret. One of the more entertaining versions was unused -07. That one included a neat idea to avoid the need for wildcards. Problem is, for some name servers, this neat DNS trick doesn't work. It does appear to work absolutely fine if you happen to have modern servers, but whilst that's OK for closed and controlled environments, it isn't for the interweb. Pity, really. all the best, Lawrence On 9 Apr 2010, at 20:51, Bernie Hoeneisen wrote: > Hi, >=20 > I accidently stepped over some history of the "void" Enumservice, = which is the predecessor of "unused": >=20 > https://datatracker.ietf.org/doc/draft-ietf-enum-void/#ballot >=20 > This might explain some of the concerns raised before and during the = BoF. In particular I understand now better what Jon Peterson tried to = explain about "usused", while convincing him to support e2md in the days = before the BoF. >=20 > I am not sure, which of the concerns expressed back then about "void" = still hold with "unused" and which are obsolete by now. >=20 > Does anybody know more about this? >=20 > cheers, > Bernie From bernie@ietf.hoeneisen.ch Sat Apr 10 02:37: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 7F1013A684D for ; Sat, 10 Apr 2010 02:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.675, 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 lWhjpvZO+ouN for ; Sat, 10 Apr 2010 02:37:20 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 49F893A67A5 for ; Sat, 10 Apr 2010 02:37:19 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1O0X7p-00009g-HG for e2md@ietf.org; Sat, 10 Apr 2010 11:37:13 +0200 Date: Sat, 10 Apr 2010 11:37:13 +0200 (CEST) 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] List of Objections 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, 10 Apr 2010 09:37:21 -0000 Hi e2md folks! During the conference call earlier this week, we agreed to collect a list of objections raised against the e2md proposal. (This list will include real as well as perceived issues. Lateron we will take them appart, but now it is important that we have a complete 'List of Objections' as we need to thoroughly understand the perceived, the L9+ and the FUD issues too.) I started this task using the e2md Trac/WiKi. (I mainly broke down the BoF minutes and fed them to tracker tickets. I also made intial assumptions on the severity.) Please find the current list of objections on: http://trac.tools.ietf.org/bof/e2md/trac/report/10 (I suggest your to bookmark this URL as a starting point.) To add new objections you are aware of, simply create a 'New Ticket'. You can also add your comments to existing tickets/objections. Note: For any additions/changes, you need to login. You can use your existing IETF login or, if your don't have one yet, just use the 'Create Account' function. In an unlikely case of problems, just drop me an email and I'll take care of it. Looking forward to your contributions to our 'List of Objections'! cheers, Bernie -- http://ucom.ch/ Tech Consulting for Internet Standardization From lconroy@insensate.co.uk Sat Apr 10 07:16:01 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 3AB023A69AA for ; Sat, 10 Apr 2010 07:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.023 X-Spam-Level: X-Spam-Status: No, score=-0.023 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, MANGLED_TOOL=2.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 nPyqveA1kZux for ; Sat, 10 Apr 2010 07:16:00 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id A253E3A67DB for ; Sat, 10 Apr 2010 07:15:59 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id D67BF124A33; Sat, 10 Apr 2010 15:15:54 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <188DB1C2-EF60-42A0-97EB-C4BF7C0297E7@insensate.co.uk> Date: Sat, 10 Apr 2010 15:15:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <188DB1C2-EF60-42A0-97EB-C4BF7C0297E7@insensate.co.uk> To: "E.164 To MetaData BOF discussion list" X-Mailer: Apple Mail (2.1078) Cc: Bernie Hoeneisen Subject: Re: [e2md] unused: Interesting background info 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, 10 Apr 2010 14:16:01 -0000 Hi Folks, responding to my own post -- sad. To clarify/fix the typo, the neat "closest encloser" scheme mentioned was in the "operational guidance" section (*section* 7) of VOID and UNUSED (up to -01. After that, it was removed). Richard also included a brief guide to number plans for the non-"steam phone" folk. all the best, Lawrence On 9 Apr 2010, at 22:17, Lawrence Conroy wrote: > Hi Bernie, folks, > This is curious. I'm watching "Groundhog Day" and this comes up. >=20 > The one you picked out is an Oooooooold ballot and an old document. > The doc went through many transformations over its extended (and > renamed) lifetime, at any point of which you could pick out another > ballot and another set of different issues. >=20 > A general complaint was that we were trying to indicate the absence > of a resource by using a record. > [which is of course what you want to do -- this is a stop sign > wrapped up as a arguably fake URI] >=20 > We DID originally want to put in a link to the numbering authority > for the particular block. However, that URI doesn't progress a session > with the destination number -- rather because this record indicates > that destination number is not in service. Thus that was not = acceptable. > The record itself works fine, does what's needed, and has been tested > and used in real networks. It is, however, a looong stretch for ENUM. >=20 > =3D> there are two issues -- this record indicates lack of a resource, > and it doesn't generate a URI. Both of those should be ENUM-specific. >=20 > Of this whole process, I do have one regret. One of the more > entertaining versions was unused -07. > That one included a neat idea to avoid the need for wildcards. > Problem is, for some name servers, this neat DNS trick doesn't work. > It does appear to work absolutely fine if you happen to have modern > servers, but whilst that's OK for closed and controlled environments, > it isn't for the interweb. > Pity, really. >=20 > all the best, > Lawrence >=20 >=20 > On 9 Apr 2010, at 20:51, Bernie Hoeneisen wrote: >> Hi, >>=20 >> I accidently stepped over some history of the "void" Enumservice, = which is the predecessor of "unused": >>=20 >> https://datatracker.ietf.org/doc/draft-ietf-enum-void/#ballot >>=20 >> This might explain some of the concerns raised before and during the = BoF. In particular I understand now better what Jon Peterson tried to = explain about "usused", while convincing him to support e2md in the days = before the BoF. >>=20 >> I am not sure, which of the concerns expressed back then about "void" = still hold with "unused" and which are obsolete by now. >>=20 >> Does anybody know more about this? >>=20 >> cheers, >> Bernie >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From kcartwright@tnsi.com Tue Apr 13 11:11: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 C1C9D3A6407 for ; Tue, 13 Apr 2010 11:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.533, 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 lSAM3bjREnjG for ; Tue, 13 Apr 2010 11:11:57 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id ADED73A6A76 for ; Tue, 13 Apr 2010 11:11:54 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42477028; Tue, 13 Apr 2010 14:11:37 -0400 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, 13 Apr 2010 14:11:37 -0400 From: "Cartwright, Kenneth" To: E.164 To MetaData BOF discussion list Date: Tue, 13 Apr 2010 14:11:36 -0400 Thread-Topic: [E2M] Call today? I thought ... Thread-Index: AcrYkXitvYVA1T4fRXqviobzOITXKACoyHMg Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F698F68A0@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: [e2md] [E2M] Call today? I thought ... 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, 13 Apr 2010 18:11:58 -0000 ...there was to be a call today at 2pm. Not so? 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 Apr 13 11:14: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 4839B3A67DA for ; Tue, 13 Apr 2010 11:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001] 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 BY8CMFOjuccp for ; Tue, 13 Apr 2010 11:14:36 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id EBE8F3A69C9 for ; Tue, 13 Apr 2010 11:14:35 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 251BF2DB825; Wed, 14 Apr 2010 06:14:29 +1200 (NZST) 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 flD22I0dk4WC; Wed, 14 Apr 2010 06:14:29 +1200 (NZST) Received: from [192.168.1.4] (121-73-182-97.dsl.telstraclear.net [121.73.182.97]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id B20192DA236; Wed, 14 Apr 2010 06:14:28 +1200 (NZST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA1F698F68A0@TNS-MAIL-NA.win2k.corp.tnsi.com> Date: Wed, 14 Apr 2010 06:14:26 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <328D463E-2450-4875-8833-87066B8F2306@nzrs.net.nz> References: <754963199212404AB8E9CFCA6C3D0CDA1F698F68A0@TNS-MAIL-NA.win2k.corp.tnsi.com> To: "Cartwright, Kenneth" X-Mailer: Apple Mail (2.1078) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] [E2M] Call today? I thought ... 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, 13 Apr 2010 18:14:37 -0000 Same here. On 14/04/2010, at 6:11 AM, Cartwright, Kenneth wrote: > ...there was to be a call today at 2pm. Not so? >=20 >=20 > This e-mail message is for the sole use of the intended = recipient(s)and may > contain confidential and privileged information of Transaction Network = Services. > Any unauthorised review, use, disclosure or distribution is = prohibited. If you > are not the intended recipient, please contact the sender by reply = e-mail and destroy all copies of the original message. >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From bernie@ietf.hoeneisen.ch Tue Apr 13 12:02:31 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 D8BFC3A6A69 for ; Tue, 13 Apr 2010 12:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 k8l+CgAqwJIl for ; Tue, 13 Apr 2010 12:02:31 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id F035D3A6A4F for ; Tue, 13 Apr 2010 12:02:30 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1O1lNN-0001fu-LE; Tue, 13 Apr 2010 21:02:21 +0200 Date: Tue, 13 Apr 2010 21:02:21 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "Cartwright, Kenneth" In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA1F698F68A0@TNS-MAIL-NA.win2k.corp.tnsi.com> Message-ID: References: <754963199212404AB8E9CFCA6C3D0CDA1F698F68A0@TNS-MAIL-NA.win2k.corp.tnsi.com> 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: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] [E2M] Call today? I thought ... 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, 13 Apr 2010 19:02:31 -0000 I do not recall a conf call being agreed for today. Have a missed anything? On Tue, 13 Apr 2010, Cartwright, Kenneth wrote: > ...there was to be a call today at 2pm. Not so? > > > This e-mail message is for the sole use of the intended recipient(s)and may > contain confidential and privileged information of Transaction Network Services. > Any unauthorised review, use, disclosure or distribution is prohibited. If you > are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > From kcartwright@tnsi.com Tue Apr 13 12:04: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 7DD723A6A7D for ; Tue, 13 Apr 2010 12:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=0.474, 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 rHJovt9yp0zP for ; Tue, 13 Apr 2010 12:04:01 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 6B4C13A6A69 for ; Tue, 13 Apr 2010 12:04:01 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42478748; Tue, 13 Apr 2010 15:03:45 -0400 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, 13 Apr 2010 15:03:45 -0400 From: "Cartwright, Kenneth" To: Bernie Hoeneisen Date: Tue, 13 Apr 2010 15:03:44 -0400 Thread-Topic: [e2md] [E2M] Call today? I thought ... Thread-Index: AcrbO+EK9hFdSObjTuCs1rakFMQMLAAAA/qQ Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F698F6933@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <754963199212404AB8E9CFCA6C3D0CDA1F698F68A0@TNS-MAIL-NA.win2k.corp.tnsi.com> 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 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] [E2M] Call today? I thought ... 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, 13 Apr 2010 19:04:02 -0000 At the end of the last call, someone said "same time next week" and a few p= eople said "yes". Oh well. No biggie. Ken -----Original Message----- From: Bernie Hoeneisen [mailto:bernie@ietf.hoeneisen.ch] Sent: Tuesday, April 13, 2010 3:02 PM To: Cartwright, Kenneth Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] [E2M] Call today? I thought ... I do not recall a conf call being agreed for today. Have a missed anything? On Tue, 13 Apr 2010, Cartwright, Kenneth wrote: > ...there was to be a call today at 2pm. Not so? > > > This e-mail message is for the sole use of the intended recipient(s)and m= ay > contain confidential and privileged information of Transaction Network Se= rvices. > Any unauthorised review, use, disclosure or distribution is prohibited. I= f you > are not the intended recipient, please contact the sender by reply e-mail= and destroy all copies of the original message. > > _______________________________________________ > 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 dean.willis@softarmor.com Tue Apr 13 16:08:39 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 AC90E3A6A76 for ; Tue, 13 Apr 2010 16:08:39 -0700 (PDT) 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 e26dcLxps2gL for ; Tue, 13 Apr 2010 16:08:38 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B80403A6809 for ; Tue, 13 Apr 2010 16:08:38 -0700 (PDT) Received: from localhost.localdomain (mobile-166-192-204-032.mycingular.net [166.192.204.32] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3DN8OaF019368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Apr 2010 18:08:31 -0500 X-User-Agent: K-9 Mail for Android In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA1F698F68A0@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <754963199212404AB8E9CFCA6C3D0CDA1F698F68A0@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: multipart/mixed; boundary="----AHV6LL69E6HSSBVTBRPGCOQL2Y8B5P" MIME-Version: 1.0 From: Dean Willis Date: Tue, 13 Apr 2010 19:08:14 -0400 To: "Cartwright, Kenneth" , "E.164 To MetaData BOF discussion list" Message-ID: <50019602-8bd4-43f4-b763-5ae4c6b0cc8e@email.android.com> Subject: Re: [e2md] [E2M] Call today? I thought ... 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, 13 Apr 2010 23:08:40 -0000 ------AHV6LL69E6HSSBVTBRPGCOQL2Y8B5P Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 RHVubm8uIEkgYW0gb24gYSB3b3JrIHNpdGUgaW4gdGhlIFVTVkkgd2l0aCBsaW1pdGVkIGFjY2Vz cyB0aGlzIHdlZWsuCi0tIApEZWFuIFdpbGxpcw== ------AHV6LL69E6HSSBVTBRPGCOQL2Y8B5P-- From HKaplan@acmepacket.com Tue Apr 13 16:16:55 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 B7C7C3A6B64 for ; Tue, 13 Apr 2010 16:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=0.275, 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 yelIoqzk6fTs for ; Tue, 13 Apr 2010 16:16:54 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 453303A6B5F for ; Tue, 13 Apr 2010 16:16:53 -0700 (PDT) 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, 13 Apr 2010 19:16:46 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 13 Apr 2010 19:16:46 -0400 From: Hadriel Kaplan To: "Cartwright, Kenneth" , Bernie Hoeneisen Date: Tue, 13 Apr 2010 19:16:44 -0400 Thread-Topic: [e2md] [E2M] Call today? I thought ... Thread-Index: AcrbO+EK9hFdSObjTuCs1rakFMQMLAAAA/qQAAikzRA= Message-ID: <430FC6BDED356B4C8498F634416644A91A79FCE9BF@mail> References: <754963199212404AB8E9CFCA6C3D0CDA1F698F68A0@TNS-MAIL-NA.win2k.corp.tnsi.com> <754963199212404AB8E9CFCA6C3D0CDA1F698F6933@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA1F698F6933@TNS-MAIL-NA.win2k.corp.tnsi.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: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] [E2M] Call today? I thought ... 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, 13 Apr 2010 23:16:55 -0000 Sorry, I didn't think there was one today either - someone said we needed a= n agenda, and no one has proposed one. I'm willing to provide a conf bridg= e for whatever, but the only agenda item I wanted, which prompted me to ask= for a call originally, was to discuss Jay's alternative to source-uri. I'= m specifically NOT volunteering to be the leader of it. :) Shall we hash out an agenda list and have a call next Tuesday, same time? -hadriel > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Cartwright, Kenneth > Sent: Tuesday, April 13, 2010 3:04 PM > To: Bernie Hoeneisen > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] [E2M] Call today? I thought ... >=20 > At the end of the last call, someone said "same time next week" and a few > people said "yes". Oh well. No biggie. >=20 >=20 > Ken >=20 > -----Original Message----- > From: Bernie Hoeneisen [mailto:bernie@ietf.hoeneisen.ch] > Sent: Tuesday, April 13, 2010 3:02 PM > To: Cartwright, Kenneth > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] [E2M] Call today? I thought ... >=20 > I do not recall a conf call being agreed for today. Have a missed > anything? >=20 From jay@nzrs.net.nz Tue Apr 13 18:27:12 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 086663A6970 for ; Tue, 13 Apr 2010 18:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[AWL=1.379, 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 OFKy2rBy7NDE for ; Tue, 13 Apr 2010 18:27:11 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 27A3C3A68CB for ; Tue, 13 Apr 2010 18:27:10 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 587D92DB772; Wed, 14 Apr 2010 13:27:02 +1200 (NZST) 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 oR9nGQiSleRH; Wed, 14 Apr 2010 13:27:02 +1200 (NZST) Received: from [192.168.22.175] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 304452DB704; Wed, 14 Apr 2010 13:27:02 +1200 (NZST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79FCE9BF@mail> Date: Wed, 14 Apr 2010 13:27:01 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <70A8628F-13B4-417E-8273-AAAD8444EEBE@nzrs.net.nz> References: <754963199212404AB8E9CFCA6C3D0CDA1F698F68A0@TNS-MAIL-NA.win2k.corp.tnsi.com> <754963199212404AB8E9CFCA6C3D0CDA1F698F6933@TNS-MAIL-NA.win2k.corp.tnsi.com> <430FC6BDED356B4C8498F634416644A91A79FCE9BF@mail> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1078) Cc: Bernie Hoeneisen , "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] [E2M] Call today? I thought ... 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, 14 Apr 2010 01:27:12 -0000 On 14/04/2010, at 11:16 AM, Hadriel Kaplan wrote: > Sorry, I didn't think there was one today either - someone said we = needed an agenda, and no one has proposed one. I'm willing to provide a = conf bridge for whatever, but the only agenda item I wanted, which = prompted me to ask for a call originally, was to discuss Jay's = alternative to source-uri. I'm specifically NOT volunteering to be the = leader of it. :) >=20 > Shall we hash out an agenda list and have a call next Tuesday, same = time? I will be in a different timezone (EST) but unfortunately in a meeting = all day and so unable to join. Week after? regards Jay >=20 > -hadriel >=20 >> -----Original Message----- >> From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf = Of >> Cartwright, Kenneth >> Sent: Tuesday, April 13, 2010 3:04 PM >> To: Bernie Hoeneisen >> Cc: E.164 To MetaData BOF discussion list >> Subject: Re: [e2md] [E2M] Call today? I thought ... >>=20 >> At the end of the last call, someone said "same time next week" and a = few >> people said "yes". Oh well. No biggie. >>=20 >>=20 >> Ken >>=20 >> -----Original Message----- >> From: Bernie Hoeneisen [mailto:bernie@ietf.hoeneisen.ch] >> Sent: Tuesday, April 13, 2010 3:02 PM >> To: Cartwright, Kenneth >> Cc: E.164 To MetaData BOF discussion list >> Subject: Re: [e2md] [E2M] Call today? I thought ... >>=20 >> I do not recall a conf call being agreed for today. Have a missed >> anything? >>=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From bernie@ietf.hoeneisen.ch Tue Apr 13 23:35: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 468C63A6BAB for ; Tue, 13 Apr 2010 23:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.439 X-Spam-Level: X-Spam-Status: No, score=-1.439 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 NxbzlWVkBESx for ; Tue, 13 Apr 2010 23:35:14 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 8AD553A6934 for ; Tue, 13 Apr 2010 23:35:14 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1O1wBj-0006fR-AA; Wed, 14 Apr 2010 08:35:03 +0200 Date: Wed, 14 Apr 2010 08:35:03 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Hadriel Kaplan In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79FCE9BF@mail> Message-ID: References: <754963199212404AB8E9CFCA6C3D0CDA1F698F68A0@TNS-MAIL-NA.win2k.corp.tnsi.com> <754963199212404AB8E9CFCA6C3D0CDA1F698F6933@TNS-MAIL-NA.win2k.corp.tnsi.com> <430FC6BDED356B4C8498F634416644A91A79FCE9BF@mail> 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: "E.164 To MetaData BOF discussion list" Subject: [e2md] Proposal for next call (was: Call today? I thought ...) 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, 14 Apr 2010 06:35:19 -0000 Hi, If no one else wants the token, I'll continue with the coordination of the e2md group. Let's try to find a 1h-slot next week. (Jay, as you are the most crusial for scheduling, could you please mail me your availabilities at times (in UT) when PST and CEST folks are not sleeping for the next 2 weeks or so? I'll then set up a Doodle trying to fit you in.) Proposed Agenda: 1) Opening / Roll Call 2) Discussion of the objections (Tracker): http://trac.tools.ietf.org/bof/e2md/trac/report/10 (Please enter your comments and missing objections you are aware of directly to the tracker in advance.) Goal: Find a common understanding on what the objections are and priorize those. 3) Discussion of the requirements (WiKi): http://trac.tools.ietf.org/bof/e2md/trac/wiki/RequirementsList (Please enter your additions, change proposals and missing requirements directly to the WiKi in advance.) Goal: Get a common understanding on what requirements we are addressing and in which timeframe. 4) How to proceed with the e2md work? Below a non-exhaustive list of alternatives: a) Request 2nd (and last) e2md BoF for IETF-78 (Maastricht) b) Have a BarBoF during IETF-78 and go for IETF-79 (Beijing) with the 2nd (real) BoF c1) Divide and conquer, i.e. something along the lines of http://ucom.ch/ietf/e2md-disc/divide_and_conquer.pdf c2) Declare the short term solution (c1) of the e2md work as "ENUM-Extension" and find a venue for carrying out the work (e.g. AD sponsored, re-charter of some existing WG, or whatsoever) d) Carry out the work elsewhere (e.g. AD sponsored, within an existing WG, completely new BoF proposal, or whatever comes to your mind...) e) Other Alternatives in sight? Please mail them to the list! Goal: Work on a decision on our way forward. Please send your comments about this proposal to the list! cheers, Bernie On Tue, 13 Apr 2010, Hadriel Kaplan wrote: > > Sorry, I didn't think there was one today either - someone said we > needed an agenda, and no one has proposed one. I'm willing to provide a > conf bridge for whatever, but the only agenda item I wanted, which > prompted me to ask for a call originally, was to discuss Jay's > alternative to source-uri. I'm specifically NOT volunteering to be the > leader of it. :) > > Shall we hash out an agenda list and have a call next Tuesday, same time? > > -hadriel > >> -----Original Message----- >> From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of >> Cartwright, Kenneth >> Sent: Tuesday, April 13, 2010 3:04 PM >> To: Bernie Hoeneisen >> Cc: E.164 To MetaData BOF discussion list >> Subject: Re: [e2md] [E2M] Call today? I thought ... >> >> At the end of the last call, someone said "same time next week" and a few >> people said "yes". Oh well. No biggie. >> >> >> Ken >> >> -----Original Message----- >> From: Bernie Hoeneisen [mailto:bernie@ietf.hoeneisen.ch] >> Sent: Tuesday, April 13, 2010 3:02 PM >> To: Cartwright, Kenneth >> Cc: E.164 To MetaData BOF discussion list >> Subject: Re: [e2md] [E2M] Call today? I thought ... >> >> I do not recall a conf call being agreed for today. Have a missed >> anything? >> > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > From bernie@ietf.hoeneisen.ch Fri Apr 16 01:47:44 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 804C73A6816 for ; Fri, 16 Apr 2010 01:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=0.547, 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 cI2SxXPi5mkD for ; Fri, 16 Apr 2010 01:47:43 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 247933A67CC for ; Fri, 16 Apr 2010 01:47:42 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1O2hD3-0001SI-CY for e2md@ietf.org; Fri, 16 Apr 2010 10:47:33 +0200 Date: Fri, 16 Apr 2010 10:47:33 +0200 (CEST) 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; 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 Subject: [e2md] Doodle: Link for poll "2nd E2MD Conf-Call" 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, 16 Apr 2010 08:47:44 -0000 Hi, Below the Doodle poll for the 2nd e2md conference call http://doodle.com/eapu88wfcmebrfd2 Please indicate your availabilities by the end of this week! Goals of the call: - Get a common understanding on what this objections are - Prepare the way foward Rough agenda: * List of Objections (draft version) http://trac.tools.ietf.org/bof/e2md/trac/report/10 * List of Requirements (draft version) http://trac.tools.ietf.org/bof/e2md/trac/wiki/RequirementsList * Discuss alternatives for way forward Of course anyone can suggest more topics to the list! cheers, Bernie From bernie@ietf.hoeneisen.ch Mon Apr 19 12:55:12 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 EEA4F3A6452 for ; Mon, 19 Apr 2010 12:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.836 X-Spam-Level: X-Spam-Status: No, score=-0.836 tagged_above=-999 required=5 tests=[AWL=-0.837, BAYES_50=0.001] 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 Um3nyoVFCfqd for ; Mon, 19 Apr 2010 12:55:12 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id C39B33A6AE6 for ; Mon, 19 Apr 2010 12:55:11 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1O3x3c-00034y-HS for e2md@ietf.org; Mon, 19 Apr 2010 21:55:00 +0200 Date: Mon, 19 Apr 2010 21:55:00 +0200 (CEST) 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; 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 Subject: [e2md] Conf Call on Mon, 2010-02-26 18:00 UT 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, 19 Apr 2010 19:55:13 -0000 Hi, Due to the high degree of uncertainty "The Cloud" is causing in these days (at least one of us is reported to be stuck on the island of Mallorca), I choose to schedule the meeting early next week. We'll be using voice call + application sharing. I made a reservation for an Adobe Connect Pro virtual meeting room. Audio will go via a bridge that can do SIP, H.323 and PSTN. (This number is even in the private ENUM tree of 'nrenum.net' ;-) ) Here the datails: Start date/time: Mon, 2010-04-26 18:00 (UTC) Collaboration Tool (Adobe Connect Pro): * http://collab.switch.ch/ietf-e2md Dial-In (Voice and/or Video): * SIP: sip:96@mcu-hd.switch.ch * H.323: h323:96@mcu-hd.switch.ch * PSTN: +41 44 250 96 96 Please contact me, in case you cannot use SIP nor H.323 and there is an issue with the costs occuring from dialing to a Swiss fixed network number. In this case we could look for another voice-bridge solution. cheers, Bernie ---------------- If you have never attended a Connect Pro meeting before: Test your connection: http://collab.switch.ch/common/help/en/support/meeting_test.htm Get a quick overview: http://www.adobe.com/go/connectpro_overview --------------- NOTES - H.323 (IP) conference dialin: Participants being part of the Global Dialing Scheme (GDS) use this number to dial into the conference. Other H.323 participants are allowed to register with the SWITCH gatekeeper. - H.320 (ISDN) conference dialin: H.320 participants use this number to dial into the conference (bonding of up to 6 B-channels is supported). The same number can be used to dialin with a normal telephone (audio only). From gonzalo.camarillo@ericsson.com Tue Apr 20 10:47:01 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 3D2BD3A694D for ; Tue, 20 Apr 2010 10:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.308 X-Spam-Level: X-Spam-Status: No, score=-104.308 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_50=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 O5rcqKktNHUu for ; Tue, 20 Apr 2010 10:47:00 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id D36973A67FD for ; Tue, 20 Apr 2010 10:46:59 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-b6-4bcde88961f7 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 0E.EC.23532.988EDCB4; Tue, 20 Apr 2010 19:46:49 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Apr 2010 19:46:49 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Apr 2010 19:46:48 +0200 Received: from [131.160.126.129] (rvi2-126-129.lmf.ericsson.se [131.160.126.129]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A80E524D0; Tue, 20 Apr 2010 20:46:48 +0300 (EEST) Message-ID: <4BCDE888.8020207@ericsson.com> Date: Tue, 20 Apr 2010 20:46:48 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Bernie Hoeneisen References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Apr 2010 17:46:48.0504 (UTC) FILETIME=[737F5B80:01CAE0B1] X-Brightmail-Tracker: AAAAAA== Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Conf Call on Mon, 2010-04-26 18:00 UT 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, 20 Apr 2010 17:47:01 -0000 Hi, I have just fixed the subject of the email. I am guessing this call will take place in April, not in February ;o) By the way, how long will it last? Cheers, Gonzalo On 19/04/2010 10:55 PM, Bernie Hoeneisen wrote: > Hi, > > Due to the high degree of uncertainty "The Cloud" is causing in these days > (at least one of us is reported to be stuck on the island of Mallorca), I > choose to schedule the meeting early next week. > > We'll be using voice call + application sharing. > > I made a reservation for an Adobe Connect Pro virtual meeting room. > Audio will go via a bridge that can do SIP, H.323 and PSTN. > (This number is even in the private ENUM tree of 'nrenum.net' ;-) ) > > > Here the datails: > > Start date/time: Mon, 2010-04-26 18:00 (UTC) > > Collaboration Tool (Adobe Connect Pro): > * http://collab.switch.ch/ietf-e2md > > Dial-In (Voice and/or Video): > * SIP: sip:96@mcu-hd.switch.ch > * H.323: h323:96@mcu-hd.switch.ch > * PSTN: +41 44 250 96 96 > > > Please contact me, in case you cannot use SIP nor H.323 and there is an > issue with the costs occuring from dialing to a Swiss fixed network > number. In this case we could look for another voice-bridge solution. > > > cheers, > Bernie > > > ---------------- > > If you have never attended a Connect Pro meeting before: > > Test your connection: > http://collab.switch.ch/common/help/en/support/meeting_test.htm > > Get a quick overview: http://www.adobe.com/go/connectpro_overview > > --------------- > > NOTES > > - H.323 (IP) conference dialin: > Participants being part of the Global Dialing Scheme (GDS) use > this number to dial into the conference. Other H.323 participants > are allowed to register with the SWITCH gatekeeper. > > - H.320 (ISDN) conference dialin: > H.320 participants use this number to dial into the conference > (bonding of up to 6 B-channels is supported). > The same number can be used to dialin with a normal telephone > (audio only). > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > From bernie@ietf.hoeneisen.ch Wed Apr 21 01:29: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 B32F33A6358 for ; Wed, 21 Apr 2010 01:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=0.593, BAYES_20=-0.74, GB_I_INVITATION=-2] 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 eH-V1RtOb8wQ for ; Wed, 21 Apr 2010 01:29:21 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 82A843A697B for ; Wed, 21 Apr 2010 01:29:13 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1O4VIr-0006zu-1R; Wed, 21 Apr 2010 10:29:01 +0200 Date: Wed, 21 Apr 2010 10:29:01 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Gonzalo Camarillo In-Reply-To: <4BCDE888.8020207@ericsson.com> Message-ID: References: <4BCDE888.8020207@ericsson.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="37663318-683649499-1271838541=:26456" 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] Conf Call on Mon, 2010-04-26 18:00 UT 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, 21 Apr 2010 08:29:22 -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-683649499-1271838541=:26456 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Hi Gonzalo Thanks for spotting the typo in the Subject Line. As you easily could guess, the date in the body of the email is the correct one: Mon, 2010-04-26 18:00 (UTC) The scheduled duration is one hour. In the attachment you find a calendar invitation. cheers. Bernie On Tue, 20 Apr 2010, Gonzalo Camarillo wrote: > Hi, > > I have just fixed the subject of the email. I am guessing this call will > take place in April, not in February ;o) > > By the way, how long will it last? > > Cheers, > > Gonzalo > > > On 19/04/2010 10:55 PM, Bernie Hoeneisen wrote: >> Hi, >> >> Due to the high degree of uncertainty "The Cloud" is causing in these days >> (at least one of us is reported to be stuck on the island of Mallorca), I >> choose to schedule the meeting early next week. >> >> We'll be using voice call + application sharing. >> >> I made a reservation for an Adobe Connect Pro virtual meeting room. >> Audio will go via a bridge that can do SIP, H.323 and PSTN. >> (This number is even in the private ENUM tree of 'nrenum.net' ;-) ) >> >> >> Here the datails: >> >> Start date/time: Mon, 2010-04-26 18:00 (UTC) >> >> Collaboration Tool (Adobe Connect Pro): >> * http://collab.switch.ch/ietf-e2md >> >> Dial-In (Voice and/or Video): >> * SIP: sip:96@mcu-hd.switch.ch >> * H.323: h323:96@mcu-hd.switch.ch >> * PSTN: +41 44 250 96 96 >> >> >> Please contact me, in case you cannot use SIP nor H.323 and there is an >> issue with the costs occuring from dialing to a Swiss fixed network >> number. In this case we could look for another voice-bridge solution. >> >> >> cheers, >> Bernie >> >> >> ---------------- >> >> If you have never attended a Connect Pro meeting before: >> >> Test your connection: >> http://collab.switch.ch/common/help/en/support/meeting_test.htm >> >> Get a quick overview: http://www.adobe.com/go/connectpro_overview --37663318-683649499-1271838541=:26456 Content-Type: TEXT/calendar; name=invite.ics Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=invite.ics QkVHSU46VkNBTEVOREFSDQ0KUFJPRElEOi0vL0dvb2dsZSBJbmMvL0dvb2ds ZSBDYWxlbmRhciA3MC45MDU0Ly9FTg0NClZFUlNJT046Mi4wDQ0KQ0FMU0NB TEU6R1JFR09SSUFODQ0KTUVUSE9EOlJFUVVFU1QNDQpCRUdJTjpWRVZFTlQN DQpEVFNUQVJUOjIwMTAwNDI2VDE4MDAwMFoNDQpEVEVORDoyMDEwMDQyNlQx OTAwMDBaDQ0KRFRTVEFNUDoyMDEwMDQyMVQwODEzNTJaDQ0KT1JHQU5JWkVS O0NOPUJlcm5pZSBIb2VuZWlzZW46bWFpbHRvOmJlcm5oYXJkLmhvZW5laXNl bkB1Y29tLmNoDQ0KVUlEOjdpNzM2NTY5OThiZGRqcG9xN2p1aXEzZHNnQGdv b2dsZS5jb20NDQpBVFRFTkRFRTtDVVRZUEU9SU5ESVZJRFVBTDtST0xFPVJF US1QQVJUSUNJUEFOVDtQQVJUU1RBVD1BQ0NFUFRFRDtSU1ZQPVRSVUUNDQog O0NOPUJlcm5pZSBIb2VuZWlzZW47WC1OVU0tR1VFU1RTPTA6bWFpbHRvOmJl cm5oYXJkLmhvZW5laXNlbkB1Y29tLmNoDQ0KQVRURU5ERUU7Q1VUWVBFPUlO RElWSURVQUw7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMt QUNUSU9OO1JTVlA9DQ0KIFRSVUU7Q049ZTJtZEBpZXRmLm9yZztYLU5VTS1H VUVTVFM9MDptYWlsdG86ZTJtZEBpZXRmLm9yZw0NCkNSRUFURUQ6MjAxMDA0 MjFUMDc1MTU1Wg0NCkRFU0NSSVBUSU9OOkNvbGxhYm9yYXRpb24gVG9vbCAo QWRvYmUgQ29ubmVjdCBQcm8pOlxuXG4qIGh0dHA6Ly9jb2xsYWIuc3dpdA0N CiBjaC5jaC9pZXRmLWUybWRcblxuXG5EaWFsLUluOlxuXG4qIFNJUDogICBz aXA6OTZAbWN1LWhkLnN3aXRjaC5jaFxuKiBILjMyMzoNDQogICBoMzIzOjk2 QG1jdS1oZC5zd2l0Y2guY2hcbiogUFNUTjogICs0MSA0NCAyNTAgOTYgOTZc blxuXG5Hb2FscyBvZiB0aGUgY2FsDQ0KIGw6XG5cbiogR2V0IGEgY29tbW9u IHVuZGVyc3RhbmRpbmcgb24gd2hhdCB0aGlzIG9iamVjdGlvbnMgYXJlXG4q IFByZXBhcmUgdA0NCiBoZSB3YXkgZm9yd2FyZFxuXG5cblJvdWdoIGFnZW5k YTpcblxuKiBMaXN0IG9mIE9iamVjdGlvbnMgKGRyYWZ0IHZlcnNpb24pXG4N DQogICBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ib2YvZTJtZC90cmFj L3JlcG9ydC8xMFxuXG4qIExpc3Qgb2YgUmVxdWlyZW1lDQ0KIG50cyAoZHJh ZnQgdmVyc2lvbilcbiAgaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYm9m L2UybWQvdHJhYy93aWtpL1JlcXVpcg0NCiBlbWVudHNMaXN0XG5cbiogRGlz Y3VzcyBhbHRlcm5hdGl2ZXMgZm9yIHdheSBmb3J3YXJkXG5cblxuT2YgY291 cnNlIGFueW9uZSANDQogY2FuIHN1Z2dlc3QgbW9yZSB0b3BpY3MgdG8gdGhl IGUybWQgbGlzdCFcblxuY2hlZXJzXCxcbiBCZXJuaWVcblZpZXcgeW91ciBl DQ0KIHZlbnQgYXQgaHR0cDovL3d3dy5nb29nbGUuY29tL2NhbGVuZGFyL2V2 ZW50P2FjdGlvbj1WSUVXJmVpZD1OMmszTXpZMU5qazVPRw0NCiBKa1pHcHdi M0UzYW5WcGNUTmtjMmNnWW1odlpXNWxhWE5BYlEmdG9rPU1UUWpZbVZ5Ym1s bFFIVmpiMjB1WTJneVptTTVORFZsTWoNDQogRTVNamczWlRjM1pXUXdOamcz TUdabU1UUXdPVEF6WkRsa1lqaGxaR1JoJmN0ej1FdXJvcGUlMkZadXJpY2gm aGw9ZW5fR0IuDQ0KTEFTVC1NT0RJRklFRDoyMDEwMDQyMVQwODEzNTFaDQ0K TE9DQVRJT046aHR0cDovL2NvbGxhYi5zd2l0Y2guY2gvaWV0Zi1lMm1kIEFO RCBzaXA6OTZAbWN1LWhkLnN3aXRjaC5jaCBPUiArDQ0KIDQxIDQ0IDI1MCA5 NiA5Ng0NClNFUVVFTkNFOjANDQpTVEFUVVM6Q09ORklSTUVEDQ0KU1VNTUFS WToybmQgZTJtZCBjb25mIGNhbGwNDQpUUkFOU1A6T1BBUVVFDQ0KRU5EOlZF VkVOVA0NCkVORDpWQ0FMRU5EQVINDQo= --37663318-683649499-1271838541=:26456-- From bernie@ietf.hoeneisen.ch Mon Apr 26 13:12: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 DB3123A6944 for ; Mon, 26 Apr 2010 13:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.229 X-Spam-Level: X-Spam-Status: No, score=-0.229 tagged_above=-999 required=5 tests=[AWL=-1.470, BAYES_50=0.001, SARE_LWSHORTT=1.24] 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 P+dS1nnEeUgj for ; Mon, 26 Apr 2010 13:12:01 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id A9DB73A6BBA for ; Mon, 26 Apr 2010 13:11:47 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1O6UeT-0003cW-JF for e2md@ietf.org; Mon, 26 Apr 2010 22:11:33 +0200 Date: Mon, 26 Apr 2010 22:11:33 +0200 (CEST) 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; 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 Subject: [e2md] Rough minutes of today's conf call 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, 26 Apr 2010 20:12:03 -0000 Please holler in case we caught anything wrongly! Goals of the call: * Get a common understanding on what this objections are * Prepare the way forward Agenda: * Hadriel's source URI proposal (brought in during the meeting) * List of Objections (draft version) http://trac.tools.ietf.org/bof/e2md/trac/report/10 * List of Requirements (draft version) http://trac.tools.ietf.org/bof/e2md/trac/wiki/RequirementsList --> Needed to be skipped for this conf call (decided on separate conf call on this) * Discuss alternatives for way forward Participants: - Jay Delay - Gonzalo Camarillo (RAI AD) - Bernie Hoeneisen (chair) - Ray Bellis - Lawrence Conroy - Victor - Jay Carpenter - Hadriel Kaplan - Dean Willis (secr. 1st half) CONCLUSIONS: The following was seen a reasonable proposal forward by the participants of the conf call around 19:30 UT (after the official end). If anybody disagrees, please state your opinion to the e2md mailing-list: - Split up the problem space to make target smaller - AD sponsored is not a sensible way forward, nor is individual submission - Have a less agressive schedule to form a Working Group - Informal Meetings in Maastricht (IETF-78) - Formal WG-forming BoF earliest by Beijing (IETF-79) 3 Informal Meetings in Maastricht: - How to deal with objections? - Short term requirements (around ENUM) - Longer term requirements (Destination Groups, Source URI, ...) Conference Calls before Maastricht: - Longer term requirements; in about 2 weeks; by Hadriel - Requirements discussion; in about 4 weeks; by Bernie - Continue discussion; in about 6 week; by Bernie NOTES: Below Dean Willis' notes from the first half of the meeting. Thanks Dean! (unfortunately Dean had to leave early and no-one else volunteered for taking notes): Bernie chairing. Noted that purpose of call is to resolve objections. Jay Daley asked: Why does Hadriel think we have to do redirection at the time of receiving a request instead of doing it later? Jay restated proposal: basically same as destination group that Ray has already drafted. Two types of carriers; do and do not publish interconnect data. Proposal allows publication of data that is meaningless unless you have the destination-group map in hand. Ray says this is also the core of the proposed spec for the UK number portability database. Hadriel thinks he understands the proposal, but that as he understands it it has nothing to do with the problem that source-uri was trying to solve. Hadriel re-stated the use case of source-uri; the source information affects the result of the lookup. Jay proposed putting source and results in response and letting subscriber filter. Discussion followed. Lawrence posed a question for clarification: one use case for source-uri is when incoming calls from a particular carrier (or associated trunk), other when caller is from a particular area or carrier, and therefore the source impacts the decision of where to go next. He suggests that Hadriel elucidate in the draft. Ray noted that there have been proposals in dnsext to tailor response based in requesting IP address. or other identifying strings. Lawrence noted that UK carriers had argued strongly against putting the actual routing tables in the DNS, and that they had instead proposed to put table indices in their and share the topology information offline. Chair moved discussion onto open objections. Starting at Objection #2: Open Issue: Is everything a DDDS? I Is it a a NAPTR? Lawrence asserts that the major problem in ENUM is DDDS specification, which was hard to write and harder to read. The problems were all caused by people understanding DDDS differently. However, the idea of NAPTR with a side-tag seems reasonable. Suggests we do NOT do another DDDS application. Ray noted that DDDS implies NAPTR (or SNAPTR or UNAPTR...). Noted that part of our goal here is to reduce load on IESG by having smallest possible changes from ENUM. Having a work item that extends four really obscure documents is hard for them. Concluded: We are NOT talking about a different port. We are talking about how hard it might be to get an entirely new DDDS approved. Our current proposal is to just reuse the E2U DDDS with a new label. If we don't want to have URIs, why are we using NAPTRs? Lawrence noted that the general question: Should application-specific data being put in to the DNS? This seems to be a real debate question on name-droppers. TXT is real data... maybe we really COULD use TXT. Hadriel noted that one of the problems in the bof was that the use-cases are unclear. Which use-case are we working on? Discussion of send-n use case followed, as it's not "new data", it's an optimization for reducing further queries. It really DOES have to be a type-35 record. Is this really E2MD? Are the other things metadata or just data? One of Olaf or Peter may have suggested during the BOF that the "unused" and "send-n" problems are more general DNS problems. Noted that this stemmed in part from insistence in 3761 that any query should be for a fully-qualified number. Noted that unused and send-n work together to reduce the number of unused entries needed when there is a whole block of unused. Noted also that cnam is not "something you can use to call someone". The same is true for the putting the caller's public key into the tree. Suggested that we could have just extended E2U more easily. From wwwrun@core3.amsl.com Tue Apr 27 08:14:01 2010 Return-Path: X-Original-To: e2md@ietf.org Delivered-To: e2md@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id DF6C43A6BAE; Tue, 27 Apr 2010 08:14:00 -0700 (PDT) From: Georges Sebek(ITU-T SG 17) To: Ray.Bellis@nominet.org.uk, bernie@ietf.hoeneisen.ch Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100427151400.DF6C43A6BAE@core3.amsl.com> Date: Tue, 27 Apr 2010 08:14:00 -0700 (PDT) Cc: e2md@ietf.org, paf@cisco.com, tsbsg17@itu.int Subject: [e2md] New Liaison Statement, "Summary of identity management related Recommendations" X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg17@itu.int, sebek@itu.int 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, 27 Apr 2010 15:14:01 -0000 Title: Summary of identity management related Recommendations Submission Date: 2010-04-27 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=885 From: Georges Sebek(ITU-T SG 17) To: IETF E2MD(Ray.Bellis@nominet.org.uk, bernie@ietf.hoeneisen.ch) Cc: e2md@ietf.org paf@cisco.com Reponse Contact: tsbsg17@itu.int sebek@itu.int Technical Contact: abarbir@live.ca Purpose: For information Body: Please find attached a liaison statement agreed to at the 7-16 April 2010 Study Group 17 (Security) meeting. The liaison statement has 4 attachments as follows: (1) Summaries of Q.10/17 draft Recommendations (2) Recommendation ITU-T X.1252, Baseline identity management terms and definitions (3) Draft Recommendation ITU-T X.1275, Guidelines on protection of personally identifiable information in the application of RFID technology (4) Draft Recommendation ITU-T X.priva, Criteria for assessing the level of protection for personally identifiable information in identity management Attachment(s): Draft Recommendation ITU-T X.priva, Criteria for assessing the level of protection for personally identifiable information in identity management (https://datatracker.ietf.org/documents/LIAISON/file1004.pdf) Recommendation ITU-T X.1252, Baseline identity management terms and definitions (https://datatracker.ietf.org/documents/LIAISON/file1005.pdf) Draft Recommendation ITU-T X.1275, Guidelines on protection of personally identifiable information in the application of RFID technology (https://datatracker.ietf.org/documents/LIAISON/file1006.pdf) COM 17-LS 121 - Summary of identity management related Recommendations (https://datatracker.ietf.org/documents/LIAISON/file1007.pdf) (1) Summaries of Q.10/17 draft Recommendations (https://datatracker.ietf.org/documents/LIAISON/file1008.pdf) From Ray.Bellis@nominet.org.uk Wed Apr 28 01:45:14 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 835943A6AF5 for ; Wed, 28 Apr 2010 01:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.949 X-Spam-Level: X-Spam-Status: No, score=-8.949 tagged_above=-999 required=5 tests=[AWL=1.650, 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 cGkAoV8yly0A for ; Wed, 28 Apr 2010 01:45:13 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 2E5C73A6B19 for ; Wed, 28 Apr 2010 01:45:12 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version:Return-Path; b=NSz81PtABKFaVo3LG5vYU5PSaD9nbMY6i9uN5sCXWDHW0YE6xScXL+an DOWmC2xxHJZqM7lQqssU2RI5uE75al5KCqbO9DkFwMhVYLNzrylvk0lu1 oAuArlxLGZmBzA3; 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=1272444301; x=1303980301; 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=20Bellis=20 |Subject:=20Re:=20[e2md]=20Rough=20minutes=20of=20today's =20conf=20call|Date:=20Wed,=2028=20Apr=202010=2008:44:56 =20+0000|Message-ID:=20|To:=20Bernie=20Hoeneisen=20,=20E.164=20To=20MetaData=20BOF=0D=0A=20discussion=20 list=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<453d3b5a-b7be-46a8-81fe-303780accc26> |In-Reply-To:=20; bh=MJTLq559f/DT6ogWjSX1RQAcFMl79Pr59hGuJRbxJIE=; b=ERxoBMn5BbNDNbVnHTpow4JLkuzznr3OZY+jxll7fMI/x0fOJ9mFWqDi XOEr336b9LQr6Y/K5GYx/sSsxEDZOnz+K722Zm3uwxLViU42iFbnBPS+J WtVrUSaEoutdNRa; X-IronPort-AV: E=Sophos;i="4.52,287,1270422000"; d="scan'208";a="23811051" Received: from host-213-248-197-145.nominet.org.uk (HELO wds-exc2.okna.nominet.org.uk) ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 28 Apr 2010 09:44:59 +0100 Received: from BDC-WDS-EXC1.okna.nominet.org.uk (2002:d5f8:c592::d5f8:c592) by wds-exc2.okna.nominet.org.uk (2002:d5f8:c591::d5f8:c591) with Microsoft SMTP Server (TLS) id 14.0.639.21; Wed, 28 Apr 2010 09:44:59 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by bdc-wds-exc1.okna.nominet.org.uk ([fe80::784f:9067:6a1a:ab8f%18]) with mapi; Wed, 28 Apr 2010 09:44:58 +0100 From: Ray Bellis To: Bernie Hoeneisen , E.164 To MetaData BOF discussion list Thread-Topic: [e2md] Rough minutes of today's conf call Thread-Index: AQHK5Xy4gmvotj7Ps0mDfZR5dxExEJI3ky4A Date: Wed, 28 Apr 2010 08:44:56 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <453d3b5a-b7be-46a8-81fe-303780accc26> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [e2md] Rough minutes of today's conf call 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, 28 Apr 2010 08:45:14 -0000 re: this point from Dean's notes: > If we don't want to have URIs, why are we using NAPTRs? I don't recall this, and it doesn't make sense to me. Other than the way that RFCs 3404 and 3761 define a flag value of 'u' to mean 'the result of this lookup is a URI' it's not otherwise required by RF= C 3403 which is the formal definition of a NAPTR record. Perhaps the problem is stated the wrong way around? Ultimately if we end up extending E2U then we do have to shoehorn our data into a URI-like format. That is one of the arguments for E2MD being a separate DDDS app. Ray From lconroy@insensate.co.uk Wed Apr 28 03:18:13 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 4C35D3A684B for ; Wed, 28 Apr 2010 03:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.058 X-Spam-Level: X-Spam-Status: No, score=0.058 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_50=0.001] 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 ud5tcAF15KLa for ; Wed, 28 Apr 2010 03:18:11 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 591D23A6805 for ; Wed, 28 Apr 2010 03:18:11 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 62F2E12B92B; Wed, 28 Apr 2010 11:17:56 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: Date: Wed, 28 Apr 2010 11:17:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk> References: To: Ray Bellis X-Mailer: Apple Mail (2.1078) Cc: Bernie Hoeneisen , "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Rough minutes of today's conf call 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, 28 Apr 2010 10:18:13 -0000 Hi Ray, that's my fault, I think. I paraphrased an *objection* we had heard as "if you don't want to have URIs, why are you using NAPTRs"? As you say, the objection entirely as phrased misses the mark, so I guess either we don't understand the real objection, or the objector doesn't understand. Listening in on the BoF audio, it seemed that people were reminding us that one could put other records into an "ENUM domain", such as TXT. This led on to an implied principle -- should one put data into DNS, or merely publish pointers to something else? Given TXT is already used in DNS (and that sure is data), can we use that? Thus a question we do need to answer is "why can't one just use TXT for textual data (like CNAM)"? honest, I did say it. all the best, Lawrence On 28 Apr 2010, at 09:44, Ray Bellis wrote: > re: this point from Dean's notes: >> If we don't want to have URIs, why are we using NAPTRs? >=20 > I don't recall this, and it doesn't make sense to me. >=20 > Other than the way that RFCs 3404 and 3761 define a flag value of 'u' = to > mean 'the result of this lookup is a URI' it's not otherwise required = by RFC > 3403 which is the formal definition of a NAPTR record. >=20 > Perhaps the problem is stated the wrong way around? >=20 > Ultimately if we end up extending E2U then we do have to shoehorn our = data > into a URI-like format. That is one of the arguments for E2MD being a > separate DDDS app. >=20 > Ray >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From richard@shockey.us Wed Apr 28 05:55:25 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 6B82728C0FB for ; Wed, 28 Apr 2010 05:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.737 X-Spam-Level: X-Spam-Status: No, score=-0.737 tagged_above=-999 required=5 tests=[AWL=-0.552, BAYES_40=-0.185] 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 Z5EukiRslNTi for ; Wed, 28 Apr 2010 05:55:21 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id CFD0A28C0EA for ; Wed, 28 Apr 2010 05:55:15 -0700 (PDT) Received: (qmail 6601 invoked by uid 0); 28 Apr 2010 12:55:03 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 28 Apr 2010 12:55:03 -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=VbntMgzifLmLc/2E15FZmM3vyqbUq0NFOU6EKBBePgZPz60fUtSUWnxchnnIzX5kIUbjlPG1GbblElfBcs9C5NPGK+yx9H3376R0vvY73+51ShXx4BuZNUg8yrBWLOUs; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1O76n8-0003AK-RI; Wed, 28 Apr 2010 06:55:03 -0600 From: "Richard Shockey" To: "'Lawrence Conroy'" , "'Ray Bellis'" References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk> In-Reply-To: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk> Date: Wed, 28 Apr 2010 08:54:57 -0400 Message-ID: <010901cae6d2$02649fb0$072ddf10$@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: AcrmvBXzgu9NgxmXQie5jbQINbhFxAAFeMkQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: 'Bernie Hoeneisen' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Rough minutes of today's conf call 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, 28 Apr 2010 12:55:25 -0000 Yea.. exactly .. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Lawrence Conroy Sent: Wednesday, April 28, 2010 6:18 AM To: Ray Bellis Cc: Bernie Hoeneisen; E.164 To MetaData BOF discussion list Subject: Re: [e2md] Rough minutes of today's conf call Hi Ray, that's my fault, I think. I paraphrased an *objection* we had heard as "if you don't want to have URIs, why are you using NAPTRs"? As you say, the objection entirely as phrased misses the mark, so I guess either we don't understand the real objection, or the objector doesn't understand. Listening in on the BoF audio, it seemed that people were reminding us that one could put other records into an "ENUM domain", such as TXT. This led on to an implied principle -- should one put data into DNS, or merely publish pointers to something else? Given TXT is already used in DNS (and that sure is data), can we use that? Thus a question we do need to answer is "why can't one just use TXT for textual data (like CNAM)"? honest, I did say it. all the best, Lawrence On 28 Apr 2010, at 09:44, Ray Bellis wrote: > re: this point from Dean's notes: >> If we don't want to have URIs, why are we using NAPTRs? > > I don't recall this, and it doesn't make sense to me. > > Other than the way that RFCs 3404 and 3761 define a flag value of 'u' to > mean 'the result of this lookup is a URI' it's not otherwise required by RFC > 3403 which is the formal definition of a NAPTR record. > > Perhaps the problem is stated the wrong way around? > > Ultimately if we end up extending E2U then we do have to shoehorn our data > into a URI-like format. That is one of the arguments for E2MD being a > separate DDDS app. > > Ray > > _______________________________________________ > 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 dean.willis@softarmor.com Wed Apr 28 11:03: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 A160B3A69D0 for ; Wed, 28 Apr 2010 11:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-0.914, BAYES_40=-0.185] 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 rtpFQUjyIF-v for ; Wed, 28 Apr 2010 11:03:21 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B874E3A6B80 for ; Wed, 28 Apr 2010 11:03:20 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3SI2s8h008622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Apr 2010 13:02:56 -0500 Message-Id: From: Dean Willis To: Lawrence Conroy In-Reply-To: <9B0CB843-4359-4F0C-AB00-1A7602306346@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: Wed, 28 Apr 2010 13:02:49 -0500 References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk> X-Mailer: Apple Mail (2.936) Cc: Bernie Hoeneisen , "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Rough minutes of today's conf call 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, 28 Apr 2010 18:03:22 -0000 On Apr 28, 2010, at 5:17 AM, Lawrence Conroy wrote: > > Thus a question we do need to answer is > "why can't one just use TXT for textual data (like CNAM)"? See: http://ietfreport.isoc.org/all-ids/draft-iab-dns-choices-08.txt The general answer is "because the semantics of the TXT record are undefined". It MIGHT be a name; it might be a racial epithet, and it might be a government inventory serial number. We have no way to tell. I had proposed using an SRV style _prefix modifier to provide the semantic on list, and I seem to recall a good many people reacting by saying I was some sort enumphobic sippohile who knew nothing about the DNS in response. I also received the more measured response that an _prefix didn't work because it breaks aggregation using wildcards, and we really need aggregation for entire number blocks that are assigned to a big corporate PBX. The IAB's current guidance, in short, says that if you think you need TXT, you probably need a new resource record type. I'm becoming more inclined to agree. -- Dean From dean.willis@softarmor.com Wed Apr 28 11:04:53 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 B55523A6B8F for ; Wed, 28 Apr 2010 11:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=0.313, 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 ZFqXO4dr-duC for ; Wed, 28 Apr 2010 11:04:53 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E329D3A69D0 for ; Wed, 28 Apr 2010 11:04:52 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3SI4WVV008663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Apr 2010 13:04:33 -0500 Message-Id: From: Dean Willis To: Ray Bellis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Apr 2010 13:04:26 -0500 References: X-Mailer: Apple Mail (2.936) Cc: Bernie Hoeneisen , "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Rough minutes of today's conf call 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, 28 Apr 2010 18:04:53 -0000 On Apr 28, 2010, at 3:44 AM, Ray Bellis wrote: > re: this point from Dean's notes: > >> If we don't want to have URIs, why are we using NAPTRs? > > I don't recall this, and it doesn't make sense to me. > > Other than the way that RFCs 3404 and 3761 define a flag value of > 'u' to > mean 'the result of this lookup is a URI' it's not otherwise > required by RFC > 3403 which is the formal definition of a NAPTR record. I believe Bernie has proposed adding a new NAPTR flag field for a terminal metadatum. The better question is "If we don't need all the regexp replacement cruft, why are we using NAPTR?" Do we need it? -- Dean From richard@shockey.us Wed Apr 28 11:40: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 4F9CA3A6B64 for ; Wed, 28 Apr 2010 11:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.684, 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 3nLq58AQWrE8 for ; Wed, 28 Apr 2010 11:40:19 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 3EED83A6C09 for ; Wed, 28 Apr 2010 11:40:18 -0700 (PDT) Received: (qmail 10234 invoked by uid 0); 28 Apr 2010 18:40:05 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 28 Apr 2010 18:40:05 -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=hRoSv4t+tTxBas0Wqasw0AZVCHasPSgVKZFiupF+RbErcvhbpPmBLpRsL6n/Y1VULUdtDtGB0UaWJtMioGcaNyptpsc13lXXl7C/q1iZykLHQh64bPjJ5Cq4lfC+LOqj; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1O7CB2-0007oM-70; Wed, 28 Apr 2010 12:40:04 -0600 From: "Richard Shockey" To: "'Dean Willis'" , "'Lawrence Conroy'" References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk> In-Reply-To: Date: Wed, 28 Apr 2010 14:39:57 -0400 Message-ID: <01b201cae702$35547a00$9ffd6e00$@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: Acrm/RBqkfrWp8qMTAqqVEyWh5qvygAA+aww Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: 'Bernie Hoeneisen' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Rough minutes of today's conf call 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, 28 Apr 2010 18:40:20 -0000 I think the IAB guidance is not applicable here. I think they were looking at an entirely different problem here. SRV records only complicate what is a simple data retrieval problem for some of us. The larger issue here is that you have a bunch of DNS weenies that don't realize what we are really trying to do is make SIP actual work better when using E164 identifiers and kill off SS7 in the process. SPID=vkgr4356;CIC=76543 really works well. Text strings that propend SIP URI's are not problems LRN=7038763456;NPDI=yes seems to work. :-) Obviously this not this is not the case for all forms of metadata. This is a "one size DOES NOT fit all" problem. Dean ..how many times have I had to tell you and the entire RAI ..there are NO such things as Enterprise number blocks where LNP is dominant? -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dean Willis Sent: Wednesday, April 28, 2010 2:03 PM To: Lawrence Conroy Cc: Bernie Hoeneisen; E.164 To MetaData BOF discussion list Subject: Re: [e2md] Rough minutes of today's conf call On Apr 28, 2010, at 5:17 AM, Lawrence Conroy wrote: > > Thus a question we do need to answer is > "why can't one just use TXT for textual data (like CNAM)"? See: http://ietfreport.isoc.org/all-ids/draft-iab-dns-choices-08.txt The general answer is "because the semantics of the TXT record are undefined". It MIGHT be a name; it might be a racial epithet, and it might be a government inventory serial number. We have no way to tell. I had proposed using an SRV style _prefix modifier to provide the semantic on list, and I seem to recall a good many people reacting by saying I was some sort enumphobic sippohile who knew nothing about the DNS in response. I also received the more measured response that an _prefix didn't work because it breaks aggregation using wildcards, and we really need aggregation for entire number blocks that are assigned to a big corporate PBX. The IAB's current guidance, in short, says that if you think you need TXT, you probably need a new resource record type. I'm becoming more inclined to agree. -- Dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From lconroy@insensate.co.uk Wed Apr 28 15:10: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 90C243A6980 for ; Wed, 28 Apr 2010 15:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.047 X-Spam-Level: X-Spam-Status: No, score=0.047 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_50=0.001] 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 YXNjfdxgP79N for ; Wed, 28 Apr 2010 15:10:20 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 172163A68CE for ; Wed, 28 Apr 2010 15:10:19 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 4C94912BDAF; Wed, 28 Apr 2010 23:10:05 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: Date: Wed, 28 Apr 2010 23:10:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4B73E62E-B80F-4CBA-9FC6-640D49BF5F84@insensate.co.uk> References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk> To: Dean Willis X-Mailer: Apple Mail (2.1078) Cc: Bernie Hoeneisen , "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Rough minutes of today's conf call 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, 28 Apr 2010 22:10:24 -0000 Hi Dean, folks, On 28 Apr 2010, at 19:02, Dean Willis wrote: > It MIGHT be a name; it might be a racial epithet, and it might be a = government inventory serial number. We have no way to tell. Apart from the amusement that epithet might bring (viz today's news = about radio microphones and disasters), I kinda guess that there would = be some restriction over the content (like it has to be your name, as = agreed by the CSP, or some such PROVISIONING restriction). Unlike SUA display strings, of course. The nearest this gets to the IAB's pronouncement is that "CNAM in a TXT = record" would require some kind of tag string to indicate that it was a = CNAM. It is however a natural example of an E2MD meta-service; stick the text = inside a E2MD+cnam:data NAPTR (i.e. the content is in the data: URL), and you know what the = domain owner asserts that it is. If it is a racial epithet, sue the domain owner/throw them in gaol. This is not a protocol issue, it's a legal issue; don't worry, be happy. Can you imagine the fees for expert witnesses to explain to the courts = how the DNS works, how CNAM works, how by provisioning this data the = domain owner is requesting that it be displayed automatically without = the permission of the recipient, and how this IS publication and so = covered by existing laws? ... [or argue the other way, depending on who's paying the fees :]. =3D> TXT needs a tag, unless we sub-domain it as you suggest, or put in = a tag string as the first one in the TXT record. Why not? Everyone else = does. (the IAB made that statement because it's not like there are none of = those out there in the wild already). =3D> E2MD NAPTR works a charm. all the best, Lawrence From dean.willis@softarmor.com Wed Apr 28 16:38: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 961303A6A05 for ; Wed, 28 Apr 2010 16:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[AWL=-0.438, BAYES_05=-1.11] 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 M2hf6rbjJLIi for ; Wed, 28 Apr 2010 16:38:10 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5E55E3A68C3 for ; Wed, 28 Apr 2010 16:38:09 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3SNbgrj011042 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Apr 2010 18:37:44 -0500 Message-Id: From: Dean Willis To: Richard Shockey In-Reply-To: <01b201cae702$35547a00$9ffd6e00$@us> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Apr 2010 18:37:37 -0500 References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk> <01b201cae702$35547a00$9ffd6e00$@us> X-Mailer: Apple Mail (2.936) Cc: "'E.164 To MetaData BOF discussion list'" , 'Bernie Hoeneisen' Subject: Re: [e2md] Rough minutes of today's conf call 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, 28 Apr 2010 23:38:11 -0000 On Apr 28, 2010, at 1:39 PM, Richard Shockey wrote: > > Dean ..how many times have I had to tell you and the entire > RAI ..there are > NO such things as Enterprise number blocks where LNP is dominant? > Hey dude, it wasn't me, it was one of the longstanding ENUMerated ones who said that an _prefix was a bad idea because it didn't play well with wildcards, and that they were still finding wildcards to be a necessity. Now if that's WRONG, then we can use Dave Crocker's _CNAME prefix idea along with Lawrence's TXT record suggestion and solve the calling-name problem immediately (and do it in-line with IAB guidance). I believe I proposed this on-list back during IETF week: _CNAME.0.9.1.9.9.1.5.2.7.9.1.e164.arpa. IN TXT "Dean Willis" -- Dean From bernie@ietf.hoeneisen.ch Wed Apr 28 23:15:45 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 863343A69D7 for ; Wed, 28 Apr 2010 23:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.127 X-Spam-Level: X-Spam-Status: No, score=-1.127 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_20=-0.74] 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 Cysy6US2mFMW for ; Wed, 28 Apr 2010 23:15:44 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 9D0B23A6946 for ; Wed, 28 Apr 2010 23:15:44 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1O7N1v-0002OV-2Q; Thu, 29 Apr 2010 08:15:23 +0200 Date: Thu, 29 Apr 2010 08:15:23 +0200 (CEST) From: 'Bernie Hoeneisen' X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Dean Willis In-Reply-To: Message-ID: References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk> <01b201cae702$35547a00$9ffd6e00$@us> 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: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Rough minutes of today's conf call 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, 29 Apr 2010 06:15:45 -0000 I think it was Otmar who claimed this to be a problem. In general he is right about this, but the CNAM case is different, as I do not expect the Calling Name to be the result of a Regular Expression. cheers, Bernie On Wed, 28 Apr 2010, Dean Willis wrote: > > On Apr 28, 2010, at 1:39 PM, Richard Shockey wrote: >> >> Dean ..how many times have I had to tell you and the entire RAI ..there are >> NO such things as Enterprise number blocks where LNP is dominant? >> > > Hey dude, it wasn't me, it was one of the longstanding ENUMerated ones who > said that an _prefix was a bad idea because it didn't play well with > wildcards, and that they were still finding wildcards to be a necessity. > > Now if that's WRONG, then we can use Dave Crocker's _CNAME prefix idea along > with Lawrence's TXT record suggestion and solve the calling-name problem > immediately (and do it in-line with IAB guidance). I believe I proposed this > on-list back during IETF week: > > _CNAME.0.9.1.9.9.1.5.2.7.9.1.e164.arpa. IN TXT "Dean Willis" > > > -- > Dean From Ray.Bellis@nominet.org.uk Thu Apr 29 00:29:01 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 787D03A69D8 for ; Thu, 29 Apr 2010 00:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.774 X-Spam-Level: X-Spam-Status: No, score=-9.774 tagged_above=-999 required=5 tests=[AWL=0.825, 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 nctG+k2Gkn2j for ; Thu, 29 Apr 2010 00:29:00 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 373593A67A1 for ; Thu, 29 Apr 2010 00:28:59 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version: Return-Path; b=j0hC9xzxJYKn8ia9WXXQ8QWJgVS7ZtM4sPYICK2dqQjATGvxG6KT5Cnk K5gmXE2WsuLmVRuSS3zCkn2GIMHf6R5SuvXeZODsL3wQQ/ZgfnWJ3AiPr gpJIphkOyRk2ih5; 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=1272526127; x=1304062127; 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=20Bellis=20 |Subject:=20Re:=20[e2md]=20Rough=20minutes=20of=20today's =20conf=20call|Date:=20Thu,=2029=20Apr=202010=2007:28:41 =20+0000|Message-ID:=20|To:=20'Bernie=20Hoeneisen'=20,=20Dean=20Willis=0D=0A=09|CC:=20'E.164=20To=20MetaData=20BOF=20discussion=20list '=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20 |In-Reply-To:=20; bh=VnJf2iV2nPQ0UWfXs68NUoi1IB4JByfnjv2ipjYhrRE=; b=JrDhKhDzx+QVnPTZc1qJV3vvx8MW2ZvlOT7kdnddaChudLnxPxMfde08 M0lvU8JmU9Zpdo390iPFh7CFg7v7dGaQ3lbBJujVGuGWKHzxL0rXMm/9Z ksYc1B4SDpjM6SN; X-IronPort-AV: E=Sophos;i="4.52,294,1270422000"; d="scan'208";a="18227515" Received: from host-213-248-197-145.nominet.org.uk (HELO wds-exc2.okna.nominet.org.uk) ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 29 Apr 2010 08:28:45 +0100 Received: from BDC-WDS-EXC1.okna.nominet.org.uk (2002:d5f8:c592::d5f8:c592) by wds-exc2.okna.nominet.org.uk (2002:d5f8:c591::d5f8:c591) with Microsoft SMTP Server (TLS) id 14.0.639.21; Thu, 29 Apr 2010 08:28:45 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by bdc-wds-exc1.okna.nominet.org.uk ([fe80::784f:9067:6a1a:ab8f%18]) with mapi; Thu, 29 Apr 2010 08:28:45 +0100 From: Ray Bellis To: 'Bernie Hoeneisen' , Dean Willis Thread-Topic: [e2md] Rough minutes of today's conf call Thread-Index: AQHK5Xy4gmvotj7Ps0mDfZR5dxExEJI3ky4AgAAJOACAAIHjgIAACmCAgABTK4CAAG8igIAAJT+A Date: Thu, 29 Apr 2010 07:28:41 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Rough minutes of today's conf call 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, 29 Apr 2010 07:29:01 -0000 On 29/04/2010 07:15, "'Bernie Hoeneisen'" wrote: >=20 > I think it was Otmar who claimed this to be a problem. In general he is > right about this, but the CNAM case is different, as I do not > expect the Calling Name to be the result of a Regular Expression. I believe that's true, although if Richard has suitable use cases I'd be happy to know about them. As Dean recalled, however, the real problem with prefixes is that it's generally impossible to provision: _cname.*.2.2.3.3.5.6.8.1.4.4.e164.arpa. IN RR "Nominet" Actually - there might be a use case for regexps: *.2.2.3.3.5.6.8.1.4.4.e164.arpa. IN NAPTR ..... "!^\\+441865332(.*)$!pstndata:...,Nominet extn:\\1" . (i.e. Automatically adding the extension number to the CNAM data). Ray From lconroy@insensate.co.uk Thu Apr 29 00:29: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 E69D73A6AB5 for ; Thu, 29 Apr 2010 00:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.961 X-Spam-Level: X-Spam-Status: No, score=-0.961 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, J_CHICKENPOX_44=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 QZR2bhvEEdQj for ; Thu, 29 Apr 2010 00:29:42 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id D573F3A67A1 for ; Thu, 29 Apr 2010 00:29:41 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id BAC6A12BF52; Thu, 29 Apr 2010 08:29:27 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: Date: Thu, 29 Apr 2010 08:29:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7AF17FDD-BF44-42DB-B9D7-B433624FCFB7@insensate.co.uk> References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk> <01b201cae702$35547a00$9ffd6e00$@us> To: Bernie Hoeneisen X-Mailer: Apple Mail (2.1078) Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Rough minutes of today's conf call 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, 29 Apr 2010 07:29:43 -0000 Hi Bernie, Dean, folks, Yep, 'twas Otmar beat me to the punch in reminding folks that the world is not all fixed number plan. However, he also mentioned wildcards. That's the kicker. You don't need/can't use those with CNAM, but doesn't this also preclude their use for any other TXT item? Just define a cnam:data service with a data: URI, put it in a NAPTR and you're done. Except for access control, and ... all the best, Lawrence On 29 Apr 2010, at 07:15, Bernie Hoeneisen wrote: > I think it was Otmar who claimed this to be a problem. In general he = is right about this, but the CNAM case is different, as I do not expect = the Calling Name to be the result of a Regular Expression. >=20 > cheers, > Bernie >=20 > On Wed, 28 Apr 2010, Dean Willis wrote: >=20 >>=20 >> On Apr 28, 2010, at 1:39 PM, Richard Shockey wrote: >>> Dean ..how many times have I had to tell you and the entire RAI = ..there are >>> NO such things as Enterprise number blocks where LNP is dominant? >>=20 >> Hey dude, it wasn't me, it was one of the longstanding ENUMerated = ones who said that an _prefix was a bad idea because it didn't play well = with wildcards, and that they were still finding wildcards to be a = necessity. >>=20 >> Now if that's WRONG, then we can use Dave Crocker's _CNAME prefix = idea along with Lawrence's TXT record suggestion and solve the = calling-name problem immediately (and do it in-line with IAB guidance). = I believe I proposed this on-list back during IETF week: >>=20 >> _CNAME.0.9.1.9.9.1.5.2.7.9.1.e164.arpa. IN TXT "Dean Willis" >>=20 >>=20 >> -- >> Dean From lendl@nic.at Thu Apr 29 04:39: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 A17203A6B5F for ; Thu, 29 Apr 2010 04:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.17 X-Spam-Level: X-Spam-Status: No, score=0.17 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] 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 ne5cr9gerBMK for ; Thu, 29 Apr 2010 04:39:05 -0700 (PDT) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id E05FD3A6B85 for ; Thu, 29 Apr 2010 04:39:00 -0700 (PDT) Received: from [10.10.0.211] (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTPSA id C9B924C362 for ; Thu, 29 Apr 2010 13:38:45 +0200 (CEST) Message-ID: <4BD96FC5.8090602@nic.at> Date: Thu, 29 Apr 2010 13:38:45 +0200 From: Otmar Lendl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: e2md@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [e2md] Rough minutes of today's conf call 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, 29 Apr 2010 11:39:06 -0000 On 29.04.2010 09:28, Ray Bellis wrote: > On 29/04/2010 07:15, "'Bernie Hoeneisen'" wrote: > >> I think it was Otmar who claimed this to be a problem. In general he is >> right about this, but the CNAM case is different, as I do not >> expect the Calling Name to be the result of a Regular Expression. The regular expression isn't the real problem here. > As Dean recalled, however, the real problem with prefixes is that it's > generally impossible to provision: > > _cname.*.2.2.3.3.5.6.8.1.4.4.e164.arpa. IN RR "Nominet" > Precisely. That's the issue. Of course, once we're in "let's create a DNSng protocol for E2MD"-mode where we add support for query-source, source-URI and other non-1034 features, then adding support for such wildcards might be possible as well. > Actually - there might be a use case for regexps: > > *.2.2.3.3.5.6.8.1.4.4.e164.arpa. IN NAPTR ..... > "!^\\+441865332(.*)$!pstndata:...,Nominet extn:\\1" . Yes, that would be a typical use-case for what an Austrian carrier would need to provision for ISDN PRI lines. (And BRIs as well, if configured in P2P mode.) And that's both for the calling-number side, as well as for the called-number side. otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From kcartwright@tnsi.com Thu Apr 29 06:56:46 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 A93CD3A6966 for ; Thu, 29 Apr 2010 06:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.308 X-Spam-Level: X-Spam-Status: No, score=-1.308 tagged_above=-999 required=5 tests=[AWL=-0.568, BAYES_20=-0.74] 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 5mS9mAZVumW2 for ; Thu, 29 Apr 2010 06:56:42 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 7C2C83A6C01 for ; Thu, 29 Apr 2010 06:49:50 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.43109514; Thu, 29 Apr 2010 09:49:06 -0400 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; Thu, 29 Apr 2010 09:49:06 -0400 From: "Cartwright, Kenneth" To: Dean Willis , Richard Shockey Date: Thu, 29 Apr 2010 09:49:04 -0400 Thread-Topic: [e2md] Rough minutes of today's conf call Thread-Index: AcrnK92TXxEwhgG1S7eZfv9NIYSYkgAchNrQ Message-ID: <754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk> <01b201cae702$35547a00$9ffd6e00$@us> 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 Cc: 'Bernie, Hoeneisen' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Rough minutes of today's conf call 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, 29 Apr 2010 13:56:46 -0000 Given the fact that so many systems involved in the VoIP space are built to= understand DNS ENUM/NAPTRs why in the world would we introduce a completel= y different DNS scheme to: (1) Recreate ENUM's "context/meaning" qualifier, the ServiceType->SubType p= air, with a *less functional* alternative (the prefix). (2) Recreate ENUM's field to hold the data, the regex/replacement field, wi= th a *less functional* alternative (the TXT record). (3) Recreate ENUM's specification for converting a TN to a domain name, the= first well know rule, with a different rule that is no better. There is no good reason (no advantage) to do the above, and multiple reason= s not to. Add to the 3 reasons above the fact that all systems that alread= y understand ENUM would now have to add a separate set of code that knows h= ow to query and parse out CNAM data from that _CNAM RR and the associate TX= T record. Furthermore, why would the people that "don't want this data in the DNS" be= upset by this data being held in NAPTRs but not upset by this data being i= n TXT records. Answer, if their stance is self consistent then they would = be equally upset by both. So the contrived prefix/TXT idea does not achiev= e the apparent goal. And as I've said on more than one occasion, systems are already serving up = CNAM data using ENUM NAPTRs. So why did those organizations specifically c= hose to not use TXT records? Answer, because using ENUM just made more sen= se, from both a technology perspective and a business perspective. I think these E2M discussions would provide a year's worth of work for Scot= t Adams. :-) Ken -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dea= n Willis Sent: Wednesday, April 28, 2010 7:38 PM To: Richard Shockey Cc: 'E.164 To MetaData BOF discussion list'; 'Bernie Hoeneisen' Subject: Re: [e2md] Rough minutes of today's conf call On Apr 28, 2010, at 1:39 PM, Richard Shockey wrote: > > Dean ..how many times have I had to tell you and the entire > RAI ..there are > NO such things as Enterprise number blocks where LNP is dominant? > Hey dude, it wasn't me, it was one of the longstanding ENUMerated ones who said that an _prefix was a bad idea because it didn't play well with wildcards, and that they were still finding wildcards to be a necessity. Now if that's WRONG, then we can use Dave Crocker's _CNAME prefix idea along with Lawrence's TXT record suggestion and solve the calling-name problem immediately (and do it in-line with IAB guidance). I believe I proposed this on-list back during IETF week: _CNAME.0.9.1.9.9.1.5.2.7.9.1.e164.arpa. IN TXT "Dean Willis" -- Dean _______________________________________________ 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 Ray.Bellis@nominet.org.uk Thu Apr 29 07:21:17 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 9494628C2BD for ; Thu, 29 Apr 2010 07:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[AWL=0.550, 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 YF1GI2YD9eEy for ; Thu, 29 Apr 2010 07:21:16 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id E040428C2BA for ; Thu, 29 Apr 2010 07:15:41 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version; b=DEdIbhNkw9FUcgZ+z2vqibrjvWbPUAr3hnONHx731Y34TOaMoTFs6UMq 9ddFkcgp5sRHkwQSNRDqZOu9UpnXm4MYmK96w0anVVV14r7rc6c2/S+rA 01MUyWrIU3X+iaj; 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=1272550529; x=1304086529; 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=20Bellis=20 |Subject:=20Re:=20[e2md]=20Rough=20minutes=20of=20today's =20conf=20call|Date:=20Thu,=2029=20Apr=202010=2014:15:25 =20+0000|Message-ID:=20|To:=20"Cartwright,=20Kenneth"=20,=20Dean=20Willis=0D=0A=09,=20Richard=20Shockey=20|CC:=20"'Ber nie@core3.amsl.com"=20<'Bernie@core3.amsl.com>,=20Hoeneis en'=0D=0A=09,=20'E.164=20To=20M etaData=20BOF=20discussion=20list'=0D=0A=09|MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted -printable|Content-ID:=20|In-Reply-To:=20<754963199212404AB8E9CFCA6C3D0CDA24 469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com>; bh=NII3oEWuRiysMhIgru1BcaB+uTtVTeJ+CsiLQXpYdc4=; b=x9lKmLWhaZuzgTQG7H7gfEFEv58x9RL/ridAZJ4eOHxj70BgC7xAd8og r6xpr/umpTbE/rN36S8AOYyWKDYm5mj3Ph7Ldv3PdxiCIxm6eVLfLiqwg SVW7X3Dc3REU645; X-IronPort-AV: E=Sophos;i="4.52,295,1270422000"; d="scan'208";a="18249269" Received: from host-213-248-197-145.nominet.org.uk (HELO wds-exc2.okna.nominet.org.uk) ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 29 Apr 2010 15:15:27 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%20]) with mapi; Thu, 29 Apr 2010 15:15:27 +0100 From: Ray Bellis To: "Cartwright, Kenneth" , Dean Willis , Richard Shockey Thread-Topic: [e2md] Rough minutes of today's conf call Thread-Index: AQHK5Xy4gmvotj7Ps0mDfZR5dxExEJI3ky4AgAAJOACAAIHjgIAACmCAgABTK4CAAO3kAIAAGCGA Date: Thu, 29 Apr 2010 14:15:25 +0000 Message-ID: In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'Bernie@core3.amsl.com" <'Bernie@core3.amsl.com>, Hoeneisen' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Rough minutes of today's conf call 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, 29 Apr 2010 14:21:17 -0000 On 29/04/2010 14:49, "Cartwright, Kenneth" wrote: > ... Loads of good stuff +1 to all that... Ray From richard@shockey.us Thu Apr 29 07:43:23 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 EB3CF3A6A88 for ; Thu, 29 Apr 2010 07:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 eqT+1C8XY74K for ; Thu, 29 Apr 2010 07:43:23 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (oproxy2-pub.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 774D928C10A for ; Thu, 29 Apr 2010 07:42:59 -0700 (PDT) Received: (qmail 10301 invoked by uid 0); 29 Apr 2010 13:42:45 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 29 Apr 2010 13:42:45 -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=iOgBenfVVoGolRNSXy+AewLmEV/bgR5LEdl3Etd1wWmVMJt6vT2HLZz4DHQlkBhJTawoaKpbUv88Tlqp/jsbVFb8OUfD34j1LrgmZGBkCE+ePZ+1NGgULP+Zm46XWPpo; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1O7Uwu-0001Ss-91; Thu, 29 Apr 2010 08:42:44 -0600 From: "Richard Shockey" To: "'Ray Bellis'" , "'Cartwright, Kenneth'" , "'Dean Willis'" References: <754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: Date: Thu, 29 Apr 2010 10:42:38 -0400 Message-ID: <00d801cae7aa$379b9480$a6d2bd80$@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: AQHK5Xy4gmvotj7Ps0mDfZR5dxExEJI3ky4AgAAJOACAAIHjgIAACmCAgABTK4CAAO3kAIAAGCGAgAAGG7A= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: 'Bernie@core3.amsl.com, 'Hoeneisen'' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Rough minutes of today's conf call 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, 29 Apr 2010 14:43:24 -0000 +1 as well. Excellent Ken an outstanding summary of the issues. I'm getting a little annoyed with the discussion ..oh well the IESG won't approve this, the IESG won't like that. It seems prudent at this time to actually ask Gonzallo and Robert what would he be able to support and argue for in the IESG. Most of us here know exactly what we want to do and why we want to do it. ENUM is there it works it scales both in private and public instantiations. We're not going to reinvent the DNS. None of us have that long a life span. -----Original Message----- From: Ray Bellis [mailto:Ray.Bellis@nominet.org.uk] Sent: Thursday, April 29, 2010 10:15 AM To: Cartwright, Kenneth; Dean Willis; Richard Shockey Cc: 'Bernie@core3.amsl.com; Hoeneisen'; 'E.164 To MetaData BOF discussion list' Subject: Re: [e2md] Rough minutes of today's conf call On 29/04/2010 14:49, "Cartwright, Kenneth" wrote: > ... Loads of good stuff +1 to all that... Ray From dean.willis@softarmor.com Thu Apr 29 10:31:46 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 D85BB3A6A45 for ; Thu, 29 Apr 2010 10:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.089 X-Spam-Level: X-Spam-Status: No, score=-1.089 tagged_above=-999 required=5 tests=[AWL=-0.904, BAYES_40=-0.185] 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 obPk3mjKZfzz for ; Thu, 29 Apr 2010 10:31:45 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id CCB703A6A2C for ; Thu, 29 Apr 2010 10:31:45 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3THVJis020869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 29 Apr 2010 12:31:23 -0500 Message-Id: <6DD61A83-DB36-4B4C-90D5-D17DC3A36689@softarmor.com> From: Dean Willis To: Bernie Hoeneisen In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Apr 2010 12:31:14 -0500 References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk> <01b201cae702$35547a00$9ffd6e00$@us> X-Mailer: Apple Mail (2.936) Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Rough minutes of today's conf call 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, 29 Apr 2010 17:31:46 -0000 On Apr 29, 2010, at 1:15 AM, Bernie Hoeneisen wrote: > > I think it was Otmar who claimed this to be a problem. In general he > is right about this, but the CNAM case is different, as I do not > expect the Calling Name to be the result of a Regular Expression. I'm thinking he was referring specifically to calling-name, as it is not infrequent for a PBX to have a block of 10, 100, or even 1000 numbers for which the administration wants to put in only a single record having the company name. Sure, for the carrier this gets shot full of LNP holes, but every company I've ever worked with had a monolithic block of numbers. -- Dean From dean.willis@softarmor.com Thu Apr 29 10:47: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 77A503A69E5 for ; Thu, 29 Apr 2010 10:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[AWL=-0.979, BAYES_50=0.001] 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 CnJ7rhig-7BI for ; Thu, 29 Apr 2010 10:47:28 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 676593A68B7 for ; Thu, 29 Apr 2010 10:47:28 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3THl2Ms021022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 29 Apr 2010 12:47:03 -0500 Message-Id: <826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.com> From: Dean Willis To: "Cartwright, Kenneth" In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Apr 2010 12:46:56 -0500 References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk> <01b201cae702$35547a00$9ffd6e00$@us> <754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com> X-Mailer: Apple Mail (2.936) Cc: 'Bernie Hoeneisen' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Rough minutes of today's conf call 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, 29 Apr 2010 17:47:29 -0000 On Apr 29, 2010, at 8:49 AM, Cartwright, Kenneth wrote: > Given the fact that so many systems involved in the VoIP space are > built to understand DNS ENUM/NAPTRs why in the world would we > introduce a completely different DNS scheme to: > > (1) Recreate ENUM's "context/meaning" qualifier, the ServiceType- > >SubType pair, with a *less functional* alternative (the prefix). > (2) Recreate ENUM's field to hold the data, the regex/replacement > field, with a *less functional* alternative (the TXT record). > (3) Recreate ENUM's specification for converting a TN to a domain > name, the first well know rule, with a different rule that is no > better. > > There is no good reason (no advantage) to do the above, and multiple > reasons not to. Add to the 3 reasons above the fact that all > systems that already understand ENUM would now have to add a > separate set of code that knows how to query and parse out CNAM data > from that _CNAM RR and the associate TXT record. Here's the "opposition" gave me. When you query the NAPTR records for a number, you get back (over the wire) every last associated NAPTR record in the RRset. The client library then filters out the one you want. So if all you want is calling name (because you''re answering a call), the server is still going to have to generate and send all the other resource records over the network. That's simply inelegant, which offends some parties. But inasmuch as we're doing it over a non-congestion-controlled transport, and the number of potential RRs is effectively unbounded, there's a real potential for congestive harm to the Internet (yeah YOU don't want to use this on the big-I Internet, but if the specs are published, somebody will!), And there's a large faction in the IETF, especially among the greybeards, who take congestion control and the avoidance of congestive collapse very seriously. Remember, they've had to nurse the Internet through several periods of "impending collapse", and their beliefs have been greatly influenced by these experiences. I've been told again and again that we solve the problem by having different DNS servers for different subsets of the data, and configuring the clients to ask the right servers for specific items, thereby reducing the RRset size, but having different servers provisioned for different data isn't DNS usage "as done on the Internet", and these folks believe it is inappropriate to document such usage in the IETF. I get it They get it, too. But they DON'T APPROVE of our approach, because once the spec is published there's no way to contain it to our little private networks. > Furthermore, why would the people that "don't want this data in the > DNS" be upset by this data being held in NAPTRs but not upset by > this data being in TXT records. Answer, if their stance is self > consistent then they would be equally upset by both. So the > contrived prefix/TXT idea does not achieve the apparent goal. Some of them don't mind some level of data in the DNS, they just want a more selective query mechanism than NAPTR because we get such big RRsets in the result. But as noted, this approach certainly doesn't satisfy all the greybeard critics; the only one that does seems to be putting a metadata pointer (and nothing else) into the DNS. The question, to me, is is there a middle ground we can compromise on that makes both factions happy (enough)? -- Dean From kcartwright@tnsi.com Thu Apr 29 13:44: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 2D06D3A6A6A for ; Thu, 29 Apr 2010 13:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[AWL=-0.910, BAYES_50=0.001] 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 FX5CcPt4c5Ez for ; Thu, 29 Apr 2010 13:44:19 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 815F33A6A81 for ; Thu, 29 Apr 2010 13:44:15 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.43125126; Thu, 29 Apr 2010 16:43:30 -0400 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; Thu, 29 Apr 2010 16:43:31 -0400 From: "Cartwright, Kenneth" To: Dean Willis Date: Thu, 29 Apr 2010 16:43:29 -0400 Thread-Topic: [e2md] Rough minutes of today's conf call Thread-Index: AcrnxAR1i4ZBCsg7RYCeDlfC/e3FbQAAI/Gw Message-ID: <754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk> <01b201cae702$35547a00$9ffd6e00$@us> <754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com> <826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.com> In-Reply-To: <826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.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: list' , 'Bernie Hoeneisen' , 'E.164 Subject: Re: [e2md] Rough minutes of today's conf call 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, 29 Apr 2010 20:44:20 -0000 (1) ENUM is based on DNS and is **already** operational today. Has it brou= ght down "the Internet's DNS"? No. (2) Given the foreseeable size of the problem space, the RR set size does h= ave to be too large. Regardless, that will be continuously evaluated as pa= rt of the expert review for each newly proposed E2M serviceType/subtype (as= it was during the ENUM expert reviews). (3) The ENUM LLC trials were conducted and completed, years ago. That init= iative has always been designed to be a separately managed DNS ecosystem, i= f you will. So what's the issue? Are folks pretending that the ENUM LLC t= rials did not happen? Or are they saying that the result of the ENUM LLC t= rials found that because NAPTRs use DNS technologies, oops, that the mainli= ne Internet DNS system was going to have issues? Or are they just not awar= e that ENUM, based on DNS technologies, is already in production today? (4) Middle grounds have already been proposed and rejected for equally amor= phous reasons from non-present third parties. The idea that you cannot create a technical standard derived from an existi= ng technical standard is fundamentally contrary to the IETF way. And the i= dea that you cannot create a technical standard because someone, somewhere = in the world could do something really silly with it and harm their systems= is not a logical approach to standards creation, and creates an impossible= solution space. Ken -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Thursday, April 29, 2010 1:47 PM To: Cartwright, Kenneth Cc: Richard Shockey; 'E.164 To MetaData BOF discussion list'; 'Bernie Hoene= isen' Subject: Re: [e2md] Rough minutes of today's conf call On Apr 29, 2010, at 8:49 AM, Cartwright, Kenneth wrote: > Given the fact that so many systems involved in the VoIP space are > built to understand DNS ENUM/NAPTRs why in the world would we > introduce a completely different DNS scheme to: > > (1) Recreate ENUM's "context/meaning" qualifier, the ServiceType- > >SubType pair, with a *less functional* alternative (the prefix). > (2) Recreate ENUM's field to hold the data, the regex/replacement > field, with a *less functional* alternative (the TXT record). > (3) Recreate ENUM's specification for converting a TN to a domain > name, the first well know rule, with a different rule that is no > better. > > There is no good reason (no advantage) to do the above, and multiple > reasons not to. Add to the 3 reasons above the fact that all > systems that already understand ENUM would now have to add a > separate set of code that knows how to query and parse out CNAM data > from that _CNAM RR and the associate TXT record. Here's the "opposition" gave me. When you query the NAPTR records for a number, you get back (over the wire) every last associated NAPTR record in the RRset. The client library then filters out the one you want. So if all you want is calling name (because you''re answering a call), the server is still going to have to generate and send all the other resource records over the network. That's simply inelegant, which offends some parties. But inasmuch as we're doing it over a non-congestion-controlled transport, and the number of potential RRs is effectively unbounded, there's a real potential for congestive harm to the Internet (yeah YOU don't want to use this on the big-I Internet, but if the specs are published, somebody will!), And there's a large faction in the IETF, especially among the greybeards, who take congestion control and the avoidance of congestive collapse very seriously. Remember, they've had to nurse the Internet through several periods of "impending collapse", and their beliefs have been greatly influenced by these experiences. I've been told again and again that we solve the problem by having different DNS servers for different subsets of the data, and configuring the clients to ask the right servers for specific items, thereby reducing the RRset size, but having different servers provisioned for different data isn't DNS usage "as done on the Internet", and these folks believe it is inappropriate to document such usage in the IETF. I get it They get it, too. But they DON'T APPROVE of our approach, because once the spec is published there's no way to contain it to our little private networks. > Furthermore, why would the people that "don't want this data in the > DNS" be upset by this data being held in NAPTRs but not upset by > this data being in TXT records. Answer, if their stance is self > consistent then they would be equally upset by both. So the > contrived prefix/TXT idea does not achieve the apparent goal. Some of them don't mind some level of data in the DNS, they just want a more selective query mechanism than NAPTR because we get such big RRsets in the result. But as noted, this approach certainly doesn't satisfy all the greybeard critics; the only one that does seems to be putting a metadata pointer (and nothing else) into the DNS. The question, to me, is is there a middle ground we can compromise on that makes both factions happy (enough)? -- Dean 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 kcartwright@tnsi.com Thu Apr 29 13:46: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 91D153A6A42 for ; Thu, 29 Apr 2010 13:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 5EWVC8FqDnJu for ; Thu, 29 Apr 2010 13:46:18 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 3DCF23A6A0B for ; Thu, 29 Apr 2010 13:46:17 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.43125177; Thu, 29 Apr 2010 16:45:46 -0400 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; Thu, 29 Apr 2010 16:45:46 -0400 From: "Cartwright, Kenneth" To: "Cartwright, Kenneth" , Dean Willis Date: Thu, 29 Apr 2010 16:45:45 -0400 Thread-Topic: [e2md] Rough minutes of today's conf call Thread-Index: AcrnxAR1i4ZBCsg7RYCeDlfC/e3FbQAAI/GwAAYQZiA= Message-ID: <754963199212404AB8E9CFCA6C3D0CDA2446917DEC@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk> <01b201cae702$35547a00$9ffd6e00$@us> <754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com> <826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.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' , list' , "'E.164@core3.amsl.com" <'E.164@core3.amsl.com> Subject: Re: [e2md] Rough minutes of today's conf call 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, 29 Apr 2010 20:46:19 -0000 Typo: the RR set size does have to be too large / the RR set size does *not= * have to be too large -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Car= twright, Kenneth Sent: Thursday, April 29, 2010 4:43 PM To: Dean Willis Cc: list'; 'Bernie Hoeneisen'; 'E.164@core3.amsl.com Subject: Re: [e2md] Rough minutes of today's conf call (1) ENUM is based on DNS and is **already** operational today. Has it brou= ght down "the Internet's DNS"? No. (2) Given the foreseeable size of the problem space, the RR set size does h= ave to be too large. Regardless, that will be continuously evaluated as pa= rt of the expert review for each newly proposed E2M serviceType/subtype (as= it was during the ENUM expert reviews). (3) The ENUM LLC trials were conducted and completed, years ago. That init= iative has always been designed to be a separately managed DNS ecosystem, i= f you will. So what's the issue? Are folks pretending that the ENUM LLC t= rials did not happen? Or are they saying that the result of the ENUM LLC t= rials found that because NAPTRs use DNS technologies, oops, that the mainli= ne Internet DNS system was going to have issues? Or are they just not awar= e that ENUM, based on DNS technologies, is already in production today? (4) Middle grounds have already been proposed and rejected for equally amor= phous reasons from non-present third parties. The idea that you cannot create a technical standard derived from an existi= ng technical standard is fundamentally contrary to the IETF way. And the i= dea that you cannot create a technical standard because someone, somewhere = in the world could do something really silly with it and harm their systems= is not a logical approach to standards creation, and creates an impossible= solution space. Ken -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Thursday, April 29, 2010 1:47 PM To: Cartwright, Kenneth Cc: Richard Shockey; 'E.164 To MetaData BOF discussion list'; 'Bernie Hoene= isen' Subject: Re: [e2md] Rough minutes of today's conf call On Apr 29, 2010, at 8:49 AM, Cartwright, Kenneth wrote: > Given the fact that so many systems involved in the VoIP space are > built to understand DNS ENUM/NAPTRs why in the world would we > introduce a completely different DNS scheme to: > > (1) Recreate ENUM's "context/meaning" qualifier, the ServiceType- > >SubType pair, with a *less functional* alternative (the prefix). > (2) Recreate ENUM's field to hold the data, the regex/replacement > field, with a *less functional* alternative (the TXT record). > (3) Recreate ENUM's specification for converting a TN to a domain > name, the first well know rule, with a different rule that is no > better. > > There is no good reason (no advantage) to do the above, and multiple > reasons not to. Add to the 3 reasons above the fact that all > systems that already understand ENUM would now have to add a > separate set of code that knows how to query and parse out CNAM data > from that _CNAM RR and the associate TXT record. Here's the "opposition" gave me. When you query the NAPTR records for a number, you get back (over the wire) every last associated NAPTR record in the RRset. The client library then filters out the one you want. So if all you want is calling name (because you''re answering a call), the server is still going to have to generate and send all the other resource records over the network. That's simply inelegant, which offends some parties. But inasmuch as we're doing it over a non-congestion-controlled transport, and the number of potential RRs is effectively unbounded, there's a real potential for congestive harm to the Internet (yeah YOU don't want to use this on the big-I Internet, but if the specs are published, somebody will!), And there's a large faction in the IETF, especially among the greybeards, who take congestion control and the avoidance of congestive collapse very seriously. Remember, they've had to nurse the Internet through several periods of "impending collapse", and their beliefs have been greatly influenced by these experiences. I've been told again and again that we solve the problem by having different DNS servers for different subsets of the data, and configuring the clients to ask the right servers for specific items, thereby reducing the RRset size, but having different servers provisioned for different data isn't DNS usage "as done on the Internet", and these folks believe it is inappropriate to document such usage in the IETF. I get it They get it, too. But they DON'T APPROVE of our approach, because once the spec is published there's no way to contain it to our little private networks. > Furthermore, why would the people that "don't want this data in the > DNS" be upset by this data being held in NAPTRs but not upset by > this data being in TXT records. Answer, if their stance is self > consistent then they would be equally upset by both. So the > contrived prefix/TXT idea does not achieve the apparent goal. Some of them don't mind some level of data in the DNS, they just want a more selective query mechanism than NAPTR because we get such big RRsets in the result. But as noted, this approach certainly doesn't satisfy all the greybeard critics; the only one that does seems to be putting a metadata pointer (and nothing else) into the DNS. The question, to me, is is there a middle ground we can compromise on that makes both factions happy (enough)? -- Dean 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. _______________________________________________ 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 dean.willis@softarmor.com Thu Apr 29 18:17:30 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 6FFF33A6827 for ; Thu, 29 Apr 2010 18:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.959 X-Spam-Level: X-Spam-Status: No, score=-0.959 tagged_above=-999 required=5 tests=[AWL=-0.960, BAYES_50=0.001] 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 jUtbs3CITZLW for ; Thu, 29 Apr 2010 18:17:28 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A5BAB3A67FC for ; Thu, 29 Apr 2010 18:17:27 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3U1Gxfn024003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 29 Apr 2010 20:17:01 -0500 Message-Id: From: Dean Willis To: "Cartwright, Kenneth" In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Apr 2010 20:16:54 -0500 References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk> <01b201cae702$35547a00$9ffd6e00$@us> <754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com> <826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> X-Mailer: Apple Mail (2.936) Cc: 'Bernie Hoeneisen' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Rough minutes of today's conf call 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, 30 Apr 2010 01:17:30 -0000 On Apr 29, 2010, at 3:43 PM, Cartwright, Kenneth wrote: > > > (1) ENUM is based on DNS and is **already** operational today. Has > it brought down "the Internet's DNS"? No. When's the last time you made an ENUM dip and got back 200 resource records? Hasn't happened yet? It will, if we keep up on this path. > (2) Given the foreseeable size of the problem space, the RR set size > does have to be too large. Regardless, that will be continuously > evaluated as part of the expert review for each newly proposed E2M > serviceType/subtype (as it was during the ENUM expert reviews). So, what guidance do we give the expert reviewer? Cut it off after the 10th resource record? The 20th? The 50th? > (3) The ENUM LLC trials were conducted and completed, years ago. > That initiative has always been designed to be a separately managed > DNS ecosystem, if you will. So what's the issue? Are folks > pretending that the ENUM LLC trials did not happen? Or are they > saying that the result of the ENUM LLC trials found that because > NAPTRs use DNS technologies, oops, that the mainline Internet DNS > system was going to have issues? They're saying that if we document this stuff as part of the mainline DNS, somebody is going to use it there, and if this catches on, Kaboom! > Or are they just not aware that ENUM, based on DNS technologies, is > already in production today? They're aware of it. When you ask for a NAPTR record for a phone number and get back one record containing a SIP URI, there's no problem. When you get two or three, there's no problem. But defining an unbounded framework to define lots more responses makes them really nervous. > (4) Middle grounds have already been proposed and rejected for > equally amorphous reasons from non-present third parties. > There's always more middle ground somewhere. The first thing is understanding the objections. Based on this discussion we keep having, I don't think we clearly understand the DNS greybeard's arguments. I think they understand what we are trying to do; they just don't see documenting this as part of the DNS and then only using it in private networks to be a viable long term control mechanism for the fallout they're expecting. > The idea that you cannot create a technical standard derived from an > existing technical standard is fundamentally contrary to the IETF > way. And the idea that you cannot create a technical standard > because someone, somewhere in the world could do something really > silly with it and harm their systems is not a logical approach to > standards creation, and creates an impossible solution space. We can create a derived technical standard. There's nobody in the DNS directorate blocking us from deriving a new "metadata protocol" that works pretty much like a DNS query, defining a new URL for it, and putting that URL into the ENUM tree and looking it up based on a phone number, then using it to query back all the metadata our switches need. Of from a dozen other approaches that might work equally well. From their point of view, they're just protecting an incredibly important piece of infrastructure from the unintended consequences of our effort to extend it. But I DO understand their argument that created an open-ended framework for putting arbitrary cruft into the DNS will eventually result in too much stuff shoved in there. It's a credible argument. People do stupid stuff with their toys. In the SIP work, everytime we created an easy way for people to do extensions, like the "P-header" debacle (which required expert review AND informational RFC) , they went off and did crazy stuff that swelled up the messages and made the protocol less interoperable. If we give them a way to do it, we'll find the entire text of the Library of Congress in the DNS not too far down the road. It's not that someone somewhere will do a silly thing with it in their own network, but that they'll do a dangerous and destructive thing with it right smack dab in the middle of the Internet's most critical name resolution facility, and it Will Cause Problems. -- Dean From lconroy@insensate.co.uk Fri Apr 30 02:12: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 3E2443A67CF for ; Fri, 30 Apr 2010 02:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.491 X-Spam-Level: X-Spam-Status: No, score=0.491 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_50=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_53=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 eUM0QAvIRkej for ; Fri, 30 Apr 2010 02:12:41 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 731C93A6AFC for ; Fri, 30 Apr 2010 02:12:15 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id E021D12CA25 for ; Fri, 30 Apr 2010 10:11:59 +0100 (BST) From: Lawrence Conroy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Apr 2010 10:12:00 +0100 Message-Id: <3E216B8F-62B4-4D8E-AF97-2BF2B22DC8B1@insensate.co.uk> To: "E.164 To MetaData BOF discussion list" Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [e2md] E2MD and DNS overload 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, 30 Apr 2010 09:12:42 -0000 Hi Dean, folks, on the grounds that the previous mail thread had a vague title, I've = started a new one. To summarise earlier posting -- channeling 20 bunkum-spouting demons, = Dean said: * People could put a set of 200 resource records into a domain. * If people use this with large RRSets on the open Internet it = will cause widespread problems. * Servers would have to generate large answers. To which I answer: - You could do that now. You don't even need to use type 35. That is a provisioning issue, not a protocol issue. I do not see how this is any different from existing RR types. Viz. DNSOPS discussions on signed response sizes and rollover. With the exception of that particular corner case where the = minimum size can be large, people do not do it. It seems unreasonable to block use of a resource record type for what is a purely operational issue. This is certainly nothing to do with E2MD. This is a complaint at ENUM. There is nothing stopping someone putting any number of email, = web, sip E2U NAPTRs (and D2U NAPTRs) voice:tel and sms:tel or even = h323 NAPTRs into a domain, now. As a user of E2U NAPTRs, I do queries regularly and I do get = RRsets that are in the 10s of records. It just works. - I don't understand how ENUM can be a Weapon of Mass Destruction. What widespread damage will be caused? Regardless of RRset size, the request is not large, so bouncing = that through the authoritative hierarchy repeatedly is not an issue. The response may be large. This comes from the authoritative = server that hosts a large RRset. This response also traverses the = recursive resolver from which the query was sent. The victims are the Auth server that hosts the large RRSet and = the recursive resolver that makes the query and receives the = truncated result. The recursive resolver wil send one query over UDP, receive one truncated response over UDP, and then fallback from that = truncated response using TCP. That IS a congestion-controlled protocol. So ... someone provisions a large RRset into an auth server; the auth server consumes bandwidth sending its responses, and it may take some small time for the recursive resolver to get a = response due to the fallback to TCP. This is not news. What other collateral damage is caused? The volume of interweb traffic that is used for DNS is tiny. ASSUMING that the Auth server for facebook.com is not the same = one that is hosting ENUM domains, people will continue to waste = their time without any interference. It's not like the Interweb has a separate tube for DNS, and that tube can get full. - Finally (from a previous channel), DNS servers don't do a lot to generate RRsets. Auth DNS servers are not like some LDAP or Web server (as would = be used with any redirection scheme). I contend that those objections are bunkum. Lest anyone misunderstand, I'm sure Dean is acting only as the = messenger, so this is NOT a dig at him. all the best, Lawrence= From jim@rfc1035.com Fri Apr 30 02:56: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 CC83C28C1C9 for ; Fri, 30 Apr 2010 02:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.116 X-Spam-Level: X-Spam-Status: No, score=0.116 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_50=0.001] 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 ey8-SpRoxT9X for ; Fri, 30 Apr 2010 02:56:01 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id 8E1AF28C1C7 for ; Fri, 30 Apr 2010 02:56:01 -0700 (PDT) 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 2C7A215427EB; Fri, 30 Apr 2010 10:55:44 +0100 (BST) Message-Id: From: Jim Reid To: Dean Willis In-Reply-To: <826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.com> 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, 30 Apr 2010 10:55:43 +0100 References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk> <01b201cae702$35547a00$9ffd6e00$@us> <754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com> <826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: 'Bernie Hoeneisen' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] lots of NAPTRs 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, 30 Apr 2010 09:56:02 -0000 On 29 Apr 2010, at 18:46, Dean Willis wrote: > Some of them don't mind some level of data in the DNS, they just > want a more selective query mechanism than NAPTR because we get such > big RRsets in the result. But as noted, this approach certainly > doesn't satisfy all the greybeard critics; the only one that does > seems to be putting a metadata pointer (and nothing else) into the > DNS. Dean, who are these greybeard critics and what, precisely, are they whining about? Whether some NAPTR or TXT record (variant) is chosen, the same provisioning problem remains. If someone put lots of data at some node in the name space, their name servers will send chubby responses. BFD. As you know, the DNS has robust and workable methods to deal with that. They're also independent of the RRset type(s) that are in the response. An E2U NAPTR takes up ~60 bytes of a DNS response. So it'll be in the man tens of NAPTRs (maybe 100 or so) before default EDNS0 payloads start to bust at the seams and TCP retries become necessary. [Assuming nobody does the right thing and adopts even bigger EDNS buffers.] So that probably means a tiny percentage of queries will go over TCP. This is no big deal either. Besides, if there is (or could be) and operational issue here, I'm sure dnsop and/or the DNS Directorate would intervene. Maybe they could be asked for advice about that now? This would settle the issue, stop the FUD, shut up these anonymous greybeard critics and give this list a clearer understanding of the parameters to work inside. In DNS circles, there's a lot of discussion about the roll-out of the signed root zones. There was concern that poorly chosen EDNS0 buffer sizes would result in too many signed responses getting truncated. [That doesn't appear to have happened BTW.] Even so, the root server operators are confident their servers could cope with many thousands of TCP queries per second. If they can provision their servers to cope with that then so can anyone using DNS for serving E2MD data. Remember too that steady state query rates at the root will be 3-4? orders of magnitude greater than at the DNS servers pumping out E2MD data. PS: Apologies for a meaningful Subject: header From richard@shockey.us Fri Apr 30 06:00: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 4E0F53A6907 for ; Fri, 30 Apr 2010 06:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.68 X-Spam-Level: X-Spam-Status: No, score=-0.68 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_50=0.001] 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 FrS2rZGaPtWX for ; Fri, 30 Apr 2010 06:00:39 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (oproxy2-pub.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id F3E483A68BD for ; Fri, 30 Apr 2010 06:00:38 -0700 (PDT) Received: (qmail 26681 invoked by uid 0); 30 Apr 2010 12:00:24 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 30 Apr 2010 12:00:22 -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=R4/1pvp9uP/TaZuYn8K45aDZhAP9v3+zGnxGeMnbJDkbI8D9qIvnd0ooIKm3dALlOru6PTZXzleMa7piwX+1SC5elvV22qlXbPcVcH5RlWla9oHDoMZgCw8wLrQ0rpzx; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1O7ppN-0002Zo-Dq; Fri, 30 Apr 2010 07:00:21 -0600 From: "Richard Shockey" To: "'Dean Willis'" , "'Cartwright, Kenneth'" References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk> <01b201cae702$35547a00$9ffd6e00$@us> <754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com> <826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: Date: Fri, 30 Apr 2010 09:00:16 -0400 Message-ID: <005501cae865$14e20c60$3ea62520$@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: AcroAt7bxLqlfCD0RleugX1KuOgTFAAYRBtA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: 'Bernie Hoeneisen' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Rough minutes of today's conf call 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, 30 Apr 2010 13:00:40 -0000 Dean ... just where are you getting your data points? You are making wild statements that have no basis in actual deployed fact. -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Thursday, April 29, 2010 9:17 PM To: Cartwright, Kenneth Cc: Richard Shockey; 'E.164 To MetaData BOF discussion list'; 'Bernie Hoeneisen' Subject: Re: [e2md] Rough minutes of today's conf call On Apr 29, 2010, at 3:43 PM, Cartwright, Kenneth wrote: > > > (1) ENUM is based on DNS and is **already** operational today. Has > it brought down "the Internet's DNS"? No. When's the last time you made an ENUM dip and got back 200 resource records? Hasn't happened yet? It will, if we keep up on this path. RS> This is just absurd .. there is no possible scenario where 200 RR records are going to be sent back but even if it was ..so what if it can actually solve a problem in the field. > (2) Given the foreseeable size of the problem space, the RR set size > does have to be too large. Regardless, that will be continuously > evaluated as part of the expert review for each newly proposed E2M > serviceType/subtype (as it was during the ENUM expert reviews). So, what guidance do we give the expert reviewer? Cut it off after the 10th resource record? The 20th? The 50th? RS> Its not our business to decide this. The existing E2U model for type is working quite well. The world has not collapsed. > (3) The ENUM LLC trials were conducted and completed, years ago. > That initiative has always been designed to be a separately managed > DNS ecosystem, if you will. So what's the issue? Are folks > pretending that the ENUM LLC trials did not happen? Or are they > saying that the result of the ENUM LLC trials found that because > NAPTRs use DNS technologies, oops, that the mainline Internet DNS > system was going to have issues? They're saying that if we document this stuff as part of the mainline DNS, somebody is going to use it there, and if this catches on, Kaboom! > Or are they just not aware that ENUM, based on DNS technologies, is > already in production today? They're aware of it. When you ask for a NAPTR record for a phone number and get back one record containing a SIP URI, there's no problem. When you get two or three, there's no problem. But defining an unbounded framework to define lots more responses makes them really nervous. RS> Makes who nervous? A bunch of people who never actually deployed ENUM databases? > (4) Middle grounds have already been proposed and rejected for > equally amorphous reasons from non-present third parties. > There's always more middle ground somewhere. The first thing is understanding the objections. Based on this discussion we keep having, I don't think we clearly understand the DNS greybeard's arguments. I think they understand what we are trying to do; they just don't see documenting this as part of the DNS and then only using it in private networks to be a viable long term control mechanism for the fallout they're expecting. RS> Well Dean the first thing is I don't think the DNS grey beards understand what we are trying to do. And this does have both public and private usages here. > The idea that you cannot create a technical standard derived from an > existing technical standard is fundamentally contrary to the IETF > way. RS> Dean this has gone far enough .. nothing in the proposed usage is fundamentally contrary to 3761 far from it it's a modest extension. And the idea that you cannot create a technical standard > because someone, somewhere in the world could do something really > silly with it and harm their systems is not a logical approach to > standards creation, and creates an impossible solution space. We can create a derived technical standard. There's nobody in the DNS directorate blocking us from deriving a new "metadata protocol" that works pretty much like a DNS query, defining a new URL for it, and putting that URL into the ENUM tree and looking it up based on a phone number, then using it to query back all the metadata our switches need. Of from a dozen other approaches that might work equally well. From their point of view, they're just protecting an incredibly important piece of infrastructure from the unintended consequences of our effort to extend it. But I DO understand their argument that created an open-ended framework for putting arbitrary cruft into the DNS will eventually result in too much stuff shoved in there. It's a credible argument. People do stupid stuff with their toys. In the SIP work, everytime we created an easy way for people to do extensions, like the "P-header" debacle (which required expert review AND informational RFC) , they went off and did crazy stuff that swelled up the messages and made the protocol less interoperable. If we give them a way to do it, we'll find the entire text of the Library of Congress in the DNS not too far down the road. It's not that someone somewhere will do a silly thing with it in their own network, but that they'll do a dangerous and destructive thing with it right smack dab in the middle of the Internet's most critical name resolution facility, and it Will Cause Problems. -- Dean From kcartwright@tnsi.com Fri Apr 30 07:03:25 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 6581B3A6987 for ; Fri, 30 Apr 2010 07:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.286 X-Spam-Level: X-Spam-Status: No, score=-0.286 tagged_above=-999 required=5 tests=[AWL=-1.487, BAYES_50=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_53=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 Hiw2YlDh0NPq for ; Fri, 30 Apr 2010 07:03:24 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id A4E5928C143 for ; Fri, 30 Apr 2010 07:03:18 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.43149778; Fri, 30 Apr 2010 10:02:49 -0400 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; Fri, 30 Apr 2010 10:02:49 -0400 From: "Cartwright, Kenneth" To: Lawrence Conroy , E.164 To MetaData BOF discussion list Date: Fri, 30 Apr 2010 10:02:47 -0400 Thread-Topic: [e2md] E2MD and DNS overload Thread-Index: AcroRUWkEKS/N9mXRB6R4Iiq1lvNXQAJnGSQ Message-ID: <754963199212404AB8E9CFCA6C3D0CDA2446918030@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <3E216B8F-62B4-4D8E-AF97-2BF2B22DC8B1@insensate.co.uk> In-Reply-To: <3E216B8F-62B4-4D8E-AF97-2BF2B22DC8B1@insensate.co.uk> 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] E2MD and DNS overload 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, 30 Apr 2010 14:03:25 -0000 Exactly!! The premise behind this point of opposition is simply off base. = And it requires the proof of an open ended negative, which is always a hug= e red flag (i.e you can't design that widget with a square corner on it bec= ause someone might use it to hurt someone). One down. On to the next. We cannot continue having the same debates over= and over and expect to get anywhere. Ken -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Law= rence Conroy Sent: Friday, April 30, 2010 5:12 AM To: E.164 To MetaData BOF discussion list Subject: [e2md] E2MD and DNS overload Hi Dean, folks, on the grounds that the previous mail thread had a vague title, I've start= ed a new one. To summarise earlier posting -- channeling 20 bunkum-spouting demons, Dean = said: * People could put a set of 200 resource records into a domain. * If people use this with large RRSets on the open Internet it will cause widespread problems. * Servers would have to generate large answers. To which I answer: - You could do that now. You don't even need to use type 35. That is a provisioning issue, not a protocol issue. I do not see how this is any different from existing RR types. Viz. DNSOPS discussions on signed response sizes and rollover. With the exception of that particular corner case where the minimum size can be large, people do not do it. It seems unreasonable to block use of a resource record type for what is a purely operational issue. This is certainly nothing to do with E2MD. This is a complaint at ENUM. There is nothing stopping someone putting any number of email, web, sip E2U NAPTRs (and D2U NAPTRs) voice:tel and sms:tel or even h323 NAPTRs into a domain, now. As a user of E2U NAPTRs, I do queries regularly and I do get RRsets that are in the 10s of records. It just works. - I don't understand how ENUM can be a Weapon of Mass Destruction. What widespread damage will be caused? Regardless of RRset size, the request is not large, so bouncing tha= t through the authoritative hierarchy repeatedly is not an issue. The response may be large. This comes from the authoritative server that hosts a large RRset. This response also traverses the recursiv= e resolver from which the query was sent. The victims are the Auth server that hosts the large RRSet and the recursive resolver that makes the query and receives the truncated result. The recursive resolver wil send one query over UDP, receive one truncated response over UDP, and then fallback from that truncated response using TCP. That IS a congestion-controlled protocol. So ... someone provisions a large RRset into an auth server; the auth server consumes bandwidth sending its responses, and it may take some small time for the recursive resolver to get a response due to the fallback to TCP. This is not news. What other collateral damage is caused? The volume of interweb traffic that is used for DNS is tiny. ASSUMING that the Auth server for facebook.com is not the same one that is hosting ENUM domains, people will continue to waste their time without any interference. It's not like the Interweb has a separate tube for DNS, and that tube can get full. - Finally (from a previous channel), DNS servers don't do a lot to generate RRsets. Auth DNS servers are not like some LDAP or Web server (as would be used with any redirection scheme). I contend that those objections are bunkum. Lest anyone misunderstand, I'm sure Dean is acting only as the messenger, so this is NOT a dig at him. all the best, Lawrence _______________________________________________ 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 kcartwright@tnsi.com Fri Apr 30 07:17:15 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 6B88C3A6974 for ; Fri, 30 Apr 2010 07:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.914 X-Spam-Level: X-Spam-Status: No, score=-0.914 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_40=-0.185] 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 jT9SUq4dUgGa for ; Fri, 30 Apr 2010 07:17:13 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 7852F3A6905 for ; Fri, 30 Apr 2010 07:17:13 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.43150333; Fri, 30 Apr 2010 10:16:41 -0400 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; Fri, 30 Apr 2010 10:16:41 -0400 From: "Cartwright, Kenneth" To: Richard Shockey , 'Dean Willis' Date: Fri, 30 Apr 2010 10:16:39 -0400 Thread-Topic: [e2md] Rough minutes of today's conf call Thread-Index: AcroAt7bxLqlfCD0RleugX1KuOgTFAAYRBtAAAKo/bA= Message-ID: <754963199212404AB8E9CFCA6C3D0CDA2446918052@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk> <01b201cae702$35547a00$9ffd6e00$@us> <754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com> <826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> <005501cae865$14e20c60$3ea62520$@us> In-Reply-To: <005501cae865$14e20c60$3ea62520$@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' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Rough minutes of today's conf call 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, 30 Apr 2010 14:17:15 -0000 This is a very true statement. "You are making wild statements that have no basis in actual deployed fact.= " Ken -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: Friday, April 30, 2010 9:00 AM To: 'Dean Willis'; Cartwright, Kenneth Cc: 'E.164 To MetaData BOF discussion list'; 'Bernie Hoeneisen' Subject: RE: [e2md] Rough minutes of today's conf call Dean ... just where are you getting your data points? You are making wild statements that have no basis in actual deployed fact. -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Thursday, April 29, 2010 9:17 PM To: Cartwright, Kenneth Cc: Richard Shockey; 'E.164 To MetaData BOF discussion list'; 'Bernie Hoeneisen' Subject: Re: [e2md] Rough minutes of today's conf call On Apr 29, 2010, at 3:43 PM, Cartwright, Kenneth wrote: > > > (1) ENUM is based on DNS and is **already** operational today. Has > it brought down "the Internet's DNS"? No. When's the last time you made an ENUM dip and got back 200 resource records? Hasn't happened yet? It will, if we keep up on this path. RS> This is just absurd .. there is no possible scenario where 200 RR records are going to be sent back but even if it was ..so what if it can actually solve a problem in the field. > (2) Given the foreseeable size of the problem space, the RR set size > does have to be too large. Regardless, that will be continuously > evaluated as part of the expert review for each newly proposed E2M > serviceType/subtype (as it was during the ENUM expert reviews). So, what guidance do we give the expert reviewer? Cut it off after the 10th resource record? The 20th? The 50th? RS> Its not our business to decide this. The existing E2U model for type i= s working quite well. The world has not collapsed. > (3) The ENUM LLC trials were conducted and completed, years ago. > That initiative has always been designed to be a separately managed > DNS ecosystem, if you will. So what's the issue? Are folks > pretending that the ENUM LLC trials did not happen? Or are they > saying that the result of the ENUM LLC trials found that because > NAPTRs use DNS technologies, oops, that the mainline Internet DNS > system was going to have issues? They're saying that if we document this stuff as part of the mainline DNS, somebody is going to use it there, and if this catches on, Kaboom! > Or are they just not aware that ENUM, based on DNS technologies, is > already in production today? They're aware of it. When you ask for a NAPTR record for a phone number and get back one record containing a SIP URI, there's no problem. When you get two or three, there's no problem. But defining an unbounded framework to define lots more responses makes them really nervous. RS> Makes who nervous? A bunch of people who never actually deployed ENUM databases? > (4) Middle grounds have already been proposed and rejected for > equally amorphous reasons from non-present third parties. > There's always more middle ground somewhere. The first thing is understanding the objections. Based on this discussion we keep having, I don't think we clearly understand the DNS greybeard's arguments. I think they understand what we are trying to do; they just don't see documenting this as part of the DNS and then only using it in private networks to be a viable long term control mechanism for the fallout they're expecting. RS> Well Dean the first thing is I don't think the DNS grey beards understand what we are trying to do. And this does have both public and private usages here. > The idea that you cannot create a technical standard derived from an > existing technical standard is fundamentally contrary to the IETF > way. RS> Dean this has gone far enough .. nothing in the proposed usage is fundamentally contrary to 3761 far from it it's a modest extension. And the idea that you cannot create a technical standard > because someone, somewhere in the world could do something really > silly with it and harm their systems is not a logical approach to > standards creation, and creates an impossible solution space. We can create a derived technical standard. There's nobody in the DNS directorate blocking us from deriving a new "metadata protocol" that works pretty much like a DNS query, defining a new URL for it, and putting that URL into the ENUM tree and looking it up based on a phone number, then using it to query back all the metadata our switches need. Of from a dozen other approaches that might work equally well. From their point of view, they're just protecting an incredibly important piece of infrastructure from the unintended consequences of our effort to extend it. But I DO understand their argument that created an open-ended framework for putting arbitrary cruft into the DNS will eventually result in too much stuff shoved in there. It's a credible argument. People do stupid stuff with their toys. In the SIP work, everytime we created an easy way for people to do extensions, like the "P-header" debacle (which required expert review AND informational RFC) , they went off and did crazy stuff that swelled up the messages and made the protocol less interoperable. If we give them a way to do it, we'll find the entire text of the Library of Congress in the DNS not too far down the road. It's not that someone somewhere will do a silly thing with it in their own network, but that they'll do a dangerous and destructive thing with it right smack dab in the middle of the Internet's most critical name resolution facility, and it Will Cause Problems. -- Dean 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 pp3129@att.com Fri Apr 30 07:43:08 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 5CA213A6ABD for ; Fri, 30 Apr 2010 07:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=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 rit+EySQcM2e for ; Fri, 30 Apr 2010 07:43:07 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id CA6E13A68F3 for ; Fri, 30 Apr 2010 07:43:04 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-2.tower-146.messagelabs.com!1272638575!27628414!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 9591 invoked from network); 30 Apr 2010 14:42:56 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-2.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Apr 2010 14:42:56 -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 o3UEgXr5005260; Fri, 30 Apr 2010 10:42:33 -0400 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 o3UEgRJZ005148; Fri, 30 Apr 2010 10:42:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Apr 2010 10:42:36 -0400 Message-ID: <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <005501cae865$14e20c60$3ea62520$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [e2md] the 200 RR of Bartholemew Cubbins :-) Thread-Index: AcroAt7bxLqlfCD0RleugX1KuOgTFAAYRBtAAAN4ziA= References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk><01b201cae702$35547a00$9ffd6e00$@us><754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com><826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.com><754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> <005501cae865$14e20c60$3ea62520$@us> From: "PFAUTZ, PENN L (ATTCORP)" To: "Richard Shockey" , "Dean Willis" , "Cartwright, Kenneth" Cc: Bernie Hoeneisen , "E.164 To MetaData BOF discussion list" Subject: [e2md] the 200 RR of Bartholemew Cubbins :-) 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, 30 Apr 2010 14:43:08 -0000 Let me see if I'm thinking about this right - the concern is that owners of ENUM domain names will provision too much data under their zones. I imagine two potential concerns here 1. that querying clients will gag - presumably no network operator would do this since it would break their service. We're not THAT dumb :-); I hope. Individual number owners in a pure 3761 end user ENUM might be more foolish but will reform when their application breaks. 2. that there will just be too much data pushed through the net as a result. I find this hard to believe. Compared to other drivers of net traffic I think this must remain tiny. I may well be missing something but tell me what it is. If there's a real problem I won't object to the solution taking other paths. Thanks, Penn Pfautz AT&T Access Management +1-732-420-4962 From bernie@ietf.hoeneisen.ch Fri Apr 30 07:52:41 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 DAA6A3A6939 for ; Fri, 30 Apr 2010 07:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_50=0.001] 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 Fg2xb2oop5OX for ; Fri, 30 Apr 2010 07:52:40 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 766EC3A69C2 for ; Fri, 30 Apr 2010 07:52:34 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1O7rZZ-00011j-UH; Fri, 30 Apr 2010 16:52:10 +0200 Date: Fri, 30 Apr 2010 16:52:09 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "PFAUTZ, PENN L (ATTCORP)" In-Reply-To: <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> Message-ID: References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk><01b201cae702$35547a00$9ffd6e00$@us><754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com><826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.com><754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> 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: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-) 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, 30 Apr 2010 14:52:41 -0000 Hi Penn On Fri, 30 Apr 2010, PFAUTZ, PENN L (ATTCORP) wrote: > Let me see if I'm thinking about this right - the concern is that owners > of ENUM domain names will provision too much data under their zones. > I imagine two potential concerns here > 1. that querying clients will gag - presumably no network operator would > do this since it would break their service. We're not THAT dumb :-); I > hope. > Individual number owners in a pure 3761 end user ENUM might be more > foolish but will reform when their application breaks. > 2. that there will just be too much data pushed through the net as a > result. I find this hard to believe. Compared to other drivers of net > traffic I think this must remain tiny. > > I may well be missing something but tell me what it is. If there's a > real problem I won't object to the solution taking other paths. You left out DNS caching servers that have also been reported to be problematic when having big DNS responses. (Even in the case the TTL is zero, some caching servers in the field will cache for a minimum time.) However, I am not in possession of any figures on how serious this caching issue might be. cheers, Bernie From richard@shockey.us Fri Apr 30 08:48: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 665033A6B02 for ; Fri, 30 Apr 2010 08:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001] 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 MEefLd-Jz1JK for ; Fri, 30 Apr 2010 08:48:21 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (oproxy2-pub.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 54AC33A6405 for ; Fri, 30 Apr 2010 08:48:21 -0700 (PDT) Received: (qmail 3236 invoked by uid 0); 30 Apr 2010 14:48:08 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 30 Apr 2010 14:48:08 -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-cr-hashedpuzzle:x-cr-puzzleid:X-Identified-User; b=oyEQwOyi1a8YH/vXQbpGpAbM+yC/kHeAcLnURol+yAnt35FgDu7GNtReOyOAriYqIsiJa6gcdnQqLk6xzBVGf9qIApsHhN+EY8u1XeMoz2k82Ri8DbwON8UIQgXd26T8; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1O7sRj-0007FK-3C; Fri, 30 Apr 2010 09:48:07 -0600 From: "Richard Shockey" To: "'Bernie Hoeneisen'" , "'PFAUTZ, PENN L \(ATTCORP\)'" References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk><01b201cae702$35547a00$9ffd6e00$@us><754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com><826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.com><754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: Date: Fri, 30 Apr 2010 11:47:56 -0400 Message-ID: <008001cae87c$84737bb0$8d5a7310$@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: AcrodLogmVT/8q8BQkecHzjN2nVpQgABagmQ Content-Language: en-us x-cr-hashedpuzzle: Ch48 DeG9 GMbj OQxZ alUw bLDk esMq hGN2 nIWm oZAH qxAg 1IyP 2Nme 3KXj 4h6l 5oXg; 5; YgBlAHIAbgBpAGUAQABpAGUAdABmAC4AaABvAGUAbgBlAGkAcwBlAG4ALgBjAGgAOwBkAGUAYQBuAC4AdwBpAGwAbABpAHMAQABzAG8AZgB0AGEAcgBtAG8AcgAuAGMAbwBtADsAZQAyAG0AZABAAGkAZQB0AGYALgBvAHIAZwA7AGsAYwBhAHIAdAB3AHIAaQBnAGgAdABAAHQAbgBzAGkALgBjAG8AbQA7AHAAcAAzADEAMgA5AEAAYQB0AHQALgBjAG8AbQA=; Sosha1_v1; 7; {E51688D3-9550-4FDE-AEAD-1748EE73E9FC}; cgBpAGMAaABhAHIAZABAAHMAaABvAGMAawBlAHkALgB1AHMA; Fri, 30 Apr 2010 15:47:45 GMT; UgBFADoAIABbAGUAMgBtAGQAXQAgACAAIAB0AGgAZQAgADIAMAAwACAAUgBSACAAbwBmACAAQgBhAHIAdABoAG8AbABlAG0AZQB3ACAAQwB1AGIAYgBpAG4AcwAgADoALQApAA== x-cr-puzzleid: {E51688D3-9550-4FDE-AEAD-1748EE73E9FC} X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-) 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, 30 Apr 2010 15:48:22 -0000 NO ..ENUM aware and optimized caching servers, in my professional experience, have not had these issues. Many of them in carrier networks can now handle up to 400 Million TN's and all the data associated with them locally with superb response times in multi terabyte memory resident databases. In private instantiations of ENUM all the data is usually cached all the time and updated as needed from external data sources like LNP. Remember these local caches usually contain internal network specific data as well as data such as Trunk group data that are essential for internal session routing. Any SP that would use BIND for this is just plain nuts. Again Ken Cartwright is right. Our knowledge of how this all scales is based on empirical fact not speculation. Want to see fat chubby DNS responses that will clog some networks..try DNSSEC. > > I may well be missing something but tell me what it is. If there's a > real problem I won't object to the solution taking other paths. You left out DNS caching servers that have also been reported to be problematic when having big DNS responses. (Even in the case the TTL is zero, some caching servers in the field will cache for a minimum time.) However, I am not in possession of any figures on how serious this caching issue might be. cheers, Bernie From richard@shockey.us Fri Apr 30 08:50:32 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 0B6E33A6BC0 for ; Fri, 30 Apr 2010 08:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=0.678, 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 6m3vvyZrnnxC for ; Fri, 30 Apr 2010 08:50:31 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 75E663A6B02 for ; Fri, 30 Apr 2010 08:50:30 -0700 (PDT) Received: (qmail 7615 invoked by uid 0); 30 Apr 2010 15:50:13 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 30 Apr 2010 15:50:11 -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=MwATKDcN6W1lRcHvd33fMpgtTqOkngrkWh+4CnR1pZANiW+ADFTpc9Lh7bNirydZu/Nu9bHhuSRRUeFboKsADQIxbVnnimkF7Il5XaUc+0YSoEn50IGWeSboDg82+Kbv; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1O7sTi-0008SZ-Vr; Fri, 30 Apr 2010 09:50:11 -0600 From: "Richard Shockey" To: "'Jim Reid'" , "'Dean Willis'" References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk> <01b201cae702$35547a00$9ffd6e00$@us> <754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com> <826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.com> In-Reply-To: Date: Fri, 30 Apr 2010 11:50:05 -0400 Message-ID: <008101cae87c$ce4c5c20$6ae51460$@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: AcroS1FwDQvDEtXSSeae9n/aPl2vIAAMTHOw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: 'Bernie Hoeneisen' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] lots of NAPTRs 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, 30 Apr 2010 15:50:32 -0000 Right Jim ...if these greybeards have a problem let them whine on this list instead of being BOF tourists. Dean, who are these greybeard critics and what, precisely, are they whining about? From HKaplan@acmepacket.com Fri Apr 30 10:46:30 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 A905C3A6B7B for ; Fri, 30 Apr 2010 10:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.179 X-Spam-Level: X-Spam-Status: No, score=-1.179 tagged_above=-999 required=5 tests=[AWL=-0.994, BAYES_40=-0.185] 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 FTvc3I9syfVT for ; Fri, 30 Apr 2010 10:46:29 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 6D89C3A6B89 for ; Fri, 30 Apr 2010 10:46:28 -0700 (PDT) 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; Fri, 30 Apr 2010 13:46:14 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 30 Apr 2010 13:46:13 -0400 From: Hadriel Kaplan To: "PFAUTZ, PENN L (ATTCORP)" , Richard Shockey , Dean Willis , "Cartwright, Kenneth" Date: Fri, 30 Apr 2010 13:46:08 -0400 Thread-Topic: [e2md] the 200 RR of Bartholemew Cubbins :-) Thread-Index: AcroAt7bxLqlfCD0RleugX1KuOgTFAAYRBtAAAN4ziAABATKMA== Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F18F6@mail> References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk><01b201cae702$35547a00$9ffd6e00$@us><754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com><826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.com><754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.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] the 200 RR of Bartholemew Cubbins :-) 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, 30 Apr 2010 17:46:30 -0000 Actually, I'm generally on the same page, but I don't think we should dismi= ss this issue too quickly. It may turn out we like green eggs and ham. ;) For me, the huge advantages of ENUM/DNS over any other protocol are (1) per= formance, (2) performance, and (3) performance. Even the built-in scalabil= ity-through-tree-distribution benefit basically boils down to performance (= you could put similar logic into any database query model, but DNS is effic= ient at it). So it does concern me if we think a single query could result in a huge lis= t of records that I don't care about. The number of E2U records in a respo= nse even in private ENUM cases has already grown into double-digits. And i= t didn't take long for that to happen. :( -hadriel > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > PFAUTZ, PENN L (ATTCORP) > Sent: Friday, April 30, 2010 10:43 AM > To: Richard Shockey; Dean Willis; Cartwright, Kenneth >=20 > Let me see if I'm thinking about this right - the concern is that owners > of ENUM domain names will provision too much data under their zones. > I imagine two potential concerns here > 1. that querying clients will gag - presumably no network operator would > do this since it would break their service. We're not THAT dumb :-); I > hope. > Individual number owners in a pure 3761 end user ENUM might be more > foolish but will reform when their application breaks. > 2. that there will just be too much data pushed through the net as a > result. I find this hard to believe. Compared to other drivers of net > traffic I think this must remain tiny. >=20 > I may well be missing something but tell me what it is. If there's a > real problem I won't object to the solution taking other paths. >=20 > Thanks, >=20 > Penn Pfautz > AT&T Access Management > +1-732-420-4962 >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From trutkowski@netmagic.com Fri Apr 30 10:57:07 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 B543228C182 for ; Fri, 30 Apr 2010 10:57:07 -0700 (PDT) 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 q9XGDsqAAkCH for ; Fri, 30 Apr 2010 10:57:07 -0700 (PDT) Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by core3.amsl.com (Postfix) with ESMTP id EF7BD28C17E for ; Fri, 30 Apr 2010 10:57:06 -0700 (PDT) Received: from [192.168.0.5] ([unknown] [173.71.223.14]) by vms173001.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L1P00858B62Z810@vms173001.mailsrvcs.net> for e2md@ietf.org; Fri, 30 Apr 2010 12:56:31 -0500 (CDT) Message-id: <4BDB19CA.7080900@netmagic.com> Date: Fri, 30 Apr 2010 13:56:26 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100406 Shredder/3.0.4 MIME-version: 1.0 To: Hadriel Kaplan References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk><01b201cae702$35547a00$9ffd6e00$@us><754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com><826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.com><754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> <430FC6BDED356B4C8498F634416644A91A8A5F18F6@mail> In-reply-to: <430FC6BDED356B4C8498F634416644A91A8A5F18F6@mail> 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] the 200 RR of Bartholemew Cubbins :-) X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com 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, 30 Apr 2010 17:57:07 -0000 On 4/30/2010 1:46 PM, Hadriel Kaplan wrote: > For me, the huge advantages of ENUM/DNS over any other protocol are (1) performance, (2) performance, and (3) performance. Even the built-in scalability-through-tree-distribution benefit basically boils down to performance (you could put similar logic into any database query model, but DNS is efficient at it). > Curious minds would ask whether this assessment includes Handles? --tony From lconroy@insensate.co.uk Fri Apr 30 11:05: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 3078928C1AB for ; Fri, 30 Apr 2010 11:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 tagged_above=-999 required=5 tests=[AWL=1.279, 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 g2IgwplET-oQ for ; Fri, 30 Apr 2010 11:05:42 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id E26843A6AF6 for ; Fri, 30 Apr 2010 11:05:41 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id A3A2212CDA8; Fri, 30 Apr 2010 19:05:25 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <4BDB19CA.7080900@netmagic.com> Date: Fri, 30 Apr 2010 19:05:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk><01b201cae702$35547a00$9ffd6e00$@us><754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com><826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.com><754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> <430FC6BDED356B4C8498F634416644A91A8A5F18F6@mail> <4BDB19CA.7080900@netmagic.com> To: trutkowski@netmagic.com X-Mailer: Apple Mail (2.1078) Cc: Bernie Hoeneisen , "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-) 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, 30 Apr 2010 18:05:43 -0000 Puzzled minds would ask for a little more context: Handles -- as in four = candles? all the best, Lawrence On 30 Apr 2010, at 18:56, Tony Rutkowski wrote: > On 4/30/2010 1:46 PM, Hadriel Kaplan wrote: >> For me, the huge advantages of ENUM/DNS over any other protocol are = (1) performance, (2) performance, and (3) performance. Even the = built-in scalability-through-tree-distribution benefit basically boils = down to performance (you could put similar logic into any database query = model, but DNS is efficient at it). >> =20 >=20 > Curious minds would ask whether this assessment includes Handles? >=20 > --tony > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From trutkowski@netmagic.com Fri Apr 30 11:14:41 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 A7CE928C26B for ; Fri, 30 Apr 2010 11:14:41 -0700 (PDT) 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 HqflADPObfcM for ; Fri, 30 Apr 2010 11:14:40 -0700 (PDT) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by core3.amsl.com (Postfix) with ESMTP id 61EE928C266 for ; Fri, 30 Apr 2010 11:14:39 -0700 (PDT) Received: from [192.168.0.5] ([unknown] [173.71.223.14]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L1P00CLEBZ5SP30@vms173005.mailsrvcs.net> for e2md@ietf.org; Fri, 30 Apr 2010 13:13:58 -0500 (CDT) Message-id: <4BDB1DE1.5060100@netmagic.com> Date: Fri, 30 Apr 2010 14:13:53 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100406 Shredder/3.0.4 MIME-version: 1.0 To: Lawrence Conroy References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk><01b201cae702$35547a00$9ffd6e00$@us><754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com><826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.com><754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> <430FC6BDED356B4C8498F634416644A91A8A5F18F6@mail> <4BDB19CA.7080900@netmagic.com> 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] the 200 RR of Bartholemew Cubbins :-) X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com 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, 30 Apr 2010 18:14:41 -0000 On 4/30/2010 2:05 PM, Lawrence Conroy wrote: > Puzzled minds would ask for a little more context: Handles -- as in four candles? > all the best, > As in http://www.handle.net/ --tony From bernie@ietf.hoeneisen.ch Fri Apr 30 11:45:07 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 4939B28C28A for ; Fri, 30 Apr 2010 11:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_20=-0.74] 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 HJ48vrMQVSZg for ; Fri, 30 Apr 2010 11:45:06 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 4266F28C27B for ; Fri, 30 Apr 2010 11:45:05 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1O7vCe-0001Qa-HB; Fri, 30 Apr 2010 20:44:44 +0200 Date: Fri, 30 Apr 2010 20:44:44 +0200 (CEST) From: 'Bernie Hoeneisen' X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Richard Shockey In-Reply-To: <008001cae87c$84737bb0$8d5a7310$@us> Message-ID: References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk><01b201cae702$35547a00$9ffd6e00$@us><754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com><826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.com><754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> <008001cae87c$84737bb0$8d5a7310$@us> 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: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-) 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, 30 Apr 2010 18:45:07 -0000 Hi Rich I trust you that Telco grade DNS caches as you describe them below can handle long DNS answers without significant problems. But people are rather concerned that loads of long DNS answers harm their (ordinary) DNS caches on the Internet. This concern needs to be addressed one way or the other. cheers, Bernie On Fri, 30 Apr 2010, Richard Shockey wrote: > NO ..ENUM aware and optimized caching servers, in my professional > experience, have not had these issues. Many of them in carrier networks can > now handle up to 400 Million TN's and all the data associated with them > locally with superb response times in multi terabyte memory resident > databases. In private instantiations of ENUM all the data is usually cached > all the time and updated as needed from external data sources like LNP. > Remember these local caches usually contain internal network specific data > as well as data such as Trunk group data that are essential for internal > session routing. > > Any SP that would use BIND for this is just plain nuts. > > Again Ken Cartwright is right. Our knowledge of how this all scales is based > on empirical fact not speculation. > > Want to see fat chubby DNS responses that will clog some networks..try > DNSSEC. > >> >> I may well be missing something but tell me what it is. If there's a >> real problem I won't object to the solution taking other paths. > > You left out DNS caching servers that have also been reported to be > problematic when having big DNS responses. > (Even in the case the TTL is zero, some caching servers in the field will > cache for a minimum time.) > > However, I am not in possession of any figures on how serious this caching > issue might be. > > cheers, > Bernie > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > From kcartwright@tnsi.com Fri Apr 30 11:52:14 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 CC0903A6979 for ; Fri, 30 Apr 2010 11:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.508, 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 U7Xebp3TZMH6 for ; Fri, 30 Apr 2010 11:52:13 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 097B73A68D5 for ; Fri, 30 Apr 2010 11:52:12 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.43160846; Fri, 30 Apr 2010 14:51:41 -0400 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; Fri, 30 Apr 2010 14:51:41 -0400 From: "Cartwright, Kenneth" To: Hadriel Kaplan , "PFAUTZ, PENN L (ATTCORP)" , Richard Shockey , Dean Willis Date: Fri, 30 Apr 2010 14:51:39 -0400 Thread-Topic: [e2md] the 200 RR of Bartholemew Cubbins :-) Thread-Index: AcroAt7bxLqlfCD0RleugX1KuOgTFAAYRBtAAAN4ziAABATKMAAEklTg Message-ID: <754963199212404AB8E9CFCA6C3D0CDA24469D7B12@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk><01b201cae702$35547a00$9ffd6e00$@us><754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com><826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.com><754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> <430FC6BDED356B4C8498F634416644A91A8A5F18F6@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A5F18F6@mail> 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: E.164, Bernie Hoeneisen , discussion list Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-) 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, 30 Apr 2010 18:52:14 -0000 >From a practical perspective, where does the worry about "a huge list of re= cords I'm not interested in" arise? I'm not seeing it. However, as stated prior, I *would* like to see either E2M or ENUM extended= to optionally allow the querier to list the ServiceTypes that it is intere= sted in. imo, this can be addressed as an optional, localized extension to= the E2U or E2M specs (but this is just a tangential point that is only a n= ice-to-have at this point). There is no need to re-invent a bad ENUM using= prefixes and TXT records to make this improvement. And to those **non-pre= sent objectors** please refrain from waving the "you can't add any new feat= ures any-where around the DNS technologies or ecosystem because it will get= misused and bring down the Internet" flag. Ken -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Friday, April 30, 2010 1:46 PM To: PFAUTZ, PENN L (ATTCORP); Richard Shockey; Dean Willis; Cartwright, Ken= neth Cc: Bernie Hoeneisen; E.164 To MetaData BOF discussion list Subject: RE: [e2md] the 200 RR of Bartholemew Cubbins :-) Actually, I'm generally on the same page, but I don't think we should dismi= ss this issue too quickly. It may turn out we like green eggs and ham. ;) For me, the huge advantages of ENUM/DNS over any other protocol are (1) per= formance, (2) performance, and (3) performance. Even the built-in scalabil= ity-through-tree-distribution benefit basically boils down to performance (= you could put similar logic into any database query model, but DNS is effic= ient at it). So it does concern me if we think a single query could result in a huge lis= t of records that I don't care about. The number of E2U records in a respo= nse even in private ENUM cases has already grown into double-digits. And i= t didn't take long for that to happen. :( -hadriel > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > PFAUTZ, PENN L (ATTCORP) > Sent: Friday, April 30, 2010 10:43 AM > To: Richard Shockey; Dean Willis; Cartwright, Kenneth > > Let me see if I'm thinking about this right - the concern is that owners > of ENUM domain names will provision too much data under their zones. > I imagine two potential concerns here > 1. that querying clients will gag - presumably no network operator would > do this since it would break their service. We're not THAT dumb :-); I > hope. > Individual number owners in a pure 3761 end user ENUM might be more > foolish but will reform when their application breaks. > 2. that there will just be too much data pushed through the net as a > result. I find this hard to believe. Compared to other drivers of net > traffic I think this must remain tiny. > > I may well be missing something but tell me what it is. If there's a > real problem I won't object to the solution taking other paths. > > Thanks, > > Penn Pfautz > AT&T Access Management > +1-732-420-4962 > > _______________________________________________ > 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 richard@shockey.us Fri Apr 30 12:13: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 06E3F3A69CB for ; Fri, 30 Apr 2010 12:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 tH8yELiGxRni for ; Fri, 30 Apr 2010 12:13:09 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 6167B3A6BF8 for ; Fri, 30 Apr 2010 12:12:57 -0700 (PDT) Received: (qmail 2158 invoked by uid 0); 30 Apr 2010 19:12:43 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 30 Apr 2010 19:12:43 -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=K1jk1Puhx6nruYnhfk4N7oCPmab9zNLqXaurfHLmUGFyP3lICrvo9MmIPcra0G1uZBfB18EdQ9L1q/LKnhGiKNSNhpnaCfLQeUOhJy3NiP9c3vap7S6fx8Bg1pi4bqbl; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1O7vdj-0004GI-H5; Fri, 30 Apr 2010 13:12:43 -0600 From: "Richard Shockey" To: , "'Lawrence Conroy'" References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk><01b201cae702$35547a00$9ffd6e00$@us><754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com><826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.com><754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> <430FC6BDED356B4C8498F634416644A91A8A5F18F6@mail> <4BDB19CA.7080900@netmagic.com> <4BDB1DE1.5060100@netmagic.com> In-Reply-To: <4BDB1DE1.5060100@netmagic.com> Date: Fri, 30 Apr 2010 15:12:38 -0400 Message-ID: <013101cae899$19bd30f0$4d3792d0$@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: AcrokPn1W4AlDoiESH23SovboTlWAAAB7FjQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: 'Bernie Hoeneisen' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-) 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, 30 Apr 2010 19:13:10 -0000 OMG ... the Handle Vampire is back. Bob Kahn ( yea that TCP Bob Kahn ) his favorite windmill. Tony the answer is of course yes. Bob did the full court press on me 10 years ago to dump DNS and consider Handle for ENUM. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Tony Rutkowski Sent: Friday, April 30, 2010 2:14 PM To: Lawrence Conroy Cc: Bernie Hoeneisen; E.164 To MetaData BOF discussion list Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-) On 4/30/2010 2:05 PM, Lawrence Conroy wrote: > Puzzled minds would ask for a little more context: Handles -- as in four candles? > all the best, > As in http://www.handle.net/ --tony _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From richard@shockey.us Fri Apr 30 12:19:34 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 AA60528C2AD for ; Fri, 30 Apr 2010 12:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_05=-1.11] 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 I5iu8LK8gbCm for ; Fri, 30 Apr 2010 12:19:32 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (oproxy2-pub.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 5744A3A6C23 for ; Fri, 30 Apr 2010 12:19:25 -0700 (PDT) Received: (qmail 2617 invoked by uid 0); 30 Apr 2010 18:19:12 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 30 Apr 2010 18:19:12 -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=io4gSDYvI1f5c+/qRXndaeFTUhoQY8GKach552BvYqSQSDNzZUE02AQbRXV4rXshdBbF4DCbCgLKniMGRpuW1CE+Y39iwthyeGnJEEHq6K2SGkvUhhPIOo9/gBk7sGkL; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1O7vjz-0007ja-B0; Fri, 30 Apr 2010 13:19:11 -0600 From: "Richard Shockey" To: "'Bernie Hoeneisen'" References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk><01b201cae702$35547a00$9ffd6e00$@us><754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com><826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.com><754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> <008001cae87c$84737bb0$8d5a7310$@us> In-Reply-To: Date: Fri, 30 Apr 2010 15:19:06 -0400 Message-ID: <013b01cae89a$00e44d10$02ace730$@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: AcrolTbCPVvhhYGeQd6Kj3DQpa2DUAAA/rIw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-) 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, 30 Apr 2010 19:19:34 -0000 No ..I still don't see a problem. Dump BIND and go with UNBOUND. Have you seen a DNSSEC response? So who are these "people"? I want the names of these people! Why they are not discussing their issues on this list? I'm getting very very tired of "somebody said this somebody said that" 'oh the DNS wonderboys won't accept that'. The discussion is here on this list not in private exchanges between BOF tourists and the BOF co-chairs. -----Original Message----- From: 'Bernie Hoeneisen' [mailto:bernie@ietf.hoeneisen.ch] Sent: Friday, April 30, 2010 2:45 PM To: Richard Shockey Cc: 'PFAUTZ, PENN L (ATTCORP)'; 'E.164 To MetaData BOF discussion list' Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-) Hi Rich I trust you that Telco grade DNS caches as you describe them below can handle long DNS answers without significant problems. But people are rather concerned that loads of long DNS answers harm their (ordinary) DNS caches on the Internet. This concern needs to be addressed one way or the other. cheers, Bernie On Fri, 30 Apr 2010, Richard Shockey wrote: > NO ..ENUM aware and optimized caching servers, in my professional > experience, have not had these issues. Many of them in carrier networks can > now handle up to 400 Million TN's and all the data associated with them > locally with superb response times in multi terabyte memory resident > databases. In private instantiations of ENUM all the data is usually cached > all the time and updated as needed from external data sources like LNP. > Remember these local caches usually contain internal network specific data > as well as data such as Trunk group data that are essential for internal > session routing. > > Any SP that would use BIND for this is just plain nuts. > > Again Ken Cartwright is right. Our knowledge of how this all scales is based > on empirical fact not speculation. > > Want to see fat chubby DNS responses that will clog some networks..try > DNSSEC. > >> >> I may well be missing something but tell me what it is. If there's a >> real problem I won't object to the solution taking other paths. > > You left out DNS caching servers that have also been reported to be > problematic when having big DNS responses. > (Even in the case the TTL is zero, some caching servers in the field will > cache for a minimum time.) > > However, I am not in possession of any figures on how serious this caching > issue might be. > > cheers, > Bernie > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > From trutkowski@netmagic.com Fri Apr 30 12:52:34 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 8EE0D3A6B2C for ; Fri, 30 Apr 2010 12:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] 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 Q64H+89MZA38 for ; Fri, 30 Apr 2010 12:52:33 -0700 (PDT) Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by core3.amsl.com (Postfix) with ESMTP id 6197B3A695A for ; Fri, 30 Apr 2010 12:52:33 -0700 (PDT) Received: from [192.168.0.5] ([unknown] [173.71.223.14]) by vms173001.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L1P008RMGI8Z840@vms173001.mailsrvcs.net> for e2md@ietf.org; Fri, 30 Apr 2010 14:51:44 -0500 (CDT) Message-id: <4BDB34D0.8060208@netmagic.com> Date: Fri, 30 Apr 2010 15:51:44 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100406 Shredder/3.0.4 MIME-version: 1.0 To: Richard Shockey References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk><01b201cae702$35547a00$9ffd6e00$@us><754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com><826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.com><754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> <430FC6BDED356B4C8498F634416644A91A8A5F18F6@mail> <4BDB19CA.7080900@netmagic.com> <4BDB1DE1.5060100@netmagic.com> <013101cae899$19bd30f0$4d3792d0$@us> In-reply-to: <013101cae899$19bd30f0$4d3792d0$@us> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Cc: "'E.164 To MetaData BOF discussion list'" , 'Bernie Hoeneisen' Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-) X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com 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, 30 Apr 2010 19:52:34 -0000 Hi Richard, > OMG ... the Handle Vampire is back. Bob Kahn ( yea that TCP Bob Kahn ) his > favorite windmill. Tony the answer is of course yes. Bob did the full court > press on me 10 years ago to dump DNS and consider Handle for ENUM. > Many of went down that path. What's new is the research out of a CNNIC institute funded by Cisco that suggests significant performance advantages for Handles - especially where security is important. CNNIC even demonstrated a concurrent parallel implementation. May be worth another bite...no pun intended - at least for some applications. --tony From richard@shockey.us Fri Apr 30 14:03:18 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 2C1C13A6833 for ; Fri, 30 Apr 2010 14:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.226 X-Spam-Level: X-Spam-Status: No, score=-1.226 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_05=-1.11] 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 ub1kC86OIjtF for ; Fri, 30 Apr 2010 14:03:17 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (oproxy2-pub.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 2152028C0E0 for ; Fri, 30 Apr 2010 14:03:10 -0700 (PDT) Received: (qmail 18402 invoked by uid 0); 30 Apr 2010 20:02:57 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 30 Apr 2010 20:02:57 -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=DXe7a1w5w5yLEluczGsEmvuPzkcTHO84TXSNkmbPI23LHTi9cFWhf8zzgAeIBxo29qNAGd7QEUjDWk2Khfbppzim+1KtDH5NpmISKzrWMlTx7XTyMlLP2idU8re1tVru; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1O7xMO-0002RC-9C; Fri, 30 Apr 2010 15:02:56 -0600 From: "Richard Shockey" To: References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk><01b201cae702$35547a00$9ffd6e00$@us><754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com><826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.com><754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> <430FC6BDED356B4C8498F634416644A91A8A5F18F6@mail> <4BDB19CA.7080900@netmagic.com> <4BDB1DE1.5060100@netmagic.com> <013101cae899$19bd30f0$4d3792d0$@us> <4BDB34D0.8060208@netmagic.com> In-Reply-To: <4BDB34D0.8060208@netmagic.com> Date: Fri, 30 Apr 2010 17:02:50 -0400 Message-ID: <016b01cae8a8$7f3b4160$7db1c420$@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: AcronpxnKZOuE3QpRJ2BclxI1sZzDAACbL5Q Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: "'E.164 To MetaData BOF discussion list'" , 'Bernie Hoeneisen' Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-) 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, 30 Apr 2010 21:03:18 -0000 Really .. I'm genuinely intrigued. Any URL's? -----Original Message----- From: Tony Rutkowski [mailto:trutkowski@netmagic.com] Sent: Friday, April 30, 2010 3:52 PM To: Richard Shockey Cc: 'Lawrence Conroy'; 'Bernie Hoeneisen'; 'E.164 To MetaData BOF discussion list' Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-) Hi Richard, > OMG ... the Handle Vampire is back. Bob Kahn ( yea that TCP Bob Kahn ) his > favorite windmill. Tony the answer is of course yes. Bob did the full court > press on me 10 years ago to dump DNS and consider Handle for ENUM. > Many of went down that path. What's new is the research out of a CNNIC institute funded by Cisco that suggests significant performance advantages for Handles - especially where security is important. CNNIC even demonstrated a concurrent parallel implementation. May be worth another bite...no pun intended - at least for some applications. --tony From trutkowski@netmagic.com Fri Apr 30 14:16: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 AA59928C2AA for ; Fri, 30 Apr 2010 14:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 roNzajvQcXMk for ; Fri, 30 Apr 2010 14:16:20 -0700 (PDT) Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by core3.amsl.com (Postfix) with ESMTP id 752783A68B9 for ; Fri, 30 Apr 2010 14:16:20 -0700 (PDT) Received: from [192.168.0.5] ([unknown] [173.71.223.14]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L1P00DH2KDOMC60@vms173019.mailsrvcs.net> for e2md@ietf.org; Fri, 30 Apr 2010 16:15:29 -0500 (CDT) Message-id: <4BDB486C.4010608@netmagic.com> Date: Fri, 30 Apr 2010 17:15:24 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100406 Shredder/3.0.4 MIME-version: 1.0 To: Richard Shockey References: <9B0CB843-4359-4F0C-AB00-1A7602306346@insensate.co.uk><01b201cae702$35547a00$9ffd6e00$@us><754963199212404AB8E9CFCA6C3D0CDA24469179A1@TNS-MAIL-NA.win2k.corp.tnsi.com><826F1F96-2970-4AC8-B829-799BB547F62D@softarmor.com><754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> <430FC6BDED356B4C8498F634416644A91A8A5F18F6@mail> <4BDB19CA.7080900@netmagic.com> <4BDB1DE1.5060100@netmagic.com> <013101cae899$19bd30f0$4d3792d0$@us> <4BDB34D0.8060208@netmagic.com> <016b01cae8a8$7f3b4160$7db1c420$@us> In-reply-to: <016b01cae8a8$7f3b4160$7db1c420$@us> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Cc: "'E.164 To MetaData BOF discussion list'" , 'Bernie Hoeneisen' Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-) X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com 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, 30 Apr 2010 21:16:21 -0000 On 4/30/2010 5:02 PM, Richard Shockey wrote: > Really .. I'm genuinely intrigued. Any URL's? > http://hdl.cnnic.cn/ http://middleware.internet2.edu/pki06/proceedings/sun-handle-dns.ppt --tony