From bmanning@karoshi.com Sat May 1 00:12:36 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 1615F3A67B6 for ; Sat, 1 May 2010 00:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.424 X-Spam-Level: X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k9tCjwOeKIf for ; Sat, 1 May 2010 00:12:35 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 334373A6A7C for ; Sat, 1 May 2010 00:12:35 -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 o417BlWU000475; Sat, 1 May 2010 07:11:47 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o417Ba01000474; Sat, 1 May 2010 07:11:36 GMT Date: Sat, 1 May 2010 07:11:36 +0000 From: bmanning@vacation.karoshi.com To: Tony Rutkowski Message-ID: <20100501071136.GA452@vacation.karoshi.com.> References: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BDB34D0.8060208@netmagic.com> User-Agent: Mutt/1.4.1i 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: Sat, 01 May 2010 07:12:36 -0000 On Fri, Apr 30, 2010 at 03:51:44PM -0400, Tony Rutkowski wrote: > 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. pointers to the published research please? (english prefered) --bill > > --tony > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From bmanning@karoshi.com Sat May 1 00:13: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 CE49A3A67B6 for ; Sat, 1 May 2010 00:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.639 X-Spam-Level: X-Spam-Status: No, score=-5.639 tagged_above=-999 required=5 tests=[AWL=0.960, BAYES_00=-2.599, 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 8jw8uyvGAOtO for ; Sat, 1 May 2010 00:13:28 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id B6B933A6783 for ; Sat, 1 May 2010 00:13:28 -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 o417D1WU000486; Sat, 1 May 2010 07:13:01 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o417D1Je000485; Sat, 1 May 2010 07:13:01 GMT Date: Sat, 1 May 2010 07:13:01 +0000 From: bmanning@vacation.karoshi.com To: Tony Rutkowski Message-ID: <20100501071301.GB452@vacation.karoshi.com.> References: <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> <4BDB486C.4010608@netmagic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BDB486C.4010608@netmagic.com> User-Agent: Mutt/1.4.1i 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: Sat, 01 May 2010 07:13:29 -0000 teach me to read to the -end- of the thread first. thanks Tony. --bill On Fri, Apr 30, 2010 at 05:15:24PM -0400, Tony Rutkowski wrote: > 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 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From jim@rfc1035.com Sat May 1 02:52:52 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 258993A6AC5 for ; Sat, 1 May 2010 02:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[AWL=0.199, 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 tvmrIDkar9rY for ; Sat, 1 May 2010 02:52:51 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id 1FB953A6AC7 for ; Sat, 1 May 2010 02:52:45 -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 4B32F15427EB; Sat, 1 May 2010 10:52:28 +0100 (BST) Message-Id: <3764143C-9276-4DD7-8126-FEF5680D20D6@rfc1035.com> From: Jim Reid 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: Sat, 1 May 2010 10:52:28 +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><754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> <008001cae87c$84737bb0$8d5a7310$@us> X-Mailer: Apple Mail (2.936) Cc: "'E.164 To MetaData BOF discussion list'" Subject: [e2md] DNS cache size issues 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, 01 May 2010 09:52:52 -0000 On 30 Apr 2010, at 19:44, Bernie Hoeneisen wrote: > 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. Who has these concerns and on what grounds? I think this is yet more FUD Bernie. Cache size concerns are coupled to RAM prices. Last time I looked 1 GB of RAM was about $30 retail. The only concern for a resolving server will be when DNSSEC validation gets switched on and throughout plummets through the floor, particularly on very busy servers. Even that's a non-issue IMO: just throw commodity hardware at it or maybe some crypto accelerators. And IIUC there aren't any resolving servers (ie caches) inside the architectures where E2MD is likely to be used in anger. From lconroy@insensate.co.uk Sat May 1 03:42:03 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A8DE3A6AD2 for ; Sat, 1 May 2010 03:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.462 X-Spam-Level: X-Spam-Status: No, score=-1.462 tagged_above=-999 required=5 tests=[AWL=1.137, 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 5kEz6MmKr5Rp for ; Sat, 1 May 2010 03:42:02 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 383DE3A6ADD for ; Sat, 1 May 2010 03:42:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 9DC6812FBBD; Sat, 1 May 2010 11:41:45 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <3764143C-9276-4DD7-8126-FEF5680D20D6@rfc1035.com> Date: Sat, 1 May 2010 11:41:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9BD24470-316D-424D-A84D-4BFBBE606BE3@insensate.co.uk> 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> <3764143C-9276-4DD7-8126-FEF5680D20D6@rfc1035.com> To: Jim Reid X-Mailer: Apple Mail (2.1078) Cc: Bernie Hoeneisen , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] DNS cache size issues 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, 01 May 2010 10:42:03 -0000 Hi Jim, folks, Slight clarification: there aren't any *broken* resolving servers (i.e. = caches) inside the architectures where E2MD is likely to be used in = anger. If there ARE any badly broken resolvers out there on the wild interweb, = they're going to have fun with DNSSEC. atb, Lawrence On 1 May 2010, at 10:52, Jim Reid wrote: > And IIUC there aren't any resolving servers (ie caches) inside the = architectures where E2MD is likely to be used in anger. From jim@rfc1035.com Sat May 1 04:40: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 5C7DD3A67AC for ; Sat, 1 May 2010 04:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[AWL=1.392, 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 xr3dpjn69qLf for ; Sat, 1 May 2010 04:40:11 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id E2AAD3A691C for ; Sat, 1 May 2010 04:40:10 -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 9C56815427EB; Sat, 1 May 2010 12:39:54 +0100 (BST) Message-Id: <2E7082F0-348D-43D9-8126-8BD0EE2D02BF@rfc1035.com> From: Jim Reid To: Lawrence Conroy In-Reply-To: <9BD24470-316D-424D-A84D-4BFBBE606BE3@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: Sat, 1 May 2010 12:39:54 +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><754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> <008001cae87c$84737bb0$8d5a7310$@us> <3764143C-9276-4DD7-8126-FEF5680D20D6@rfc1035.com> <9BD24470-316D-424D-A84D-4BFBBE606BE3@insensate.co.uk> X-Mailer: Apple Mail (2.936) Cc: Bernie Hoeneisen , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] DNS cache size issues 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, 01 May 2010 11:40:12 -0000 On 1 May 2010, at 11:41, Lawrence Conroy wrote: > Slight clarification: there aren't any *broken* resolving servers > (i.e. caches) inside the architectures where E2MD is likely to be > used in anger. OK. > If there ARE any badly broken resolvers out there on the wild > interweb, they're going to have fun with DNSSEC. Not necessarily. There are badly broken resolvers out there. They don't seem to be breaking (well breaking any more than usual) as DNSSEC roll-out continues. Famous last words... We'll know for sure next week. There will only be 1 root server (A) with the unsigned root zone from Thursday. So if there's a spike in strange traffic -- too many TCP priming queries, too many repeated priming queries, etc -- at A after that point... From dean.willis@softarmor.com Mon May 3 08:03: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 70FDD28C1FE for ; Mon, 3 May 2010 08:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.341 X-Spam-Level: X-Spam-Status: No, score=-0.341 tagged_above=-999 required=5 tests=[AWL=-1.542, 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 Dqqh-dbb4uK1 for ; Mon, 3 May 2010 08:03:03 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 3911128C1F8 for ; Mon, 3 May 2010 08:03:00 -0700 (PDT) Received: from [192.168.2.105] (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 o43F2XPk025866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 May 2010 10:02:40 -0500 Message-Id: <084C28EF-C3BD-4EB0-89FE-784B76CC7499@softarmor.com> From: Dean Willis To: Lawrence Conroy In-Reply-To: <3E216B8F-62B4-4D8E-AF97-2BF2B22DC8B1@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: Mon, 3 May 2010 10:02:27 -0500 References: <3E216B8F-62B4-4D8E-AF97-2BF2B22DC8B1@insensate.co.uk> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" 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: Mon, 03 May 2010 15:03:04 -0000 On Apr 30, 2010, at 4:12 AM, Lawrence Conroy wrote: > 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, I hope I was only channeling a dozen or so . . . if there's 20 of these guys out there, we're going to need to bring more of our own people! > 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. The difference, according to some greybeards, is that Having an RFC That Defines Lots Of Resource Records somehow says to people that using lots of resource records is OK. Sure, you can do crazy stuff now, but there aren't quite so many officially published guidelines that appear to be encouraging you to do it. It's like the argument that while any chemistry student can figure out how to nitrate glycerine, not too many preschoolers try it. But if we published comic books on the procedure, kids are likely to skip the "add LOTS of ice" step and blow themselves up. We might be able to ameliorate this argument by having strong guidelines on how NOT to use the specification incorporated into it. > > 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. Also quite true. I've noted that some of the greybeards seem to be pretty much fundamentally offended by the existence of ENUM. I'm not sure there's a lot we can do about this. But they don't come straight out and attack ENUM directly; rather they slip in their arguments about ENUM with respect to any other uses of the ENUM approach, as they think this helps Contain the Evil. I don't have a good solution for dealing with this strategy. It may be that the best approach is a head-on confrontation that puts the central question on the table: Is ENUM too broken to use? If not, then this is no worse, and they need to get off their soapbox. Risk: We get a community consensus that ENUM is in fact too broken to use. I can't estimate the risk of this, but it is greater than zero. > 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. > What I seemed to be hearing from some of the greybeards was that while it's "supposed to work this way", in practice it doesn't. If they're throwing fud, can we respond with peer-reviewed evidence? Do we have any nice research papers showing measurements of this sort of usage and giving "proof" that TCP fallback is working? > - 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). Well, that's true "now". But if we start doing requester-specific DNS responses (which people are talking about, example Hadriel's draft) instead of just pasting the memory-cached records into the response, then it is likely to increase the computational load on the Auth DNS server dramatically. So we perhaps need to be careful about this one. -- Dean From jim@rfc1035.com Mon May 3 08:30: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 C1A7D28C21D for ; Mon, 3 May 2010 08:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.499 X-Spam-Level: * X-Spam-Status: No, score=1.499 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_DYNAMIC_DHCP=1.398, RDNS_DYNAMIC=0.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 tfWSfLXj1RYI for ; Mon, 3 May 2010 08:30:52 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by core3.amsl.com (Postfix) with ESMTP id 03DC528C228 for ; Mon, 3 May 2010 08:30:51 -0700 (PDT) Received: from dhcp-25-210.ripemtg.ripe.net (dhcp-25-210.ripemtg.ripe.net [193.0.25.210]) by shaun.rfc1035.com (Postfix) with ESMTP id 532A6CBC425; Mon, 3 May 2010 16:30:35 +0100 (BST) Message-Id: <518AAE54-B04C-4FAF-91B3-857261F9740C@rfc1035.com> From: Jim Reid To: Dean Willis In-Reply-To: <084C28EF-C3BD-4EB0-89FE-784B76CC7499@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: Mon, 3 May 2010 16:30:34 +0100 References: <3E216B8F-62B4-4D8E-AF97-2BF2B22DC8B1@insensate.co.uk> <084C28EF-C3BD-4EB0-89FE-784B76CC7499@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" 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: Mon, 03 May 2010 15:30:53 -0000 On 3 May 2010, at 16:02, Dean Willis wrote: > The difference, according to some greybeards, is that Having an RFC > That Defines Lots Of Resource Records somehow says to people that > using lots of resource records is OK. WTF? We're not supposed to put data in the DNS because some clueless bozo might put "too many" RRs? This is beyond FUD. What next? Don't use IP because you might send too many packets? Or don't buy a computer because you'll burn too many CPU cycles and spend too much money on software? > Sure, you can do crazy stuff now, but there aren't quite so many > officially published guidelines that appear to be encouraging you to > do it. And there's nothing in this e2md discussion which suggests doing crazy stuff either. At least nothing yet, > It's like the argument that while any chemistry student can figure > out how to nitrate glycerine, not too many preschoolers try it. But > if we published comic books on the procedure, kids are likely to > skip the "add LOTS of ice" step and blow themselves up. So let them. We're all supposed to be adults here and responsible for our own actions. I don't see why anyone can argue DNS has to be a special case. There's no other RFC or protocol spec that says "if you do stupid shit or add too much data, Bad Things will happen". So insisting e2md does this is unreasonable. > We might be able to ameliorate this argument by having strong > guidelines on how NOT to use the specification incorporated into it. This is asking to prove a negative and quite unreasonable Dean. Should the spec say "here's not how to (ab)use the scheme to disprove the existence of the Loch Ness monster"? It would be much more sensible and practical to provide guidelines on the recommended/likely use cases wrt to numbers of RRs, packet sizes and so on. > Also quite true. I've noted that some of the greybeards seem to be > pretty much fundamentally offended by the existence of ENUM. Tough. That ship has sailed. These anonymous greybeards just have to get over it. Life sucks sometimes. > I'm not sure there's a lot we can do about this. But they don't come > straight out and attack ENUM directly; rather they slip in their > arguments about ENUM with respect to any other uses of the ENUM > approach, as they think this helps Contain the Evil. > > I don't have a good solution for dealing with this strategy. I would hope rational argument and common sense will do the job. Get some hard data based on actual use cases and requirements. Show why the ENUM-like NAPTR approach works best (or least-worst). List the other options that were considered and explain why they were rejected. So if anyone pushes back, they won't be doing so from grounds that have a valid basis in engineering or operations. From dean.willis@softarmor.com Mon May 3 09:00: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 A8F6C3A6939 for ; Mon, 3 May 2010 09:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[AWL=-1.212, BAYES_50=0.001, J_CHICKENPOX_21=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 3aoJhBoi2oqY for ; Mon, 3 May 2010 09:00:31 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8785E28C27C for ; Mon, 3 May 2010 09:00:24 -0700 (PDT) Received: from [192.168.2.105] (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 o43FxTNn026512 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 May 2010 10:59:47 -0500 Message-Id: From: Dean Willis To: Jim Reid 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: Mon, 3 May 2010 10:59:22 -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> 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: Mon, 03 May 2010 16:00:32 -0000 On Apr 30, 2010, at 4:55 AM, Jim Reid wrote: > 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? I believe the argument about lack of specificity in the query mechanism of DNS was raised by both John Klensin and Dave Crocker. Crocker, in particular, took us to task during the BOF for not having considered an _prefix model for selective queries. In a side conversation I had with him, Klensin seemed to be concerned that we really NEEDED a database query language sort of expressivity here, while insistent that the DNS was not the right place to be doing database queries. Peter Koch and Olaf Kolkmann also spent a fair bit of time at the mic during the BOF. Also, we spent a rather large amount of pre-meeting time with the less- bearded Jon Peterson chewing on the loose ends of the spec. He seemed to be most concerned about the open-endedness of the framework model. If we were adding one type of metadata per standards-track RFC, he might be less concerned. But perhaps he's merely maneuvering us into a path that gives him better tools for obstructing the work, because it;s fairly easy to hold up a standards-track document . > > 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. RIght. But if the data were structured differently (as per using an _prefix to make a new node for a specific datum), then the responses won't be so chubby. To me, it comes back to the question of whether or not one needs all that data at the same time. For example, when routing an outgoing call, one really needs all the NAPTR records for that routing process. But when one is receiving a call and only needs is the calling-name, why should we also send all the records that would be used to route the call? Would it be reasonable for us to differentiate between bits of metadata based on when in the process that metadata gets used, and perhaps use this differentiation to break the data up into different nodes? > > 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. What about the impact of that middle ground of "larger than one packet" UDP responses? EDNS0 (RFC 2716, 4.5) would appear to allow for some hefty datagrams before truncation, and those make the transport people nervous. Would it be reasonable for E2MD to suggest a max datagram size of 1280? > > 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. OK, that's a good proposal. I think something like it is really going to be required for E2MD to succeed. -- Dean From dean.willis@softarmor.com Mon May 3 09:24: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 296103A6A0A for ; Mon, 3 May 2010 09:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[AWL=-0.890, 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 3V7ynCM-vVpb for ; Mon, 3 May 2010 09:24:03 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C2DD23A6A44 for ; Mon, 3 May 2010 09:24:02 -0700 (PDT) Received: from [192.168.2.105] (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 o43GNI5D026710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 May 2010 11:23:30 -0500 Message-Id: <6D340A54-7DEC-4935-85D6-A2E0A5A72EBD@softarmor.com> From: Dean Willis To: Richard Shockey In-Reply-To: <005501cae865$14e20c60$3ea62520$@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: Mon, 3 May 2010 11:23:11 -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> <005501cae865$14e20c60$3ea62520$@us> 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: Mon, 03 May 2010 16:24:04 -0000 On Apr 30, 2010, at 8:00 AM, Richard Shockey wrote: > Dean ... just where are you getting your data points? You are making > wild > statements that have no basis in actual deployed fact. > From the people that were beating us up in and out of meetings at IETF 77. > -----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. If we have an open-ended framework for defining metadata, and a generic RR format for putting that metadata into, then it's certainly not outside the realm of possibility for somebody somewhere to decide that it's a Good Idea to have 200 RRs. That "somebody somewhere" might even include another SDO. It's no crazier than some of the things the mobile-phone SDOs have done. Consequently, there are people who believe that open-ended frameworks with loose registration policies for this sort of thing are inappropriate, and it's better to get community consensus for each new use-case. >> ... > > 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? A bunch of people who see themselves as the guardians of the Internet and its operational principles, specifically around congestion control. I don't suppose you've noticed, but its pretty much impossible to get any new UDP application past Transport these days, and has been for a long time. >> (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 ones I talked to seemed to understand, at least to the limits of my (admittedly limited) ability to tell. > >> 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. I don't disagree. There are, however, people who don't much like 3761, and they're part of the community that's sending up flak. We have to deal with them one way or another. Maybe just shouting louder will work eventually, but it gives me a headache. -- Dean From dean.willis@softarmor.com Mon May 3 09:31: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 3E19A3A6A0A for ; Mon, 3 May 2010 09:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.873 X-Spam-Level: X-Spam-Status: No, score=-0.873 tagged_above=-999 required=5 tests=[AWL=-0.874, 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 4Tv67BQoUZ20 for ; Mon, 3 May 2010 09:31:29 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B1B8F3A69CE for ; Mon, 3 May 2010 09:31:29 -0700 (PDT) Received: from [192.168.2.105] (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 o43GUlTl026793 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 May 2010 11:30:57 -0500 Message-Id: From: Dean Willis To: "PFAUTZ, PENN L (ATTCORP)" In-Reply-To: <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.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: Mon, 3 May 2010 11:30:41 -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> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> X-Mailer: Apple Mail (2.936) 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: Mon, 03 May 2010 16:31:31 -0000 On Apr 30, 2010, at 9:42 AM, 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. 3. That innocent intermediate nodes, not designed for the load, will gag. Envision a user on an enterprise network that runs a DNS-relay firewall. Said user runs an app that makes an E2MD query, and the enterprise firewall falls over. The owner of the queried domain involved might not care that much, but it's certainly going to annoy the corp IT guy. 4). That other traffic on the network links will be impacted by large UDP datagrams that fall somewhere between the path-MTU and the configured upper-limit of the EDNS0 nodes involved, which might well approach 64k before they start truncating and falling-back to TCP. -- Dean From dean.willis@softarmor.com Mon May 3 09:37: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 6081B3A69B9 for ; Mon, 3 May 2010 09:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.857 X-Spam-Level: X-Spam-Status: No, score=-0.857 tagged_above=-999 required=5 tests=[AWL=-0.858, 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 S1zaGvOSyyAK for ; Mon, 3 May 2010 09:37:32 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id CA7363A6A3B for ; Mon, 3 May 2010 09:37:23 -0700 (PDT) Received: from [192.168.2.105] (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 o43GafwW026870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 May 2010 11:36:51 -0500 Message-Id: <5372C024-BF14-4A0F-AFCB-6BBDA3300436@softarmor.com> From: Dean Willis To: Richard Shockey In-Reply-To: <008001cae87c$84737bb0$8d5a7310$@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: Mon, 3 May 2010 11:36:34 -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> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> <008001cae87c$84737bb0$8d5a7310$@us> X-Mailer: Apple Mail (2.936) 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: Mon, 03 May 2010 16:37:33 -0000 On Apr 30, 2010, at 10:47 AM, 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. But that's just the problem. The corporate firewall is probably not an ENUM aware and optimized caching server. It's probably something hacked together by two graduate students using a codebase derived from BIND-2 that's been ported to an embedded operating system. I know you think that E2MD will only be used in private networks, but unless the specifications clearly say "ONLY FOR USE IN PRIVATE NETWORKS THAT ARE DESIGNED FOR ENUM" (and maybe even then) somebody is likely to innocently build an application that runs on "the real Internet" and there will be great surprise and dismay when things start breaking. > > 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. It's based on empirical fact in closed networks carefully managed by experts to work well with ENUM. Where ENUM is used "on the Internet" today, it has quite small RRsets; typically one record per node. > > Want to see fat chubby DNS responses that will clog some networks..try > DNSSEC. Point! I'm still waiting to see DNSSEC in the wild. -- Dean From dean.willis@softarmor.com Mon May 3 09:45: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 63FB328C23F for ; Mon, 3 May 2010 09:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.842 X-Spam-Level: X-Spam-Status: No, score=-0.842 tagged_above=-999 required=5 tests=[AWL=-0.843, 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 iG2Q37NApNrB for ; Mon, 3 May 2010 09:45:07 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 812EF28C22C for ; Mon, 3 May 2010 09:45:07 -0700 (PDT) Received: from [192.168.2.105] (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 o43GiPlk026987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 May 2010 11:44:37 -0500 Message-Id: <28F8B3F9-1F8A-480B-A8F7-9246DCC193B2@softarmor.com> From: Dean Willis To: Jim Reid In-Reply-To: <3764143C-9276-4DD7-8126-FEF5680D20D6@rfc1035.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: Mon, 3 May 2010 11:44:18 -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> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> <008001cae87c$84737bb0$8d5a7310$@us> <3764143C-9276-4DD7-8126-FEF5680D20D6@rfc1035.com> X-Mailer: Apple Mail (2.936) Cc: Bernie Hoeneisen , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] DNS cache size issues 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, 03 May 2010 16:45:08 -0000 On May 1, 2010, at 4:52 AM, Jim Reid wrote: > On 30 Apr 2010, at 19:44, Bernie Hoeneisen wrote: > >> 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. > > Who has these concerns and on what grounds? I think this is yet more > FUD Bernie. Cache size concerns are coupled to RAM prices. Last time > I looked 1 GB of RAM was about $30 retail. Some of the DNS relays out there don't cost $30. I think the one that runs my office cost $19.95... > > The only concern for a resolving server will be when DNSSEC > validation gets switched on and throughout plummets through the > floor, particularly on very busy servers. Even that's a non-issue > IMO: just throw commodity hardware at it or maybe some crypto > accelerators. And IIUC there aren't any resolving servers (ie > caches) inside the architectures where E2MD is likely to be used in > anger. You're still saying that E2MD isn't going to be used on the open Internet, just in specially-walled gardens. That might be true. If it is, then making a strong case for it being that way in the specification might help. It'll also draw fire from people who think we have no business inventing a walled-garden protocol in the IETF, but that's a different issue. -- Dean From richard@shockey.us Mon May 3 09:57: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 B5E423A6A1F for ; Mon, 3 May 2010 09:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.666 X-Spam-Level: X-Spam-Status: No, score=-0.666 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 KC2VV8we2xfr for ; Mon, 3 May 2010 09:57:23 -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 AF4DD28C24C for ; Mon, 3 May 2010 09:57:22 -0700 (PDT) Received: (qmail 10467 invoked by uid 0); 3 May 2010 16:57:07 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 3 May 2010 16:57:07 -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=ixDlmbueye7ea0V6mMPdxgNmJ8Vv10oGbvPSWa8wvilwY1+KxOqw+zFicUey/f1gsmgglBy8Pfg/WSWUydKVO7yvRvBJpB3zesitfbmquzSKz5pZcyh3EbATqqCWY1L2; 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 1O8yx8-0006VW-SO; Mon, 03 May 2010 10:57:07 -0600 From: "Richard Shockey" To: "'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><754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> <008001cae87c$84737bb0$8d5a7310$@us> <5372C024-BF14-4A0F-AFCB-6BBDA3300436@softarmor.com> In-Reply-To: <5372C024-BF14-4A0F-AFCB-6BBDA3300436@softarmor.com> Date: Mon, 3 May 2010 12:57:01 -0400 Message-ID: <006401caeae1$a7143120$f53c9360$@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: Acrq3uDhsvouu4QpQGKGbkUpHmRbMAAASvlw 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: Mon, 03 May 2010 16:57:24 -0000 > 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. But that's just the problem. The corporate firewall is probably not an ENUM aware and optimized caching server. It's probably something hacked together by two graduate students using a codebase derived from BIND-2 that's been ported to an embedded operating system. I know you think that E2MD will only be used in private networks, but unless the specifications clearly say "ONLY FOR USE IN PRIVATE NETWORKS THAT ARE DESIGNED FOR ENUM" (and maybe even then) somebody is likely to innocently build an application that runs on "the real Internet" and there will be great surprise and dismay when things start breaking. RS> I did not say E2MD will ONLY be used in private networks. Only that is clearly one of the strongest use cases and where nearly all of the existing applications are. You are arguing for a negative. There is no empirical evidence that even if this technique were used on the "real Internet" it would break anything. As for the problems that some in the IETF have with ENUM in general...tough. That was a political issue not a technical one. I can appreciate the frustration some have had with the deployment of e164.arpa but its irrelevant to this discussion. We need an application that does number translations. > > 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. It's based on empirical fact in closed networks carefully managed by experts to work well with ENUM. Where ENUM is used "on the Internet" today, it has quite small RRsets; typically one record per node. > > Want to see fat chubby DNS responses that will clog some networks..try > DNSSEC. Point! I'm still waiting to see DNSSEC in the wild. -- Dean From pp3129@att.com Mon May 3 09:58: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 41A2C28C25C for ; Mon, 3 May 2010 09:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.421 X-Spam-Level: X-Spam-Status: No, score=-105.421 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_05=-1.11, 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 3GMtuYFkojoU for ; Mon, 3 May 2010 09:58:13 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id F11B828C257 for ; Mon, 3 May 2010 09:58:10 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-15.tower-121.messagelabs.com!1272905875!36274717!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 22984 invoked from network); 3 May 2010 16:57:55 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-15.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2010 16:57:55 -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 o43GvcCM000404 for ; Mon, 3 May 2010 12:57:38 -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 o43GvWgI032750 for ; Mon, 3 May 2010 12:57:33 -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: Mon, 3 May 2010 12:57:48 -0400 Message-ID: <35FE871E2B085542A35726420E29DA6B03E2EA73@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [e2md] the 200 RR of Bartholemew Cubbins :-) Thread-Index: Acrq3hIFMzdxZS7OQneCkF5Q2JW85wAAkjaQ 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> From: "PFAUTZ, PENN L (ATTCORP)" To: "Dean Willis" 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: Mon, 03 May 2010 16:58:14 -0000 Dean: Thanks for the clarification. If I understand, e2md is not breaking DNS per se but some other stuff along the query response path. While I still think rational self-interest on the part of those owning the domain name would tend to restrict this, we certainly know that rational self-interest doesn't always happen. That being said and acknowledging the possibility of a problem, I'm not sure why we can't have a working group but one specifically tasked with, among other things, addressing the potential problem. I was only listening in remotely but kind of got the feeling that we were being told we couldn't have a WG until we arrived at a conclusion about the solution to the problem.=20 Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Monday, May 03, 2010 12:31 PM To: PFAUTZ, PENN L (ATTCORP) Cc: Richard Shockey; Cartwright, Kenneth; Bernie Hoeneisen; E.164 To MetaData BOF discussion list Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-) On Apr 30, 2010, at 9:42 AM, PFAUTZ, PENN L (ATTCORP) wrote: > Let me see if I'm thinking about this right - the concern is that =20 > 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 =20 > 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. 3. That innocent intermediate nodes, not designed for the load, will =20 gag. Envision a user on an enterprise network that runs a DNS-relay =20 firewall. Said user runs an app that makes an E2MD query, and the =20 enterprise firewall falls over. The owner of the queried domain =20 involved might not care that much, but it's certainly going to annoy =20 the corp IT guy. 4). That other traffic on the network links will be impacted by large =20 UDP datagrams that fall somewhere between the path-MTU and the =20 configured upper-limit of the EDNS0 nodes involved, which might well =20 approach 64k before they start truncating and falling-back to TCP. -- Dean From dean.willis@softarmor.com Mon May 3 10:00: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 CD6B228C258 for ; Mon, 3 May 2010 10:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.828 X-Spam-Level: X-Spam-Status: No, score=-0.828 tagged_above=-999 required=5 tests=[AWL=-0.829, 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 8bUAML3iAYni for ; Mon, 3 May 2010 10:00:24 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C51243A6A4B for ; Mon, 3 May 2010 10:00:24 -0700 (PDT) Received: from [192.168.2.105] (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 o43Gxn0a027118 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 May 2010 12:00:03 -0500 Message-Id: From: Dean Willis To: Jim Reid In-Reply-To: <518AAE54-B04C-4FAF-91B3-857261F9740C@rfc1035.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: Mon, 3 May 2010 11:59:43 -0500 References: <3E216B8F-62B4-4D8E-AF97-2BF2B22DC8B1@insensate.co.uk> <084C28EF-C3BD-4EB0-89FE-784B76CC7499@softarmor.com> <518AAE54-B04C-4FAF-91B3-857261F9740C@rfc1035.com> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" 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: Mon, 03 May 2010 17:00:25 -0000 On May 3, 2010, at 10:30 AM, Jim Reid wrote: > On 3 May 2010, at 16:02, Dean Willis wrote: > >> The difference, according to some greybeards, is that Having an RFC >> That Defines Lots Of Resource Records somehow says to people that >> using lots of resource records is OK. > > WTF? We're not supposed to put data in the DNS because some clueless > bozo might put "too many" RRs? This is beyond FUD. What next? Don't > use IP because you might send too many packets? Or don't buy a > computer because you'll burn too many CPU cycles and spend too much > money on software? If we define an easy way for people to extend a protocol, experiences shows us people will use that easy way, and often use it in an ill- advised manner. In response to this, some people (notably Jon Peterson in this debate) seem to favor requiring a standards-track effort for each new extension > >> Sure, you can do crazy stuff now, but there aren't quite so many >> officially published guidelines that appear to be encouraging you >> to do it. > > And there's nothing in this e2md discussion which suggests doing > crazy stuff either. At least nothing yet, I seem to recall David Schwartz popping up with a bunch of new use cases during ITF 77. I think the number I heard was "At least 50." > >> It's like the argument that while any chemistry student can figure >> out how to nitrate glycerine, not too many preschoolers try it. But >> if we published comic books on the procedure, kids are likely to >> skip the "add LOTS of ice" step and blow themselves up. > > So let them. We're all supposed to be adults here and responsible > for our own actions. I don't see why anyone can argue DNS has to be > a special case. There's no other RFC or protocol spec that says "if > you do stupid shit or add too much data, Bad Things will happen". So > insisting e2md does this is unreasonable. Actually, caveats on extensibility are pretty common in protocol specifications. I can give you some pretty good examples from the SIP world. Originally, all SIP extension headers required standards-track work. RFC 3427 relaxed this and allowed informational documents to define a special class of extension header fields called "P-headers". Almost immediately, 3GPP starting writing up P-header info-RFCs, most of which have turned out either to be specification/interop nightmares, or absolutely critical standards that should have been Standards Track all along. Another corollary is the SIP INFO method, When first specified, it provided an unbounded range of message communication between two SIP UAs. As long as the two UAs in question knew what they were doing with it, they could stick any MIME payload type in an INFO and send it using SIP. Chaos ensued, and there are people who have been working for years to clean it up. Yet again with SIP: the MESSAGE method. Originally envisioned for sending instant messages (eg, texts) between users, it immediately swelled up with big payloads (often over UDP and started killing both servers and networks. So another protocol, MSRP, was introduced along with a replacement architecture. Incidentally, this is pretty much like putting a metadata pointer into the DNS, then using some other protocol to get the actual metadata. > >> We might be able to ameliorate this argument by having strong >> guidelines on how NOT to use the specification incorporated into it. > > This is asking to prove a negative and quite unreasonable Dean. > Should the spec say "here's not how to (ab)use the scheme to > disprove the existence of the Loch Ness monster"? It would be much > more sensible and practical to provide guidelines on the recommended/ > likely use cases wrt to numbers of RRs, packet sizes and so on. Ok, I can see that. > >> Also quite true. I've noted that some of the greybeards seem to be >> pretty much fundamentally offended by the existence of ENUM. > > Tough. That ship has sailed. These anonymous greybeards just have to > get over it. Life sucks sometimes. > >> I'm not sure there's a lot we can do about this. But they don't >> come straight out and attack ENUM directly; rather they slip in >> their arguments about ENUM with respect to any other uses of the >> ENUM approach, as they think this helps Contain the Evil. >> >> I don't have a good solution for dealing with this strategy. > > I would hope rational argument and common sense will do the job. Then we're going to need some of both ;-). > > Get some hard data based on actual use cases and requirements. Show > why the ENUM-like NAPTR approach works best (or least-worst). List > the other options that were considered and explain why they were > rejected. So if anyone pushes back, they won't be doing so from > grounds that have a valid basis in engineering or operations. > Excellent suggestion! -- Dean From richard@shockey.us Mon May 3 10:09:54 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 3153C3A6A70 for ; Mon, 3 May 2010 10:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.643 X-Spam-Level: X-Spam-Status: No, score=-0.643 tagged_above=-999 required=5 tests=[AWL=-0.644, 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 cnm+3F9Nyu9R for ; Mon, 3 May 2010 10:09:52 -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 EEC943A6A6C for ; Mon, 3 May 2010 10:09:17 -0700 (PDT) Received: (qmail 28621 invoked by uid 0); 3 May 2010 17:09:04 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 3 May 2010 17:09:04 -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=bu+BuMKNju+rKJQ5OIfoW7s9KkCKeA+JwK2lbb8IKXUne5xw8LLHMBHiib4fPIDLQsRRnnj1+msGGOhr8iM2ARWLU4RgBoSXZgUrigIM+EIUfhcVjenaU5OELw7WEYo5; 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 1O8z8h-0005JH-LY; Mon, 03 May 2010 11:09:03 -0600 From: "Richard Shockey" To: "'Dean Willis'" , "'Jim Reid'" 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: Mon, 3 May 2010 13:08:57 -0400 Message-ID: <006501caeae3$5248f7f0$f6dae7d0$@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: Acrq2buetJOTuuDRROmLUpuUv72jfAACCfag 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: Mon, 03 May 2010 17:09:54 -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? I believe the argument about lack of specificity in the query mechanism of DNS was raised by both John Klensin and Dave Crocker. Crocker, in particular, took us to task during the BOF for not having considered an _prefix model for selective queries. In a side conversation I had with him, Klensin seemed to be concerned that we really NEEDED a database query language sort of expressivity here, while insistent that the DNS was not the right place to be doing database queries. RS> What is the DNS if not a distributed database that you query against? Peter Koch and Olaf Kolkmann also spent a fair bit of time at the mic during the BOF. > > 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. RIght. But if the data were structured differently (as per using an _prefix to make a new node for a specific datum), then the responses won't be so chubby. To me, it comes back to the question of whether or not one needs all that data at the same time. For example, when routing an outgoing call, one really needs all the NAPTR records for that routing process. But when one is receiving a call and only needs is the calling-name, why should we also send all the records that would be used to route the call? RS> So what? Have you noticed how many E2U definitions we have now? http://www.iana.org/assignments/enum-services RS> Dean this is a old argument us ENUM greybeards have had for years. You get back all the records from the query and then sort. End of story. Would it be reasonable for us to differentiate between bits of metadata based on when in the process that metadata gets used, and perhaps use this differentiation to break the data up into different nodes? RS> NO. > > 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. What about the impact of that middle ground of "larger than one packet" UDP responses? EDNS0 (RFC 2716, 4.5) would appear to allow for some hefty datagrams before truncation, and those make the transport people nervous. Would it be reasonable for E2MD to suggest a max datagram size of 1280? RS> you can make all the recommendations you want but understand that they will be promptly ignored in the field. > > 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. OK, that's a good proposal. I think something like it is really going to be required for E2MD to succeed. RS> We need some clarity here, sooner rather than later. If it clear that all we are going to get is a bunch of FUD from some IETF quarters and we end up having to reinvent DNS code here than it makes no sense to continue this elliptical conversation. We cant continue to argue with Peter, John K, Peterson etal if they choose not to participate on this list. Having you essentially acting as a proxy for them is not productive. -- Dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From dean.willis@softarmor.com Mon May 3 10:11: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 66F6B3A6A5E for ; Mon, 3 May 2010 10:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.814 X-Spam-Level: X-Spam-Status: No, score=-0.814 tagged_above=-999 required=5 tests=[AWL=-0.815, 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 Yn1g2+zirRrn for ; Mon, 3 May 2010 10:11:26 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2CF733A68BE for ; Mon, 3 May 2010 10:11:15 -0700 (PDT) Received: from [192.168.2.105] (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 o43HAfG6027262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 May 2010 12:10:54 -0500 Message-Id: <747E8988-E62E-4B61-9CFB-56904C637BA9@softarmor.com> From: Dean Willis To: "PFAUTZ, PENN L (ATTCORP)" In-Reply-To: <35FE871E2B085542A35726420E29DA6B03E2EA73@gaalpa1msgusr7a.ugd.att.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: Mon, 3 May 2010 12:10:34 -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> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> <35FE871E2B085542A35726420E29DA6B03E2EA73@gaalpa1msgusr7a.ugd.att.com> X-Mailer: Apple Mail (2.936) 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: Mon, 03 May 2010 17:11:32 -0000 On May 3, 2010, at 11:57 AM, PFAUTZ, PENN L (ATTCORP) wrote: > Dean: > Thanks for the clarification. If I understand, e2md is not breaking > DNS > per se but some other stuff along the query response path. > While I still think rational self-interest on the part of those owning > the domain name would tend to restrict this, we certainly know that > rational self-interest doesn't always happen. > That being said and acknowledging the possibility of a problem, I'm > not > sure why we can't have a working group but one specifically tasked > with, > among other things, addressing the potential problem. I was only > listening in remotely but kind of got the feeling that we were being > told we couldn't have a WG until we arrived at a conclusion about the > solution to the problem. Excellent point. I'm thinking it's more along the lines of "we can't have a working group that refuses to acknowledge that the problem even exists, and based on this is not only going to ignore said problem, but has predetermined to adopt an architecture that is likely to cause said problem to manifest in the most direct and immediate way." Coming back with a charter proposal that includes investigating the problem space, developing (and getting consensus on) requirements, analyzing existing protocols (like enum) as potential solutions against those requirements, and then developing a solution (ostensibly re-using as much existing specification as possible) is more likely to get a working group established. But it doesn't meet the goal that I hear Richard and others driving at, which is to, in the shortest possible time (preferably within 90 days) and the fewest possible changes (almost none) extend ENUM to deliver metadata as NAPTR records. The two approaches are pretty much diametrically opposed. -- Dean From dean.willis@softarmor.com Mon May 3 10:30: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 B4B163A686A for ; Mon, 3 May 2010 10:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[AWL=-1.101, BAYES_50=0.001, J_CHICKENPOX_41=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 pypYF4zV39+k for ; Mon, 3 May 2010 10:30:42 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1ABB63A67C2 for ; Mon, 3 May 2010 10:30:42 -0700 (PDT) Received: from [192.168.2.105] (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 o43HTvUk027487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 May 2010 12:30:13 -0500 Message-Id: From: Dean Willis To: "Richard Shockey" In-Reply-To: <006501caeae3$5248f7f0$f6dae7d0$@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: Mon, 3 May 2010 12:29:50 -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> <006501caeae3$5248f7f0$f6dae7d0$@us> X-Mailer: Apple Mail (2.936) Cc: "'E.164 To MetaData BOF discussion list'" , 'Bernie Hoeneisen' 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: Mon, 03 May 2010 17:30:43 -0000 > > I believe the argument about lack of specificity in the query > mechanism of DNS was raised by both John Klensin and Dave Crocker. > Crocker, in particular, took us to task during the BOF for not having > considered an _prefix model for selective queries. In a side > conversation I had with him, Klensin seemed to be concerned that we > really NEEDED a database query language sort of expressivity here, > while insistent that the DNS was not the right place to be doing > database queries. > > > RS> What is the DNS if not a distributed database that you query > against? > It's a fairly limited kind of database, in that its "query language" is restricted to node name (a master key) and node type (a subkey). That is, a combination of name and type explicitly indicates a database record set, what we might call a "node" in DNS. A query returns all the resource records at a given node. ENUM extended the query language with the "type+subtype" model. But it's important to note that this extension happens at the client end, not the server. The server still returns all the resource records at the node, then the client filters out the queried subtype and discards the resource records that aren't interesting. From a database point of view, this is a Really Ugly Hack. It's much cleaner to have the server process the subkey, so that the result set is smaller. However, the approach used by ENUM works nicely for ENUM in that its not unusual for the whole result-set to be "interesting" to the client. In base ENUM, the result-set consists of URIs that are used to connect to the target and might be tried sequentially, so sending back the whole set makes a sort of sense. It is not obvious that this same property applies to all metadata use cases. Calling-name is a standout, where the property obviously does NOT apply. Of what possible benefit is the record-set related to calling a user, when you're querying it in response to having been called by that user and just need his name? > Peter Koch and Olaf Kolkmann also spent a fair bit of time at the mic > during the BOF. > >> >> 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. > > RIght. But if the data were structured differently (as per using an > _prefix to make a new node for a specific datum), then the responses > won't be so chubby. > > To me, it comes back to the question of whether or not one needs all > that data at the same time. For example, when routing an outgoing > call, one really needs all the NAPTR records for that routing process. > But when one is receiving a call and only needs is the calling-name, > why should we also send all the records that would be used to route > the call? > > RS> So what? Have you noticed how many E2U definitions we have now? > > http://www.iana.org/assignments/enum-services For starters, the set of E2U definitions is pretty much horrifying. But AFAIK, all these services are still oriented to the calling party, rather than to the called party. Also, none of the (currently) require differential treatment based on the authenticated identity of the requesting party. > > RS> Dean this is a old argument us ENUM greybeards have had for > years. You > get back all the records from the query and then sort. End of story. > Maybe so, but that;s still part of what they're complaining about. The argument is "If that's the way ENUM works, and you need something that works differently, you shouldn't be using ENUM!" -- Dean From richard@shockey.us Mon May 3 10:32:28 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 679F43A6A7B for ; Mon, 3 May 2010 10:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.62 X-Spam-Level: X-Spam-Status: No, score=-0.62 tagged_above=-999 required=5 tests=[AWL=-0.621, 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 LdwANpbbTvKR for ; Mon, 3 May 2010 10:32:27 -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 758F93A67C2 for ; Mon, 3 May 2010 10:32:27 -0700 (PDT) Received: (qmail 19441 invoked by uid 0); 3 May 2010 16:32:06 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 3 May 2010 16:32:06 -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=WfsjeIPPa6QnkA0bwCrRzGAa/SkDPsfWE2zEJ/rINBX+KU3Uss1VNiU40v8CiojSw1Pab0h4rLukonP4h8jle/WeIBcJxvhIcSEoE10i7FYVmm5ujST6wKcf2p4CWzwf; 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 1O8zUy-0003sl-Sk; Mon, 03 May 2010 11:32:05 -0600 From: "Richard Shockey" To: "'PFAUTZ, PENN L \(ATTCORP\)'" , "'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><754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> <35FE871E2B085542A35726420E29DA6B03E2EA73@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <35FE871E2B085542A35726420E29DA6B03E2EA73@gaalpa1msgusr7a.ugd.att.com> Date: Mon, 3 May 2010 13:31:59 -0400 Message-ID: <007001caeae6$898d58c0$9ca80a40$@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: Acrq3hIFMzdxZS7OQneCkF5Q2JW85wAAkjaQAAEQmvA= 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: Mon, 03 May 2010 17:32:28 -0000 That being said and acknowledging the possibility of a problem, I'm not sure why we can't have a working group but one specifically tasked with, among other things, addressing the potential problem. I was only listening in remotely but kind of got the feeling that we were being told we couldn't have a WG until we arrived at a conclusion about the solution to the problem. Penn Pfautz AT&T Access Management +1-732-420-4962 RS> Penn we have not been told we cannot have a WG. This entire discussion is contrary to the way things should work in the IETF. One BOF co-chair is attempting to engineer the solution before the WG is even formed and that is just plain wrong. Discussing boundaries is one this discussion is not that. The function of a BOF is to see whether A. IS there is a problem B. Is the IETF the right place to do it C. Are there people who want to work on it. Those questions have been answered in the affirmative. IMHO this entire discussion should be set aside and concentrate on 1. Wordsmithing the charter 2. Getting another BOF set up for Maastricht. The question then is should the charter support a pure extension of the ENUM service registration process with expert review or is this going to end up being a one off RFC for each registration. I do not support any general use case document here. The use case can be defined in the registration documents. I'm sick of use case documents. Form the WG that is the only rational task at hand, though I will say this discussion will give the IESG a suitable record of where folks stand. From kcartwright@tnsi.com Mon May 3 11:03: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 8D3DA3A6976 for ; Mon, 3 May 2010 11:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.811 X-Spam-Level: X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[AWL=-0.812, 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 MIIcXU4O1fPr for ; Mon, 3 May 2010 11:03:39 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 50F2E3A6896 for ; Mon, 3 May 2010 11:03:39 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.43235692; Mon, 03 May 2010 14:02:59 -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, 3 May 2010 14:02:59 -0400 From: "Cartwright, Kenneth" To: Dean Willis , "PFAUTZ, PENN L (ATTCORP)" Date: Mon, 3 May 2010 14:02:57 -0400 Thread-Topic: [e2md] the 200 RR of Bartholemew Cubbins :-) Thread-Index: Acrq3hBOWGNB5MLeQRyYZbrG5MtYBQADKYXQ Message-ID: <754963199212404AB8E9CFCA6C3D0CDA24469D804A@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> 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] 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: Mon, 03 May 2010 18:03:40 -0000 Great googly moogly. Dean, how can you continue to paint and debate a scen= ario that is not being proposed? :-) This discussion is just too funny. -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Monday, May 03, 2010 12:31 PM To: PFAUTZ, PENN L (ATTCORP) Cc: Richard Shockey; Cartwright, Kenneth; Bernie Hoeneisen; E.164 To MetaDa= ta BOF discussion list Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-) On Apr 30, 2010, at 9:42 AM, 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. 3. That innocent intermediate nodes, not designed for the load, will gag. Envision a user on an enterprise network that runs a DNS-relay firewall. Said user runs an app that makes an E2MD query, and the enterprise firewall falls over. The owner of the queried domain involved might not care that much, but it's certainly going to annoy the corp IT guy. 4). That other traffic on the network links will be impacted by large UDP datagrams that fall somewhere between the path-MTU and the configured upper-limit of the EDNS0 nodes involved, which might well approach 64k before they start truncating and falling-back to TCP. -- 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 Mon May 3 11:19: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 F3E493A688B for ; Mon, 3 May 2010 11:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[AWL=0.519, 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 lizo4In8sAS5 for ; Mon, 3 May 2010 11:19:36 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id BF8B73A657C for ; Mon, 3 May 2010 11:19:35 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.43236254; Mon, 03 May 2010 14:19:15 -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, 3 May 2010 14:19:15 -0400 From: "Cartwright, Kenneth" To: "PFAUTZ, PENN L (ATTCORP)" , Dean Willis Date: Mon, 3 May 2010 14:19:14 -0400 Thread-Topic: [e2md] the 200 RR of Bartholemew Cubbins :-) Thread-Index: Acrq3hIFMzdxZS7OQneCkF5Q2JW85wAAkjaQAAMvaYA= Message-ID: <754963199212404AB8E9CFCA6C3D0CDA24469D807E@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> <35FE871E2B085542A35726420E29DA6B03E2EA73@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <35FE871E2B085542A35726420E29DA6B03E2EA73@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: "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: Mon, 03 May 2010 18:19:37 -0000 Right. I second that. Ken -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of PFA= UTZ, PENN L (ATTCORP) Sent: Monday, May 03, 2010 12:58 PM To: Dean Willis Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-) Dean: Thanks for the clarification. If I understand, e2md is not breaking DNS per se but some other stuff along the query response path. While I still think rational self-interest on the part of those owning the domain name would tend to restrict this, we certainly know that rational self-interest doesn't always happen. That being said and acknowledging the possibility of a problem, I'm not sure why we can't have a working group but one specifically tasked with, among other things, addressing the potential problem. I was only listening in remotely but kind of got the feeling that we were being told we couldn't have a WG until we arrived at a conclusion about the solution to the problem. Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Monday, May 03, 2010 12:31 PM To: PFAUTZ, PENN L (ATTCORP) Cc: Richard Shockey; Cartwright, Kenneth; Bernie Hoeneisen; E.164 To MetaData BOF discussion list Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-) On Apr 30, 2010, at 9:42 AM, 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. 3. That innocent intermediate nodes, not designed for the load, will gag. Envision a user on an enterprise network that runs a DNS-relay firewall. Said user runs an app that makes an E2MD query, and the enterprise firewall falls over. The owner of the queried domain involved might not care that much, but it's certainly going to annoy the corp IT guy. 4). That other traffic on the network links will be impacted by large UDP datagrams that fall somewhere between the path-MTU and the configured upper-limit of the EDNS0 nodes involved, which might well approach 64k before they start truncating and falling-back to TCP. -- 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 dean.willis@softarmor.com Mon May 3 12:29:38 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 A3DB83A68E7 for ; Mon, 3 May 2010 12:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.782 X-Spam-Level: X-Spam-Status: No, score=-0.782 tagged_above=-999 required=5 tests=[AWL=-0.783, 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 UPp4qJWpY1hC for ; Mon, 3 May 2010 12:29:37 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E217E3A6863 for ; Mon, 3 May 2010 12:29:36 -0700 (PDT) Received: from [192.168.2.105] (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 o43JTLoR028637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 May 2010 14:29:22 -0500 Message-Id: <3455D019-1B58-40C8-BEF0-1C42A30B2746@softarmor.com> From: Dean Willis To: "Cartwright, Kenneth" In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA24469D804A@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: Mon, 3 May 2010 14:29:15 -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> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> <754963199212404AB8E9CFCA6C3D0CDA24469D804A@TNS-MAIL-NA.win2k.corp.tnsi.com> X-Mailer: Apple Mail (2.936) 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: Mon, 03 May 2010 19:29:38 -0000 On May 3, 2010, at 1:02 PM, Cartwright, Kenneth wrote: > Great googly moogly. Dean, how can you continue to paint and debate > a scenario that is not being proposed? :-) This discussion is just > too funny. Other people have raised the questions: I'm just repeating them because many of the people on this list seem to think that by blustering on the list that they've answered the questions. They haven't. I don't hold the opposition's belief's as sacred, but I believe that if we can't muster an argument that convinces me, we're not likely to convince them. How can you say this scenario is not being proposed? We've clearly proposed an open-ended framework for adding new metadata types into the ENUM database with a minimal review policy for registering new metadata types. Obviously if we let just anybody register anything they want as metadata, we're potentially going to see many different metadata types, and potentially many resource-records per node. The ENUM database is clearly a subset of DNS, and DNS affects the whole Internet. We might well be thinking of ENUM as a walled-garden protocol that is used in an entirely different fashion than the DNS, but the DNS people do not see it that way. None of our text, AFAIK in any use-case draft, solutions draft, or charter draft says anything about exclusively operating ENUM in isolation from "the DNS". If it did, we'd be having an entirely different debate. If what we really want to do is define a profile of DNS that's used only in private networks, then let's make that abundantly clear in the work and most especially in the proposed charter. If what we really want to do is investigate, define, and solve the metadata problem in a way that is consistent with the guiding principles given by the IAB, then let's build a problem statement and charter around that approach. Simply trying the same "We're going to put this stuff in the DNS, dammit, and up yours if you don't think that's a good idea!" approach is probably not going to get us any further at the next BOF than it did at the last one. And I'm surely not going to be the one standing at the front of the room getting fruit thrown at me for presenting it! -- Dean From dean.willis@softarmor.com Mon May 3 12:32:27 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 65B1F3A6ADD for ; Mon, 3 May 2010 12:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=0.530, 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 vWWtNrymsyuR for ; Mon, 3 May 2010 12:32:26 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 39BFC3A6AD6 for ; Mon, 3 May 2010 12:32:24 -0700 (PDT) Received: from [192.168.2.105] (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 o43JW4vf028666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 May 2010 14:32:08 -0500 Message-Id: <09C1E64A-D9B5-465E-8825-B3F8AD50515C@softarmor.com> From: Dean Willis To: "Cartwright, Kenneth" In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA24469D807E@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: Mon, 3 May 2010 14:31:59 -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> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> <35FE871E2B085542A35726420E29DA6B03E2EA73@gaalpa1msgusr7a.ugd.att.com> <754963199212404AB8E9CFCA6C3D0CDA24469D807E@TNS-MAIL-NA.win2k.corp.tnsi.com> X-Mailer: Apple Mail (2.936) 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: Mon, 03 May 2010 19:32:27 -0000 So, we need to show up with a problem statement and a charter around refining and solving that problem. This is NOT the same thing as showing up with a 99% complete solution that we're absolutely committed to delivering "now and unmodified." This could well lead to a different solution than the one we have in mind. If we're OK with that, then I think we can make it happen. -- Dean On May 3, 2010, at 1:19 PM, Cartwright, Kenneth wrote: > Right. I second that. > > Ken > > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf > Of PFAUTZ, PENN L (ATTCORP) > Sent: Monday, May 03, 2010 12:58 PM > To: Dean Willis > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-) > > Dean: > Thanks for the clarification. If I understand, e2md is not breaking > DNS > per se but some other stuff along the query response path. > While I still think rational self-interest on the part of those owning > the domain name would tend to restrict this, we certainly know that > rational self-interest doesn't always happen. > That being said and acknowledging the possibility of a problem, I'm > not > sure why we can't have a working group but one specifically tasked > with, > among other things, addressing the potential problem. I was only > listening in remotely but kind of got the feeling that we were being > told we couldn't have a WG until we arrived at a conclusion about the > solution to the problem. > > Penn Pfautz > AT&T Access Management > +1-732-420-4962 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Monday, May 03, 2010 12:31 PM > To: PFAUTZ, PENN L (ATTCORP) > Cc: Richard Shockey; Cartwright, Kenneth; Bernie Hoeneisen; E.164 To > MetaData BOF discussion list > Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-) > > > On Apr 30, 2010, at 9:42 AM, 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. > > 3. That innocent intermediate nodes, not designed for the load, will > gag. Envision a user on an enterprise network that runs a DNS-relay > firewall. Said user runs an app that makes an E2MD query, and the > enterprise firewall falls over. The owner of the queried domain > involved might not care that much, but it's certainly going to annoy > the corp IT guy. > > 4). That other traffic on the network links will be impacted by large > UDP datagrams that fall somewhere between the path-MTU and the > configured upper-limit of the EDNS0 nodes involved, which might well > approach 64k before they start truncating and falling-back to TCP. > > -- > 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 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. > From richard@shockey.us Mon May 3 12:57: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 79E9928C2AE for ; Mon, 3 May 2010 12:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.699, 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 sfP8IDyCq-EX for ; Mon, 3 May 2010 12:57:11 -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 969AE28C28D for ; Mon, 3 May 2010 12:57:07 -0700 (PDT) Received: (qmail 31456 invoked by uid 0); 3 May 2010 19:56:53 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 3 May 2010 19:56:53 -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=bu9dqIiA76pV905vRkO4ov43lN3TH25j8a8R5MTQ0w97qu9zKTvBCWtRMYh7rkC26shw7tFOOMrazL8npgt62tuoihP6OvuiFsBiRlN7SY2QnGGBVWhmMywaKMUC8tqw; 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 1O91l7-00073N-6Y; Mon, 03 May 2010 13:56:53 -0600 From: "Richard Shockey" To: "'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><754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> <35FE871E2B085542A35726420E29DA6B03E2EA73@gaalpa1msgusr7a.ugd.att.com> <754963199212404AB8E9CFCA6C3D0CDA24469D807E@TNS-MAIL-NA.win2k.corp.tnsi.com> <09C1E64A-D9B5-465E-8825-B3F8AD50515C@softarmor.com> In-Reply-To: <09C1E64A-D9B5-465E-8825-B3F8AD50515C@softarmor.com> Date: Mon, 3 May 2010 15:56:47 -0400 Message-ID: <00af01caeafa$c432fd40$4c98f7c0$@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: Acrq91XA3EieA5yLRfWI9Qobuidz8QAAdP6A 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: Mon, 03 May 2010 19:57:14 -0000 But Dean that is not what you are doing. You are artificially constraining the discussion to, "Well you cant do this or that" since Dr. Flappinlips went up to the microphone in Anaheim and said something. If there are objections to a proposed solution or concerns about DNS response that should be done in a properly chartered WG or in consultations with DNSOPS. I do not consider the comments made in Anaheim as potentially constrictive only an opinion at a BOF. Now how much time have you asked for in Maastricht? And can we constrain further discussion to a proper revision of the charter? -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dean Willis Sent: Monday, May 03, 2010 3:32 PM To: Cartwright, Kenneth Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-) So, we need to show up with a problem statement and a charter around refining and solving that problem. This is NOT the same thing as showing up with a 99% complete solution that we're absolutely committed to delivering "now and unmodified." This could well lead to a different solution than the one we have in mind. If we're OK with that, then I think we can make it happen. -- Dean On May 3, 2010, at 1:19 PM, Cartwright, Kenneth wrote: > Right. I second that. > > Ken > > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf > Of PFAUTZ, PENN L (ATTCORP) > Sent: Monday, May 03, 2010 12:58 PM > To: Dean Willis > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-) > > Dean: > Thanks for the clarification. If I understand, e2md is not breaking > DNS > per se but some other stuff along the query response path. > While I still think rational self-interest on the part of those owning > the domain name would tend to restrict this, we certainly know that > rational self-interest doesn't always happen. > That being said and acknowledging the possibility of a problem, I'm > not > sure why we can't have a working group but one specifically tasked > with, > among other things, addressing the potential problem. I was only > listening in remotely but kind of got the feeling that we were being > told we couldn't have a WG until we arrived at a conclusion about the > solution to the problem. > > Penn Pfautz > AT&T Access Management > +1-732-420-4962 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Monday, May 03, 2010 12:31 PM > To: PFAUTZ, PENN L (ATTCORP) > Cc: Richard Shockey; Cartwright, Kenneth; Bernie Hoeneisen; E.164 To > MetaData BOF discussion list > Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-) > > > On Apr 30, 2010, at 9:42 AM, 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. > > 3. That innocent intermediate nodes, not designed for the load, will > gag. Envision a user on an enterprise network that runs a DNS-relay > firewall. Said user runs an app that makes an E2MD query, and the > enterprise firewall falls over. The owner of the queried domain > involved might not care that much, but it's certainly going to annoy > the corp IT guy. > > 4). That other traffic on the network links will be impacted by large > UDP datagrams that fall somewhere between the path-MTU and the > configured upper-limit of the EDNS0 nodes involved, which might well > approach 64k before they start truncating and falling-back to TCP. > > -- > 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 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 richard@shockey.us Mon May 3 13:10: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 00EF53A6B1A for ; Mon, 3 May 2010 13:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[AWL=-0.530, 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 L8hVxCqSXpos for ; Mon, 3 May 2010 13:10: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 AB2BC3A6AAC for ; Mon, 3 May 2010 13:09:52 -0700 (PDT) Received: (qmail 30804 invoked by uid 0); 3 May 2010 19:09:39 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 3 May 2010 19:09:39 -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=EHfJL0vjffdUSnyW8BJBQA0Nhg2iQISGSrmtwOERs8YKKFPpOZJna9JqJyAtaOM6X+iHmcU9oKb/SVMuDdlt2kxMisUoRYOE1pTeSfTkaidq5u7LEIzbI8rvMZilg98X; 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 1O91xS-0007Ie-2g; Mon, 03 May 2010 14:09:38 -0600 From: "Richard Shockey" To: "'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> <754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: Date: Mon, 3 May 2010 16:09:32 -0400 Message-ID: <00b001caeafc$8c0fbbe0$a42f33a0$@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: AcroAt7bxLqlfCD0RleugX1KuOgTFAC+HRGw 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] 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, 03 May 2010 20:10:41 -0000 > 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. RS> Just wonderful ..we're back to my old CNAM draft where I had to define a new PSTNDATA URI! Hey if that can fix this argument, fine I'm all for it. It's a kludge but A. the document was ENUM WG approved its in the IESG queue. We can make it a general case for all metadata use the existing ENUM service registration procedure and be done with it. It just needs a full revision. This is what I was trying to avoid but ..hey It would work. From kcartwright@tnsi.com Mon May 3 13:53: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 742CB28C2D0 for ; Mon, 3 May 2010 13:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.169 X-Spam-Level: X-Spam-Status: No, score=-1.169 tagged_above=-999 required=5 tests=[AWL=-0.429, 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 3v+Sc-ZzwObS for ; Mon, 3 May 2010 13:53:23 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 57EED28C2B9 for ; Mon, 3 May 2010 13:53:18 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.43241164; Mon, 03 May 2010 16:52:56 -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, 3 May 2010 16:52:56 -0400 From: "Cartwright, Kenneth" To: Dean Willis Date: Mon, 3 May 2010 16:52:55 -0400 Thread-Topic: [e2md] the 200 RR of Bartholemew Cubbins :-) Thread-Index: Acrq9vODHHUb7QSdTmW6yoGS6MpNyAACtvZQ Message-ID: <754963199212404AB8E9CFCA6C3D0CDA24469D8272@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> <754963199212404AB8E9CFCA6C3D0CDA24469D804A@TNS-MAIL-NA.win2k.corp.tnsi.com> <3455D019-1B58-40C8-BEF0-1C42A30B2746@softarmor.com> In-Reply-To: <3455D019-1B58-40C8-BEF0-1C42A30B2746@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: "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: Mon, 03 May 2010 20:53:24 -0000 Ok. So I'll end my portion of this fruitless discussoin and be happy to partici= pate in a re-constituted effort to re-define the charter and discuss the pr= oposed RFCs. Ken -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Monday, May 03, 2010 3:29 PM To: Cartwright, Kenneth Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-) On May 3, 2010, at 1:02 PM, Cartwright, Kenneth wrote: > Great googly moogly. Dean, how can you continue to paint and debate > a scenario that is not being proposed? :-) This discussion is just > too funny. Other people have raised the questions: I'm just repeating them because many of the people on this list seem to think that by blustering on the list that they've answered the questions. They haven't. I don't hold the opposition's belief's as sacred, but I believe that if we can't muster an argument that convinces me, we're not likely to convince them. How can you say this scenario is not being proposed? We've clearly proposed an open-ended framework for adding new metadata types into the ENUM database with a minimal review policy for registering new metadata types. Obviously if we let just anybody register anything they want as metadata, we're potentially going to see many different metadata types, and potentially many resource-records per node. The ENUM database is clearly a subset of DNS, and DNS affects the whole Internet. We might well be thinking of ENUM as a walled-garden protocol that is used in an entirely different fashion than the DNS, but the DNS people do not see it that way. None of our text, AFAIK in any use-case draft, solutions draft, or charter draft says anything about exclusively operating ENUM in isolation from "the DNS". If it did, we'd be having an entirely different debate. If what we really want to do is define a profile of DNS that's used only in private networks, then let's make that abundantly clear in the work and most especially in the proposed charter. If what we really want to do is investigate, define, and solve the metadata problem in a way that is consistent with the guiding principles given by the IAB, then let's build a problem statement and charter around that approach. Simply trying the same "We're going to put this stuff in the DNS, dammit, and up yours if you don't think that's a good idea!" approach is probably not going to get us any further at the next BOF than it did at the last one. And I'm surely not going to be the one standing at the front of the room getting fruit thrown at me for presenting it! -- 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 dean.willis@softarmor.com Mon May 3 19:55:49 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 0C0593A6B8A for ; Mon, 3 May 2010 19:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[AWL=-0.779, 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 gurgWufQP2-K for ; Mon, 3 May 2010 19:55:48 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2C8293A6B93 for ; Mon, 3 May 2010 19:55:48 -0700 (PDT) Received: from [192.168.2.105] (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 o442tUgS031737 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 May 2010 21:55:33 -0500 Message-Id: <4425CC51-22C0-44EC-8B3A-0CFB3FAE5141@softarmor.com> From: Dean Willis To: Richard Shockey In-Reply-To: <00af01caeafa$c432fd40$4c98f7c0$@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: Mon, 3 May 2010 21:55:24 -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> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> <35FE871E2B085542A35726420E29DA6B03E2EA73@gaalpa1msgusr7a.ugd.att.com> <754963199212404AB8E9CFCA6C3D0CDA24469D807E@TNS-MAIL-NA.win2k.corp.tnsi.com> <09C1E64A-D9B5-465E-8825-B3F8AD50515C@softarmor.com> <00af01caeafa$c432fd40$4c98f7c0$@us> X-Mailer: Apple Mail (2.936) 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: Tue, 04 May 2010 02:55:49 -0000 On May 3, 2010, at 2:56 PM, Richard Shockey wrote: > But Dean that is not what you are doing. You are artificially > constraining > the discussion to, "Well you cant do this or that" since Dr. > Flappinlips > went up to the microphone in Anaheim and said something. Sorry. I'm trying to say we have to have an agreed on ANSWER to Dr. Flappinlips that says we have a solid and presentable consensus on what we want to do. > If there are > objections to a proposed solution or concerns about DNS response > that should > be done in a properly chartered WG or in consultations with DNSOPS. > I do not > consider the comments made in Anaheim as potentially constrictive > only an > opinion at a BOF. well, those are the opinions that are going to get heard when it comes time for the I* to decide whether or not to charter us. > > Now how much time have you asked for in Maastricht? And can we > constrain > further discussion to a proper revision of the charter? > Me ask for time in Maastricht? Haven't done it. Don't plan to. Might not be there -- no travel budget. I only volunteered to help chair the BOF for Anaheim, and it was the most embarrassing 60 minutes of my entire professional life, and that's including the time I drank too much at the company meeting and karakoed to YMCA including the dance steps ... It will take many years to regain whatever shred of credibility I thought I had prior to that meeting! I'll start a separate thread on whether we BOF at Anaheim. -- Dean From dean.willis@softarmor.com Mon May 3 20:03: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 7D1FB3A6BA6 for ; Mon, 3 May 2010 20:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.766 X-Spam-Level: X-Spam-Status: No, score=-0.766 tagged_above=-999 required=5 tests=[AWL=-0.767, 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 Gy3vShc-NEPE for ; Mon, 3 May 2010 20:03:50 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A96303A6B7E for ; Mon, 3 May 2010 20:03:50 -0700 (PDT) Received: from [192.168.2.105] (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 o4433ZxS031825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 3 May 2010 22:03:36 -0500 Message-Id: <8267BF4C-9869-4D62-AE75-07E3828DE9CC@softarmor.com> 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: Mon, 3 May 2010 22:03:29 -0500 X-Mailer: Apple Mail (2.936) Subject: [e2md] Question: BOF in Maastricht? 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, 04 May 2010 03:03:51 -0000 Do we try to pull together another BOF in Maastricht? If so, we're going to need a new-and-improved charter that incorporates the lessons learned from Anaheim, assuming we learned some ;-). We're also going to need some volunteers to run the meeting. I can't commit to being there; I'm a little short on travel budget. I might make it on air-miles if I can find a traveling gypsy troop to sleep with. I'll start a separate thread on what we might want in a charter. I see a couple of options. If we don't BOF in Maastricht, we could perhaps schedule an informal design team meeting under RAI, and I think the ADs will let us have meeting space. -- Dean From dean.willis@softarmor.com Mon May 3 20:22: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 C327C3A6B98 for ; Mon, 3 May 2010 20:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.754 X-Spam-Level: X-Spam-Status: No, score=-0.754 tagged_above=-999 required=5 tests=[AWL=-0.755, 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 TQyTAGODGee2 for ; Mon, 3 May 2010 20:22:40 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A51373A6B74 for ; Mon, 3 May 2010 20:22:40 -0700 (PDT) Received: from [192.168.2.105] (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 o443MOn8031958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 3 May 2010 22:22:26 -0500 Message-Id: <4A9A4987-2A77-4B5A-B442-CC7F5F9251EA@softarmor.com> 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: Mon, 3 May 2010 22:22:19 -0500 X-Mailer: Apple Mail (2.936) Subject: [e2md] Where do we think we're going with E2MD? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 03:22:47 -0000 Before we start trying to nail-down a next-gen charter, I'd like to ask some questions about where we think we're going with E2MD. I see a couple of paths: 1) We come up a level and do a problem definition, then a requirements analysis, then an analysis of extant protocols to see if anything can be hammered into shape, and then a final protocol to meet those requirements. 2) We stay with a straightforward ENUM extension as proposed in Bernie's draft, and commit to developing the guidance necessary to make such a mechanism "Internet safe", including giving guidance on when it really needs to be used in a private network as opposed to public Internet. This will mean talking about the security sensitivity of data, the size of RRsets, etc. 3) As #2, but we ditch the "framework" model and require standards- track work for each new metadata type. 4) We stay with ENUM extension, but define an extension model that offers better query selectivity, such as using new RR types for some queries where NAPTR might not be optimal. Again, we may need to include source-URI work and deal with content sensitivity (although it could be as simple as saying "When used on the Internet, one must assume that all data is world-readable and therefore not provision any data that requires privacy controls.") 5) We make a minimal modification to ENUM to add a metadata URI; basically one NAPTR record per E.164, and define how some other protocol can be used to retrieve the metadata. Possibly we extend the scope to include developing a highly-efficient stateless UDP protocol based on DNS Query that meets the needs for high-capacity private networks, and possibly a profile for using HTTP (or HTTP/TLS) that meets the requirements for public networks and/or authentication- sensitive responses. Also optionally, we could define the high- efficiency protocol such that it can be accessed directly in private networks without the need to dereference a URL from ENUM, assuming that the querying node is already configured with where-to-ask (which is how we really use DNS now). Open question: Does said high- efficiency protocol address Hadriel's source-URI requirements? Or we could do some combination of these things, or something entirely different. The important thing is that we 1) have a strong consensus on what we're doing, and 2) anticipate and be prepared to answer the questions we know are coming, because we heard them at Anaheim. -- Dean From dean.willis@softarmor.com Mon May 3 20:28:36 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 39B403A6BA5 for ; Mon, 3 May 2010 20:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[AWL=-0.650, 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 87Rhou0H1Yzt for ; Mon, 3 May 2010 20:28:35 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 30A1C3A6B98 for ; Mon, 3 May 2010 20:28:35 -0700 (PDT) Received: from [192.168.2.105] (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 o443SJue031993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 3 May 2010 22:28:20 -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: Mon, 3 May 2010 22:28:13 -0500 X-Mailer: Apple Mail (2.936) Subject: [e2md] Poll: dividing metadata into calling and answering phases 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, 04 May 2010 03:28:36 -0000 We've heard suggestions that some metadata is used when placing a call, some is used to optimize the lookup operation in ENUM, and other data is used only when answering a call. Richard has already answered "NO" (although he's allowed to change his mind, of course.) So how do we feel about this difference? 1) Is there something fundamentally different that allows us to divide metadata into two or more categories for query purposes? 2) If so, should the metadata query protocol allow selective queries so that a given lookup operation only returns one (or some other subset) of data categories? -- Dean From dean.willis@softarmor.com Mon May 3 20:46: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 7372D3A68F6 for ; Mon, 3 May 2010 20:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.733 X-Spam-Level: X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[AWL=-0.734, 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 EYc91MarrA5c for ; Mon, 3 May 2010 20:46:31 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 49D9B3A68CD for ; Mon, 3 May 2010 20:46:31 -0700 (PDT) Received: from [192.168.2.105] (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 o443kFVs032098 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 3 May 2010 22:46:17 -0500 Message-Id: <92B7D81F-E0BB-4E88-8353-A355EC08D2EA@softarmor.com> 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: Mon, 3 May 2010 22:46:10 -0500 X-Mailer: Apple Mail (2.936) Subject: [e2md] Ponderings on different roots for different sorts of metadata 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, 04 May 2010 03:46:32 -0000 In "The DNS" as preached by the disciples thereof, there is a single root, and all namespaces are encompassed within that root. This is subtly different from how several people have told me they want to use E2MD. Essentially, as I understand it, current practice is to use different roots for different topics. If one wants the calling name for a phone number, one looks that phone number up in e.164.arpa on a given server, and if one wants the default route to that number, one might well look in that number in the same e164.arpa tree on an entirely different server, which is attached to an entirely different hierarchy of numbers all the way up to an entirely different e164.arpa root. A client must be configured to know which server to ask for any given sort of data, and asking the wrong one could result in a significant malfunction. I can see how this makes the DNS people nervous. I know, it's not all that different from how we use ENUM in practice, but so far that hasn't required any special tweaking of the ENUM spec to allow it. If we have to come out and make an explicit allowance for alt-root operations, I think we're going to get a special sort of attention traditionally reserved for victims of the Inquisition. Thumbscrews, anybody? Should we consider approaches for making this stuff all work without alt-root solutions? We've had a couple of proposals put on the table: If I recall correctly, these proposals include: 1) Having a single root that dereferences using a URI to some other service that handles the "alternate source" issue. 2) using different roots besides e164.arpa for private networks. 3) Using some sort of "delegation" model (perhaps a prefix) to find the right server for a specific sort of question. Noted that whatever we come up with here doesn't have to be the way people actually use the protocol, but it does need to be a complete enough answer that it is plausible and could actually be used, safely, on the Internet, if somebody wanted to. -- Dean From jim@rfc1035.com Tue May 4 00:25: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 D62903A67FB for ; Tue, 4 May 2010 00:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_DYNAMIC_DHCP=1.398, RDNS_DYNAMIC=0.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 g6exARAIa1Ty for ; Tue, 4 May 2010 00:25:28 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by core3.amsl.com (Postfix) with ESMTP id 7AC1A3A67AE for ; Tue, 4 May 2010 00:25:28 -0700 (PDT) Received: from dhcp-25-210.ripemtg.ripe.net (dhcp-25-210.ripemtg.ripe.net [193.0.25.210]) by shaun.rfc1035.com (Postfix) with ESMTP id 391B1CBC425; Tue, 4 May 2010 08:25:13 +0100 (BST) Message-Id: <3A7FD4AC-7710-4307-8084-851AECE67858@rfc1035.com> From: Jim Reid To: Dean Willis In-Reply-To: <5372C024-BF14-4A0F-AFCB-6BBDA3300436@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: Tue, 4 May 2010 08:25:13 +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><754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> <008001cae87c$84737bb0$8d5a7310$@us> <5372C024-BF14-4A0F-AFCB-6BBDA3300436@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: 'Bernie Hoeneisen' , "'E.164 To MetaData BOF discussion list'" Subject: [e2md] chubby DNS responses 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, 04 May 2010 07:25:30 -0000 On 3 May 2010, at 17:36, Dean Willis wrote: > I'm still waiting to see DNSSEC in the wild. You won't have long to wait. The last root server gets the signed root zone tomorrow. So far, the roll-out hasn't created strange traffic patterns or client/ resolving server behaviour. Assuming there are no surprises, the root will flip to a real KSK and ZSK on July 1st: http://www.root-dnssec.org. The data from this exercise should provide useful guidance about packet sizes and truncation for the discussions on this list. From jim@rfc1035.com Tue May 4 00:31: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 6DA3F3A686A for ; Tue, 4 May 2010 00:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.849 X-Spam-Level: X-Spam-Status: No, score=0.849 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HELO_DYNAMIC_DHCP=1.398, RDNS_DYNAMIC=0.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 pcJbRy5M7OOU for ; Tue, 4 May 2010 00:31:10 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by core3.amsl.com (Postfix) with ESMTP id 574C23A67FB for ; Tue, 4 May 2010 00:31:09 -0700 (PDT) Received: from dhcp-25-210.ripemtg.ripe.net (dhcp-25-210.ripemtg.ripe.net [193.0.25.210]) by shaun.rfc1035.com (Postfix) with ESMTP id 05D14CBC425; Tue, 4 May 2010 08:30:54 +0100 (BST) Message-Id: From: Jim Reid To: Dean Willis In-Reply-To: <28F8B3F9-1F8A-480B-A8F7-9246DCC193B2@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: Tue, 4 May 2010 08:30:54 +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><754963199212404AB8E9CFCA6C3D0CDA2446917DDF@TNS-MAIL-NA.win2k.corp.tnsi.com> <005501cae865$14e20c60$3ea62520$@us> <35FE871E2B085542A35726420E29DA6B03DCFCD1@gaalpa1msgusr7a.ugd.att.com> <008001cae87c$84737bb0$8d5a7310$@us> <3764143C-9276-4DD7-8126-FEF5680D20D6@rfc1035.com> <28F8B3F9-1F8A-480B-A8F7-9246DCC193B2@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: Bernie Hoeneisen , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] DNS cache size issues 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, 04 May 2010 07:31:14 -0000 On 3 May 2010, at 17:44, Dean Willis wrote: >> Who has these concerns and on what grounds? I think this is yet >> more FUD Bernie. Cache size concerns are coupled to RAM prices. >> Last time I looked 1 GB of RAM was about $30 retail. > > Some of the DNS relays out there don't cost $30. I think the one > that runs my office cost $19.95... So what? It's NEVER going to handle or cache large amounts of DNS data, whether that's E2MD NAPTRs or not. > You're still saying that E2MD isn't going to be used on the open > Internet, just in specially-walled gardens. No I'm not. It is quite likely E2MD will mostly be used by consenting adults behind closed doors, but not exclusively so. > That might be true. If it is, then making a strong case for it being > that way in the specification might help. It'll also draw fire from > people who think we have no business inventing a walled-garden > protocol in the IETF, but that's a different issue. Indeed. And another angels on pinhead debate. From jim@rfc1035.com Tue May 4 01:09: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 1199D3A691E for ; Tue, 4 May 2010 01:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.234 X-Spam-Level: X-Spam-Status: No, score=-0.234 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, HELO_DYNAMIC_DHCP=1.398, RDNS_DYNAMIC=0.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 M813SHMGW0f0 for ; Tue, 4 May 2010 01:09:53 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by core3.amsl.com (Postfix) with ESMTP id 0F17B3A6932 for ; Tue, 4 May 2010 01:09:41 -0700 (PDT) Received: from dhcp-25-210.ripemtg.ripe.net (dhcp-25-210.ripemtg.ripe.net [193.0.25.210]) by shaun.rfc1035.com (Postfix) with ESMTP id 50CEFCBC427; Tue, 4 May 2010 09:09:24 +0100 (BST) Message-Id: <91B92DCA-CE0F-48F4-966D-76D5050FAD40@rfc1035.com> From: Jim Reid To: Dean Willis 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, 4 May 2010 09:09:24 +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: [e2md] EDNS packet sizes 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, 04 May 2010 08:09:55 -0000 On 3 May 2010, at 16:59, Dean Willis wrote: > Would it be reasonable for E2MD to suggest a max datagram size of > 1280? I don't know. It's not clear to me if link-level fragmentation is likely to be a significant concern. And besides, there are other protocols like NFS which seem to get by OK with UDP jumbograms. It would be wise for this list to pick something that was compatible with RFC3226. Choosing other numbers would create a conflict with that RFC and no doubt least to IESG and/or AD whining. From bmanning@karoshi.com Tue May 4 04:02: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 2D2333A6B39 for ; Tue, 4 May 2010 04:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.055 X-Spam-Level: X-Spam-Status: No, score=-5.055 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_05=-1.11, 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 uA-citSK90dF for ; Tue, 4 May 2010 04:02:07 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 483E03A6B13 for ; Tue, 4 May 2010 04:01:44 -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 o44B1GWU025169; Tue, 4 May 2010 11:01:23 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o44B1ErK025166; Tue, 4 May 2010 11:01:14 GMT Date: Tue, 4 May 2010 11:01:14 +0000 From: bmanning@vacation.karoshi.com To: Jim Reid Message-ID: <20100504110114.GB24886@vacation.karoshi.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> <91B92DCA-CE0F-48F4-966D-76D5050FAD40@rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <91B92DCA-CE0F-48F4-966D-76D5050FAD40@rfc1035.com> User-Agent: Mutt/1.4.1i Cc: 'Bernie Hoeneisen' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] EDNS packet sizes 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, 04 May 2010 11:02:08 -0000 some of us are setting the current threshold to 1220 - instead of 1280, due to tunnel/VPN overhead. then there are others setting the threshold to 9k. --bill On Tue, May 04, 2010 at 09:09:24AM +0100, Jim Reid wrote: > On 3 May 2010, at 16:59, Dean Willis wrote: > > >Would it be reasonable for E2MD to suggest a max datagram size of > >1280? > > I don't know. It's not clear to me if link-level fragmentation is > likely to be a significant concern. And besides, there are other > protocols like NFS which seem to get by OK with UDP jumbograms. It > would be wise for this list to pick something that was compatible with > RFC3226. Choosing other numbers would create a conflict with that RFC > and no doubt least to IESG and/or AD whining. > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From pp3129@att.com Tue May 4 04:22: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 C87AA3A6B61 for ; Tue, 4 May 2010 04:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.788 X-Spam-Level: X-Spam-Status: No, score=-104.788 tagged_above=-999 required=5 tests=[AWL=-0.789, 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 XAZUUVge9xMV for ; Tue, 4 May 2010 04:22:53 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 3FFB428C0DD for ; Tue, 4 May 2010 04:22:27 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-14.tower-167.messagelabs.com!1272972124!26759544!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 27300 invoked from network); 4 May 2010 11:22:04 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-14.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2010 11:22:04 -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 o44BLlmt004462 for ; Tue, 4 May 2010 07:21:47 -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 o44BLgJv004400 for ; Tue, 4 May 2010 07:21:43 -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: Tue, 4 May 2010 07:21:57 -0400 Message-ID: <35FE871E2B085542A35726420E29DA6B03E2ED5B@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <4A9A4987-2A77-4B5A-B442-CC7F5F9251EA@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [e2md] Where do we think we're going with E2MD? Thread-Index: AcrrORBbaO1ArqrTSP+qHplQzYq+QwAQoReg References: <4A9A4987-2A77-4B5A-B442-CC7F5F9251EA@softarmor.com> From: "PFAUTZ, PENN L (ATTCORP)" To: "Dean Willis" , "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Where do we think we're going with E2MD? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 11:22:56 -0000 Is it legit as a charter to basically state the use cases we've come up with and say we'll examine the alternatives laid out in (2), (3),(4), and (5) as potential solutions taking into account the concerns (list them) brought up at the BOF.=20 Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dean Willis Sent: Monday, May 03, 2010 11:22 PM To: E.164 To MetaData BOF discussion list Subject: [e2md] Where do we think we're going with E2MD? Before we start trying to nail-down a next-gen charter, I'd like to =20 ask some questions about where we think we're going with E2MD. I see a couple of paths: 1) We come up a level and do a problem definition, then a requirements =20 analysis, then an analysis of extant protocols to see if anything can =20 be hammered into shape, and then a final protocol to meet those =20 requirements. 2) We stay with a straightforward ENUM extension as proposed in =20 Bernie's draft, and commit to developing the guidance necessary to =20 make such a mechanism "Internet safe", including giving guidance on =20 when it really needs to be used in a private network as opposed to =20 public Internet. This will mean talking about the security sensitivity =20 of data, the size of RRsets, etc. 3) As #2, but we ditch the "framework" model and require standards-=20 track work for each new metadata type. 4) We stay with ENUM extension, but define an extension model that =20 offers better query selectivity, such as using new RR types for some =20 queries where NAPTR might not be optimal. Again, we may need to =20 include source-URI work and deal with content sensitivity (although it =20 could be as simple as saying "When used on the Internet, one must =20 assume that all data is world-readable and therefore not provision any =20 data that requires privacy controls.") 5) We make a minimal modification to ENUM to add a metadata URI; =20 basically one NAPTR record per E.164, and define how some other =20 protocol can be used to retrieve the metadata. Possibly we extend the =20 scope to include developing a highly-efficient stateless UDP protocol =20 based on DNS Query that meets the needs for high-capacity private =20 networks, and possibly a profile for using HTTP (or HTTP/TLS) that =20 meets the requirements for public networks and/or authentication-=20 sensitive responses. Also optionally, we could define the high-=20 efficiency protocol such that it can be accessed directly in private =20 networks without the need to dereference a URL from ENUM, assuming =20 that the querying node is already configured with where-to-ask (which =20 is how we really use DNS now). Open question: Does said high-=20 efficiency protocol address Hadriel's source-URI requirements? Or we could do some combination of these things, or something entirely =20 different. The important thing is that we 1) have a strong consensus =20 on what we're doing, and 2) anticipate and be prepared to answer the =20 questions we know are coming, because we heard them at Anaheim. -- Dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From dean.willis@softarmor.com Tue May 4 08:58:28 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 7CB023A6CA1 for ; Tue, 4 May 2010 08:58:28 -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=[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 LJgfA+bT4c6S for ; Tue, 4 May 2010 08:58:27 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B67413A6C89 for ; Tue, 4 May 2010 08:58:25 -0700 (PDT) Received: from localhost.localdomain (mobile-166-189-195-006.mycingular.net [166.189.195.6] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o44Fw1pR006125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 May 2010 10:58:08 -0500 X-User-Agent: K-9 Mail for Android In-Reply-To: <35FE871E2B085542A35726420E29DA6B03E2ED5B@gaalpa1msgusr7a.ugd.att.com> References: <4A9A4987-2A77-4B5A-B442-CC7F5F9251EA@softarmor.com> <35FE871E2B085542A35726420E29DA6B03E2ED5B@gaalpa1msgusr7a.ugd.att.com> Content-Type: multipart/mixed; boundary="----DWYW5MYT7LV20M85UM05RILHY8AVLG" MIME-Version: 1.0 From: Dean Willis Date: Tue, 04 May 2010 10:57:50 -0500 To: "PFAUTZ, PENN L (ATTCORP)" , "E.164 To MetaData BOF discussion list" Message-ID: <2bd60d95-dd1c-4c0c-aa37-96f50a937713@email.android.com> Subject: Re: [e2md] Where do we think we're going with E2MD? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 15:58:28 -0000 ------DWYW5MYT7LV20M85UM05RILHY8AVLG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 WWVhaCwgdGhhdCBjb3VsZCB3b3JrLgotLSAKRGVhbiBXaWxsaXMKCiJQRkFVVFosIFBFTk4gTCAo QVRUQ09SUCkiIDxwcDMxMjlAYXR0LmNvbT4gd3JvdGU6Cgo+SXMgaXQgbGVnaXQgYXMgYSBjaGFy dGVyIHRvIGJhc2ljYWxseSBzdGF0ZSB0aGUgdXNlIGNhc2VzIHdlJ3ZlIGNvbWUgdXAKPndpdGgg YW5kIHNheSB3ZSdsbCBleGFtaW5lIHRoZSBhbHRlcm5hdGl2ZXMgbGFpZCBvdXQgaW4gKDIpLCAo MyksKDQpLAo+YW5kICg1KSBhcyBwb3RlbnRpYWwgc29sdXRpb25zIHRha2luZyBpbnRvIGFjY291 bnQgdGhlIGNvbmNlcm5zIChsaXN0Cj50aGVtKSBicm91Z2h0IHVwIGF0IHRoZSBCT0YuIAo+Cj5Q ZW5uIFBmYXV0ego+QVQmVCBBY2Nlc3MgTWFuYWdlbWVudAo+KzEtNzMyLTQyMC00OTYyCj4tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+RnJvbTogZTJtZC1ib3VuY2VzQGlldGYub3JnIFttYWls dG86ZTJtZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YKPkRlYW4gV2lsbGlzCj5TZW50 OiBNb25kYXksIE1heSAwMywgMjAxMCAxMToyMiBQTQo+VG86IEUuMTY0IFRvIE1ldGFEYXRhIEJP RiBkaXNjdXNzaW9uIGxpc3QKPlN1YmplY3Q6IFtlMm1kXSBXaGVyZSBkbyB3ZSB0aGluayB3ZSdy ZSBnb2luZyB3aXRoIEUyTUQ/Cj4KPgo+QmVmb3JlIHdlIHN0YXJ0IHRyeWluZyB0byBuYWlsLWRv d24gYSBuZXh0LWdlbiBjaGFydGVyLCBJJ2QgbGlrZSB0byAgCj5hc2sgc29tZSBxdWVzdGlvbnMg YWJvdXQgd2hlcmUgd2UgdGhpbmsgd2UncmUgZ29pbmcgd2l0aCBFMk1ELgo+Cj5JIHNlZSBhIGNv dXBsZSBvZiBwYXRoczoKPgo+MSkgV2UgY29tZSB1cCBhIGxldmVsIGFuZCBkbyBhIHByb2JsZW0g ZGVmaW5pdGlvbiwgdGhlbiBhIHJlcXVpcmVtZW50cyAgCj5hbmFseXNpcywgdGhlbiBhbiBhbmFs eXNpcyBvZiBleHRhbnQgcHJvdG9jb2xzIHRvIHNlZSBpZiBhbnl0aGluZyBjYW4gIAo+YmUgaGFt bWVyZWQgaW50byBzaGFwZSwgYW5kIHRoZW4gYSBmaW5hbCBwcm90b2NvbCB0byBtZWV0IHRob3Nl ICAKPnJlcXVpcmVtZW50cy4KPgo+MikgV2Ugc3RheSB3aXRoIGEgc3RyYWlnaHRmb3J3YXJkIEVO VU0gZXh0ZW5zaW9uIGFzIHByb3Bvc2VkIGluICAgCj5CZXJuaWUncyBkcmFmdCwgYW5kIGNvbW1p dCB0byBkZXZlbG9waW5nIHRoZSBndWlkYW5jZSBuZWNlc3NhcnkgdG8gIAo+bWFrZSBzdWNoIGEg bWVjaGFuaXNtICJJbnRlcm5ldCBzYWZlIiwgaW5jbHVkaW5nIGdpdmluZyBndWlkYW5jZSBvbiAg Cj53aGVuIGl0IHJlYWxseSBuZWVkcyB0byBiZSB1c2VkIGluIGEgcHJpdmF0ZSBuZXR3b3JrIGFz IG9wcG9zZWQgdG8gIAo+cHVibGljIEludGVybmV0LiBUaGlzIHdpbGwgbWVhbiB0YWxraW5nIGFi b3V0IHRoZSBzZWN1cml0eSBzZW5zaXRpdml0eSAgCj5vZiBkYXRhLCB0aGUgc2l6ZSBvZiBSUnNl dHMsIGV0Yy4KPgo+MykgIEFzICMyLCBidXQgd2UgZGl0Y2ggdGhlICJmcmFtZXdvcmsiIG1vZGVs IGFuZCByZXF1aXJlIHN0YW5kYXJkcy0gCj50cmFjayB3b3JrIGZvciBlYWNoIG5ldyBtZXRhZGF0 YSB0eXBlLgo+Cj40KSBXZSBzdGF5IHdpdGggRU5VTSBleHRlbnNpb24sIGJ1dCBkZWZpbmUgYW4g ZXh0ZW5zaW9uIG1vZGVsIHRoYXQgIAo+b2ZmZXJzIGJldHRlciBxdWVyeSBzZWxlY3Rpdml0eSwg c3VjaCBhcyB1c2luZyBuZXcgUlIgdHlwZXMgZm9yIHNvbWUgIAo+cXVlcmllcyB3aGVyZSBOQVBU UiBtaWdodCBub3QgYmUgb3B0aW1hbC4gQWdhaW4sIHdlIG1heSBuZWVkIHRvICAKPmluY2x1ZGUg c291cmNlLVVSSSB3b3JrIGFuZCBkZWFsIHdpdGggY29udGVudCBzZW5zaXRpdml0eSAoYWx0aG91 Z2ggaXQgIAo+Y291bGQgYmUgYXMgc2ltcGxlIGFzIHNheWluZyAiV2hlbiB1c2VkIG9uIHRoZSBJ bnRlcm5ldCwgb25lIG11c3QgIAo+YXNzdW1lIHRoYXQgYWxsIGRhdGEgaXMgd29ybGQtcmVhZGFi bGUgYW5kIHRoZXJlZm9yZSBub3QgcHJvdmlzaW9uIGFueSAgCj5kYXRhIHRoYXQgcmVxdWlyZXMg cHJpdmFjeSBjb250cm9scy4iKQo+Cj41KSBXZSBtYWtlIGEgbWluaW1hbCBtb2RpZmljYXRpb24g dG8gRU5VTSB0byBhZGQgYSBtZXRhZGF0YSBVUkk7ICAKPmJhc2ljYWxseSBvbmUgTkFQVFIgcmVj b3JkIHBlciBFLjE2NCwgYW5kIGRlZmluZSBob3cgc29tZSBvdGhlciAgCj5wcm90b2NvbCBjYW4g YmUgdXNlZCB0byByZXRyaWV2ZSB0aGUgbWV0YWRhdGEuIFBvc3NpYmx5IHdlIGV4dGVuZCB0aGUg IAo+c2NvcGUgdG8gaW5jbHVkZSBkZXZlbG9waW5nIGEgaGlnaGx5LWVmZmljaWVudCBzdGF0ZWxl c3MgVURQIHByb3RvY29sICAKPmJhc2VkIG9uIEROUyBRdWVyeSB0aGF0IG1lZXRzIHRoZSBuZWVk cyBmb3IgaGlnaC1jYXBhY2l0eSBwcml2YXRlICAKPm5ldHdvcmtzLCBhbmQgcG9zc2libHkgYSBw cm9maWxlIGZvciB1c2luZyBIVFRQIChvciBIVFRQL1RMUykgdGhhdCAgCj5tZWV0cyB0aGUgcmVx dWlyZW1lbnRzIGZvciBwdWJsaWMgbmV0d29ya3MgYW5kL29yIGF1dGhlbnRpY2F0aW9uLSAKPnNl bnNpdGl2ZSByZXNwb25zZXMuIEFsc28gb3B0aW9uYWxseSwgd2UgY291bGQgZGVmaW5lIHRoZSBo aWdoLSAKPmVmZmljaWVuY3kgcHJvdG9jb2wgc3VjaCB0aGF0IGl0IGNhbiBiZSBhY2Nlc3NlZCBk aXJlY3RseSBpbiBwcml2YXRlICAKPm5ldHdvcmtzIHdpdGhvdXQgdGhlIG5lZWQgdG8gZGVyZWZl cmVuY2UgYSBVUkwgZnJvbSBFTlVNLCBhc3N1bWluZyAgCj50aGF0IHRoZSBxdWVyeWluZyBub2Rl IGlzIGFscmVhZHkgY29uZmlndXJlZCB3aXRoIHdoZXJlLXRvLWFzayAod2hpY2ggIAo+aXMgaG93 IHdlIHJlYWxseSB1c2UgRE5TIG5vdykuIE9wZW4gcXVlc3Rpb246IERvZXMgc2FpZCBoaWdoLSAK PmVmZmljaWVuY3kgcHJvdG9jb2wgYWRkcmVzcyBIYWRyaWVsJ3Mgc291cmNlLVVSSSByZXF1aXJl bWVudHM/Cj4KPk9yIHdlIGNvdWxkIGRvIHNvbWUgY29tYmluYXRpb24gb2YgdGhlc2UgdGhpbmdz LCBvciBzb21ldGhpbmcgZW50aXJlbHkgIAo+ZGlmZmVyZW50LiBUaGUgaW1wb3J0YW50IHRoaW5n IGlzIHRoYXQgd2UgMSkgaGF2ZSBhIHN0cm9uZyBjb25zZW5zdXMgIAo+b24gd2hhdCB3ZSdyZSBk b2luZywgYW5kIDIpIGFudGljaXBhdGUgYW5kIGJlIHByZXBhcmVkIHRvIGFuc3dlciB0aGUgIAo+ cXVlc3Rpb25zIHdlIGtub3cgYXJlIGNvbWluZywgYmVjYXVzZSB3ZSBoZWFyZCB0aGVtIGF0IEFu YWhlaW0uCj4KPi0tCj5EZWFuCj4KPgo+Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwo+ZTJtZCBtYWlsaW5nIGxpc3QKPmUybWRAaWV0Zi5vcmcKPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZTJtZAo+Cg== ------DWYW5MYT7LV20M85UM05RILHY8AVLG-- From HKaplan@acmepacket.com Thu May 6 12:44: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 E088E3A6C15 for ; Thu, 6 May 2010 12:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.03 X-Spam-Level: X-Spam-Status: No, score=-1.03 tagged_above=-999 required=5 tests=[AWL=-1.030, 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 sDjLdTOFEeGH for ; Thu, 6 May 2010 12:44:02 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C9CD03A6ADA for ; Thu, 6 May 2010 12:44:01 -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, 6 May 2010 15:43:48 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 6 May 2010 15:43:45 -0400 From: Hadriel Kaplan To: Dean Willis , Richard Shockey Date: Thu, 6 May 2010 15:43:38 -0400 Thread-Topic: Querying CName (was: lots of NAPTRs) Thread-Index: Acrq5lXJlfJrN5SzS0u9BacDNFHswgCbQ2UQ Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D73E0@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> <006501caeae3$5248f7f0$f6dae7d0$@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: [e2md] Querying CName (was: 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: Thu, 06 May 2010 19:44:03 -0000 Right, so for the CName use-case in particular, I think we can address the = issue you cited below. We just do in public ENUM what we sometimes do toda= y in private ENUM: we use a different subdomain. Like .cname.e164.arpa. Or if you want to make it more generic: .source.e164.arpa, and put any othe= r source query-key based answers in that sub-tree.=20 (not to be confused with source-uri, which is a different animal altogether= ) -hadriel > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Dean Willis > Sent: Monday, May 03, 2010 1:30 PM > To: Richard Shockey >=20 > It's a fairly limited kind of database, in that its "query language" > is restricted to node name (a master key) and node type (a subkey). > That is, a combination of name and type explicitly indicates a > database record set, what we might call a "node" in DNS. A query > returns all the resource records at a given node. >=20 > ENUM extended the query language with the "type+subtype" model. But > it's important to note that this extension happens at the client end, > not the server. The server still returns all the resource records at > the node, then the client filters out the queried subtype and discards > the resource records that aren't interesting. >=20 > From a database point of view, this is a Really Ugly Hack. It's much > cleaner to have the server process the subkey, so that the result set > is smaller. >=20 > However, the approach used by ENUM works nicely for ENUM in that its > not unusual for the whole result-set to be "interesting" to the > client. In base ENUM, the result-set consists of URIs that are used > to connect to the target and might be tried sequentially, so sending > back the whole set makes a sort of sense. >=20 > It is not obvious that this same property applies to all metadata use > cases. Calling-name is a standout, where the property obviously does > NOT apply. Of what possible benefit is the record-set related to > calling a user, when you're querying it in response to having been > called by that user and just need his name? >=20 From lconroy@insensate.co.uk Thu May 6 16:04: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 D83613A69BD for ; Thu, 6 May 2010 16:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.647 X-Spam-Level: X-Spam-Status: No, score=-0.647 tagged_above=-999 required=5 tests=[AWL=0.093, 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 4izy4grZulLR for ; Thu, 6 May 2010 16:04:11 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 7629B3A6A28 for ; Thu, 6 May 2010 16:04:11 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id DAF841337D0; Fri, 7 May 2010 00:03:56 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D73E0@mail> Date: Fri, 7 May 2010 00:03:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0E7FFADA-A621-4A2E-888A-079844CA1276@insensate.co.uk> 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> <006501caeae3$5248f7f0$f6dae7d0$@us> <430FC6BDED356B4C8498F634416644A91A8A7D73E0@mail> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1078) Cc: "'E.164 To MetaData BOF discussion list'" , 'Bernie Hoeneisen' Subject: Re: [e2md] Querying CName (was: 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: Thu, 06 May 2010 23:04:13 -0000 Hi Hadriel, folks, I'm surprised no one else jumped in. Ahem ... if you look at rfc3761bis, RFC3761, and before that RFC2916, = you will note the IANA considerations. =3D> I do not believe that one can readily do that kind of delegation = within e164.arpa. I suspect that an apex outside e164.arpa. would not be covered by the = agreement. all the best, Lawrence On 6 May 2010, at 20:43, Hadriel Kaplan wrote: >=20 > Right, so for the CName use-case in particular, I think we can address = the issue you cited below. We just do in public ENUM what we sometimes = do today in private ENUM: we use a different subdomain. Like = .cname.e164.arpa. >=20 >=20 > Or if you want to make it more generic: .source.e164.arpa, and put any = other source query-key based answers in that sub-tree.=20 >=20 > (not to be confused with source-uri, which is a different animal = altogether) >=20 > -hadriel >=20 >=20 >> -----Original Message----- >> From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf = Of >> Dean Willis >> Sent: Monday, May 03, 2010 1:30 PM >> To: Richard Shockey >>=20 >> It's a fairly limited kind of database, in that its "query language" >> is restricted to node name (a master key) and node type (a subkey). >> That is, a combination of name and type explicitly indicates a >> database record set, what we might call a "node" in DNS. A query >> returns all the resource records at a given node. >>=20 >> ENUM extended the query language with the "type+subtype" model. But >> it's important to note that this extension happens at the client end, >> not the server. The server still returns all the resource records at >> the node, then the client filters out the queried subtype and = discards >> the resource records that aren't interesting. >>=20 >> =46rom a database point of view, this is a Really Ugly Hack. It's = much >> cleaner to have the server process the subkey, so that the result set >> is smaller. >>=20 >> However, the approach used by ENUM works nicely for ENUM in that its >> not unusual for the whole result-set to be "interesting" to the >> client. In base ENUM, the result-set consists of URIs that are used >> to connect to the target and might be tried sequentially, so sending >> back the whole set makes a sort of sense. >>=20 >> It is not obvious that this same property applies to all metadata use >> cases. Calling-name is a standout, where the property obviously does >> NOT apply. Of what possible benefit is the record-set related to >> calling a user, when you're querying it in response to having been >> called by that user and just need his name? >>=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From HKaplan@acmepacket.com Thu May 6 16:14: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 30E0C3A69BD for ; Thu, 6 May 2010 16:14:22 -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 RXSkeRUL8K7y for ; Thu, 6 May 2010 16:14:20 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C53F63A67EA for ; Thu, 6 May 2010 16:14:19 -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, 6 May 2010 19:14:06 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 6 May 2010 19:14:05 -0400 From: Hadriel Kaplan To: Lawrence Conroy Date: Thu, 6 May 2010 19:14:05 -0400 Thread-Topic: [e2md] Querying CName (was: lots of NAPTRs) Thread-Index: AcrtcHVX98b+Q7KQQK2eQpdEOn+jbQAAG6dQ Message-ID: <430FC6BDED356B4C8498F634416644A91A8A7D7454@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> <006501caeae3$5248f7f0$f6dae7d0$@us> <430FC6BDED356B4C8498F634416644A91A8A7D73E0@mail> <0E7FFADA-A621-4A2E-888A-079844CA1276@insensate.co.uk> In-Reply-To: <0E7FFADA-A621-4A2E-888A-079844CA1276@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 Cc: "'E.164 To MetaData BOF discussion list'" , 'Bernie Hoeneisen' Subject: Re: [e2md] Querying CName (was: 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: Thu, 06 May 2010 23:14:22 -0000 I read it, and I didn't see the problem. Can you elaborate? I'm not saying it wouldn't take an RFC to do this - we would have to give I= ANA additional instructions. So?=20 Or do it for a new domain, like source164.arpa. I don't care. The point i= s it's solvable even in a "public" context. :) -hadriel > -----Original Message----- > From: Lawrence Conroy [mailto:lconroy@insensate.co.uk] > Sent: Thursday, May 06, 2010 7:04 PM > To: Hadriel Kaplan > Cc: Dean Willis; Richard Shockey; 'Bernie Hoeneisen'; 'E.164 To MetaData > BOF discussion list' > Subject: Re: [e2md] Querying CName (was: lots of NAPTRs) >=20 > Hi Hadriel, folks, > I'm surprised no one else jumped in. > Ahem ... if you look at rfc3761bis, RFC3761, and before that RFC2916, you > will note the IANA considerations. > =3D> I do not believe that one can readily do that kind of delegation wit= hin > e164.arpa. > I suspect that an apex outside e164.arpa. would not be covered by the > agreement. > all the best, > Lawrence >=20 > On 6 May 2010, at 20:43, Hadriel Kaplan wrote: >=20 > > > > Right, so for the CName use-case in particular, I think we can address > the issue you cited below. We just do in public ENUM what we sometimes d= o > today in private ENUM: we use a different subdomain. > Like .cname.e164.arpa. > > > > > > Or if you want to make it more generic: .source.e164.arpa, and put any > other source query-key based answers in that sub-tree. > > > > (not to be confused with source-uri, which is a different animal > altogether) > > > > -hadriel > > > > > >> -----Original Message----- > >> From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf O= f > >> Dean Willis > >> Sent: Monday, May 03, 2010 1:30 PM > >> To: Richard Shockey > >> > >> It's a fairly limited kind of database, in that its "query language" > >> is restricted to node name (a master key) and node type (a subkey). > >> That is, a combination of name and type explicitly indicates a > >> database record set, what we might call a "node" in DNS. A query > >> returns all the resource records at a given node. > >> > >> ENUM extended the query language with the "type+subtype" model. But > >> it's important to note that this extension happens at the client end, > >> not the server. The server still returns all the resource records at > >> the node, then the client filters out the queried subtype and discards > >> the resource records that aren't interesting. > >> > >> From a database point of view, this is a Really Ugly Hack. It's much > >> cleaner to have the server process the subkey, so that the result set > >> is smaller. > >> > >> However, the approach used by ENUM works nicely for ENUM in that its > >> not unusual for the whole result-set to be "interesting" to the > >> client. In base ENUM, the result-set consists of URIs that are used > >> to connect to the target and might be tried sequentially, so sending > >> back the whole set makes a sort of sense. > >> > >> It is not obvious that this same property applies to all metadata use > >> cases. Calling-name is a standout, where the property obviously does > >> NOT apply. Of what possible benefit is the record-set related to > >> calling a user, when you're querying it in response to having been > >> called by that user and just need his name? > >> > > _______________________________________________ > > e2md mailing list > > e2md@ietf.org > > https://www.ietf.org/mailman/listinfo/e2md From bernie@ietf.hoeneisen.ch Sun May 9 08:45:05 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 8FAC53A6A47 for ; Sun, 9 May 2010 08:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.692 X-Spam-Level: X-Spam-Status: No, score=-0.692 tagged_above=-999 required=5 tests=[AWL=-0.693, 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 sThXGE9Uvxln for ; Sun, 9 May 2010 08:45:04 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 86ADB3A6A48 for ; Sun, 9 May 2010 08:44:59 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1OB8gF-0001CW-Mp; Sun, 09 May 2010 17:44:35 +0200 Date: Sun, 9 May 2010 17:44:35 +0200 (CEST) From: 'Bernie Hoeneisen' X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Hadriel Kaplan In-Reply-To: <430FC6BDED356B4C8498F634416644A91A8A7D73E0@mail> 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> <006501caeae3$5248f7f0$f6dae7d0$@us> <430FC6BDED356B4C8498F634416644A91A8A7D73E0@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] Querying CName (was: 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: Sun, 09 May 2010 15:45:05 -0000 Hi Hadriel Interesting proposal. However, introducing new apexes results in provisioning issues. You need to make the same (sub-)^x delegations for every apex. This is not really efficient, does not scale, and introduces problems with synchronization. (Note: E2M+cnam and E2U+sip (and others) are likely to have the same source of information for provisioning, so that this does not really appear to be straight forward.) This probabely works fine in environments where there are only a few (more or less static) delegations. Some questions arising from this: 1) Do we really have more cnam-like use cases (so that it is worth to make things complicated in the first place)? 2) Are there other use case types, which would require a different apex? 3) Is cnam really so much different? >From the lookup point of view, the only difference is that it is not used to make a routing decision and that the result affects the calling party (i.e. SIP From HF as opposed to the R-URI). The lookup is made before establishment of the SIP session as with any other ENUM lookup. >From the provisioning point of view, however, it comes to the same: It is information about the number. The source of the information is most likely the same as the one used to provision all the other NAPTR RR (e.g. E2U+sip, E2U+h323, ...). If the answer to all these questions is 'no', we might want to consider the 'cnam' tale closed and treat 'cnam' as every other E2MD use case. cheers, Bernie On Thu, 6 May 2010, Hadriel Kaplan wrote: > > Right, so for the CName use-case in particular, I think we can address > the issue you cited below. We just do in public ENUM what we sometimes > do today in private ENUM: we use a different subdomain. Like > .cname.e164.arpa. > > > Or if you want to make it more generic: .source.e164.arpa, and put any > other source query-key based answers in that sub-tree. > > (not to be confused with source-uri, which is a different animal altogether) > > -hadriel > > >> -----Original Message----- >> From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of >> Dean Willis >> Sent: Monday, May 03, 2010 1:30 PM >> To: Richard Shockey >> >> It's a fairly limited kind of database, in that its "query language" >> is restricted to node name (a master key) and node type (a subkey). >> That is, a combination of name and type explicitly indicates a >> database record set, what we might call a "node" in DNS. A query >> returns all the resource records at a given node. >> >> ENUM extended the query language with the "type+subtype" model. But >> it's important to note that this extension happens at the client end, >> not the server. The server still returns all the resource records at >> the node, then the client filters out the queried subtype and discards >> the resource records that aren't interesting. >> >> From a database point of view, this is a Really Ugly Hack. It's much >> cleaner to have the server process the subkey, so that the result set >> is smaller. >> >> However, the approach used by ENUM works nicely for ENUM in that its >> not unusual for the whole result-set to be "interesting" to the >> client. In base ENUM, the result-set consists of URIs that are used >> to connect to the target and might be tried sequentially, so sending >> back the whole set makes a sort of sense. >> >> It is not obvious that this same property applies to all metadata use >> cases. Calling-name is a standout, where the property obviously does >> NOT apply. Of what possible benefit is the record-set related to >> calling a user, when you're querying it in response to having been >> called by that user and just need his name? >> > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > From bernie@ietf.hoeneisen.ch Thu May 13 06:29: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 0E9033A6B1E for ; Thu, 13 May 2010 06:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.732 X-Spam-Level: X-Spam-Status: No, score=-0.732 tagged_above=-999 required=5 tests=[AWL=-0.547, 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 Ys4Dpypq4Uoq for ; Thu, 13 May 2010 06:29:22 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 695743A6B33 for ; Thu, 13 May 2010 06:28:27 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1OCYSW-0006Q1-1C for e2md@ietf.org; Thu, 13 May 2010 15:28:16 +0200 Date: Thu, 13 May 2010 15:28:16 +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] Action Required: Your version of the Problem statement needed 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, 13 May 2010 13:29:23 -0000 Dear E2MD fellows >From the different opinions stated within the last months, I've come to the conclusion that we are missing a common understanding of the problem statement for E2MD. Or in other words, I am not sure whether all of us are trying to solve the same problem... If we want to make progress of any kind we must sort this out, before taking any further steps. Therefore I kindly request all of you to express to this list, WHAT YOU THINK IS THE PROBLEM we are going to address with E2MD? Please send your version of the problem statement to this list no later than May 20th, 2010. (Note: the deadline for requesting meeting time for Maastricht is approaching.) Once we have collected all the different versions of problem statement, we can consolidate those and we will have a basis for the decision on the path forward. Looking forward to get your input (by Thu, 20 May 2010)! cheers, Bernie From richard@shockey.us Thu May 13 08:01: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 5A9203A6B39 for ; Thu, 13 May 2010 08:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[AWL=-0.612, 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 AnchQ5Y1YCxk for ; Thu, 13 May 2010 08:01:39 -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 1D25E3A68DF for ; Thu, 13 May 2010 08:01:38 -0700 (PDT) Received: (qmail 3828 invoked by uid 0); 13 May 2010 15:00:09 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 13 May 2010 15:00:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To: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=aewMhVZTF/b57X0Qj8azpowluCNMFBaUcSTLG2CeSPLLOeweBosHasskDDGSch8h/7y9g2VBn6rR4DB5VZhvSk7WT7VnrEA6eNg56f5bcOBL0qCFf0mRYA2tjgXDcUvh; 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 1OCZtP-0007TJ-F1; Thu, 13 May 2010 09:00:08 -0600 From: "Richard Shockey" To: "'Bernie Hoeneisen'" , "'E.164 To MetaData BOF discussion list'" References: In-Reply-To: Date: Thu, 13 May 2010 10:59:59 -0400 Message-ID: <002f01caf2ac$f69161a0$e3b424e0$@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: AcryoEf+8WYMkhCAR9qeXnqmZTaPKAACmKhw 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} Subject: Re: [e2md] Action Required: Your version of the Problem statement needed 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, 13 May 2010 15:01:40 -0000 Well for me its killing off SS7 and TCAP. People have other use cases that are also interesting. I don't think we have a issue understanding what is the problem statement is. Non URI data in ENUM. What about that doesn't people understand? Bernie why are you making this so complicated? >From what I can see there is little or no disagreement among the folks on this list except with Dean who is playing proxy for some BOF tourists in Anaheim. Shadow boxing future issues is intellectually interesting but at this stage counterproductive. The goal is forming WG and sorting out the issues there. The only goal right is revising the proposed charter for clarity and deciding on what you folks want to do in Maastricht because it is increasingly clear that I'm not going to be there. BTW there is another issue here. Dean has indicated he may not be in Maastricht either so there needs to be a group consensus on who should lead another BOF there. Frankly I'd like to nominate Ray Bellis for one of the co-chairs. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Bernie Hoeneisen Sent: Thursday, May 13, 2010 9:28 AM To: E.164 To MetaData BOF discussion list Subject: [e2md] Action Required: Your version of the Problem statement needed Dear E2MD fellows >From the different opinions stated within the last months, I've come to the conclusion that we are missing a common understanding of the problem statement for E2MD. Or in other words, I am not sure whether all of us are trying to solve the same problem... If we want to make progress of any kind we must sort this out, before taking any further steps. Therefore I kindly request all of you to express to this list, WHAT YOU THINK IS THE PROBLEM we are going to address with E2MD? Please send your version of the problem statement to this list no later than May 20th, 2010. (Note: the deadline for requesting meeting time for Maastricht is approaching.) Once we have collected all the different versions of problem statement, we can consolidate those and we will have a basis for the decision on the path forward. Looking forward to get your input (by Thu, 20 May 2010)! cheers, Bernie _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From Ray.Bellis@nominet.org.uk Thu May 13 08:55: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 001823A6C11 for ; Thu, 13 May 2010 08:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.79 X-Spam-Level: X-Spam-Status: No, score=-9.79 tagged_above=-999 required=5 tests=[AWL=0.809, 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 L8M-kCkkn4ZR for ; Thu, 13 May 2010 08:55:30 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 7764C3A68B3 for ; Thu, 13 May 2010 08:55:29 -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=CwLBaO49m93JJvQA1etsv95sTKxuzT7eN1xTLkcr/8cB+7HYlWTqGQIP +g8FYPko9cY8+gh5Wksg6EoyORoQaaRljQznEsPc0w3fRsfX5pODNOywA GSUjpxDy3qlwaYw; 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=1273766121; x=1305302121; 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]=20Action=20Required:=20Your=20ve rsion=20of=20the=20Problem=20statement=0D=0A=20needed |Date:=20Thu,=2013=20May=202010=2015:55:18=20+0000 |Message-ID:=20 |To:=20Richard=20Shockey=20|CC:=20'E. 164=20To=20MetaData=20BOF=20discussion=20list'=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20 quoted-printable|Content-ID:=20<0bccbfc0-e530-45ef-8420-b 70ac79e4d30>|In-Reply-To:=20<002f01caf2ac$f69161a0$e3b424 e0$@us>; bh=w3mIvmeMMgsSGyUzV4ZCRm8vLA1ob0jBMfbpd32Xh6c=; b=Ycb1mkIwkqKCZiZg8XyF1dZAGyOxcENniALZQ7dgp6VEbGOoLIW5HtfY J6kxwnSdadC+ysJykRqo5aOccslapvgQOmr7p5KJvN8jNOX2lkEtyWlAK CVEcXK7veAV+E4u; X-IronPort-AV: E=Sophos;i="4.53,223,1272841200"; d="scan'208";a="18591260" Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx4.nominet.org.uk with ESMTP; 13 May 2010 16:55:19 +0100 Received: from BDC-WDS-EXC1.okna.nominet.org.uk (2002:d5f8:c592::d5f8:c592) by wds-exc1.okna.nominet.org.uk (2002:d5f8:c590::d5f8:c590) with Microsoft SMTP Server (TLS) id 14.0.639.21; Thu, 13 May 2010 16:55:19 +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, 13 May 2010 16:55:18 +0100 From: Ray Bellis To: Richard Shockey Thread-Topic: [e2md] Action Required: Your version of the Problem statement needed Thread-Index: AQHK8rSvQFmUc0wtC0y3gcX9vEo2lg== Date: Thu, 13 May 2010 15:55:18 +0000 Message-ID: In-Reply-To: <002f01caf2ac$f69161a0$e3b424e0$@us> 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: <0bccbfc0-e530-45ef-8420-b70ac79e4d30> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Action Required: Your version of the Problem statement needed 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, 13 May 2010 15:55:32 -0000 > Non URI data in ENUM. Rich, That's part of it, I agree, but probably not sufficient. How about: "Records in ENUM-like databases which do not represent communication end-points". That covers: 1. trees other than e164.arpa (since they're not strictly "ENUM") 2. metadata like "unused" and "send-n" 3. data unnecessarily forced into "uri-like" syntax 4. the possibility of other RRs (not ideal for some of us, but needs addressing, if only to eliminate it). Ray From richard@shockey.us Thu May 13 09:30:54 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 D3D433A685A for ; Thu, 13 May 2010 09:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.519 X-Spam-Level: X-Spam-Status: No, score=-0.519 tagged_above=-999 required=5 tests=[AWL=-0.668, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] 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 SVScsguEnSen for ; Thu, 13 May 2010 09:30:53 -0700 (PDT) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id 904FE3A683C for ; Thu, 13 May 2010 09:30:51 -0700 (PDT) Received: (qmail 30369 invoked by uid 0); 13 May 2010 16:21:20 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 13 May 2010 16:21:20 -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=Ri4ivqMT17mjp43uBARLppU+44soGTXarghxvVMBIg2/dr5tq0czwQmWyVnaA+RRw3QpAvDc0wBCIpMShKK92LRmI37w6Ss1f4cwMxQIRVg3F6lo4WCRshcnHFXs11fv; 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 1OCb9z-0007VL-M5; Thu, 13 May 2010 10:21:20 -0600 From: "Richard Shockey" To: "'Ray Bellis'" References: <002f01caf2ac$f69161a0$e3b424e0$@us> In-Reply-To: Date: Thu, 13 May 2010 12:21:12 -0400 Message-ID: <001301caf2b8$4ea968f0$ebfc3ad0$@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: AQHK8rSvQFmUc0wtC0y3gcX9vEo2lpJPipuw 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] Action Required: Your version of the Problem statement needed 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, 13 May 2010 16:30:54 -0000 You have a point ... consider below... -----Original Message----- From: Ray Bellis [mailto:Ray.Bellis@nominet.org.uk] Sent: Thursday, May 13, 2010 11:55 AM To: Richard Shockey Cc: 'E.164 To MetaData BOF discussion list' Subject: Re: [e2md] Action Required: Your version of the Problem statement needed > Non URI data in ENUM. Rich, That's part of it, I agree, but probably not sufficient. How about: "Records in ENUM-like databases which do not represent communication end-points". "Records in ENUM like databases which do not represent Session Establishment Data (SED)" That aligns the terminology with SPEERMINT. That covers: 1. trees other than e164.arpa (since they're not strictly "ENUM") 2. metadata like "unused" and "send-n" 3. data unnecessarily forced into "uri-like" syntax 4. the possibility of other RRs (not ideal for some of us, but needs addressing, if only to eliminate it). Ray From Ray.Bellis@nominet.org.uk Thu May 13 10:09: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 4869D3A6C11 for ; Thu, 13 May 2010 10:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.925 X-Spam-Level: X-Spam-Status: No, score=-9.925 tagged_above=-999 required=5 tests=[AWL=0.674, 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 nJSWXSiAfZx4 for ; Thu, 13 May 2010 10:09:17 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 5988C3A6B83 for ; Thu, 13 May 2010 10:09:15 -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=D8qLV5pScGkbiIwde76TXPYo8FBm/LSpnsc8gMxVvtLzPJoMnW5Zn82t xpMAj/A1RtQE/zfi8nTyEVZpCtdsbg8Qhri5+3/3F0HHTlWXr8ZgBb4Hs X11FZMz5HsZMRSM; 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=1273770547; x=1305306547; 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]=20Action=20Required:=20Your=20ve rsion=20of=20the=20Problem=20statement=0D=0A=20needed |Date:=20Thu,=2013=20May=202010=2017:09:03=20+0000 |Message-ID:=20 |To:=20Richard=20Shockey=20|CC:=20'E. 164=20To=20MetaData=20BOF=20discussion=20list'=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20 quoted-printable|Content-ID:=20<0f581664-2d93-4650-bdd4-d adeb6030e1c>|In-Reply-To:=20<001301caf2b8$4ea968f0$ebfc3a d0$@us>; bh=+tpkXMFVi0Ip57JO4a8x0bl1H+N+9kBzDquMiB6jeyI=; b=zPsYUknIujXrfWWFDsq549aSGe4OgH5Zqba9GJcXKBgTsMOIbM61hK9R +09jySUCwekkplTJXa05TJtQ7aZ5QQqYIqrY9atEFGJ3iyOXWFXG/4mH/ WDVRSEdtmuEtZM/; X-IronPort-AV: E=Sophos;i="4.53,223,1272841200"; d="scan'208";a="18592017" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 13 May 2010 18:09:05 +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, 13 May 2010 18:09:05 +0100 From: Ray Bellis To: Richard Shockey Thread-Topic: [e2md] Action Required: Your version of the Problem statement needed Thread-Index: AQHK8rSvQFmUc0wtC0y3gcX9vEo2lpJPipuwgAAN9JE= Date: Thu, 13 May 2010 17:09:03 +0000 Message-ID: In-Reply-To: <001301caf2b8$4ea968f0$ebfc3ad0$@us> 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: <0f581664-2d93-4650-bdd4-dadeb6030e1c> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Action Required: Your version of the Problem statement needed 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, 13 May 2010 17:09:18 -0000 On 13/05/2010 17:21, "Richard Shockey" wrote: > "Records in ENUM like databases which do not represent Session Establishm= ent > Data (SED)" That aligns the terminology with SPEERMINT. Isn't that rather x-over-IP specific? (per the "Multimedia INTerconnect" part of the SPEERMINT acronym) Ray From dean.willis@softarmor.com Thu May 13 10:28:54 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 27E553A6BC1 for ; Thu, 13 May 2010 10:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.728 X-Spam-Level: X-Spam-Status: No, score=-0.728 tagged_above=-999 required=5 tests=[AWL=-0.729, 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 zNE6hFduS+fD for ; Thu, 13 May 2010 10:28:53 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id CA9A43A6C22 for ; Thu, 13 May 2010 10:26:17 -0700 (PDT) Received: from [192.168.2.2] (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 o4DHPuVm016686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 May 2010 12:25:58 -0500 Message-ID: <4BEC361F.4000607@softarmor.com> Date: Thu, 13 May 2010 12:25:51 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) MIME-Version: 1.0 To: Bernie Hoeneisen References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: [e2md] Dean's Proxy-Shill Version of the Problem statement 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, 13 May 2010 17:28:54 -0000 Bernie Hoeneisen wrote: > WHAT YOU THINK IS THE PROBLEM we are going to address with E2MD? Trying to address, or going to address? What we are currently trying to do based on current proposals and discussion, as seen by the people for whom I'm apparently either a meat-puppet or proxy or whipping-boy, depending on your POV: An easily extensible framework for inserting arbitrary data into the DNS, where that data is related to an E.164 number also resolvable in the DNS. The framework's organizational model is expected to be based as closely as possible on the existing ENUM framework. The framework is expected to provide for a multiplicity of different data types and provide for a semantic definition of each data type as well as define its relationship with the aforementioned E.164 number. The framework is NOT expected to provide a selective query mechanism; rather, a DNS query for framework data associated with an E.164 number is expected to return all such data known by the DNS to the querying node. The framework's expected query mechanism is straight-up DNS, and as such will make no considerations for authentication, authorization, or selective response based on the identity of the querying node. Further, the framework is expected to make no considerations for network congestion, reliability, integrity, privacy, or overly-large response sets beyond the inherent mechanisms of the DNS. The framework is expected to provide for standardization and IANA registration of new data types without a requirement for IETF consensus on each new data type. I believe every objection I've been able to understand is related to some assertion in the preceding statement. I've explored each one of these points on the list (and in many individual conversations with list participants), including making proposals for alternate constructions, and found that the group consensus comes back to supporting the above definition after we've talked about it awhile. It's probable that we don't see our consensus position from the same perspective as the "loyal opposition", but we really do need to understand and argue it from their point of view if we expect to overcome their arguments. -- dean From Ray.Bellis@nominet.org.uk Thu May 13 13:25: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 8FBDA3A67B2 for ; Thu, 13 May 2010 13:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.021 X-Spam-Level: X-Spam-Status: No, score=-10.021 tagged_above=-999 required=5 tests=[AWL=0.578, 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 mNnNHWVL1no8 for ; Thu, 13 May 2010 13:25:26 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 2571D3A68DE for ; Thu, 13 May 2010 13:24:47 -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=gTld1yx4rc/xDQYchyrnZF/NuRv9l5yBwu5STzF90HAlUA/qeMMogHZw HEK0WRZy9yaQoD8Qu6dIz2PqhLqY8RONL9i/ys1cLhTyiwrPMBt4NXf7J MF4OexyXvEcXFls; 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=1273782284; x=1305318284; 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]=20Dean's=20Proxy-Shill=20Version =20of=20the=20Problem=20statement|Date:=20Thu,=2013=20May =202010=2020:24:35=20+0000|Message-ID:=20|To:=20Dean=20Willis=20|CC:=20E.164=20To=20MetaData=20BOF=20di scussion=20list=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<51ccb07d-1c0c-4bcf-aec9-8883d810a28b> |In-Reply-To:=20<4BEC361F.4000607@softarmor.com>; bh=QKNB40+T7kLu5pwYb3pzhl3fu2kW5CWAF++UolOaxGI=; b=0t9Rwv4LPpM+vc9mhr/Q2X3bviHcQeYwlsetTtIDDBeCTj1PkeoMREbn Sm8ItmzZStj6bHAk268/Pfyg/k1QsA/3VCl4DnmFpB6wBR6rQXqe06iir x5KtgMjfj+rzttH; X-IronPort-AV: E=Sophos;i="4.53,224,1272841200"; d="scan'208";a="18594001" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 13 May 2010 21:24:37 +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, 13 May 2010 21:24:37 +0100 From: Ray Bellis To: Dean Willis Thread-Topic: [e2md] Dean's Proxy-Shill Version of the Problem statement Thread-Index: AQHK8sHDwrL8HcNm+EebiyZ93zdBepJPzxeA Date: Thu, 13 May 2010 20:24:35 +0000 Message-ID: In-Reply-To: <4BEC361F.4000607@softarmor.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-ID: <51ccb07d-1c0c-4bcf-aec9-8883d810a28b> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Dean's Proxy-Shill Version of the Problem statement 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, 13 May 2010 20:25:30 -0000 > An easily extensible framework for inserting arbitrary data into the DNS, > where that data is related to an E.164 number also resolvable in the DNS. > The framework's organizational model is expected to be based as closely a= s > possible on the existing ENUM framework. The framework is expected to pro= vide > for a multiplicity of different data types and provide for a semantic > definition of each data type as well as define its relationship with the > aforementioned E.164 number. OK, I'm with you up to here, although I'd argue that only the first sentenc= e is actually a "problem statement". > The framework is NOT expected to provide a selective query mechanism; rat= her, > a DNS query for framework data associated with an E.164 number is expecte= d to > return all such data known by the DNS to the querying node. Just like ENUM. > The framework's expected query mechanism is straight-up DNS, Just like ENUM. > and as such will make no considerations for authentication, authorization= , or > selective response based on the identity of the querying node. Just like ENUM. > Further, the framework is expected to make no considerations for network > congestion, reliability, integrity, privacy, or overly-large response set= s > beyond the inherent mechanisms of the DNS. Just like ENUM. > The framework is expected to provide for standardization and IANA registr= ation > of new data types without a requirement for IETF consensus on each new da= ta > type. Just like ENUM (=A73.4 of draft-ietf-enum-enumservices-guide) > I believe every objection I've been able to understand is related to some > assertion in the preceding statement. I've explored each one of these poi= nts > on the list (and in many individual conversations with list participants)= , > including making proposals for alternate constructions, and found that th= e > group consensus comes back to supporting the above definition after we've > talked about it awhile. Certain participants have particular as-yet undocumented use cases in mind which might benefit from selective responses. Of course that really _would= _ be problematic for the DNS folks, where objections to "Source URI" are already on record, and as also evidenced by the extensive discussions in DNSEXT regarding the Google/Yahoo! "client IP" option. Beyond that you're probably correct about the group consensus although I believe your choice of words on some of the allegedly contentious points is unnecessarily prejudicial. > It's probable that we don't see our consensus position from the same > perspective as the "loyal opposition", but we really do need to understan= d and > argue it from their point of view if we expect to overcome their argument= s. How can we understand and argue it from their point of view (and reach consensus according to the IETF way) unless they come here and put their point of view to us directly, in writing? If it's not here in black and white on the list then it's effectively just hearsay and FUD. I do appreciate what you're trying to do, but proxying for the nay-sayers i= s simply not going to achieve consensus. They need to come here and speak fo= r themselves. Kind regards, Ray From richard@shockey.us Thu May 13 14:46:05 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 AE24A3A6CF4 for ; Thu, 13 May 2010 14:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=0.724, 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 csHitixeqaXh for ; Thu, 13 May 2010 14:46:03 -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 8CEAA3A6924 for ; Thu, 13 May 2010 14:46:03 -0700 (PDT) Received: (qmail 18937 invoked by uid 0); 13 May 2010 20:52:05 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 13 May 2010 20:52:04 -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=arugIfXZil04FRKKVVhGJGku+YqDz2Ep4YWSzlOB9uGUX8dHVFCyL/fkZBKSEcGURBIxNPRwRNAB46i/zxPUJ1HGgWdwQA+wF+3zCXs4f+6R2UxpkqJaAzvkmKjT9YLv; 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 1OCfO0-0007JX-2A; Thu, 13 May 2010 14:52:04 -0600 From: "Richard Shockey" To: "'Ray Bellis'" References: <001301caf2b8$4ea968f0$ebfc3ad0$@us> In-Reply-To: Date: Thu, 13 May 2010 16:51:57 -0400 Message-ID: <008701caf2de$20fd4090$62f7c1b0$@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: AQHK8rSvQFmUc0wtC0y3gcX9vEo2lpJPipuwgAAN9JGAAD4sgA== 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] Action Required: Your version of the Problem statement needed 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, 13 May 2010 21:46:05 -0000 I may be thick this time of day but could you elaborate on your statement? I don't Grok it. -----Original Message----- From: Ray Bellis [mailto:Ray.Bellis@nominet.org.uk] Sent: Thursday, May 13, 2010 1:09 PM To: Richard Shockey Cc: 'E.164 To MetaData BOF discussion list' Subject: Re: [e2md] Action Required: Your version of the Problem statement needed On 13/05/2010 17:21, "Richard Shockey" wrote: > "Records in ENUM like databases which do not represent Session Establishment > Data (SED)" That aligns the terminology with SPEERMINT. Isn't that rather x-over-IP specific? (per the "Multimedia INTerconnect" part of the SPEERMINT acronym) Ray From dean.willis@softarmor.com Thu May 13 15:25: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 AB73A3A68AB for ; Thu, 13 May 2010 15:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.713 X-Spam-Level: X-Spam-Status: No, score=-0.713 tagged_above=-999 required=5 tests=[AWL=-0.714, 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 O5Q8Fw-LgdED for ; Thu, 13 May 2010 15:25:19 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8D3EB3A6918 for ; Thu, 13 May 2010 15:24:45 -0700 (PDT) Received: from [192.168.2.2] (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 o4DMOVJA019994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 May 2010 17:24:35 -0500 Message-ID: <4BEC7C1A.7050306@softarmor.com> Date: Thu, 13 May 2010 17:24:26 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) MIME-Version: 1.0 To: Ray Bellis References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Dean's Proxy-Shill Version of the Problem statement 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, 13 May 2010 22:25:20 -0000 Ray Bellis wrote: > > I do appreciate what you're trying to do, but proxying for the nay-sayers is > simply not going to achieve consensus. They need to come here and speak for > themselves. Practically speaking, they don't need to come here and we can't expect them to. They can achieve their goals merely by saying to the IESG/IAB (I*) that E2MD is a bad idea and should not have a working group. If pressed, all they have to do is rattle off the salient points in the problem description I gave, and shut up. Said problem description unfortunately hits a large majority of the "panic buttons". We might (and evidently do) believe they're wrong. To make a case, we need to 1) understand their arguments, 2) thoroughly refute those arguments, and 3) do so in writing and in an I-D that is clear, concise, and overcomes the arguments they're going to be making to the I*. This I-D needs to be in front of the I* and lay out the arguments, so that when they pop up, the I* has the refutation clearly in front of them. further, once the I-D is in front of the I*, we need to take the time to socialize it with the individuals involved. Once they've been talked through the argument (if it is sound), they're a lot more likely to press our opposition for details that said opposition is unlikely to be prepared to present. Think of this as a court case. The opposition are "confidential informants" with good standing before the court, espousing a position that is enshrined in tradition and practice. We're the plaintiffs, asking the court to set a new precedent. The burden of proof is on us. We aren't going to get very far by just showing up in front of the bewigged justices and shouting about our inherent rightness. -- Dean From dean.willis@softarmor.com Thu May 13 15:36: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 A76123A67C2 for ; Thu, 13 May 2010 15:36:43 -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.705, 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 1IVDlYiGRp3K for ; Thu, 13 May 2010 15:36:42 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 40F513A6881 for ; Thu, 13 May 2010 15:36:32 -0700 (PDT) Received: from [192.168.2.2] (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 o4DMaKWo020062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 May 2010 17:36:22 -0500 Message-ID: <4BEC7EDF.7000908@softarmor.com> Date: Thu, 13 May 2010 17:36:15 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) MIME-Version: 1.0 To: Ray Bellis References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Dean's Proxy-Shill Version of the Problem statement 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, 13 May 2010 22:36:43 -0000 Ray Bellis wrote: >> An easily extensible framework for inserting arbitrary data into the DNS, >> where that data is related to an E.164 number also resolvable in the DNS. >> The framework's organizational model is expected to be based as closely as >> possible on the existing ENUM framework. The framework is expected to provide >> for a multiplicity of different data types and provide for a semantic >> definition of each data type as well as define its relationship with the >> aforementioned E.164 number. > > OK, I'm with you up to here, although I'd argue that only the first sentence > is actually a "problem statement". Are the rest of the sentences true and consistent with the work we've proposed to do? ... > Just like ENUM. That's not an answer to the argument. From their POV, it is an assertion of what's wrong with the e2md approach. > Certain participants have particular as-yet undocumented use cases in mind > which might benefit from selective responses. Of course that really _would_ > be problematic for the DNS folks, where objections to "Source URI" are > already on record, and as also evidenced by the extensive discussions in > DNSEXT regarding the Google/Yahoo! "client IP" option. On the other hand, taking selective response and DNS' weakness in this area into consideration might well shift our solution space into another line, where the objections would not be so easily argued. In very large part, we're running into opposition because we're building on top of the DNS. If we were building a parallel system, or an adjunct system that DNS points into (but that puts the metadata itself outside the DNS) then we wouldn't be getting the pushback we're getting. So if there's any way WE can achieve consensus on a shift that alleviates this issue, then we really, really ought to consider it. > > Beyond that you're probably correct about the group consensus although I > believe your choice of words on some of the allegedly contentious points is > unnecessarily prejudicial. Are they truly prejudicial, or just succinct and unapologetic? Clearly they're emotionally loaded from the perspective of the IESG/IAB, but does that make them "wrong"? Remember, I'm trying to phrase it the way that "the opposition" will summarize the work, and they aren't going to sugar-coat the pill for us. We seem to feel like we have very good reasons for making the choices that are producing the allegedly contentious points. Maybe if we got them written down, we'd find that they're good enough to overcome the contention. I'm personally not convinced yet, biut I'm prepared to be. -- Dean From richard@shockey.us Thu May 13 16:37: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 E7CA63A68E4 for ; Thu, 13 May 2010 16:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.427 X-Spam-Level: X-Spam-Status: No, score=-0.427 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] 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 4vouci4Lp4Qs for ; Thu, 13 May 2010 16:37:00 -0700 (PDT) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id 640243A6802 for ; Thu, 13 May 2010 16:36:57 -0700 (PDT) Received: (qmail 11830 invoked by uid 0); 13 May 2010 22:48:55 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 13 May 2010 22:48:55 -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=D8ir3IgR4yFttErXAkDJ3ki7IAWuVCvnw6VldqFD4Im54EoT/QPlmNoFCCzbBBCHn2AATrSZQimhewX/dH8oK6CQvFFCln0BUhlqmsY9oY0hPmllCPKBwJRwfYHzy3lu; 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 1OChD5-00032Y-Ck; Thu, 13 May 2010 16:48:55 -0600 From: "Richard Shockey" To: "'Dean Willis'" , "'Ray Bellis'" References: <4BEC7C1A.7050306@softarmor.com> In-Reply-To: <4BEC7C1A.7050306@softarmor.com> Date: Thu, 13 May 2010 18:48:48 -0400 Message-ID: <00ce01caf2ee$740e6880$5c2b3980$@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: Acry6yenJfcX73/kQiilM3zk5vlIDwAAf0Tg 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] Dean's Proxy-Shill Version of the Problem statement 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, 13 May 2010 23:37:02 -0000 Ray Bellis wrote: > > I do appreciate what you're trying to do, but proxying for the nay-sayers is > simply not going to achieve consensus. They need to come here and speak for > themselves. Practically speaking, they don't need to come here and we can't expect them to. RS> of course we can expect them to voice their opinions they don't need a proxy. That is not the IETF way. They can achieve their goals merely by saying to the IESG/IAB (I*) that E2MD is a bad idea and should not have a working group. If pressed, all they have to do is rattle off the salient points in the problem description I gave, and shut up. Said problem description unfortunately hits a large majority of the "panic buttons". RS> Fine lets recharter the ENUM WG and find out. The existing ENUM charter was very explicit on allowing this kind of work to move forward. 2. The working group will examine and document the use of RFC 3761 to facilitate network interconnection for services using E.164 addressing. The working group will coordinate its activities with other IETF Working groups, existing or to be chartered, that are investigating elements of peering and or interconnection for VoIP or other services that typically use E.164 addressing. 3. The working group will continue examine and document various aspects of ENUM administrative and /or operational procedures irrespective of whether e164.arpa domain is used. 4. The working group will also examine the use of RFC 3761 technology for storing and delivering other information about services addressed by E.164 numbers, for example PSTN call routing and signaling data. We might (and evidently do) believe they're wrong. To make a case, we need to 1) understand their arguments, 2) thoroughly refute those arguments, and 3) do so in writing and in an I-D that is clear, concise, and overcomes the arguments they're going to be making to the I*. This I-D needs to be in front of the I* and lay out the arguments, so that when they pop up, the I* has the refutation clearly in front of them. further, once the I-D is in front of the I*, we need to take the time to socialize it with the individuals involved. Once they've been talked through the argument (if it is sound), they're a lot more likely to press our opposition for details that said opposition is unlikely to be prepared to present. Again let's just go to the IESG and right now find out. I've got precedent ( always a strong hand in any argument) and an approved charter on my side. And RFC and approved ID's that are explicit on the issues. IMHO we have the stronger argument and again this is not about the DNS its about making SIP actually deploy better. Think of this as a court case. The opposition are "confidential informants" with good standing before the court, espousing a position that is enshrined in tradition and practice. We're the plaintiffs, asking the court to set a new precedent. The burden of proof is on us. We aren't going to get very far by just showing up in front of the bewigged justices and shouting about our inherent rightness. Dean you have been working for lawyers too long. -- Dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From Ray.Bellis@nominet.org.uk Thu May 13 17:39: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 4A1BD3A6986 for ; Thu, 13 May 2010 17:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.093 X-Spam-Level: X-Spam-Status: No, score=-10.093 tagged_above=-999 required=5 tests=[AWL=0.506, 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 zHuossAsFud6 for ; Thu, 13 May 2010 17:38:59 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 8EA553A695D for ; Thu, 13 May 2010 17:38:59 -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=wwHR5rLCTcFdAXfNcCwM/3YZsJ8h1fLlU44HDjBr9XShk35gh35xPqnG 4X+tdV15dMZTQgvQF7C2EECXlQWT+SfiC6GxhUdkOtSq89iRaP9ecK3d3 lDDCvhr9MEaGRfR; 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=1273797530; x=1305333530; 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]=20Dean's=20Proxy-Shill=20Version =20of=20the=20Problem=20statement|Date:=20Fri,=2014=20May =202010=2000:38:46=20+0000|Message-ID:=20|To:=20Dean=20Willis=20|CC:=20E.164=20To=20MetaData=20BOF=20di scussion=20list=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20 |In-Reply-To:=20<4BEC7EDF.7000908@softarmor.com>; bh=NT2AyJzx+OtEIi9s0NrUhF2ZzALRDGYNKtcOYVDWFfI=; b=tbrUS9ew+14hK3178Cx5Op8HGwpY4DkITs2ONhW+7aLkhJBOasfHWnhJ nsA/fAbpcQIcGLSX8uKxubOIVlMy9xvY0F5BWjvrU44FIg9SrFZeLYjJg KKqWmg9zGYLZmPv; X-IronPort-AV: E=Sophos;i="4.53,225,1272841200"; d="scan'208";a="24227630" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 14 May 2010 01:38:48 +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; Fri, 14 May 2010 01:38:47 +0100 From: Ray Bellis To: Dean Willis Thread-Topic: [e2md] Dean's Proxy-Shill Version of the Problem statement Thread-Index: AQHK8sHDwrL8HcNm+EebiyZ93zdBepJPzxeAgAAUBoCAADL/AA== Date: Fri, 14 May 2010 00:38:46 +0000 Message-ID: In-Reply-To: <4BEC7EDF.7000908@softarmor.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: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Dean's Proxy-Shill Version of the Problem statement 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, 14 May 2010 00:39:01 -0000 > Are the rest of the sentences true and consistent with the work we've pro= posed > to do? They're consistent with the approach in Bernie's draft. However on the last call the it was proposed that it might be a good idea to simply reboot the ENUM WG. In another message Richard has shown that much (if not all) of what we want to do is _already_ within charter. [[[ I first proposed E2M during the Dublin IETF, as a way to mitigate concerns that a particular ex-AD had over use of E2U for "non-communications data". AFAICR he was OK with this proposal, which then laid dormant until Bernie wrote it up. For my own Send-N draft, my plan had actually been to simply wait for the ENUM Services Guide draft to become an RFC, and the re-file under the exper= t review process. ]]] Ray From richard@shockey.us Thu May 13 18:20: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 349B93A68D5 for ; Thu, 13 May 2010 18:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.725, 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 qMaEgo5xM++p for ; Thu, 13 May 2010 18:20:32 -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 0FD133A6928 for ; Thu, 13 May 2010 18:20:30 -0700 (PDT) Received: (qmail 22778 invoked by uid 0); 14 May 2010 01:20:20 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 14 May 2010 01:20:20 -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=B9SGg+FPztZjKMKzGzrpLtKPyFZne9ZYyDFSXBi1heGmeiEaWmxphJ98doc3H/fibJDSBwu5gyxatiebeckvv+Mjyl2ZIQxR33RoqU+qHlDjJz5jx0m6aaE7sb2WAnZ/; 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 1OCjZc-0004Xf-Ap; Thu, 13 May 2010 19:20:20 -0600 From: "Richard Shockey" To: "'Ray Bellis'" , "'Dean Willis'" References: <4BEC7EDF.7000908@softarmor.com> In-Reply-To: Date: Thu, 13 May 2010 21:20:13 -0400 Message-ID: <00e501caf303$9b166cb0$d1434610$@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: AQHK8sHDwrL8HcNm+EebiyZ93zdBepJPzxeAgAAUBoCAADL/AIAACXdg 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: 'IETF ENUM list' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Dean's Proxy-Shill Version of the Problem statement 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, 14 May 2010 01:20:32 -0000 So ... all in favor of re chartering the ENUM WG ..please hum on this list or the ENUM WG list now attached. Its time to force the issue. This is important work ultimately central to making SIP work better. Stall and delay is not a rational option here. SIP Service providers and IMS providers want clarity and direction on where the technical standards are moving, if at all. If the IETF doesn't do this it will be done privately and without proper community and peer review. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Ray Bellis Sent: Thursday, May 13, 2010 8:39 PM To: Dean Willis Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] Dean's Proxy-Shill Version of the Problem statement > Are the rest of the sentences true and consistent with the work we've proposed > to do? They're consistent with the approach in Bernie's draft. However on the last call the it was proposed that it might be a good idea to simply reboot the ENUM WG. In another message Richard has shown that much (if not all) of what we want to do is _already_ within charter. [[[ I first proposed E2M during the Dublin IETF, as a way to mitigate concerns that a particular ex-AD had over use of E2U for "non-communications data". AFAICR he was OK with this proposal, which then laid dormant until Bernie wrote it up. For my own Send-N draft, my plan had actually been to simply wait for the ENUM Services Guide draft to become an RFC, and the re-file under the expert review process. ]]] Ray _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From Ray.Bellis@nominet.org.uk Fri May 14 00:24: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 ED04D3A6A38 for ; Fri, 14 May 2010 00:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.15 X-Spam-Level: X-Spam-Status: No, score=-10.15 tagged_above=-999 required=5 tests=[AWL=0.449, 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 l7m2Za0kDiQZ for ; Fri, 14 May 2010 00:24:29 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id ADCD73A6A36 for ; Fri, 14 May 2010 00:23:40 -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=fPK6vDlDVqQLmzQigrzyJGcXGLQex22T3IkeRUhS5a2vjf1T+KPCIeq6 PIQ5lUOwLA+ThelDsOHXQjPaqgYmlCr0QzVpEy7GNH7RYnVvkumtYjyhk 0MuB43vlt+jFkFn; 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=1273821811; x=1305357811; 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]=20Action=20Required:=20Your=20ve rsion=20of=20the=20Problem=20statement=0D=0A=20needed |Date:=20Fri,=2014=20May=202010=2007:23:28=20+0000 |Message-ID:=20 |To:=20Richard=20Shockey=20|CC:=20'E. 164=20To=20MetaData=20BOF=20discussion=20list'=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20 quoted-printable|Content-ID:=20<24405780-9bc0-4829-89ee-e fda199dbe74>|In-Reply-To:=20<008701caf2de$20fd4090$62f7c1 b0$@us>; bh=anq5T0yZflfYk18QWEHSVqzpx/iE/spuW4pBXxLEGJQ=; b=ae2ZJ7OxbZEKyydWFGhxFM3+0tsSL0Mfio6nK06a7MRQKJANU/MSetx4 DTLW4S0mRMChTOem8k4orAbz/+aW0C0ZnwIsZ1PL47QPEaCHwKvT9GsCv 04WXH1gpXs1YThG; X-IronPort-AV: E=Sophos;i="4.53,227,1272841200"; d="scan'208";a="18597764" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 14 May 2010 08:23:29 +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; Fri, 14 May 2010 08:23:29 +0100 From: Ray Bellis To: Richard Shockey Thread-Topic: [e2md] Action Required: Your version of the Problem statement needed Thread-Index: AQHK8rSvQFmUc0wtC0y3gcX9vEo2lpJPipuwgAAN9JGAAD4sgIAAsI3W Date: Fri, 14 May 2010 07:23:28 +0000 Message-ID: In-Reply-To: <008701caf2de$20fd4090$62f7c1b0$@us> 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: <24405780-9bc0-4829-89ee-efda199dbe74> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Action Required: Your version of the Problem statement needed 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, 14 May 2010 07:24:31 -0000 > I may be thick this time of day but could you elaborate on your statement= ? I > don't Grok it. I meant that the SPEERMINT term "SED" only applies (IMHO) to those communication protocols that come under "multimedia" - e.g. SIP, etc. We already have 'http' and 'mailto' URIs in ENUM, and whilst (at a stretch) those could be considered "communication end-points" I wouldn't consider them "SED". Ray P.s. +1 to the hum From bernie@ietf.hoeneisen.ch Fri May 14 00:57:57 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 515A83A6A4A for ; Fri, 14 May 2010 00:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.680, 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 94cnUy8BCX0i for ; Fri, 14 May 2010 00:57:56 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 6157B3A687B for ; Fri, 14 May 2010 00:57:56 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1OCpmB-0002qv-3I; Fri, 14 May 2010 09:57:43 +0200 Date: Fri, 14 May 2010 09:57:42 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Ray Bellis In-Reply-To: Message-ID: References: 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] Dean's Proxy-Shill Version of the Problem statement 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, 14 May 2010 07:57:57 -0000 On Fri, 14 May 2010, Ray Bellis wrote: >> Are the rest of the sentences true and consistent with the work we've >> proposed to do? > > They're consistent with the approach in Bernie's draft. Just for clarification: http://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-02 (based on the Dublin discussions and other sources) has never intended to force a particular solution. I intended to provide a problem statement and propose a possible solution to the problem that was being discussed prior to submission as I-D. I still believe a solution along the lines of http://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-02 is feasible, however we need to address the concerns that have been raised in the meantime, one way or the other. cheers, Bernie From dean.willis@softarmor.com Fri May 14 01:11: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 66B6D3A698D for ; Fri, 14 May 2010 01:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[AWL=-0.593, 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 PbfOTk9R2Op2 for ; Fri, 14 May 2010 01:11:24 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 783213A6A67 for ; Fri, 14 May 2010 01:11:24 -0700 (PDT) Received: from [192.168.2.109] (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 o4E8B2s0024360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 May 2010 03:11:04 -0500 Message-ID: <4BED0591.9070608@softarmor.com> Date: Fri, 14 May 2010 03:10:57 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernie Hoeneisen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Dean's Proxy-Shill Version of the Problem statement 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, 14 May 2010 08:11:30 -0000 Bernie Hoeneisen wrote: > On Fri, 14 May 2010, Ray Bellis wrote: > >>> Are the rest of the sentences true and consistent with the work we've >>> proposed to do? >> >> >> They're consistent with the approach in Bernie's draft. > > > Just for clarification: > > http://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-02 (based on > the Dublin discussions and other sources) has never intended to force a > particular solution. I intended to provide a problem statement and > propose a possible solution to the problem that was being discussed > prior to submission as I-D. > > I still believe a solution along the lines of > http://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-02 is > feasible, however we need to address the concerns that have been raised > in the meantime, one way or the other. Ok, that's important to think about. Most of the "concerned parties" who spoke to me before or after the Anaheim BOF seemed to think that the cited draft's approach was a "done deal" and the that we were asking to form a WG that would polish that approach and send it up the tree. Just how far away from that approach would we be willing to explore? Might we, for example, consider a model where the data is held somewhere outside of ENUM, and ENUM just contains a pointer to the data? I ask because everytime we've started to move away from the metadata-in-enum model in conversation, we seem to have moved quickly back to it. -- Dean From bernie@ietf.hoeneisen.ch Fri May 14 01:15: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 2591C28C0F4; Fri, 14 May 2010 01:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.656, 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 Sb4Q89qbkLXw; Fri, 14 May 2010 01:15:45 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 3A20A3A6A67; Fri, 14 May 2010 01:15:20 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1OCq2y-0002vk-CQ; Fri, 14 May 2010 10:15:04 +0200 Date: Fri, 14 May 2010 10:15:04 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Richard Shockey In-Reply-To: <00e501caf303$9b166cb0$d1434610$@us> Message-ID: References: <4BEC7EDF.7000908@softarmor.com> <00e501caf303$9b166cb0$d1434610$@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: 'IETF ENUM list' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Dean's Proxy-Shill Version of the Problem statement 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, 14 May 2010 08:15:46 -0000 As an individual I see it a viable way to work out at least parts of the E2MD cases in the ENUM WG (once we've sorted out which parts are suitable). In this case E2MD would continue to work on those parts that are not suitable for ENUM. As a co-chair of the ENUM WG the appropriate answer to this consultative hum from Rich is: abstention cheers, Bernie On Thu, 13 May 2010, Richard Shockey wrote: > So ... all in favor of re chartering the ENUM WG ..please hum on this list > or the ENUM WG list now attached. > > Its time to force the issue. This is important work ultimately central to > making SIP work better. Stall and delay is not a rational option here. SIP > Service providers and IMS providers want clarity and direction on where the > technical standards are moving, if at all. If the IETF doesn't do this it > will be done privately and without proper community and peer review. > > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Ray > Bellis > Sent: Thursday, May 13, 2010 8:39 PM > To: Dean Willis > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] Dean's Proxy-Shill Version of the Problem statement > > >> Are the rest of the sentences true and consistent with the work we've > proposed >> to do? > > They're consistent with the approach in Bernie's draft. > > However on the last call the it was proposed that it might be a good > idea to simply reboot the ENUM WG. In another message Richard has shown > that much (if not all) of what we want to do is _already_ within charter. > > [[[ > I first proposed E2M during the Dublin IETF, as a way to mitigate concerns > that a particular ex-AD had over use of E2U for "non-communications data". > AFAICR he was OK with this proposal, which then laid dormant until Bernie > wrote it up. > > For my own Send-N draft, my plan had actually been to simply wait for the > ENUM Services Guide draft to become an RFC, and the re-file under the expert > review process. > ]]] > > 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 Ray.Bellis@nominet.org.uk Fri May 14 01:28: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 A0CDA28C0FC for ; Fri, 14 May 2010 01:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.195 X-Spam-Level: X-Spam-Status: No, score=-10.195 tagged_above=-999 required=5 tests=[AWL=0.404, 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 aAk6QCAhP7e0 for ; Fri, 14 May 2010 01:28:05 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 7A0B028C107 for ; Fri, 14 May 2010 01:25:54 -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=aR1g1HN7AdPDJk2ljvj8ILr1FaBTY96Vv/HvrVm2n02SjYgtEp4BteMp Lra2V17GR0thvRRMFIjevJunHA5FN4qEHmLu8DR3FnvEInyoSYA7DaXyY cNhGDWU5LeEqrcQ; 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=1273825545; x=1305361545; 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]=20Dean's=20Proxy-Shill=20Version =20of=20the=20Problem=20statement|Date:=20Fri,=2014=20May =202010=2008:25:31=20+0000|Message-ID:=20|To:=20Dean=20Willis=20|CC:=20E.164=20To=20MetaData=20BOF=20di scussion=20list=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<26f70bf6-cd0c-4f9a-b95a-7fe5c9ba6a16> |In-Reply-To:=20<4BED0591.9070608@softarmor.com>; bh=hKGlj1yxQCwzTZu2hYIDu3rRE8RwAHbcSu8PBvxh8kE=; b=5pxSG7J11cuWtauDu+NnY7ijcwo6c+1hYEHMRdVs/0N4bbtvkoxrTzv2 jdUBnnXFLnH28LRYnOM+3f53kly+BgkwEz1YUxM/85ioes1v7VDOoO3X6 lyueMJS/JhA+iW4; X-IronPort-AV: E=Sophos;i="4.53,227,1272841200"; d="scan'208";a="24230944" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 14 May 2010 09:25:35 +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; Fri, 14 May 2010 09:25:34 +0100 From: Ray Bellis To: Dean Willis Thread-Topic: [e2md] Dean's Proxy-Shill Version of the Problem statement Thread-Index: AQHK8sHDwrL8HcNm+EebiyZ93zdBepJPzxeAgAAUBoCAADL/AIAAad8AgAADtICAABTVgA== Date: Fri, 14 May 2010 08:25:31 +0000 Message-ID: In-Reply-To: <4BED0591.9070608@softarmor.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: <26f70bf6-cd0c-4f9a-b95a-7fe5c9ba6a16> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Dean's Proxy-Shill Version of the Problem statement 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, 14 May 2010 08:28:06 -0000 > Just how far away from that approach would we be willing to explore? > Might we, for example, consider a model where the data is held somewhere > outside of ENUM, and ENUM just contains a pointer to the data? That depends on the data. For Send-N, absolutely not. The data is trivially small, and getting it returned as quickly as possible in response to a query for an incomplete number is a specific design goal. For the example given during the BOF of a record describing a ring tone, absolutely! That should clearly take the form of a *reference* to the ring-tone data, and not the data itself. For unused, maybe a hybrid approach - a small amount of data might be necessary in the actual record (i.e. a "reason code", combined with a reference to more detailed information). Ray From jim@rfc1035.com Fri May 14 05:16: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 306133A6BC7 for ; Fri, 14 May 2010 05:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.37 X-Spam-Level: X-Spam-Status: No, score=-0.37 tagged_above=-999 required=5 tests=[AWL=0.370, 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 J4mzyv-p2BHj for ; Fri, 14 May 2010 05:16:09 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id 746813A6BC5 for ; Fri, 14 May 2010 05:15:23 -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 96B241542837; Fri, 14 May 2010 13:15:11 +0100 (BST) Message-Id: <280CDB63-BC7F-413D-BD38-440CA42E134E@rfc1035.com> From: Jim Reid To: Dean Willis In-Reply-To: <4BEC7C1A.7050306@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, 14 May 2010 13:15:11 +0100 References: <4BEC7C1A.7050306@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Dean's Proxy-Shill Version of the Problem statement 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, 14 May 2010 12:16:10 -0000 On 13 May 2010, at 23:24, Dean Willis wrote: > Practically speaking, they don't need to come here and we can't expect > them to. EH? Let me see if I've got this right. Some anonymous greybeards (who may or may not exist) don't/won't participate in the discussion or provide a clear indication of their concerns and requirements. But they get an absolute veto whatever bottom-up consensus the rest of us agree. Is this how the IETF works these days? From jim@rfc1035.com Fri May 14 05:18: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 0BF8F3A6B09; Fri, 14 May 2010 05:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.323 X-Spam-Level: X-Spam-Status: No, score=-1.323 tagged_above=-999 required=5 tests=[AWL=1.276, 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 dsfQAdDf9wcp; Fri, 14 May 2010 05:18:40 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id 1720E3A6BB5; Fri, 14 May 2010 05:17:28 -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 7935D1542837; Fri, 14 May 2010 13:17:17 +0100 (BST) Message-Id: From: Jim Reid To: "Richard Shockey" In-Reply-To: <00e501caf303$9b166cb0$d1434610$@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: Fri, 14 May 2010 13:17:17 +0100 References: <4BEC7EDF.7000908@softarmor.com> <00e501caf303$9b166cb0$d1434610$@us> X-Mailer: Apple Mail (2.936) Cc: 'IETF ENUM list' , "'E.164 To MetaData BOF discussion list'" Subject: [e2md] Rechartering the ENUM WG 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, 14 May 2010 12:18:41 -0000 On 14 May 2010, at 02:20, Richard Shockey wrote: > So ... all in favor of re chartering the ENUM WG ..please hum on > this list > or the ENUM WG list now attached. hum++ Apologies for a relevant SubjectL header. :-) From cdel@firsthand.net Fri May 14 05:50: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 CCE8C3A6AA7; Fri, 14 May 2010 05:50:46 -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 3Yn0oWFP21lh; Fri, 14 May 2010 05:50:45 -0700 (PDT) Received: from outmail28.go.net.mt (outmail50.go.net.mt [80.93.157.50]) by core3.amsl.com (Postfix) with ESMTP id 91AC03A6971; Fri, 14 May 2010 05:50:43 -0700 (PDT) Received: from [172.20.1.72] (helo=fender72.go.net.mt) by outmail28.go.net.mt with esmtp (Exim 4.67) (envelope-from ) id 1OCuLS-000752-4a; Fri, 14 May 2010 14:50:26 +0200 Received: from [195.158.93.136] (helo=[192.168.3.5]) by fender72.go.net.mt with esmtp (Exim 4.67) (envelope-from ) id 1OCuLR-0007JW-UM; Fri, 14 May 2010 14:50:26 +0200 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Christian Larrinaga In-Reply-To: <00e501caf303$9b166cb0$d1434610$@us> Date: Fri, 14 May 2010 14:50:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BEC7EDF.7000908@softarmor.com> <00e501caf303$9b166cb0$d1434610$@us> To: Richard Shockey X-Mailer: Apple Mail (2.1078) X-Mailman-Approved-At: Fri, 14 May 2010 06:18:59 -0700 Cc: 'IETF ENUM list' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] [Enum] Dean's Proxy-Shill Version of the Problem statement 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, 14 May 2010 12:50:46 -0000 I don't believe IETF should be afraid if others decide to take IETF = stuff and do their own take with it. That is not a good reason to do = those carbuncle things In IETF. What is a good reason is if the WG is = taking the initiative and doing work that is for everyone, scales and = isn't just trying to satisfy a need in some walled garden.=20 So what would be the workplan? Apologies if I've missed a draft that = explains this. In which case I would be grateful for a pointer.=20 Christian On 14 May 2010, at 03:20, Richard Shockey wrote: > So ... all in favor of re chartering the ENUM WG ..please hum on this = list > or the ENUM WG list now attached. >=20 > Its time to force the issue. This is important work ultimately central = to > making SIP work better. Stall and delay is not a rational option here. = SIP > Service providers and IMS providers want clarity and direction on = where the > technical standards are moving, if at all. If the IETF doesn't do this = it > will be done privately and without proper community and peer review.=20= >=20 > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf = Of Ray > Bellis > Sent: Thursday, May 13, 2010 8:39 PM > To: Dean Willis > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] Dean's Proxy-Shill Version of the Problem = statement >=20 >=20 >> Are the rest of the sentences true and consistent with the work we've > proposed >> to do? >=20 > They're consistent with the approach in Bernie's draft. >=20 > However on the last call the it was proposed that it might be a good > idea to simply reboot the ENUM WG. In another message Richard has = shown > that much (if not all) of what we want to do is _already_ within = charter. >=20 > [[[ > I first proposed E2M during the Dublin IETF, as a way to mitigate = concerns > that a particular ex-AD had over use of E2U for "non-communications = data". > AFAICR he was OK with this proposal, which then laid dormant until = Bernie > wrote it up. >=20 > For my own Send-N draft, my plan had actually been to simply wait for = the > ENUM Services Guide draft to become an RFC, and the re-file under the = expert > review process. > ]]] >=20 > Ray >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri May 14 06:51: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 799413A68CF for ; Fri, 14 May 2010 06:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.744 X-Spam-Level: X-Spam-Status: No, score=-1.744 tagged_above=-999 required=5 tests=[AWL=0.521, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 VeJECmBYMmiA for ; Fri, 14 May 2010 06:51:10 -0700 (PDT) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id 45C0E3A6903 for ; Fri, 14 May 2010 06:51:10 -0700 (PDT) Received: (qmail 14594 invoked by uid 0); 14 May 2010 13:51:01 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 14 May 2010 13:51:01 -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=RLwov4AL/XpPbkEgdzfV2om1SNsOiLJW//iL9Kj0tXtNLVkkFNc2NNanDJ6rA7Mild41RH8mYOo3tO4nJbI4vi3csIoQNgUFHSL3ao1iPxvc0P/3bm6jxpKYKJGJLzrO; 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 1OCvI4-0000XE-NG; Fri, 14 May 2010 07:51:01 -0600 From: "Richard Shockey" To: "'Ray Bellis'" , "'Dean Willis'" References: <4BED0591.9070608@softarmor.com> In-Reply-To: Date: Fri, 14 May 2010 09:50:54 -0400 Message-ID: <006401caf36c$79b716a0$6d2543e0$@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: AQHK8sHDwrL8HcNm+EebiyZ93zdBepJPzxeAgAAUBoCAADL/AIAAad8AgAADtICAABTVgIAAWmPA 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] Dean's Proxy-Shill Version of the Problem statement 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, 14 May 2010 13:51:11 -0000 CNAM is either way .. if the data is going to be used in a public DNS tree yes there probably should be pointer that requires authentication. For all the infrastructure EWNUM systems no..its just a look up function in a closed trusted tree. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Ray Bellis Sent: Friday, May 14, 2010 4:26 AM To: Dean Willis Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] Dean's Proxy-Shill Version of the Problem statement > Just how far away from that approach would we be willing to explore? > Might we, for example, consider a model where the data is held somewhere > outside of ENUM, and ENUM just contains a pointer to the data? That depends on the data. For Send-N, absolutely not. The data is trivially small, and getting it returned as quickly as possible in response to a query for an incomplete number is a specific design goal. For the example given during the BOF of a record describing a ring tone, absolutely! That should clearly take the form of a *reference* to the ring-tone data, and not the data itself. For unused, maybe a hybrid approach - a small amount of data might be necessary in the actual record (i.e. a "reason code", combined with a reference to more detailed information). Ray _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From richard@shockey.us Fri May 14 06: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 1BC2E3A6839 for ; Fri, 14 May 2010 06:54:19 -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.069, 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 m-4JC5b5skd8 for ; Fri, 14 May 2010 06:54:17 -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 84AFE3A680A for ; Fri, 14 May 2010 06:54:16 -0700 (PDT) Received: (qmail 27127 invoked by uid 0); 14 May 2010 13:53:12 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 14 May 2010 13:53: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=HHH76tB/PoeNmQyRo1ahUt/s2yjBzI3T5r+YE1zo0/0dNwJPrHvI3OZKMnmmYK7QbVM5/pi6a9xC8z+bJc0GbK+3kJwuRoDKXe/EujxZTvf/nT69EWspgDVUZtRNZ+Rb; 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 1OCvKC-0002CP-8h; Fri, 14 May 2010 07:53:12 -0600 From: "Richard Shockey" To: "'Jim Reid'" , "'Dean Willis'" References: <4BEC7C1A.7050306@softarmor.com> <280CDB63-BC7F-413D-BD38-440CA42E134E@rfc1035.com> In-Reply-To: <280CDB63-BC7F-413D-BD38-440CA42E134E@rfc1035.com> Date: Fri, 14 May 2010 09:53:06 -0400 Message-ID: <006501caf36c$c81a1310$584e3930$@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: AcrzXzkquT2vx7/6Rji42+SZsAzCeQADVLvA 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] Dean's Proxy-Shill Version of the Problem statement 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, 14 May 2010 13:54:19 -0000 So it seems, plus rough consensus is no longer tolerated ..its unanimous consent. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Jim Reid Sent: Friday, May 14, 2010 8:15 AM To: Dean Willis Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] Dean's Proxy-Shill Version of the Problem statement On 13 May 2010, at 23:24, Dean Willis wrote: > Practically speaking, they don't need to come here and we can't expect > them to. EH? Let me see if I've got this right. Some anonymous greybeards (who may or may not exist) don't/won't participate in the discussion or provide a clear indication of their concerns and requirements. But they get an absolute veto whatever bottom-up consensus the rest of us agree. Is this how the IETF works these days? _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From lendl@nic.at Fri May 14 07:03:59 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2775C3A68B1 for ; Fri, 14 May 2010 07:03:59 -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 GfBRg8uM1TRM for ; Fri, 14 May 2010 07:03:58 -0700 (PDT) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 163EC28C117 for ; Fri, 14 May 2010 07:03:57 -0700 (PDT) Received: from [10.10.0.212] (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 4A4854D02C for ; Fri, 14 May 2010 16:03:46 +0200 (CEST) Message-ID: <4BED5842.4020101@nic.at> Date: Fri, 14 May 2010 16:03:46 +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: <002f01caf2ac$f69161a0$e3b424e0$@us> In-Reply-To: <002f01caf2ac$f69161a0$e3b424e0$@us> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [e2md] Action Required: Your version of the Problem statement needed 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, 14 May 2010 14:03:59 -0000 On 13.05.2010 16:59, Richard Shockey wrote: > > Non URI data in ENUM. What about that doesn't people understand? > Ok. Can I take it as a given that you don't need E2MD to support * different answers based on who's asking * different answers based on source-URI * different answers based on some kind of trunk (or SIP-peer) information ? otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From HKaplan@acmepacket.com Fri May 14 07:38: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 622203A698B for ; Fri, 14 May 2010 07:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.487 X-Spam-Level: X-Spam-Status: No, score=-1.487 tagged_above=-999 required=5 tests=[AWL=-0.377, 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 zK9lw2MX0E-S for ; Fri, 14 May 2010 07:38:43 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 524F63A688B for ; Fri, 14 May 2010 07:38:43 -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, 14 May 2010 10:38:33 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 14 May 2010 10:38:32 -0400 From: Hadriel Kaplan To: Jim Reid , Dean Willis Date: Fri, 14 May 2010 10:38:31 -0400 Thread-Topic: [e2md] Dean's Proxy-Shill Version of the Problem statement Thread-Index: AcrzX0cpBu1ZLPPcSWSM4OoRwPsNCAADfLBw Message-ID: <430FC6BDED356B4C8498F634416644A91C139911FD@mail> References: <4BEC7C1A.7050306@softarmor.com> <280CDB63-BC7F-413D-BD38-440CA42E134E@rfc1035.com> In-Reply-To: <280CDB63-BC7F-413D-BD38-440CA42E134E@rfc1035.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] Dean's Proxy-Shill Version of the Problem statement 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, 14 May 2010 14:38:44 -0000 We can't expect people who object to an E2MD working group to join this mai= ling list to voice their objections - this isn't even an official working g= roup mailing list! And even if it were, it's not reasonable for everyone i= n the IETF to join every IETF mailing list they don't like. Only the peopl= e *interested* in the topic join a particular list, not people dis-interest= ed in the topic. =20 The process of the IETF is for people with a common problem and goal create= a charter to work on it, and that charter gets hashed out in public. This= mailing list is simply to help us hash out such a charter - not the place = for the public consensus debate. Dean's just trying to lay out what object= ions we'll face if we try it again. -hadriel > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Jim Reid > Sent: Friday, May 14, 2010 8:15 AM > To: Dean Willis > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] Dean's Proxy-Shill Version of the Problem statement >=20 > On 13 May 2010, at 23:24, Dean Willis wrote: >=20 > > Practically speaking, they don't need to come here and we can't expect > > them to. >=20 > EH? Let me see if I've got this right. Some anonymous greybeards (who > may or may not exist) don't/won't participate in the discussion or > provide a clear indication of their concerns and requirements. But > they get an absolute veto whatever bottom-up consensus the rest of us > agree. Is this how the IETF works these days? > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From dean.willis@softarmor.com Fri May 14 09:09: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 6FFCF3A6B4E for ; Fri, 14 May 2010 09:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[AWL=-0.679, 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 UntQAcqR7oXd for ; Fri, 14 May 2010 09:09:49 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 73CBC3A6B5D for ; Fri, 14 May 2010 09:09:49 -0700 (PDT) Received: from [192.168.2.109] (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 o4EG9ckB028765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 May 2010 11:09:40 -0500 Message-ID: <4BED75BA.1010508@softarmor.com> Date: Fri, 14 May 2010 11:09:30 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Reid References: <4BEC7C1A.7050306@softarmor.com> <280CDB63-BC7F-413D-BD38-440CA42E134E@rfc1035.com> In-Reply-To: <280CDB63-BC7F-413D-BD38-440CA42E134E@rfc1035.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Dean's Proxy-Shill Version of the Problem statement 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, 14 May 2010 16:09:50 -0000 Jim Reid wrote: > On 13 May 2010, at 23:24, Dean Willis wrote: > >> Practically speaking, they don't need to come here and we can't expect >> them to. > > > EH? Let me see if I've got this right. Some anonymous greybeards (who > may or may not exist) don't/won't participate in the discussion or > provide a clear indication of their concerns and requirements. But they > get an absolute veto whatever bottom-up consensus the rest of us agree. > Is this how the IETF works these days? > Yep. That's pretty much the BOF process in a nutshell. The BOF makes areguments "for". The opposition makes arguments -- usually "against", but there can be more than one faction. The I* weighs the arguments. The decision is "rough consensus". Note that resources meeting rooms, meeting slots, IESG attention, RFC editor, etc. are all scarce. This biases the process towards rejecting new work, especially if that work is controversial. They have no responsibility to let us form a working group just because we want to. We have to be able to form a consensus in the greater community that the work is doable, benefits the Internet, has a community of interest that will deploy IN THE INTERNET, and that we have the right people committed to doing the work in the IETF. Lacking such consensus, the default answer is "No." -- Dean From dean.willis@softarmor.com Fri May 14 09:25: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 65E743A6B6C for ; Fri, 14 May 2010 09:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[AWL=-0.670, 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 he87jSlhz6Cp for ; Fri, 14 May 2010 09:25:32 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id EF1A23A6B27 for ; Fri, 14 May 2010 09:24:50 -0700 (PDT) Received: from [192.168.2.109] (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 o4EGOekb028932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 14 May 2010 11:24:41 -0500 Message-ID: <4BED7940.20405@softarmor.com> Date: Fri, 14 May 2010 11:24:32 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "E.164 To MetaData BOF discussion list" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [e2md] E2MD and Indirection -- a new problem statement 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, 14 May 2010 16:25:33 -0000 I've heard Ray and Richard say that indirection might be appropriate in some cases. If we're willing to factor that into the work, we might have an opportunity. If we amended our problem statement to say that we would analyze the initial use cases, determine which cases need to be "in the database" and which need to be indirectly referenced, show how to indirectly reference where needed, and provide guidance for future users on how to make this determination and provide future guidance on dereferencing, then I predict our problem statement would be MUCH more palatable to the opposition. Let's try a re-write of my proxy-shill version and see if it gets friendlier looking. This one's a bit rough, but it should convey the basics: Goal of the E2MD Work --------------------- An easily extensible framework for using the DNS to discover data that is related to an E.164 number also resolvable in the DNS. The framework's organizational model is expected to be based as closely as possible on the existing ENUM framework. The framework is expected to provide for a multiplicity of different data types and provide for a semantic definition of each data type as well as define its relationship with the aforementioned E.164 number. The framework is expected to provide for storing some data types directly in the DNS, and in other cases to store a reference to the data in the DNS, with that determination based on the nature of the data type and its use cases. The framework is NOT expected to provide a selective query mechanism; rather, a DNS query for framework data associated with an E.164 number is expected to return all such data and data references known by the DNS to the querying node. The framework's expected query mechanism is expected to be straight-up DNS, and as such will make no considerations for authentication, authorization, or selective response based on the identity of the querying node. Further, the framework's query mechanism is expected to make no considerations for network congestion, reliability, integrity, privacy, or overly-large response sets beyond the inherent mechanisms of the DNS. Where such considerations are significant, the framework is expected to provide guidance on the use of other protocols that will be used to retrieve the framework data referenced from the DNS, and such other protocols are expected to provide needed considerations for authentication, authorization, selective response based on the identity of the querying node, network congestion, reliability, integrity, privacy, and large responses. The framework is expected to provide for standardization and IANA registration of new data types without a requirement for IETF consensus on each new data type, using the existing ENUM service registration model. From richard@shockey.us Fri May 14 10:15: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 E7C073A6B82 for ; Fri, 14 May 2010 10:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=0.677, 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 XPkNwHgbfNFc for ; Fri, 14 May 2010 10:15:41 -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 ACF5E3A6BE7 for ; Fri, 14 May 2010 10:15:18 -0700 (PDT) Received: (qmail 6382 invoked by uid 0); 14 May 2010 17:15:09 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 14 May 2010 17:15:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To: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=BS3PhV2TnZoyEIGP74Xc9PMznbg4wV8pYcHIFu4rHIOcLf58m8SV49ycpUEj0oIQJHxn0dl2aOzcbEpFQSd/xORzIx2xelJmGy8GlTTFLHs1CY4Ob/HwQyX4UPXSanMc; 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 1OCyTd-0004mj-CN; Fri, 14 May 2010 11:15:09 -0600 From: "Richard Shockey" To: "'Otmar Lendl'" , "'E.164 To MetaData BOF discussion list'" References: <002f01caf2ac$f69161a0$e3b424e0$@us> <4BED5842.4020101@nic.at> In-Reply-To: <4BED5842.4020101@nic.at> Date: Fri, 14 May 2010 13:15:03 -0400 Message-ID: <00a901caf388$fe6eda60$fb4c8f20$@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: AcrzbkhkzMr7n2yqR+medochncORTQAGomnw 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} Subject: Re: [e2md] Action Required: Your version of the Problem statement needed 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, 14 May 2010 17:15:48 -0000 Oh certainly all of the below are essential attributes of a successful e2MD system. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Otmar Lendl Sent: Friday, May 14, 2010 10:04 AM To: e2md@ietf.org Subject: Re: [e2md] Action Required: Your version of the Problem statement needed On 13.05.2010 16:59, Richard Shockey wrote: > > Non URI data in ENUM. What about that doesn't people understand? > Ok. Can I take it as a given that you don't need E2MD to support * different answers based on who's asking * different answers based on source-URI * different answers based on some kind of trunk (or SIP-peer) information ? otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From richard@shockey.us Fri May 14 10:34:16 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 4676B3A6BFD for ; Fri, 14 May 2010 10:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.47 X-Spam-Level: X-Spam-Status: No, score=-0.47 tagged_above=-999 required=5 tests=[AWL=-0.805, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] 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 d83UMsEEbFOv for ; Fri, 14 May 2010 10:34:16 -0700 (PDT) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id E85583A68C3 for ; Fri, 14 May 2010 10:33:31 -0700 (PDT) Received: (qmail 10545 invoked by uid 0); 14 May 2010 17:33:22 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 14 May 2010 17:33: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=GgTtgtnDx/yvJSTo+0/64GzHZxfUzyzMfiwoPmpjouPEY6A1e4Byc1kkgCmTqHmAPNhIWEYQQejqN2rAG/aREcLOMaBcxyFoB30AJLzWnhvgdwTbsINC3ISTsxC72qV1; 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 1OCylG-0000Ma-HG; Fri, 14 May 2010 11:33:22 -0600 From: "Richard Shockey" To: "'Dean Willis'" , "'E.164 To MetaData BOF discussion list'" References: <4BED7940.20405@softarmor.com> In-Reply-To: <4BED7940.20405@softarmor.com> Date: Fri, 14 May 2010 13:33:16 -0400 Message-ID: <00aa01caf38b$89ffd910$9dff8b30$@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: Acrzg5M97ghUoucvR5a/pFhdlAk3zwABX9qw 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: 'IETF ENUM list' Subject: Re: [e2md] E2MD and Indirection -- a new problem statement 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, 14 May 2010 17:34:16 -0000 DNS technology Dean !!! ..stop this "It's the DNS" thing. Its not about the DNS it never was. You are perpetuating the problem once again. If you note the ENUM charter we never ever used the word DNS. That was deliberate and calculated when I wrote it. Delete the word DNS from your text and it closer to the reality here. Now of course the solution is really the two variants of 3761 in deployment the public trees and the private closed ones. The use cases would reflect that matrix of options. Indirection is NOT needed in closed systems its simply interjects a redundant look up into the system that causes delay is session set up. Goal of the E2MD Work (see how much better it reads when you don't talk about the DNS :-) --------------------- An easily extensible framework for using the DNS to discover data that is related to an E.164 number. The framework's organizational model is expected to be based as closely as possible on the existing ENUM [RFC 3761 framework] . The framework is expected to provide for a multiplicity of different data types and provide for a semantic definition of each data type as well as define its relationship with the aforementioned E.164 number. The framework is expected to provide for storing some data types directly, and in other cases to store a reference to the data, with that determination based on the nature of the data type and its use cases. The framework is NOT expected to provide a selective query mechanism; rather, a query for framework data associated with an E.164 number is expected to return all such data and data. The framework's query mechanism will make no considerations for authentication, authorization, or selective response based on the identity of the querying node. Further, the framework's mechanism is expected to make no considerations for network congestion, reliability, integrity, privacy, or overly-large response sets. Where such considerations are significant, the framework is expected to provide guidance on the use of other protocols that will be used to retrieve the framework data referenced , and such other protocols are expected to provide needed considerations for authentication, authorization, selective response based on the identity of the querying node, network congestion, reliability, integrity, privacy, and large responses. The framework is expected to provide for standardization and IANA registration of new data types without a requirement for IETF consensus on each new data type, using the existing ENUM service registration model. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dean Willis Sent: Friday, May 14, 2010 12:25 PM To: E.164 To MetaData BOF discussion list Subject: [e2md] E2MD and Indirection -- a new problem statement I've heard Ray and Richard say that indirection might be appropriate in some cases. If we're willing to factor that into the work, we might have an opportunity. If we amended our problem statement to say that we would analyze the initial use cases, determine which cases need to be "in the database" and which need to be indirectly referenced, show how to indirectly reference where needed, and provide guidance for future users on how to make this determination and provide future guidance on dereferencing, then I predict our problem statement would be MUCH more palatable to the opposition. Let's try a re-write of my proxy-shill version and see if it gets friendlier looking. This one's a bit rough, but it should convey the basics: Goal of the E2MD Work --------------------- An easily extensible framework for using the DNS to discover data that is related to an E.164 number also resolvable in the DNS. The framework's organizational model is expected to be based as closely as possible on the existing ENUM framework. The framework is expected to provide for a multiplicity of different data types and provide for a semantic definition of each data type as well as define its relationship with the aforementioned E.164 number. The framework is expected to provide for storing some data types directly in the DNS, and in other cases to store a reference to the data in the DNS, with that determination based on the nature of the data type and its use cases. The framework is NOT expected to provide a selective query mechanism; rather, a DNS query for framework data associated with an E.164 number is expected to return all such data and data references known by the DNS to the querying node. The framework's expected query mechanism is expected to be straight-up DNS, and as such will make no considerations for authentication, authorization, or selective response based on the identity of the querying node. Further, the framework's query mechanism is expected to make no considerations for network congestion, reliability, integrity, privacy, or overly-large response sets beyond the inherent mechanisms of the DNS. Where such considerations are significant, the framework is expected to provide guidance on the use of other protocols that will be used to retrieve the framework data referenced from the DNS, and such other protocols are expected to provide needed considerations for authentication, authorization, selective response based on the identity of the querying node, network congestion, reliability, integrity, privacy, and large responses. The framework is expected to provide for standardization and IANA registration of new data types without a requirement for IETF consensus on each new data type, using the existing ENUM service registration model. _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From dean.willis@softarmor.com Fri May 14 22:33: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 835473A6970; Fri, 14 May 2010 22:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[AWL=-0.670, 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 pVMwzDhTNhFm; Fri, 14 May 2010 22:33:09 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2246A3A6983; Fri, 14 May 2010 22:29:29 -0700 (PDT) Received: from [192.168.2.2] (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 o4F5TCWq001548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 15 May 2010 00:29:19 -0500 Message-ID: <4BEE3123.80509@softarmor.com> Date: Sat, 15 May 2010 00:29:07 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) MIME-Version: 1.0 To: Richard Shockey References: <4BED7940.20405@softarmor.com> <00aa01caf38b$89ffd910$9dff8b30$@us> In-Reply-To: <00aa01caf38b$89ffd910$9dff8b30$@us> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'IETF ENUM list' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] E2MD and Indirection -- a new problem statement 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, 15 May 2010 05:33:10 -0000 Richard Shockey wrote: > DNS technology Dean !!! ..stop this "It's the DNS" thing. Its not about the > DNS it never was. You are perpetuating the problem once again. Dude! Slow down and get this through your head: As far as the "rest of the IETF" is concerned, ENUM is about putting phone numbers in the DNS, and as long as ENUM relies on the core protocol of the DNS, any extension to ENUM is an extension to the DNS. Failure to understand this very fundamental concept is why we don't understand the objections that Olaf and Peter and John and Jon and other DNS people keep bringing up. And it's why "just restarting the ENUM working group" will not solve the E2MD problem: the same people that are objecting to E2MD as a standalone working group will object to restarting ENUM. This is also why the CNAM draft that "had consensus in ENUM" did NOT advance through the IETF and is not currently "a standard." If the approach was ever going to fly, it would have migrated south for the winter years ago! Either solve the problem in a way that is acceptable to "the DNS people" by using the DNS consistently with their guidelines, or move the problem outside the DNS. Trying to shove it down their throats is just going to perpetuate further non-progress. -- Dean From trutkowski@netmagic.com Sat May 15 04:31: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 60B733A6A39; Sat, 15 May 2010 04:31:45 -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.905, 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 xJ0y-tzq7DUG; Sat, 15 May 2010 04:31:44 -0700 (PDT) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by core3.amsl.com (Postfix) with ESMTP id 12E683A67DB; Sat, 15 May 2010 04:31:43 -0700 (PDT) Received: from [192.168.0.28] ([unknown] [173.71.223.14]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L2G003C4LCINP30@vms173003.mailsrvcs.net>; Sat, 15 May 2010 06:31:33 -0500 (CDT) Message-id: <4BEE8612.1050907@netmagic.com> Date: Sat, 15 May 2010 07:31:30 -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: Dean Willis References: <4BED7940.20405@softarmor.com> <00aa01caf38b$89ffd910$9dff8b30$@us> <4BEE3123.80509@softarmor.com> In-reply-to: <4BEE3123.80509@softarmor.com> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Cc: 'IETF ENUM list' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] [Enum] E2MD and Indirection -- a new problem statement 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: Sat, 15 May 2010 11:31:45 -0000 On 5/15/2010 1:29 AM, Dean Willis wrote: > Either solve the problem in a way that is acceptable to "the DNS people" > by using the DNS consistently with their guidelines, or move the > problem outside the DNS. Trying to shove it down their throats is just > going to perpetuate further non-progress. > > Well said. The OID Resolution Sytem (ORS) folks ran into the same pushback from the "DNS people," even when a similar instantiation occurred with ONS. --tony From bmanning@karoshi.com Sat May 15 15:58:38 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 E21D43A67C2; Sat, 15 May 2010 15:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.355 X-Spam-Level: X-Spam-Status: No, score=-4.355 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFem8QelVGMQ; Sat, 15 May 2010 15:58:38 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 0E3963A63C9; Sat, 15 May 2010 15:58:33 -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 o4FMvDXb009848; Sat, 15 May 2010 22:57:29 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o4FMulIF009847; Sat, 15 May 2010 22:56:47 GMT Date: Sat, 15 May 2010 22:56:42 +0000 From: bmanning@vacation.karoshi.com To: Tony Rutkowski Message-ID: <20100515225642.GA9833@vacation.karoshi.com.> References: <4BED7940.20405@softarmor.com> <00aa01caf38b$89ffd910$9dff8b30$@us> <4BEE3123.80509@softarmor.com> <4BEE8612.1050907@netmagic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BEE8612.1050907@netmagic.com> User-Agent: Mutt/1.4.1i Cc: 'IETF ENUM list' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] [Enum] E2MD and Indirection -- a new problem statement 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, 15 May 2010 22:58:39 -0000 hum, as a "DNS person"... I spent a fair number of hours ~70% of my time, working on something almost identical to the VSGN-ONS platform ... with the AutoID labs folks in Japan. We never called it anything other than what it was, DNS with extentions. Never remember any public pushback from the "DNS people" on ONS. Archives? --bill On Sat, May 15, 2010 at 07:31:30AM -0400, Tony Rutkowski wrote: > On 5/15/2010 1:29 AM, Dean Willis wrote: > >Either solve the problem in a way that is acceptable to "the DNS people" > > by using the DNS consistently with their guidelines, or move the > >problem outside the DNS. Trying to shove it down their throats is just > >going to perpetuate further non-progress. > > > > > > Well said. The OID Resolution Sytem (ORS) folks ran into > the same pushback from the "DNS people," even when a > similar instantiation occurred with ONS. > > --tony > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum From lendl@cert.at Sat May 15 13:33: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 2C9223A6842 for ; Sat, 15 May 2010 13:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.97 X-Spam-Level: X-Spam-Status: No, score=0.97 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_32=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 P-yDKrWqpRZL for ; Sat, 15 May 2010 13:33:28 -0700 (PDT) Received: from nuwen.cert.at (nuwen.cert.at [83.136.33.135]) by core3.amsl.com (Postfix) with ESMTP id CB7613A62C1 for ; Sat, 15 May 2010 13:33:27 -0700 (PDT) Received: from meta.lan (meta.intern.cert.at [172.21.48.6]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by nuwen.cert.at (Postfix) with ESMTPS id C575810073; Sat, 15 May 2010 22:33:07 +0200 (CEST) Received: from lendl by meta.lan with local (Exim 4.69) (envelope-from ) id 1ODO2l-0004fv-Ka; Sat, 15 May 2010 22:33:07 +0200 Date: Sat, 15 May 2010 22:33:07 +0200 From: Otmar Lendl To: Richard Shockey Message-ID: <20100515203307.GB17608@nic.at> References: <002f01caf2ac$f69161a0$e3b424e0$@us> <4BED5842.4020101@nic.at> <00a901caf388$fe6eda60$fb4c8f20$@us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00a901caf388$fe6eda60$fb4c8f20$@us> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-CERTat-MailScanner-ID: C575810073.2F631 X-CERTat-MailScanner: Found to be clean X-CERTat-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.399, required 5, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-CERTat-MailScanner-From: lendl@cert.at Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Action Required: Your version of the Problem statement needed 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: Sun, 16 May 2010 06:57:03 -0000 On 2010/05/14 19:05, Richard Shockey wrote: > Oh certainly all of the below are essential attributes of a successful e2MD > system. Which contradicts your > > Non URI data in ENUM. What about that doesn't people understand? statement. Plain DNS and thus ENUM do not provide these extended query features, and if you need need them in E2MD, then E2MD is not just ENUM with non-uri data. You can't have it both ways. otmar > > Ok. Can I take it as a given that you don't need E2MD to support > > * different answers based on who's asking > * different answers based on source-URI > * different answers based on some kind of trunk (or SIP-peer) information > > ? > -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg From lconroy@insensate.co.uk Sun May 16 04:39: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 93C9C3A69F9 for ; Sun, 16 May 2010 04:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.015 X-Spam-Level: X-Spam-Status: No, score=0.015 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_50=0.001, J_CHICKENPOX_32=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 04ZhjNseueaf for ; Sun, 16 May 2010 04:39:56 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 5FCCE3A69F1 for ; Sun, 16 May 2010 04:39:56 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 6AFF71394C9; Sun, 16 May 2010 12:39:46 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <20100515203307.GB17608@nic.at> Date: Sun, 16 May 2010 12:39:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <48DEDD4A-473D-448B-A02B-1D458CD0E30B@insensate.co.uk> References: <002f01caf2ac$f69161a0$e3b424e0$@us> <4BED5842.4020101@nic.at> <00a901caf388$fe6eda60$fb4c8f20$@us> <20100515203307.GB17608@nic.at> To: Otmar Lendl X-Mailer: Apple Mail (2.1078) Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Action Required: Your version of the Problem statement needed 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: Sun, 16 May 2010 11:39:59 -0000 Hi Otmar, folks, Regarding non-URI data ... (i) Actually, we DID have a perfectly valid URI that can be used to contain data; the Data URL. Apart from anything else, this IS used in HTML in existing web sites that do not cause the interwebs to implode. It would have worked just fine; use of data: was blocked because IESG folk didn't *like* it. Otherwise, we wouldn't be having this extended meditation on the number of angels that will fit on a pinhead. Hence Plan B was to define a DDDS application to use NAPTR to hold non-URI data, without the arcane restrictions on use. (ii) As in all things, the problem lies not with ENUM but in the stunning way in which DDDS was written and approved. It is perfectly possible** to define a DDDS Application that uses NAPTR to produce an output other than URIs (viz. SNAPTR, D2U, ...) That DDDS application would NOT inherit the same textual restrictions as E2U on use of its target -because it is not E2U-. That application would have a new flag** indicating that the "target output in REGEXP is text", and explaining how the text should be interpreted. ** Speaking of stunningly stupid, someone might raise an erratum on 3404, as that reserves *all* flags for future versions of itself. I continue to fail to see what is wrong or hard about this. Either: - we work on E2U to remove the arcane textual blocks on data that does not *directly* lead to making a communications session to a remote target, is not definitely an assigned E.164 number, ... OR - we create a new DDDS application and rely on resolvers cacheing the NAPTR RRset. My preference is for the former, but I'm easy either way. Unused & Send-N & CNAM & "SPID" should be out the door quickly once folk decide which way they want us to work the Layer 9 problem. "Small bite", "short timescales", "running code" -- this hits the traditional IETF punch points. It might even be done before I retire. ---- Regarding selective responses ... Providing different answers based on who's asking is indeed not the way that DNS servers according to 1034/1035 are supposed to act. Perhaps one should raise that with OpenDNS & Google? Hadriel has already said that this IS happening/going to happen, and he's waiting for a DNS code point to do this officially. (see, e.g. his posting of 29th march, that I received at 22:17:18 +1:00). Once that code point is in place, I would imagine that the E2MD output would be a description of the data that *could* be returned and how it would be used. Why this particular data was returned to a query by this particular client is NOT in scope for E2MD, AFAICT. ---- =20 For the other scribes, have a thought to decaf and reducing the intake of psychotomimetics. all the best, Lawrence On 15 May 2010, at 21:33, Otmar Lendl wrote: > On 2010/05/14 19:05, Richard Shockey wrote: >> Oh certainly all of the below are essential attributes of a = successful e2MD >> system. >=20 > Which contradicts your >=20 >>> Non URI data in ENUM. What about that doesn't people understand? >=20 > statement. >=20 > Plain DNS and thus ENUM do not provide these extended query features, > and if you need need them in E2MD, then E2MD is not just ENUM with > non-uri data. >=20 > You can't have it both ways. >=20 > otmar >=20 >>=20 >> Ok. Can I take it as a given that you don't need E2MD to support >>=20 >> * different answers based on who's asking >> * different answers based on source-URI >> * different answers based on some kind of trunk (or SIP-peer) = information >>=20 >> ? >>=20 >=20 > --=20 > // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 > // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H > // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From bernie@ietf.hoeneisen.ch Sun May 16 05:35: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 B33B73A6898 for ; Sun, 16 May 2010 05:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=-1.335, BAYES_20=-0.74, SUBJ_ALL_CAPS=2.077] 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 B67jJtM2O26X for ; Sun, 16 May 2010 05:35:29 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id D12473A6A35 for ; Sun, 16 May 2010 05:35:28 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1ODd3v-0008GD-E2 for e2md@ietf.org; Sun, 16 May 2010 14:35:19 +0200 Date: Sun, 16 May 2010 14:35:19 +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] RFC 5507 & RFC 5395 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: Sun, 16 May 2010 12:35:29 -0000 Hi E2MD list The following RFC helps us to better understand to objections against E2MD expressed by the DNS folks: http://tools.ietf.org/html/rfc5507 Further information can also be found in: http://tools.ietf.org/html/rfc5395 To address the various objections I recommend everyone to read at least the former (RFC 5507), as it explains quite some arguments grey-beards and others have expressed before and during the BoF. cheers, Bernie From jim@rfc1035.com Mon May 17 04:51: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 4AEB728C16A for ; Mon, 17 May 2010 04:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[AWL=-0.099, 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 lj1Lz-NXi04V for ; Mon, 17 May 2010 04:51:03 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id B32903A6847 for ; Mon, 17 May 2010 04:44:41 -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 175DB1542837; Mon, 17 May 2010 12:44:31 +0100 (BST) Message-Id: <32FCCBEC-E8B1-45D9-A068-0B120AAADC55@rfc1035.com> From: Jim Reid 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: Mon, 17 May 2010 12:44:30 +0100 References: X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] RFC 5507 & RFC 5395 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, 17 May 2010 11:51:04 -0000 On 16 May 2010, at 13:35, Bernie Hoeneisen wrote: > To address the various objections I recommend everyone to read at > least the former (RFC 5507), as it explains quite some arguments > grey-beards and others have expressed before and during the BoF. Bernie, while these links are useful they don't really help us make progress. In the context of the discussion on this list RFC5507 pretty much says there are two choices open to us: a new RRtype or a new subtype of an existing RRtype (=> NAPTR). If it's the latter, careful attention to the size of the returned RRset is necessary. This is not news. So we're still running around in circles. Without clear use cases and/ or requirements, it's not possible to decide which of the two approaches above makes more sense. I am frustrated and disappointed that this information is still to be presented here (other than in vague anecdotal terms). It's pointless to continue a technical discussion unless there is an generally accepted problem statement. With that in mind, I make the following suggestion. Could whoever is in charge of this BOF ask those who have use cases and requirements to submit them and set a deadline for that input? If nothing is forthcoming, then there isn't a problem to work on and we can all go home. And if we get that info, there would at least be a basis for a problem statement that could then be analysed and perhaps worked on. From jim@rfc1035.com Mon May 17 04:56: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 3563D3A68C2 for ; Mon, 17 May 2010 04:56:12 -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 1zgFP7bnYKcb for ; Mon, 17 May 2010 04:56:11 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id E533628C0FF for ; Mon, 17 May 2010 04:50:16 -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 90DEC1542837; Mon, 17 May 2010 12:50:07 +0100 (BST) Message-Id: <37E73C40-D6B9-46E3-BF79-6114613EE591@rfc1035.com> From: Jim Reid To: Lawrence Conroy In-Reply-To: <48DEDD4A-473D-448B-A02B-1D458CD0E30B@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: Mon, 17 May 2010 12:50:06 +0100 References: <002f01caf2ac$f69161a0$e3b424e0$@us> <4BED5842.4020101@nic.at> <00a901caf388$fe6eda60$fb4c8f20$@us> <20100515203307.GB17608@nic.at> <48DEDD4A-473D-448B-A02B-1D458CD0E30B@insensate.co.uk> X-Mailer: Apple Mail (2.936) Cc: "'E.164 To MetaData BOF discussion list'" , Otmar Lendl Subject: [e2md] Stupid DNS tricks 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, 17 May 2010 11:56:12 -0000 On 16 May 2010, at 12:39, Lawrence Conroy wrote: > Providing different answers based on who's asking is indeed not the > way that DNS servers according to 1034/1035 are supposed to act. > Perhaps one should raise that with OpenDNS & Google? This isn't our problem and we should keep well out of it. FWIW, there has been a discussion about Stupid DNS Tricks (tm) on dnsop and it doesn't seem to be going anywhere. The web content providers who want this stuff appear to be unable to convince the WG that their ideas are sound or worthwhile. These schemes will also lose big time when/if they sign their zones. Followups and replies to dnsop@ietf.org. Thanks. From bernie@ietf.hoeneisen.ch Mon May 17 06:24: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 F06C83A6CA0 for ; Mon, 17 May 2010 06:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.621 X-Spam-Level: X-Spam-Status: No, score=-0.621 tagged_above=-999 required=5 tests=[AWL=-0.622, 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 4fke6YqAvBHY for ; Mon, 17 May 2010 06:24:44 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id A69F73A6BDA for ; Mon, 17 May 2010 06:19:47 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1OE0EL-0004bJ-12; Mon, 17 May 2010 15:19:37 +0200 Date: Mon, 17 May 2010 15:19:36 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Jim Reid In-Reply-To: <32FCCBEC-E8B1-45D9-A068-0B120AAADC55@rfc1035.com> Message-ID: References: <32FCCBEC-E8B1-45D9-A068-0B120AAADC55@rfc1035.com> 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 Cc: "E.164 To MetaData BOF discussion list" Subject: [e2md] Problem statement, Requirements and Use Cases (was RFC 5507 & RFC 5395) 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, 17 May 2010 13:24:46 -0000 Hi Jim On Mon, 17 May 2010, Jim Reid wrote: > With that in mind, I make the following suggestion. Could whoever is in > charge of this BOF ask those who have use cases and requirements to submit > them and set a deadline for that input? If nothing is forthcoming, then there > isn't a problem to work on and we can all go home. And if we get that info, > there would at least be a basis for a problem statement that could then be > analysed and perhaps worked on. About Problem statement: Last week I sent out an email with Subject: "Action Required: Your version of the Problem statement needed", which pretty much covers this. As I have only seen a few answers, I maybe could send a reminder. About Requirements: A call for requirements sime weeks ago resulted in the following: http://trac.tools.ietf.org/bof/e2md/trac/wiki/RequirementsList (AFAICR only Jay and Dean have been contributing so far.) About Use Cases: BTW: Long before the BoF I also publically asked for Use Cases, which is still the basis for the Use Cases we are discussing here. Details see E2MD archives. Wiki page under construction: http://trac.tools.ietf.org/bof/e2md/trac/wiki/UseCases Wiki: Here the list of links to the Wiki pages: - Main E2MD Wiki Page: http://trac.tools.ietf.org/bof/e2md/trac/wiki - Requirements: http://trac.tools.ietf.org/bof/e2md/trac/wiki/RequirementsList - Use Cases (under construction) http://trac.tools.ietf.org/bof/e2md/trac/wiki/UseCases - Objections (Ticketing System) http://trac.tools.ietf.org/bof/e2md/trac/report/10 I would wish the Wiki was more of a collaborative happening as opposed to one person doing all the work... cheers, Bernie From pp3129@att.com Mon May 17 07:26: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 EFBCB28C0F3 for ; Mon, 17 May 2010 07:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.393 X-Spam-Level: X-Spam-Status: No, score=-104.393 tagged_above=-999 required=5 tests=[AWL=-0.394, 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 zHc+X4ZMK-wx for ; Mon, 17 May 2010 07:26:57 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id CDE3A3A6A26 for ; Mon, 17 May 2010 07:22:56 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-12.tower-121.messagelabs.com!1274106165!32820600!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 23010 invoked from network); 17 May 2010 14:22:45 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-12.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 May 2010 14:22:45 -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 o4HEMQav009045 for ; Mon, 17 May 2010 10:22:27 -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 o4HEMLX3008915 for ; Mon, 17 May 2010 10:22:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 May 2010 10:22:38 -0400 Message-ID: <35FE871E2B085542A35726420E29DA6B03F95813@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [e2md] Problem statement, Requirements and Use Cases (was RFC 5507 & RFC 5395) Thread-Index: Acr1xFKNQ4yM6wo0TK+YD4hGImVBogABrAlA References: <32FCCBEC-E8B1-45D9-A068-0B120AAADC55@rfc1035.com> From: "PFAUTZ, PENN L (ATTCORP)" To: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Problem statement, Requirements and Use Cases (was RFC 5507 & RFC 5395) 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, 17 May 2010 14:26:59 -0000 So I went through the RFCs which seemed to say, "You probably should use = a new RR type if you're going to get too much data and it's not as bad = getting new RRs as you think." Na=EFve question: if we said we wanted a WG based on the assumption that = we'll define new RR type(s) as needed would that settle the naysayers' = hash? I'll be happy to send some text for G-SPID separately Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of = Bernie Hoeneisen Sent: Monday, May 17, 2010 9:20 AM To: Jim Reid Cc: E.164 To MetaData BOF discussion list Subject: [e2md] Problem statement, Requirements and Use Cases (was RFC = 5507 & RFC 5395) Hi Jim On Mon, 17 May 2010, Jim Reid wrote: > With that in mind, I make the following suggestion. Could whoever is = in=20 > charge of this BOF ask those who have use cases and requirements to = submit=20 > them and set a deadline for that input? If nothing is forthcoming, = then there=20 > isn't a problem to work on and we can all go home. And if we get that = info,=20 > there would at least be a basis for a problem statement that could = then be=20 > analysed and perhaps worked on. About Problem statement: Last week I sent out an email with Subject: "Action Required: Your = version=20 of the Problem statement needed", which pretty much covers this. As I = have=20 only seen a few answers, I maybe could send a reminder. About Requirements: A call for requirements sime weeks ago resulted in the following: http://trac.tools.ietf.org/bof/e2md/trac/wiki/RequirementsList (AFAICR only Jay and Dean have been contributing so far.) About Use Cases: BTW: Long before the BoF I also publically asked for Use Cases, which=20 is still the basis for the Use Cases we are discussing here. Details see = E2MD archives. Wiki page under construction: http://trac.tools.ietf.org/bof/e2md/trac/wiki/UseCases Wiki: Here the list of links to the Wiki pages: - Main E2MD Wiki Page: http://trac.tools.ietf.org/bof/e2md/trac/wiki - Requirements: http://trac.tools.ietf.org/bof/e2md/trac/wiki/RequirementsList - Use Cases (under construction) http://trac.tools.ietf.org/bof/e2md/trac/wiki/UseCases - Objections (Ticketing System) http://trac.tools.ietf.org/bof/e2md/trac/report/10 I would wish the Wiki was more of a collaborative happening as opposed = to=20 one person doing all the work... cheers, Bernie _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From Ray.Bellis@nominet.org.uk Mon May 17 08:09:28 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 B51523A6A43 for ; Mon, 17 May 2010 08:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.016 X-Spam-Level: X-Spam-Status: No, score=-10.016 tagged_above=-999 required=5 tests=[AWL=0.583, 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 6cV9N+lnuvIs for ; Mon, 17 May 2010 08:09:27 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 080C13A68CD for ; Mon, 17 May 2010 08:09:26 -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: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=i75OoactSnukhdMQor4KghoY1DjfyGU7L/SpmcQomy/TSfLrSNSd/Dgs aWUJ7o/djlfEiwTEj+yJVPdlki4a17hv+QJdlsTTkZ/jry9RRO/rwA2iv sFHbwylPoHmCpr5; 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=1274108959; x=1305644959; 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]=20Problem=20statement,=20Require ments=20and=20Use=20Cases=20(was=20RFC=0D=0A=205507=20& =20RFC=205395)|Date:=20Mon,=2017=20May=202010=2015:09:13 =20+0000|Message-ID:=20|To:=20"PFAUTZ,=20PENN=20L=20(ATTCORP)"=20,=20E.164=20To=20MetaData=20BOF=0D=0A=20discussio n=20list=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<8824dce1-70e9-4dde-bd09-009f39ddc8fe> |In-Reply-To:=20<35FE871E2B085542A35726420E29DA6B03F95813 @gaalpa1msgusr7a.ugd.att.com>; bh=yS/pnQRmBZjzU+U7RXXi4eK4ZqXW2a2SuB4EP0/fsz0=; b=I9ruwMKDDe0wzOxwsRDJMqy8WLSQVocS2J1Q5wOXes9heYOnK9QTVMiA qUAiUbxlN331xga+5YqdWNYHZMKCwHzFGfXo+v7K7NV9eSKS4hk78V/ke VtTWH8WkiC0uHHx; X-IronPort-AV: E=Sophos;i="4.53,247,1272841200"; d="scan'208";a="18689626" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 17 May 2010 16:09:17 +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; Mon, 17 May 2010 16:09:17 +0100 From: Ray Bellis To: "PFAUTZ, PENN L (ATTCORP)" , E.164 To MetaData BOF discussion list Thread-Topic: [e2md] Problem statement, Requirements and Use Cases (was RFC 5507 & RFC 5395) Thread-Index: AQHK9dLqjbCqBaBNQki9yeCLjcrcQg== Date: Mon, 17 May 2010 15:09:13 +0000 Message-ID: In-Reply-To: <35FE871E2B085542A35726420E29DA6B03F95813@gaalpa1msgusr7a.ugd.att.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8824dce1-70e9-4dde-bd09-009f39ddc8fe> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [e2md] Problem statement, Requirements and Use Cases (was RFC 5507 & RFC 5395) 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, 17 May 2010 15:09:28 -0000 On 17/05/2010 15:22, "PFAUTZ, PENN L (ATTCORP)" wrote: > So I went through the RFCs which seemed to say, "You probably should use = a new > RR type if you're going to get too much data and it's not as bad getting = new > RRs as you think." >=20 > Na=EFve question: if we said we wanted a WG based on the assumption that = we'll > define new RR type(s) as needed would that settle the naysayers' hash? It might, but it then doesn't meet some of the technical requirements for some of the use cases. For 'Send-N' and 'unused', in particular, NAPTR fits because these answers are given back instead of "communication end points" in response to the usual DDDS algorithm query. A new RR type for those would be self-defeating. Ray From dean.willis@softarmor.com Mon May 17 08:13: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 DC5343A6D12 for ; Mon, 17 May 2010 08:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[AWL=-0.662, 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 Qb9YEmhFcrH5 for ; Mon, 17 May 2010 08:13:21 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 99C9F3A6D13 for ; Mon, 17 May 2010 08:12:37 -0700 (PDT) Received: from [192.168.2.2] (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 o4HFCQNb026050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 17 May 2010 10:12:27 -0500 Message-ID: <4BF15CD5.9010606@softarmor.com> Date: Mon, 17 May 2010 10:12:21 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) MIME-Version: 1.0 To: "PFAUTZ, PENN L (ATTCORP)" References: <32FCCBEC-E8B1-45D9-A068-0B120AAADC55@rfc1035.com> <35FE871E2B085542A35726420E29DA6B03F95813@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <35FE871E2B085542A35726420E29DA6B03F95813@gaalpa1msgusr7a.ugd.att.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Problem statement, Requirements and Use Cases (was RFC 5507 & RFC 5395) 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, 17 May 2010 15:13:26 -0000 PFAUTZ, PENN L (ATTCORP) wrote: > So I went through the RFCs which seemed to say, "You probably should > use a new RR type if you're going to get too much data and it's not > as bad getting new RRs as you think." > > Naïve question: if we said we wanted a WG based on the assumption > that we'll define new RR type(s) as needed would that settle the > naysayers' hash? I believe it would settle some of their hash. Not all of it, of course; if we propose an RR-type for putting a caller-ID photo jpg into the DNS, they're still going to get upset and say "no". And preserving their ability to say "no" on a per-case basis is something they really want. However, if we agree to, for each use case, consider whether we should re-use an existing RR type or define a new RR-type, and that we will also make a similar determination about whether to put the data itself into the DNS or put a pointer to the data into the DNS, then I think we're going to get a lot less pushback than our current proposal "enjoys". I had a side discussion with Jim about his experience in getting new RR-types approved, and to summarize, my impression was that it was kind of random. Some RR-types were unexpectedly easy, others unexpectedly difficult. -- Dean From pp3129@att.com Mon May 17 10:32: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 C62733A6A27 for ; Mon, 17 May 2010 10:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.905 X-Spam-Level: X-Spam-Status: No, score=-104.905 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_05=-1.11, 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 4n2yuMoVirTv for ; Mon, 17 May 2010 10:32:06 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id ACF673A689D for ; Mon, 17 May 2010 10:32:00 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1274117511!44311128!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 27318 invoked from network); 17 May 2010 17:31:52 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-14.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 May 2010 17:31:52 -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 o4HHVXJC022957 for ; Mon, 17 May 2010 13:31: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 o4HHVToL022868 for ; Mon, 17 May 2010 13:31:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 May 2010 13:31:46 -0400 Message-ID: <35FE871E2B085542A35726420E29DA6B03F959AB@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [e2md] Problem statement, Requirements and Use Cases (was RFC 5507 & RFC 5395) Thread-Index: AQHK9dLqjbCqBaBNQki9yeCLjcrcQpJV30+g References: <35FE871E2B085542A35726420E29DA6B03F95813@gaalpa1msgusr7a.ugd.att.com> From: "PFAUTZ, PENN L (ATTCORP)" To: "Ray Bellis" , "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Problem statement, Requirements and Use Cases (was RFC 5507 & RFC 5395) 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, 17 May 2010 17:32:07 -0000 Ray: I see your point. It also appears that send-n and unused would never by = themselves raise response size issues since I wouldn't expect to see a = send-n RR in or an unused RR for a domain name that would have other = NAPTR records in its RR set. So let me bump the na=EFve question up a = level: Please sirs, may we have an e2md WG that will analyze proposed use cases = guided by RFC 5507 & RFC 5395 and propose appropriate implementations? Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: Ray Bellis [mailto:Ray.Bellis@nominet.org.uk]=20 Sent: Monday, May 17, 2010 11:09 AM To: PFAUTZ, PENN L (ATTCORP); E.164 To MetaData BOF discussion list Subject: Re: [e2md] Problem statement, Requirements and Use Cases (was = RFC 5507 & RFC 5395) On 17/05/2010 15:22, "PFAUTZ, PENN L (ATTCORP)" wrote: > So I went through the RFCs which seemed to say, "You probably should = use a new > RR type if you're going to get too much data and it's not as bad = getting new > RRs as you think." >=20 > Na=EFve question: if we said we wanted a WG based on the assumption = that we'll > define new RR type(s) as needed would that settle the naysayers' hash? It might, but it then doesn't meet some of the technical requirements = for some of the use cases. For 'Send-N' and 'unused', in particular, NAPTR fits because these = answers are given back instead of "communication end points" in response to the usual DDDS algorithm query. A new RR type for those would be self-defeating. Ray From jim@rfc1035.com Mon May 17 11:36: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 4BC6C3A683C for ; Mon, 17 May 2010 11:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.095 X-Spam-Level: X-Spam-Status: No, score=-0.095 tagged_above=-999 required=5 tests=[AWL=-0.096, 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 iaHwmfQheU9j for ; Mon, 17 May 2010 11:36:38 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id 33D473A67AD for ; Mon, 17 May 2010 11:36:37 -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 E60B61542837; Mon, 17 May 2010 19:36:25 +0100 (BST) Message-Id: <289C39E5-AFC7-4F99-867A-CAAB6E245D82@rfc1035.com> From: Jim Reid To: Dean Willis In-Reply-To: <4BF15CD5.9010606@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: Mon, 17 May 2010 19:36:25 +0100 References: <32FCCBEC-E8B1-45D9-A068-0B120AAADC55@rfc1035.com> <35FE871E2B085542A35726420E29DA6B03F95813@gaalpa1msgusr7a.ugd.att.com> <4BF15CD5.9010606@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: [e2md] the RFC5935 process 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, 17 May 2010 18:36:39 -0000 On 17 May 2010, at 16:12, Dean Willis wrote: > I had a side discussion with Jim about his experience in getting new > RR-types approved, and to summarize, my impression was that it was > kind > of random. Some RR-types were unexpectedly easy, others unexpectedly > difficult. The problems were with what I consider were some interfering busy- bodies who seemed to meddle for the sake of it. In fairness, this was the first time the 5395 process had been used. So some teething problems from well-intentioned but probably misinformed bystanders were perhaps to be expected. Oh well. One of them decided he knew better than me what the requirements were for the problem I needed the new RR for. He didn't appear to understand he didn't have a say on the allocation of a new type code or a veto over the template I submitted either. Others mistakenly felt that the suggested name for one of the new RRtypes had some bearing on zone semantics. [I doubt they'd read the documentation.] Anyone who wants to know the details can buy me beer or consult the dnsext archives from late 2008. There were no difficulties with the expert reviews of the templates. Or with the reviewers. They were helpful and did their job of allocating the new type codes with the minimum of fuss. Which is how the 5935 process is supposed to work. It's meant to be simple and straightforward to get new RR type codes assigned -- no RFC required! -- as long as the new RR does not mess with zone cut semantics or entail changes to additional section processing. This is perhaps the most important thing to bear in mind if a new RRtype turns out to be the path this BOF will follow. From dean.willis@softarmor.com Mon May 17 14:38: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 B0CCF3A6B9E for ; Mon, 17 May 2010 14:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.653, 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 iw2S7Rhyb2Ij for ; Mon, 17 May 2010 14:38:21 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 036A53A6B50 for ; Mon, 17 May 2010 14:38:17 -0700 (PDT) Received: from [192.168.2.109] (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 o4HLc4nZ029573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 17 May 2010 16:38:08 -0500 From: Dean Willis To: "PFAUTZ, PENN L (ATTCORP)" In-Reply-To: <35FE871E2B085542A35726420E29DA6B03F959AB@gaalpa1msgusr7a.ugd.att.com> References: <35FE871E2B085542A35726420E29DA6B03F95813@gaalpa1msgusr7a.ugd.att.com> <35FE871E2B085542A35726420E29DA6B03F959AB@gaalpa1msgusr7a.ugd.att.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 17 May 2010 16:37:57 -0500 Message-ID: <1274132277.2972.4.camel@damnableubu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Problem statement, Requirements and Use Cases (was RFC 5507 & RFC 5395) 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, 17 May 2010 21:38:22 -0000 On Mon, 2010-05-17 at 13:31 -0400, PFAUTZ, PENN L (ATTCORP) wrote: > Please sirs, may we have an e2md WG that will analyze proposed use cases guided by RFC 5507 & RFC 5395 and propose appropriate implementations? That probably would work. I think all we need to do is agree to analyze the problem(s) and solve each appropriately while respecting the "rules", rather than insisting on one-size-fits-all hack/slash on ENUM to define a framework for adding arbitrary metadata into NAPTR records. -- Dean From Ray.Bellis@nominet.org.uk Tue May 18 01:50: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 6039A3A6C32 for ; Tue, 18 May 2010 01:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.316 X-Spam-Level: X-Spam-Status: No, score=-9.316 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_05=-1.11, 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 8+M7A1kXVWY4 for ; Tue, 18 May 2010 01:50:38 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 45D4C3A6C31 for ; Tue, 18 May 2010 01:46:26 -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: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=N6LdqNoFUKfqCL3oPjwhKdqTfkgtTymla/it/aVdLZNP4RRAqzfHB6/5 b3HSD82K2JY0kCYFsubZc/vB8TMAg8r1A/P1HPh0yazPmerpYLYM4JrEr joAV8h6/tnMBPWJ; 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=1274172383; x=1305708383; 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]=20the=20RFC5935=20process|Date: =20Tue,=2018=20May=202010=2008:46:16=20+0000|Message-ID: =20|To:=20E.164 =20To=20MetaData=20BOF=20discussion=20list=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20quot ed-printable|Content-ID:=20|In-Reply-To:=20<289C39E5-AFC7-4F99-867A-CAAB6E24 5D82@rfc1035.com>; bh=tTD/l7i6JWwGKaaYjLuHXCwyJ0WwLc9/TvJXwQ7hAvU=; b=ZxoTse/3VFEDnUFncqp8Kbc4ognnlrQThRgv/E089LP8fc7SE3l2rsf2 Tvf9PL022YH5uEF8s3B8QBRCN3doELdbLqr2z79dTLWm1z0G5a0RnbBZV r7hOQr5dKB8BwJ7; X-IronPort-AV: E=Sophos;i="4.53,254,1272841200"; d="scan'208";a="24322079" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 18 May 2010 09:46:18 +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; Tue, 18 May 2010 09:46:18 +0100 From: Ray Bellis To: E.164 To MetaData BOF discussion list Thread-Topic: [e2md] the RFC5935 process Thread-Index: AQHK9e/hZEjyyTCGxkSwF5TLxWQJ4ZJW4UcA Date: Tue, 18 May 2010 08:46:16 +0000 Message-ID: In-Reply-To: <289C39E5-AFC7-4F99-867A-CAAB6E245D82@rfc1035.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 Subject: Re: [e2md] the RFC5935 process 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, 18 May 2010 08:50:39 -0000 > It's meant to be simple and straightforward to get new RR type codes > assigned -- no RFC required! -- as long as the new RR does not mess > with zone cut semantics or entail changes to additional section > processing. This is perhaps the most important thing to bear in mind > if a new RRtype turns out to be the path this BOF will follow. And this indeed is another reason why Send-N doesn't use a new RR. It _could_ have been designed to be a new RR which is returned automagicall= y in the additional section whenever the original DDDS query returned no NAPT= R records (RCODE =3D 0, ANSWERS =3D 0). However that would require "additional section processing", and adding new logic to DNS implementations to cope with that is a very high bar to overcome. Ray From victor.pascual.avila@gmail.com Tue May 18 04:21: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 0E06E3A6A97 for ; Tue, 18 May 2010 04:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.742 X-Spam-Level: X-Spam-Status: No, score=-0.742 tagged_above=-999 required=5 tests=[AWL=-0.743, 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 K78jTfXyZ1Ew for ; Tue, 18 May 2010 04:21:44 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id D2A193A693C for ; Tue, 18 May 2010 04:20:11 -0700 (PDT) Received: by fxm17 with SMTP id 17so95123fxm.31 for ; Tue, 18 May 2010 04:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=c3I3BY1NyHiOYZoggx8spuy7YcomkI7jzCCeCQPdeNI=; b=x1OV5CZpIAbr2uN+CGPqo98cNud1kC4K3cmkIL77OY/vHNpzuGsCzTNiUxLUdI+3Lu QubH5OkJ3ZoaB97OL9EEFxCeiEbskQsGtMvE40jg9zQIujmI/hS289rZTIej7Ljrh1BC I2XD8WTp8QRwhUeq1qOGxjzXESy4590qUXqJg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JJ3M+AEHoL5uD1EeaKhcXlDrFrP07Dd3Io/hoWSbcG2Q4L1HehvI3hTcmJPB8JwyDK zO8iCdBZKWTZu36PfJTW52/9hoqcVLHUhQEsW2JT8S3tobv55vS/3bHvG5MrAN2ECtYc LYVGZHKz3mL6JNoKlYXzbGbo1q4IQOTqyyfSk= MIME-Version: 1.0 Received: by 10.102.214.32 with SMTP id m32mr4501368mug.42.1274181600871; Tue, 18 May 2010 04:20:00 -0700 (PDT) Received: by 10.103.168.14 with HTTP; Tue, 18 May 2010 04:20:00 -0700 (PDT) In-Reply-To: <37E73C40-D6B9-46E3-BF79-6114613EE591@rfc1035.com> References: <002f01caf2ac$f69161a0$e3b424e0$@us> <4BED5842.4020101@nic.at> <00a901caf388$fe6eda60$fb4c8f20$@us> <20100515203307.GB17608@nic.at> <48DEDD4A-473D-448B-A02B-1D458CD0E30B@insensate.co.uk> <37E73C40-D6B9-46E3-BF79-6114613EE591@rfc1035.com> Date: Tue, 18 May 2010 13:20:00 +0200 Message-ID: From: Victor Pascual Avila To: Jim Reid Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "E.164 To MetaData BOF discussion list" , Otmar Lendl Subject: Re: [e2md] Stupid DNS tricks 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, 18 May 2010 11:21:46 -0000 On Mon, May 17, 2010 at 1:50 PM, Jim Reid wrote: > FWIW, there has > been a discussion about Stupid DNS Tricks (tm) on dnsop and it doesn't se= em > to be going anywhere. The web content providers who want this stuff appea= r > to be unable to convince the WG that their ideas are sound or worthwhile. > These schemes will also lose big time when/if they sign their zones. > > Followups and replies to dnsop@ietf.org. Thanks. Wasn't that discussion on dnsext? Cheers, --=20 Victor Pascual =C3=81vila From jim@rfc1035.com Tue May 18 04:31: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 209E13A6924 for ; Tue, 18 May 2010 04:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=1.208, 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 Oe8RD4-DN8Ix for ; Tue, 18 May 2010 04:31:50 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id BDE093A6933 for ; Tue, 18 May 2010 04:30:40 -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 6C6211542837; Tue, 18 May 2010 12:30:31 +0100 (BST) Message-Id: From: Jim Reid To: Victor Pascual Avila 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, 18 May 2010 12:30:30 +0100 References: <002f01caf2ac$f69161a0$e3b424e0$@us> <4BED5842.4020101@nic.at> <00a901caf388$fe6eda60$fb4c8f20$@us> <20100515203307.GB17608@nic.at> <48DEDD4A-473D-448B-A02B-1D458CD0E30B@insensate.co.uk> <37E73C40-D6B9-46E3-BF79-6114613EE591@rfc1035.com> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" , Otmar Lendl Subject: Re: [e2md] Stupid DNS tricks 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, 18 May 2010 11:31:51 -0000 On 18 May 2010, at 12:20, Victor Pascual Avila wrote: > Wasn't that discussion on dnsext? yeah... whatever... who cares? From lconroy@insensate.co.uk Tue May 18 05:24: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 E41D728C0E0 for ; Tue, 18 May 2010 05:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.236 X-Spam-Level: X-Spam-Status: No, score=-0.236 tagged_above=-999 required=5 tests=[AWL=-0.237, 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 O8uk9uL2B0pI for ; Tue, 18 May 2010 05:24:55 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id D12153A6B3B for ; Tue, 18 May 2010 05:22:07 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 9213E13AB83 for ; Tue, 18 May 2010 13:21:57 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) From: Lawrence Conroy In-Reply-To: Date: Tue, 18 May 2010 13:21:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4DF850F6-5A5E-4031-BADA-9EA68A0DE939@insensate.co.uk> References: <002f01caf2ac$f69161a0$e3b424e0$@us> <4BED5842.4020101@nic.at> <00a901caf388$fe6eda60$fb4c8f20$@us> <20100515203307.GB17608@nic.at> <48DEDD4A-473D-448B-A02B-1D458CD0E30B@insensate.co.uk> <37E73C40-D6B9-46E3-BF79-6114613EE591@rfc1035.com> To: "E.164 To MetaData BOF discussion list" X-Mailer: Apple Mail (2.1078) Subject: Re: [e2md] Stupid DNS tricks 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, 18 May 2010 12:24:59 -0000 Hi Folks, To second Jim's hint, please don't go hunting down that thread -- it = will make your eyes bleed. ... and it is not going anywhere fast. all the best, Lawrence On 18 May 2010, at 12:30, Jim Reid wrote: > On 18 May 2010, at 12:20, Victor Pascual Avila wrote: >> Wasn't that discussion on dnsext? > yeah... whatever... who cares? From kcartwright@tnsi.com Tue May 18 08:31: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 57E623A6A38 for ; Tue, 18 May 2010 08:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.657 X-Spam-Level: X-Spam-Status: No, score=-0.657 tagged_above=-999 required=5 tests=[AWL=-0.658, 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 Lo4LAlVMpYvn for ; Tue, 18 May 2010 08:31:23 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id A44BD3A680F for ; Tue, 18 May 2010 08:30:52 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.43744751; Tue, 18 May 2010 11:30: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; Tue, 18 May 2010 11:30:41 -0400 From: "Cartwright, Kenneth" To: Dean Willis , "PFAUTZ, PENN L (ATTCORP)" Date: Tue, 18 May 2010 11:30:39 -0400 Thread-Topic: [e2md] Problem statement, Requirements and Use Cases (was RFC 5507 & RFC 5395) Thread-Index: Acr2CUVmbOEqng5nT9O8qMbCKJ040wAjU7gA Message-ID: <754963199212404AB8E9CFCA6C3D0CDA2446C831EA@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <35FE871E2B085542A35726420E29DA6B03F95813@gaalpa1msgusr7a.ugd.att.com> <35FE871E2B085542A35726420E29DA6B03F959AB@gaalpa1msgusr7a.ugd.att.com> <1274132277.2972.4.camel@damnableubu> In-Reply-To: <1274132277.2972.4.camel@damnableubu> 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] Problem statement, Requirements and Use Cases (was RFC 5507 & RFC 5395) 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, 18 May 2010 15:31:24 -0000 Ouch. I think what Dean might have meant to say was... "That probably would work. I think all we need to do is agree to analyze t= he problem(s) and solve each appropriately, while respecting the concerns a= nd motives of all parties. We should not assume and force pre-conceived so= lutions or solution constraints that, after thoroughly analyzing the proble= m(s) and the solution(s), are inappropriate or unfounded." Dean, if that's not what you meant to say, please accept my apologies. :-) Ken -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dea= n Willis Sent: Monday, May 17, 2010 5:38 PM To: PFAUTZ, PENN L (ATTCORP) Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] Problem statement, Requirements and Use Cases (was RFC = 5507 & RFC 5395) On Mon, 2010-05-17 at 13:31 -0400, PFAUTZ, PENN L (ATTCORP) wrote: > Please sirs, may we have an e2md WG that will analyze proposed use cases = guided by RFC 5507 & RFC 5395 and propose appropriate implementations? That probably would work. I think all we need to do is agree to analyze the problem(s) and solve each appropriately while respecting the "rules", rather than insisting on one-size-fits-all hack/slash on ENUM to define a framework for adding arbitrary metadata into NAPTR records. -- 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 bernie@ietf.hoeneisen.ch Tue May 18 11:54: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 C765F3A6A51 for ; Tue, 18 May 2010 11:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[AWL=-0.509, 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 8yWNvjffQvXK for ; Tue, 18 May 2010 11:54:50 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 9C91F3A6A29 for ; Tue, 18 May 2010 11:54:50 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1OERw8-00029a-Vf for e2md@ietf.org; Tue, 18 May 2010 20:54:41 +0200 Date: Tue, 18 May 2010 20:54:40 +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] Doodle poll: Next Conf-Call on Requirements 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, 18 May 2010 18:54:51 -0000 Hi, As decided at the last conf call, we will have a dedicated conf call on requirements / use cases. Please indicate your availabilities on Doodle: http://www.doodle.com/3hqunikiwxzkrez5 Goals: * Get a common understanding on the set of requirements and use cases we are going to address Topics: * List of Requirements (draft version) http://trac.tools.ietf.org/bof/e2md/trac/wiki/RequirementsList * Use Cases (under construction) http://trac.tools.ietf.org/bof/e2md/trac/wiki/UseCases Note: No other topics are discussed during this call. Looking forward to you Doodle responses! cheers, Bernie From richard@shockey.us Tue May 18 15:11:03 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96C033A69BD for ; Tue, 18 May 2010 15:11:03 -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 cm64IkGn-zKh for ; Tue, 18 May 2010 15:10:56 -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 E90DB3A6A6E for ; Tue, 18 May 2010 15:10:55 -0700 (PDT) Received: (qmail 24735 invoked by uid 0); 18 May 2010 22:10:48 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 18 May 2010 22:10:48 -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=Idil2Qaa2PKKh+j7IuZG4+7Q9Po3gohZrWtXpFbIh6Qq4uiMsEqpcY8tY/qzEiUhzhijpJfoFLzTO0wo8uDI/gguU8pN1b19kgwuvL5IhODtI+Tm9x1SX2vudeOOtpH9; Received: from [74.85.101.1] (helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OEUzw-0000yQ-6Z; Tue, 18 May 2010 16:10:48 -0600 From: "Richard Shockey" To: "'Dean Willis'" , "'PFAUTZ, PENN L \(ATTCORP\)'" References: <35FE871E2B085542A35726420E29DA6B03F95813@gaalpa1msgusr7a.ugd.att.com> <35FE871E2B085542A35726420E29DA6B03F959AB@gaalpa1msgusr7a.ugd.att.com> <1274132277.2972.4.camel@damnableubu> In-Reply-To: <1274132277.2972.4.camel@damnableubu> Date: Tue, 18 May 2010 18:10:41 -0400 Message-ID: <002b01caf6d6$f50c78f0$df256ad0$@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: Acr2CULWKVj2kVwfTXWHE2zXUPDITgAzQd0w Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 74.85.101.1 authed with richard@shockey.us} Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Problem statement, Requirements and Use Cases (was RFC 5507 & RFC 5395) 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, 18 May 2010 22:11:03 -0000 On Mon, 2010-05-17 at 13:31 -0400, PFAUTZ, PENN L (ATTCORP) wrote: > Please sirs, may we have an e2md WG that will analyze proposed use cases guided by RFC 5507 & RFC 5395 and propose appropriate implementations? That probably would work. I think all we need to do is agree to analyze the problem(s) and solve each appropriately while respecting the "rules", RS> What rules are that Dean? rather than insisting on one-size-fits-all hack/slash on ENUM to define a framework for adding arbitrary metadata into NAPTR records. RS> We will have to separate the requirements for what are clearly closed private implementations 3761 for E2MD vs those that may use the single root DNS. The requirements, certainly the security and privacy issues are very different. -- Dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From lconroy@insensate.co.uk Tue May 18 15:52:27 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 D6EE83A69DB for ; Tue, 18 May 2010 15:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.402 X-Spam-Level: X-Spam-Status: No, score=0.402 tagged_above=-999 required=5 tests=[AWL=-0.839, 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 YhG2yAdV8NU7 for ; Tue, 18 May 2010 15:52:26 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 929963A6A08 for ; Tue, 18 May 2010 15:52:25 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 0C4E813B1EC; Tue, 18 May 2010 23:52:15 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Lawrence Conroy In-Reply-To: Date: Tue, 18 May 2010 23:52:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Bernie Hoeneisen X-Mailer: Apple Mail (2.1078) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Doodle poll: Next Conf-Call on Requirements 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, 18 May 2010 22:52:27 -0000 Hi Bernie, folks, I am slightly confused. The Dean & Rich show does that :)p This looks rather like a Bait 'n' Switch deal. AFAICT, there is an idea to revive the ENUM WG and to work on *some* of the items in that. I agree++ with that -- ENUM Vivax! In fact, on list everyone has agreed with that and our friendly channeled demons don't seem to have raised a complaint yet :). For ENUM (as opposed to any other WG) ... First Step: I'd guess that revival could work on Send-N and Unused. [Assuming we can roll back some of the more arcane restrictions in section 1.2 of rfc3761bis and the bit moved into the second paragraph of the intro of section 2]. These **should** be short term work items. Even CNAM and SPID could be done in the existing ENUM WG as well, I suspect. Heck -- we have number portability already, so why not? Second step: In the past the IESG appear to have resisted URIs that do not act as "direct" session initiators to Internet services. I remember the protracted pain of pushing against that resistance (that initially included use of telephone numbers, video telephony service, and even SMS =A7-/ So ... ISTM that it might be useful to re-charter ENUM to extend its remit to either unwind these alleged but unwritten rules (or write them in stone so at last we know what the limits ARE). ----- SO ... what is the other stuff that you are asking for requirements, and some seem to be thinking of other RR types, use of other protocols, indirection, ... ? It sure isn't ENUM. I seem to have lost track. Clarification required. all the best, Lawrence On 18 May 2010, at 19:54, Bernie Hoeneisen wrote: > Hi, >=20 > As decided at the last conf call, we will have a dedicated conf call = on requirements / use cases. >=20 > Please indicate your availabilities on Doodle: >=20 > http://www.doodle.com/3hqunikiwxzkrez5 >=20 >=20 > Goals: >=20 > * Get a common understanding on the set of requirements and use cases > we are going to address >=20 >=20 > Topics: >=20 > * List of Requirements (draft version) > http://trac.tools.ietf.org/bof/e2md/trac/wiki/RequirementsList >=20 > * Use Cases (under construction) > http://trac.tools.ietf.org/bof/e2md/trac/wiki/UseCases >=20 > Note: No other topics are discussed during this call. >=20 > Looking forward to you Doodle responses! >=20 > cheers, > Bernie > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From bernie@ietf.hoeneisen.ch Wed May 19 00:53: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 BDAC03A6BF4 for ; Wed, 19 May 2010 00:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.585 X-Spam-Level: X-Spam-Status: No, score=-0.585 tagged_above=-999 required=5 tests=[AWL=-0.586, 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 i6CnUbZS+y5O for ; Wed, 19 May 2010 00:53:29 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id A1E3C3A6C15 for ; Wed, 19 May 2010 00:49:37 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1OEe1v-0007X2-Of; Wed, 19 May 2010 09:49:27 +0200 Date: Wed, 19 May 2010 09:49:27 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Lawrence Conroy In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: 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: Next Conf-Call on Requirements 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, 19 May 2010 07:53:31 -0000 Hi Lawrence On Tue, 18 May 2010, Lawrence Conroy wrote: > Hi Bernie, folks, > I am slightly confused. The Dean & Rich show does that :)p > > This looks rather like a Bait 'n' Switch deal. I face difficulties to see the connection between your email the one you replied to. Your email appears to be a reply to an administrative email containing a doodle poll request. Was your reply really meant as a followup to the doodle poll request or which email was meant? > First Step: > I'd guess that revival could work on Send-N and Unused. > [Assuming we can roll back some of the more arcane restrictions > in section 1.2 of rfc3761bis and the bit moved into the second > paragraph of the intro of section 2]. [Moved to ENUM as it is about 3761bis.] > ----- > > SO ... what is the other stuff that you are asking for requirements, > and some seem to be thinking of other RR types, use of other protocols, > indirection, ... ? > > It sure isn't ENUM. I seem to have lost track. Clarification required. In the upcoming conference call (as decided in the previous call), we intend to discuss the requirements. The goal is to find a common understanding of the requirements and uses cases. I wish we could even walk out of the call with a subset of requirements and use cases that has high chances to lead to an agreed charter soon. Though, timing might be in the way of my wishes... Or was your question not related to the upcoming conference call, but rather to some other email/topic? cheers, Bernie From bernie@ietf.hoeneisen.ch Wed May 19 01:38:27 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 558B028C0ED for ; Wed, 19 May 2010 01:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.551 X-Spam-Level: X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[AWL=-0.552, 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 vMRh0AZHftCv for ; Wed, 19 May 2010 01:38:26 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 483273A6B61 for ; Wed, 19 May 2010 01:34:12 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1OEej5-0007fv-I2 for e2md@ietf.org; Wed, 19 May 2010 10:34:03 +0200 Date: Wed, 19 May 2010 10:34:03 +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] REMINDER: Action Required: Your version of the Problem statement needed (fwd) X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 08:38:27 -0000 Dear E2MD fellows Last week I asked everybody to send his understanding of the problem statement to the list (see below). So far a few responses have come in. However, most of you have not sent a problem statement yet. The deadline is tomorrow. So there a still a coule of hours left. To have an overview on the different version of the problem is crusial for making progress with E2MD! Consequences: Those of you, who decide to not to send their problem statement to the mailing list, will be considered as "not having a problem". In these occasions where resources are limited (e.g. time on a conference call, speaking time in a meeting) those who sent in a (precise) problem statement will be given priority. If you do not agree with the above rule, you can challenge it, by making an alternative proposal to the list. Silence will be taken as consent. cheers, Bernie ---------- Forwarded message ---------- Date: Thu, 13 May 2010 15:28:16 From: Bernie Hoeneisen To: E.164 To MetaData BOF discussion list Subject: [e2md] Action Required: Your version of the Problem statement needed Dear E2MD fellows >From the different opinions stated within the last months, I've come to the conclusion that we are missing a common understanding of the problem statement for E2MD. Or in other words, I am not sure whether all of us are trying to solve the same problem... If we want to make progress of any kind we must sort this out, before taking any further steps. Therefore I kindly request all of you to express to this list, WHAT YOU THINK IS THE PROBLEM we are going to address with E2MD? Please send your version of the problem statement to this list no later than May 20th, 2010. (Note: the deadline for requesting meeting time for Maastricht is approaching.) Once we have collected all the different versions of problem statement, we can consolidate those and we will have a basis for the decision on the path forward. Looking forward to get your input (by Thu, 20 May 2010)! cheers, Bernie _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From pp3129@att.com Wed May 19 08:04: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 508243A66B4 for ; Wed, 19 May 2010 08:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.37 X-Spam-Level: X-Spam-Status: No, score=-104.37 tagged_above=-999 required=5 tests=[AWL=-0.371, 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 nZtr1x3Pq3+y for ; Wed, 19 May 2010 08:04:09 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 50D253A69A4 for ; Wed, 19 May 2010 08:04:03 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-15.tower-129.messagelabs.com!1274281434!27885174!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 31260 invoked from network); 19 May 2010 15:03:55 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-15.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 May 2010 15:03:55 -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 o4JF3ZXZ000985 for ; Wed, 19 May 2010 11:03:35 -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 o4JF3Uhu000874 for ; Wed, 19 May 2010 11:03:30 -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: Wed, 19 May 2010 11:03:47 -0400 Message-ID: <35FE871E2B085542A35726420E29DA6B040143F4@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [e2md] Problem statement, Requirements and Use Cases Thread-Index: Acr1xFKNQ4yM6wo0TK+YD4hGImVBogBnlS2Q References: <32FCCBEC-E8B1-45D9-A068-0B120AAADC55@rfc1035.com> From: "PFAUTZ, PENN L (ATTCORP)" To: "E.164 To MetaData BOF discussion list" Subject: [e2md] Problem statement, Requirements and Use Cases X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 15:04:10 -0000 As promised some words for the Global SP ID use case: Use RFC 3761 technology provide for the Carrier of Record for an E.164 number (as defined in RFC 5067) to publish the mapping of that E.164 to a globally defined identifier, specifically an IANA Enterprise Number as defined in RFC 2578. [fire away!] Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Bernie Hoeneisen Sent: Monday, May 17, 2010 9:20 AM To: Jim Reid Cc: E.164 To MetaData BOF discussion list Subject: [e2md] Problem statement, Requirements and Use Cases (was RFC 5507 & RFC 5395) Hi Jim On Mon, 17 May 2010, Jim Reid wrote: > With that in mind, I make the following suggestion. Could whoever is in=20 > charge of this BOF ask those who have use cases and requirements to submit=20 > them and set a deadline for that input? If nothing is forthcoming, then there=20 > isn't a problem to work on and we can all go home. And if we get that info,=20 > there would at least be a basis for a problem statement that could then be=20 > analysed and perhaps worked on. About Problem statement: Last week I sent out an email with Subject: "Action Required: Your version=20 of the Problem statement needed", which pretty much covers this. As I have=20 only seen a few answers, I maybe could send a reminder. About Requirements: A call for requirements sime weeks ago resulted in the following: http://trac.tools.ietf.org/bof/e2md/trac/wiki/RequirementsList (AFAICR only Jay and Dean have been contributing so far.) About Use Cases: BTW: Long before the BoF I also publically asked for Use Cases, which=20 is still the basis for the Use Cases we are discussing here. Details see E2MD archives. Wiki page under construction: http://trac.tools.ietf.org/bof/e2md/trac/wiki/UseCases Wiki: Here the list of links to the Wiki pages: - Main E2MD Wiki Page: http://trac.tools.ietf.org/bof/e2md/trac/wiki - Requirements: http://trac.tools.ietf.org/bof/e2md/trac/wiki/RequirementsList - Use Cases (under construction) http://trac.tools.ietf.org/bof/e2md/trac/wiki/UseCases - Objections (Ticketing System) http://trac.tools.ietf.org/bof/e2md/trac/report/10 I would wish the Wiki was more of a collaborative happening as opposed to=20 one person doing all the work... cheers, Bernie _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From trutkowski@netmagic.com Wed May 19 08:52: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 BC1703A69FC for ; Wed, 19 May 2010 08:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.816 X-Spam-Level: X-Spam-Status: No, score=-0.816 tagged_above=-999 required=5 tests=[AWL=-0.817, 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 J1DkUHbsPuUL for ; Wed, 19 May 2010 08:52:28 -0700 (PDT) Received: from vms173011pub.verizon.net (vms173011pub.verizon.net [206.46.173.11]) by core3.amsl.com (Postfix) with ESMTP id 8C9AD3A69F9 for ; Wed, 19 May 2010 08:52:28 -0700 (PDT) Received: from [192.168.0.20] ([unknown] [173.71.223.14]) by vms173011.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L2O00IGDC2H4OA0@vms173011.mailsrvcs.net> for e2md@ietf.org; Wed, 19 May 2010 10:51:54 -0500 (CDT) Message-id: <4BF40919.9000907@netmagic.com> Date: Wed, 19 May 2010 11:51: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: "PFAUTZ, PENN L (ATTCORP)" References: <32FCCBEC-E8B1-45D9-A068-0B120AAADC55@rfc1035.com> <35FE871E2B085542A35726420E29DA6B040143F4@gaalpa1msgusr7a.ugd.att.com> In-reply-to: <35FE871E2B085542A35726420E29DA6B040143F4@gaalpa1msgusr7a.ugd.att.com> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Problem statement, Requirements and Use Cases 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: Wed, 19 May 2010 15:52:29 -0000 On 5/19/2010 11:03 AM, PFAUTZ, PENN L (ATTCORP) wrote: > Use RFC 3761 technology provide for the Carrier of Record for an E.164 > number (as defined in RFC 5067) to publish the mapping of > that E.164 to a globally defined identifier, specifically an IANA > Enterprise Number as defined in RFC 2578. > Hi Penn, Good choice. However, the text needs tweaking to read: Use RFC 3761 technology to provide for the Carrier of Record for an E.164 number (as defined in RFC 5067) to publish the mapping of that E.164 number using an assigned Carrier of Record Object Identifier (OID)) such as an IANA Enterprise Number as defined in RFC 2578. Ref. Rec. ITU-T Recs. X.660 and X.680. The changes clarify what identifier is being specified and includes reference to the authoritative OID standard. It also allows for the possibility of using other assigned OIDs for a Carrier of Record. Although more than 35,000 Enterprise Numbers have been registered with IANA, there are many carriers who have OIDs that were registered with national authorities for Carrier of Record purposes. As long as there is a valid, globally unique OID, some flexibility should exist. For example, ATT has the OID 1.3.6.1.4.74 from IANA's OID block, but it also has 0.7.7223 that it uses for some services in Argentina. best, tony From pp3129@att.com Wed May 19 09:45: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 8944B3A6847 for ; Wed, 19 May 2010 09:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.336 X-Spam-Level: X-Spam-Status: No, score=-104.336 tagged_above=-999 required=5 tests=[AWL=-0.337, 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 LVsmwCsDCcrG for ; Wed, 19 May 2010 09:45:23 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id A556B3A6818 for ; Wed, 19 May 2010 09:45:23 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-11.tower-129.messagelabs.com!1274287515!14712346!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 15119 invoked from network); 19 May 2010 16:45:16 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 May 2010 16:45:16 -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 o4JGivGi017195 for ; Wed, 19 May 2010 12:44:57 -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 o4JGipPe017096 for ; Wed, 19 May 2010 12:44:52 -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: Wed, 19 May 2010 12:45:10 -0400 Message-ID: <35FE871E2B085542A35726420E29DA6B0401450B@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <4BF40919.9000907@netmagic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [e2md] Problem statement, Requirements and Use Cases Thread-Index: Acr3a0BZG8yLIclLRaCzOX53GUtXzwABkaUA References: <32FCCBEC-E8B1-45D9-A068-0B120AAADC55@rfc1035.com> <35FE871E2B085542A35726420E29DA6B040143F4@gaalpa1msgusr7a.ugd.att.com> <4BF40919.9000907@netmagic.com> From: "PFAUTZ, PENN L (ATTCORP)" To: Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Problem statement, Requirements and Use Cases X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 16:45:24 -0000 Tony: This is an area that will need more discussion which I hope will ensue, if not necessarily under e2md then in the IETF, ITU, i3 and national SDOs. At least some bodies are looking for a single integer (SPN), e.g. the value under the OID 1.3.6.1.4 arc, for AT&T 74. There have also been some requests to support hierarchy subtending an SPN.=20 Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: Tony Rutkowski [mailto:trutkowski@netmagic.com]=20 Sent: Wednesday, May 19, 2010 11:52 AM To: PFAUTZ, PENN L (ATTCORP) Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] Problem statement, Requirements and Use Cases On 5/19/2010 11:03 AM, PFAUTZ, PENN L (ATTCORP) wrote: > Use RFC 3761 technology provide for the Carrier of Record for an E.164 > number (as defined in RFC 5067) to publish the mapping of > that E.164 to a globally defined identifier, specifically an IANA > Enterprise Number as defined in RFC 2578. > =20 Hi Penn, Good choice. However, the text needs tweaking to read: Use RFC 3761 technology to provide for the Carrier of Record for an E.164 number (as defined in RFC 5067) to publish the mapping of that E.164 number using an assigned Carrier of Record Object Identifier (OID)) such as an IANA Enterprise Number as defined in RFC 2578. Ref. Rec. ITU-T Recs. X.660 and X.680. The changes clarify what identifier is being specified and includes reference to the authoritative OID standard. It also allows for the possibility of using other assigned OIDs for a Carrier of Record. Although more than 35,000 Enterprise Numbers have been registered with IANA, there are many carriers who have OIDs that were registered with national authorities for Carrier of Record purposes. As long as there is a valid, globally unique OID, some flexibility should exist. For example, ATT has the OID 1.3.6.1.4.74 from IANA's OID block, but it also has 0.7.7223 that it uses for some services in Argentina. best, tony From trutkowski@netmagic.com Wed May 19 10:18: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 4F7AB3A6C7B for ; Wed, 19 May 2010 10:18:32 -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 jmNTLDsimNAQ for ; Wed, 19 May 2010 10:18:31 -0700 (PDT) Received: from vms173013pub.verizon.net (vms173013pub.verizon.net [206.46.173.13]) by core3.amsl.com (Postfix) with ESMTP id 254A328C0DC for ; Wed, 19 May 2010 10:17:34 -0700 (PDT) Received: from [192.168.0.20] ([unknown] [173.71.223.14]) by vms173013.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L2O0071AG09QH90@vms173013.mailsrvcs.net> for e2md@ietf.org; Wed, 19 May 2010 12:16:57 -0500 (CDT) Message-id: <4BF41D09.8080604@netmagic.com> Date: Wed, 19 May 2010 13:16:57 -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: "PFAUTZ, PENN L (ATTCORP)" References: <32FCCBEC-E8B1-45D9-A068-0B120AAADC55@rfc1035.com> <35FE871E2B085542A35726420E29DA6B040143F4@gaalpa1msgusr7a.ugd.att.com> <4BF40919.9000907@netmagic.com> <35FE871E2B085542A35726420E29DA6B0401450B@gaalpa1msgusr7a.ugd.att.com> In-reply-to: <35FE871E2B085542A35726420E29DA6B0401450B@gaalpa1msgusr7a.ugd.att.com> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Problem statement, Requirements and Use Cases 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: Wed, 19 May 2010 17:18:32 -0000 On 5/19/2010 12:45 PM, PFAUTZ, PENN L (ATTCORP) wrote: > This is an area that will need more discussion which I hope will ensue, > if not necessarily under e2md then in the IETF, ITU, i3 and national > SDOs. At least some bodies are looking for a single integer (SPN), e.g. > the value under the OID 1.3.6.1.4 arc, for AT&T 74. There have also been > some requests to support hierarchy subtending an SPN. > Agreed. Another international carrier identifier choice is ITU-ICCs pursuant to the M.1400 standard. However, their six alphanumeric character structure doesn't scale, and the uptake has been minimal. Almost every country has one or more national identifiers for carriers, but those differ structurally and are not global by definition. Then there is the new NeuStar proposal for a five digit number issued by either the ITU equivalent of IANA (the TSB) or by national telephone managers like NeuStar. However, these don't scale, would have significant regulatory burdens and costs, and seem unlikely to be accepted as a new global SPID. OIDs on the other hand were created in the 1980s as a universal, simple, extensible identifier for all entities, explicitly including service providers. They are hierarchical and can be recursively resolved. They are widely used as SPIDs. The assignment identity proofing and maintenance leaves something to be improved, but this is being addressed with the use of X.509 or EVcerts or other assurance overlays. Anyhow, those seem like the SPID alternatives. --tony From kcartwright@tnsi.com Wed May 19 11:50: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 45CF83A6D1A; Wed, 19 May 2010 11:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.636 X-Spam-Level: X-Spam-Status: No, score=-0.636 tagged_above=-999 required=5 tests=[AWL=-0.637, 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 g9-Rz4RsdbUb; Wed, 19 May 2010 11:50:35 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 9047B3A6D45; Wed, 19 May 2010 11:39:39 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.43788276; Wed, 19 May 2010 14:39:27 -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, 19 May 2010 14:39:27 -0400 From: "Cartwright, Kenneth" To: "trutkowski@netmagic.com" , "PFAUTZ, PENN L (ATTCORP)" Date: Wed, 19 May 2010 14:39:26 -0400 Thread-Topic: [e2md] Problem statement, Requirements and Use Cases Thread-Index: Acr3a0oWVJhs61uMS1qbkx3qpv5RpgAEpNCg Message-ID: <754963199212404AB8E9CFCA6C3D0CDA2446D2C041@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <32FCCBEC-E8B1-45D9-A068-0B120AAADC55@rfc1035.com> <35FE871E2B085542A35726420E29DA6B040143F4@gaalpa1msgusr7a.ugd.att.com> <4BF40919.9000907@netmagic.com> In-Reply-To: <4BF40919.9000907@netmagic.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: "drinks@ietf.org" , "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Problem statement, Requirements and Use Cases X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 18:50:37 -0000 As Penn wisely points out, this can be discussed in detail in the appropria= te forum at the appropriate time, however, .... The ITUs OID looks like a good option. It seems to meet the following requ= irements/advantages: 1) It already exists; no need to invent and debate a new scheme, approach, = documentation set, etc. 2) It is hierarchical; organizations can optionally create sub-OIDs (or sub= trees) under their main OID if they need to. 3) The sub-identifiers under the main identifier can be opaque; they need n= ot have a known, or the same known, meaning to all parties that may use/see= them 4) There is an existing urn that _might_ be useful "urn:oid" 5) If the set of existing OIDs already allocated under one of the existing = OID trees (e.g. 1.3.6.1.4) are not appropriate then it seems that an organi= zation (e.g. IANA) can be formally delegated the responsibility of dolling = out (similar to the way that it doles out Enterprise Numbers) the OIDs unde= r a new OID tree. IOW, the OID tree it centrally managed, but the manageme= nt of sub-trees can be delegated. 6) They are cleanly parseable by a computer or a human; their form is stand= ardized and well structured. A disadvantage, however, is that ITU OIDs can theoretically be fairly long = (in contrast to the 4 characters that comprise a north american OCN or SPID= , or the handful of digits that comprise the IANA Enterprise Number). But = it is not clear to me whether in practice, given our use case, if they will= ever be as long as they can theoretically be. The spec for our usage woul= d just need to address this point. http://www.itu.int/ITU-T/asn1/uuid.html http://www.oid-info.com/#oid Ken -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Ton= y Rutkowski Sent: Wednesday, May 19, 2010 11:52 AM To: PFAUTZ, PENN L (ATTCORP) Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] Problem statement, Requirements and Use Cases On 5/19/2010 11:03 AM, PFAUTZ, PENN L (ATTCORP) wrote: > Use RFC 3761 technology provide for the Carrier of Record for an E.164 > number (as defined in RFC 5067) to publish the mapping of > that E.164 to a globally defined identifier, specifically an IANA > Enterprise Number as defined in RFC 2578. > Hi Penn, Good choice. However, the text needs tweaking to read: Use RFC 3761 technology to provide for the Carrier of Record for an E.164 number (as defined in RFC 5067) to publish the mapping of that E.164 number using an assigned Carrier of Record Object Identifier (OID)) such as an IANA Enterprise Number as defined in RFC 2578. Ref. Rec. ITU-T Recs. X.660 and X.680. The changes clarify what identifier is being specified and includes reference to the authoritative OID standard. It also allows for the possibility of using other assigned OIDs for a Carrier of Record. Although more than 35,000 Enterprise Numbers have been registered with IANA, there are many carriers who have OIDs that were registered with national authorities for Carrier of Record purposes. As long as there is a valid, globally unique OID, some flexibility should exist. For example, ATT has the OID 1.3.6.1.4.74 from IANA's OID block, but it also has 0.7.7223 that it uses for some services in Argentina. best, tony _______________________________________________ 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 Wed May 19 12:05: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 B8B663A6A94 for ; Wed, 19 May 2010 12:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.617 X-Spam-Level: X-Spam-Status: No, score=-0.617 tagged_above=-999 required=5 tests=[AWL=-0.618, 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 a09kSeQpamGG for ; Wed, 19 May 2010 12:05:10 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id D03D23A6C64 for ; Wed, 19 May 2010 11:58:21 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.43788774; Wed, 19 May 2010 14:58:09 -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, 19 May 2010 14:58:09 -0400 From: "Cartwright, Kenneth" To: "PFAUTZ, PENN L (ATTCORP)" , E.164 To MetaData BOF discussion list Date: Wed, 19 May 2010 14:58:07 -0400 Thread-Topic: [e2md] Problem statement, Requirements and Use Cases Thread-Index: Acr1xFKNQ4yM6wo0TK+YD4hGImVBogBnlS2QAACs+rA= Message-ID: <754963199212404AB8E9CFCA6C3D0CDA2446D2C070@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <32FCCBEC-E8B1-45D9-A068-0B120AAADC55@rfc1035.com> <35FE871E2B085542A35726420E29DA6B040143F4@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <35FE871E2B085542A35726420E29DA6B040143F4@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 Subject: Re: [e2md] Problem statement, Requirements and Use Cases X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 19:05:11 -0000 Applying Penn's general phraseology to Rich's CNAM, one might say the high-= level CNAM problem statement is... Use RFC 3761 technology to provide a standardized query/response protocol f= or the Calling Name information of E.164 numbers in either public or access= controlled environments. But to keep Dean happy, ( :-) just teasing Dean), here's a more generic way= of stating this... Using technologies that coherently integrate with existing, IP based, call = establishment technology stacks and call flows, provide a standardized quer= y/response protocol for the Calling Name information of E.164 numbers in ei= ther public or access controlled environments. Rich can probably offer a more thorough problem statement. But the more de= tailed requirements are already documented elsewhere. Ken -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of PFA= UTZ, PENN L (ATTCORP) Sent: Wednesday, May 19, 2010 11:04 AM To: E.164 To MetaData BOF discussion list Subject: [e2md] Problem statement, Requirements and Use Cases As promised some words for the Global SP ID use case: Use RFC 3761 technology provide for the Carrier of Record for an E.164 number (as defined in RFC 5067) to publish the mapping of that E.164 to a globally defined identifier, specifically an IANA Enterprise Number as defined in RFC 2578. [fire away!] Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Bernie Hoeneisen Sent: Monday, May 17, 2010 9:20 AM To: Jim Reid Cc: E.164 To MetaData BOF discussion list Subject: [e2md] Problem statement, Requirements and Use Cases (was RFC 5507 & RFC 5395) Hi Jim On Mon, 17 May 2010, Jim Reid wrote: > With that in mind, I make the following suggestion. Could whoever is in > charge of this BOF ask those who have use cases and requirements to submit > them and set a deadline for that input? If nothing is forthcoming, then there > isn't a problem to work on and we can all go home. And if we get that info, > there would at least be a basis for a problem statement that could then be > analysed and perhaps worked on. About Problem statement: Last week I sent out an email with Subject: "Action Required: Your version of the Problem statement needed", which pretty much covers this. As I have only seen a few answers, I maybe could send a reminder. About Requirements: A call for requirements sime weeks ago resulted in the following: http://trac.tools.ietf.org/bof/e2md/trac/wiki/RequirementsList (AFAICR only Jay and Dean have been contributing so far.) About Use Cases: BTW: Long before the BoF I also publically asked for Use Cases, which is still the basis for the Use Cases we are discussing here. Details see E2MD archives. Wiki page under construction: http://trac.tools.ietf.org/bof/e2md/trac/wiki/UseCases Wiki: Here the list of links to the Wiki pages: - Main E2MD Wiki Page: http://trac.tools.ietf.org/bof/e2md/trac/wiki - Requirements: http://trac.tools.ietf.org/bof/e2md/trac/wiki/RequirementsList - Use Cases (under construction) http://trac.tools.ietf.org/bof/e2md/trac/wiki/UseCases - Objections (Ticketing System) http://trac.tools.ietf.org/bof/e2md/trac/report/10 I would wish the Wiki was more of a collaborative happening as opposed to one person doing all the work... cheers, Bernie _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From trutkowski@netmagic.com Wed May 19 12:44: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 A2FFF3A685B; Wed, 19 May 2010 12:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.583 X-Spam-Level: X-Spam-Status: No, score=-0.583 tagged_above=-999 required=5 tests=[AWL=-0.584, 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 8gZGyJiTBmN0; Wed, 19 May 2010 12:44:25 -0700 (PDT) Received: from vms173013pub.verizon.net (vms173013pub.verizon.net [206.46.173.13]) by core3.amsl.com (Postfix) with ESMTP id A3A463A6D03; Wed, 19 May 2010 12:36:28 -0700 (PDT) Received: from [192.168.0.20] ([unknown] [173.71.223.14]) by vms173013.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L2O00F06MA4AM70@vms173013.mailsrvcs.net>; Wed, 19 May 2010 14:32:29 -0500 (CDT) Message-id: <4BF43CCC.3040305@netmagic.com> Date: Wed, 19 May 2010 15:32:28 -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: "Cartwright, Kenneth" References: <32FCCBEC-E8B1-45D9-A068-0B120AAADC55@rfc1035.com> <35FE871E2B085542A35726420E29DA6B040143F4@gaalpa1msgusr7a.ugd.att.com> <4BF40919.9000907@netmagic.com> <754963199212404AB8E9CFCA6C3D0CDA2446D2C041@TNS-MAIL-NA.win2k.corp.tnsi.com> In-reply-to: <754963199212404AB8E9CFCA6C3D0CDA2446D2C041@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Cc: "drinks@ietf.org" , "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Problem statement, Requirements and Use Cases 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: Wed, 19 May 2010 19:44:27 -0000 Hi Ken, Just to clarify. > 5) If the set of existing OIDs already allocated under one of the existing OID trees (e.g. 1.3.6.1.4) are not appropriate then it seems that an organization (e.g. IANA) can be formally delegated the responsibility of dolling out (similar to the way that it doles out Enterprise Numbers) the OIDs under a new OID tree. IOW, the OID tree it centrally managed, but the management of sub-trees can be delegated. > This has recently been done for some other namespaces, e.g, for object tags (2.27), telebiometrics (2.42), cybersecurity (2.48), and alerting (2.29). You can peruse the tree at http://www.oid-info.com/cgi-bin/display?tree=2 The flip side is that a lot of carriers and enterprises exist in the arcs 0.3 and 1.3.6.1.4 and there are a couple decades of extensive OID uses, e.g., for SNMP and PKI certs, and any structured ontology for a new arc would likely include at least a geographic layer using a 3 number country code which gets pretty close to the existing Enterprise Number number count. > A disadvantage, however, is that ITU OIDs can theoretically be fairly long (in contrast to the 4 characters that comprise a north american OCN or SPID, or the handful of digits that comprise the IANA Enterprise Number). But it is not clear to me whether in What is called an OCN in the North America is known as an ITU Carrier Code worldwide, and created pursuant to ITU-T Rec. M.1400. It's a six character alphanumeric code. See Annex E. https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-M.1400-200607-I!!PDF-E&type=items Another advantage of OIDs includes their widespread inclusion in X.509 digital certificates. --tony From pp3129@att.com Wed May 19 12:55: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 75F063A6A17; Wed, 19 May 2010 12:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.608 X-Spam-Level: X-Spam-Status: No, score=-105.608 tagged_above=-999 required=5 tests=[AWL=0.991, BAYES_00=-2.599, 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 5f8suG0pzZmn; Wed, 19 May 2010 12:55:12 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 1C2773A6A8E; Wed, 19 May 2010 12:53:59 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-11.tower-120.messagelabs.com!1274298830!48138065!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 3665 invoked from network); 19 May 2010 19:53:51 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 May 2010 19:53:51 -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 o4JJrWtS008749; Wed, 19 May 2010 15:53:32 -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 o4JJrRn1008641; Wed, 19 May 2010 15:53: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: Wed, 19 May 2010 15:53:44 -0400 Message-ID: <35FE871E2B085542A35726420E29DA6B040146B8@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CF49FA0EF@srvxchg> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [e2md] Problem statement, Requirements and Use Cases Thread-Index: Acr3a0oWVJhs61uMS1qbkx3qpv5RpgAEpNCgAAK1GJAAAPeMcA== References: <32FCCBEC-E8B1-45D9-A068-0B120AAADC55@rfc1035.com><35FE871E2B085542A35726420E29DA6B040143F4@gaalpa1msgusr7a.ugd.att.com><4BF40919.9000907@netmagic.com> <754963199212404AB8E9CFCA6C3D0CDA2446D2C041@TNS-MAIL-NA.win2k.corp.tnsi.com> <76AC5FEF83F1E64491446437EA81A61F7CF49FA0EF@srvxchg> From: "PFAUTZ, PENN L (ATTCORP)" To: "Sumanth Channabasappa" , "Cartwright, Kenneth" , Cc: drinks@ietf.org, "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Problem statement, Requirements and Use Cases X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 19:55:15 -0000 Aye, that's the question! I know of at least a couple of bodies looking for SPN that would just like to use the terminal element - not the rest of the OID string. Whether that ultimately makes sense or the overhead of using the whole thing proves in I don't know. One could even imagine different local conventions. =20 Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: Sumanth Channabasappa [mailto:sumanth@cablelabs.com]=20 Sent: Wednesday, May 19, 2010 3:45 PM To: Cartwright, Kenneth; trutkowski@netmagic.com; PFAUTZ, PENN L (ATTCORP) Cc: drinks@ietf.org; E.164 To MetaData BOF discussion list Subject: RE: [e2md] Problem statement, Requirements and Use Cases When we speak about OIDs here, we are speaking of OIDs formed via the IANA Enterprise Numbers, correct (1.3.6.1.4...)? If so, do we need an extra string for all enterprises (1.3...) or can we just use the enterprise number? And if we want a hierarchy, it can always be constructed underneath the IANA Enterprise number, no? - S -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Cartwright, Kenneth Sent: Wednesday, May 19, 2010 12:39 PM To: trutkowski@netmagic.com; PFAUTZ, PENN L (ATTCORP) Cc: drinks@ietf.org; E.164 To MetaData BOF discussion list Subject: Re: [drinks] [e2md] Problem statement, Requirements and Use Cases As Penn wisely points out, this can be discussed in detail in the appropriate forum at the appropriate time, however, .... The ITUs OID looks like a good option. It seems to meet the following requirements/advantages: 1) It already exists; no need to invent and debate a new scheme, approach, documentation set, etc. 2) It is hierarchical; organizations can optionally create sub-OIDs (or sub trees) under their main OID if they need to. 3) The sub-identifiers under the main identifier can be opaque; they need not have a known, or the same known, meaning to all parties that may use/see them 4) There is an existing urn that _might_ be useful "urn:oid" 5) If the set of existing OIDs already allocated under one of the existing OID trees (e.g. 1.3.6.1.4) are not appropriate then it seems that an organization (e.g. IANA) can be formally delegated the responsibility of dolling out (similar to the way that it doles out Enterprise Numbers) the OIDs under a new OID tree. IOW, the OID tree it centrally managed, but the management of sub-trees can be delegated. 6) They are cleanly parseable by a computer or a human; their form is standardized and well structured. A disadvantage, however, is that ITU OIDs can theoretically be fairly long (in contrast to the 4 characters that comprise a north american OCN or SPID, or the handful of digits that comprise the IANA Enterprise Number). But it is not clear to me whether in practice, given our use case, if they will ever be as long as they can theoretically be. The spec for our usage would just need to address this point. http://www.itu.int/ITU-T/asn1/uuid.html http://www.oid-info.com/#oid Ken -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Tony Rutkowski Sent: Wednesday, May 19, 2010 11:52 AM To: PFAUTZ, PENN L (ATTCORP) Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] Problem statement, Requirements and Use Cases On 5/19/2010 11:03 AM, PFAUTZ, PENN L (ATTCORP) wrote: > Use RFC 3761 technology provide for the Carrier of Record for an E.164 > number (as defined in RFC 5067) to publish the mapping of that E.164=20 > to a globally defined identifier, specifically an IANA Enterprise=20 > Number as defined in RFC 2578. > Hi Penn, Good choice. However, the text needs tweaking to read: Use RFC 3761 technology to provide for the Carrier of Record for an E.164 number (as defined in RFC 5067) to publish the mapping of that E.164 number using an assigned Carrier of Record Object Identifier (OID)) such as an IANA Enterprise Number as defined in RFC 2578. Ref. Rec. ITU-T Recs. X.660 and X.680. The changes clarify what identifier is being specified and includes reference to the authoritative OID standard. It also allows for the possibility of using other assigned OIDs for a Carrier of Record. Although more than 35,000 Enterprise Numbers have been registered with IANA, there are many carriers who have OIDs that were registered with national authorities for Carrier of Record purposes. As long as there is a valid, globally unique OID, some flexibility should exist. For example, ATT has the OID 1.3.6.1.4.74 from IANA's OID block, but it also has 0.7.7223 that it uses for some services in Argentina. best, tony _______________________________________________ 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 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. _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks From trutkowski@netmagic.com Wed May 19 13:13: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 6C2BC3A63D3; Wed, 19 May 2010 13:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[AWL=-0.511, 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 QECWDo-OIvNr; Wed, 19 May 2010 13:12:58 -0700 (PDT) Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by core3.amsl.com (Postfix) with ESMTP id C10653A689D; Wed, 19 May 2010 13:12:53 -0700 (PDT) Received: from [192.168.0.20] ([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 <0L2O00JP9O1YEK70@vms173001.mailsrvcs.net>; Wed, 19 May 2010 15:10:52 -0500 (CDT) Message-id: <4BF445C6.1020308@netmagic.com> Date: Wed, 19 May 2010 16:10:46 -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: Sumanth Channabasappa References: <32FCCBEC-E8B1-45D9-A068-0B120AAADC55@rfc1035.com> <35FE871E2B085542A35726420E29DA6B040143F4@gaalpa1msgusr7a.ugd.att.com> <4BF40919.9000907@netmagic.com> <754963199212404AB8E9CFCA6C3D0CDA2446D2C041@TNS-MAIL-NA.win2k.corp.tnsi.com> <76AC5FEF83F1E64491446437EA81A61F7CF49FA0EF@srvxchg> In-reply-to: <76AC5FEF83F1E64491446437EA81A61F7CF49FA0EF@srvxchg> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Cc: "drinks@ietf.org" , "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Problem statement, Requirements and Use Cases 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: Wed, 19 May 2010 20:13:01 -0000 On 5/19/2010 3:44 PM, Sumanth Channabasappa wrote: > When we speak about OIDs here, we are speaking of OIDs formed via the IANA Enterprise Numbers, correct (1.3.6.1.4...)? If so, do we need an extra string for all enterprises (1.3...) or can we just use the enterprise number? And if we want a hierarchy, it can always be constructed underneath the IANA Enterprise number, no? > You could do this. However, you lose the ability to have other SPID OID constructs, including those with localizations. Different countries and carriers have chosen different OID arcs they are using. Like it or not, E.164 numbers are under the control of sovereign States and provider assignees, and they might just want to specify and control their own namespaces for Carriers of Record. It seems wise to provide that latitude for any spec you are devising. --tony From sumanth@cablelabs.com Wed May 19 12:49: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 2C3093A63D3; Wed, 19 May 2010 12:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.225 X-Spam-Level: * X-Spam-Status: No, score=1.225 tagged_above=-999 required=5 tests=[AWL=-0.912, BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 7pQOqfU1xw3F; Wed, 19 May 2010 12:49:16 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id CE83B3A6874; Wed, 19 May 2010 12:44:54 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o4JJijl0031643; Wed, 19 May 2010 13:44:45 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 19 May 2010 13:44:45 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 19 May 2010 13:44:46 -0600 From: Sumanth Channabasappa To: "Cartwright, Kenneth" , "trutkowski@netmagic.com" , "PFAUTZ, PENN L (ATTCORP)" Date: Wed, 19 May 2010 13:44:44 -0600 Thread-Topic: [e2md] Problem statement, Requirements and Use Cases Thread-Index: Acr3a0oWVJhs61uMS1qbkx3qpv5RpgAEpNCgAAK1GJA= Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CF49FA0EF@srvxchg> References: <32FCCBEC-E8B1-45D9-A068-0B120AAADC55@rfc1035.com> <35FE871E2B085542A35726420E29DA6B040143F4@gaalpa1msgusr7a.ugd.att.com> <4BF40919.9000907@netmagic.com> <754963199212404AB8E9CFCA6C3D0CDA2446D2C041@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA2446D2C041@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 X-Approved: ondar X-Mailman-Approved-At: Wed, 19 May 2010 13:35:57 -0700 Cc: "drinks@ietf.org" , "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Problem statement, Requirements and Use Cases X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 19:49:18 -0000 When we speak about OIDs here, we are speaking of OIDs formed via the IANA = Enterprise Numbers, correct (1.3.6.1.4...)? If so, do we need an extra stri= ng for all enterprises (1.3...) or can we just use the enterprise number? A= nd if we want a hierarchy, it can always be constructed underneath the IANA= Enterprise number, no? - S -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Cartwright, Kenneth Sent: Wednesday, May 19, 2010 12:39 PM To: trutkowski@netmagic.com; PFAUTZ, PENN L (ATTCORP) Cc: drinks@ietf.org; E.164 To MetaData BOF discussion list Subject: Re: [drinks] [e2md] Problem statement, Requirements and Use Cases As Penn wisely points out, this can be discussed in detail in the appropria= te forum at the appropriate time, however, .... The ITUs OID looks like a good option. It seems to meet the following requ= irements/advantages: 1) It already exists; no need to invent and debate a new scheme, approach, = documentation set, etc. 2) It is hierarchical; organizations can optionally create sub-OIDs (or sub= trees) under their main OID if they need to. 3) The sub-identifiers under the main identifier can be opaque; they need n= ot have a known, or the same known, meaning to all parties that may use/see= them 4) There is an existing urn that _might_ be useful "urn:oid" 5) If the set of existing OIDs already allocated under one of the existing = OID trees (e.g. 1.3.6.1.4) are not appropriate then it seems that an organi= zation (e.g. IANA) can be formally delegated the responsibility of dolling = out (similar to the way that it doles out Enterprise Numbers) the OIDs unde= r a new OID tree. IOW, the OID tree it centrally managed, but the manageme= nt of sub-trees can be delegated. 6) They are cleanly parseable by a computer or a human; their form is stand= ardized and well structured. A disadvantage, however, is that ITU OIDs can theoretically be fairly long = (in contrast to the 4 characters that comprise a north american OCN or SPID= , or the handful of digits that comprise the IANA Enterprise Number). But = it is not clear to me whether in practice, given our use case, if they will= ever be as long as they can theoretically be. The spec for our usage woul= d just need to address this point. http://www.itu.int/ITU-T/asn1/uuid.html http://www.oid-info.com/#oid Ken -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Ton= y Rutkowski Sent: Wednesday, May 19, 2010 11:52 AM To: PFAUTZ, PENN L (ATTCORP) Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] Problem statement, Requirements and Use Cases On 5/19/2010 11:03 AM, PFAUTZ, PENN L (ATTCORP) wrote: > Use RFC 3761 technology provide for the Carrier of Record for an E.164=20 > number (as defined in RFC 5067) to publish the mapping of that E.164=20 > to a globally defined identifier, specifically an IANA Enterprise=20 > Number as defined in RFC 2578. > Hi Penn, Good choice. However, the text needs tweaking to read: Use RFC 3761 technology to provide for the Carrier of Record for an E.164 number (as defined in RFC 5067) to publish the mapping of that E.164 number using an assigned Carrier of Record Object Identifier (OID)) such as an IANA Enterprise Number as defined in RFC 2578. Ref. Rec. ITU-T Recs. X.660 and X.680. The changes clarify what identifier is being specified and includes referen= ce to the authoritative OID standard. It also allows for the possibility o= f using other assigned OIDs for a Carrier of Record. Although more than 35= ,000 Enterprise Numbers have been registered with IANA, there are many carr= iers who have OIDs that were registered with national authorities for Carri= er of Record purposes. As long as there is a valid, globally unique OID, s= ome flexibility should exist. For example, ATT has the OID 1.3.6.1.4.74 from IANA's OID block, but it als= o has 0.7.7223 that it uses for some services in Argentina. best, tony _______________________________________________ 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 Ser= vices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-ma= il and destroy all copies of the original message. _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks From richard@shockey.us Wed May 19 18:23: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 6E8EE3A6BA6 for ; Wed, 19 May 2010 18:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 f9vsuzJzKlwY for ; Wed, 19 May 2010 18:23:03 -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 491DA3A689C for ; Wed, 19 May 2010 18:22:12 -0700 (PDT) Received: (qmail 23344 invoked by uid 0); 20 May 2010 01:15:25 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 20 May 2010 01:15:25 -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=Oseq/g6DjEETlNYlb37+xdxaLenO0EcOiieFNKt5UnBZEMa3F7S4DtcNfbRdnnDuWJgdxOJaV1Tqf2+Rl2oYhaMPAq5XP/R9uFkJ6lGrInVvDDiWtJ0upz4kPV4aaCYc; 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 1OEuM9-0000mw-Io; Wed, 19 May 2010 19:15:25 -0600 From: "Richard Shockey" To: "'Sumanth Channabasappa'" , "'Cartwright, Kenneth'" , , "'PFAUTZ, PENN L \(ATTCORP\)'" References: <32FCCBEC-E8B1-45D9-A068-0B120AAADC55@rfc1035.com> <35FE871E2B085542A35726420E29DA6B040143F4@gaalpa1msgusr7a.ugd.att.com> <4BF40919.9000907@netmagic.com> <754963199212404AB8E9CFCA6C3D0CDA2446D2C041@TNS-MAIL-NA.win2k.corp.tnsi.com> <76AC5FEF83F1E64491446437EA81A61F7CF49FA0EF@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CF49FA0EF@srvxchg> Date: Wed, 19 May 2010 21:15:18 -0400 Message-ID: <000801caf7b9$e9de9790$bd9bc6b0$@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: Acr3a0oWVJhs61uMS1qbkx3qpv5RpgAEpNCgAAK1GJAAC9pR4A== 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: drinks@ietf.org, 'IETF ENUM list' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Problem statement, Requirements and Use Cases X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 01:23:04 -0000 Well .. as far as I'm concerned the discussion of what is the namespace is charming but ultimately another discussion. What is important is the definition of the use case and why opaque carrier identification methodologies is important (vs edge URI identification) and I'd like to call for volunteers to help me or someone to write this up as a ID. There is no possible doubt that this is important to the global telecommunications industry and IMHO is principally utilized principally in private-carrier-infrastructure ENUM instantiations. Not to say that, by some for form of indirection, this could live in e164.arpa but either way it makes sense. It's the right thing to do and the timing is right now. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Sumanth Channabasappa Sent: Wednesday, May 19, 2010 3:45 PM To: Cartwright, Kenneth; trutkowski@netmagic.com; PFAUTZ, PENN L (ATTCORP) Cc: drinks@ietf.org; E.164 To MetaData BOF discussion list Subject: Re: [e2md] Problem statement, Requirements and Use Cases When we speak about OIDs here, we are speaking of OIDs formed via the IANA Enterprise Numbers, correct (1.3.6.1.4...)? If so, do we need an extra string for all enterprises (1.3...) or can we just use the enterprise number? And if we want a hierarchy, it can always be constructed underneath the IANA Enterprise number, no? - S -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Cartwright, Kenneth Sent: Wednesday, May 19, 2010 12:39 PM To: trutkowski@netmagic.com; PFAUTZ, PENN L (ATTCORP) Cc: drinks@ietf.org; E.164 To MetaData BOF discussion list Subject: Re: [drinks] [e2md] Problem statement, Requirements and Use Cases As Penn wisely points out, this can be discussed in detail in the appropriate forum at the appropriate time, however, .... The ITUs OID looks like a good option. It seems to meet the following requirements/advantages: 1) It already exists; no need to invent and debate a new scheme, approach, documentation set, etc. 2) It is hierarchical; organizations can optionally create sub-OIDs (or sub trees) under their main OID if they need to. 3) The sub-identifiers under the main identifier can be opaque; they need not have a known, or the same known, meaning to all parties that may use/see them 4) There is an existing urn that _might_ be useful "urn:oid" 5) If the set of existing OIDs already allocated under one of the existing OID trees (e.g. 1.3.6.1.4) are not appropriate then it seems that an organization (e.g. IANA) can be formally delegated the responsibility of dolling out (similar to the way that it doles out Enterprise Numbers) the OIDs under a new OID tree. IOW, the OID tree it centrally managed, but the management of sub-trees can be delegated. 6) They are cleanly parseable by a computer or a human; their form is standardized and well structured. A disadvantage, however, is that ITU OIDs can theoretically be fairly long (in contrast to the 4 characters that comprise a north american OCN or SPID, or the handful of digits that comprise the IANA Enterprise Number). But it is not clear to me whether in practice, given our use case, if they will ever be as long as they can theoretically be. The spec for our usage would just need to address this point. http://www.itu.int/ITU-T/asn1/uuid.html http://www.oid-info.com/#oid Ken -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Tony Rutkowski Sent: Wednesday, May 19, 2010 11:52 AM To: PFAUTZ, PENN L (ATTCORP) Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] Problem statement, Requirements and Use Cases On 5/19/2010 11:03 AM, PFAUTZ, PENN L (ATTCORP) wrote: > Use RFC 3761 technology provide for the Carrier of Record for an E.164 > number (as defined in RFC 5067) to publish the mapping of that E.164 > to a globally defined identifier, specifically an IANA Enterprise > Number as defined in RFC 2578. > Hi Penn, Good choice. However, the text needs tweaking to read: Use RFC 3761 technology to provide for the Carrier of Record for an E.164 number (as defined in RFC 5067) to publish the mapping of that E.164 number using an assigned Carrier of Record Object Identifier (OID)) such as an IANA Enterprise Number as defined in RFC 2578. Ref. Rec. ITU-T Recs. X.660 and X.680. The changes clarify what identifier is being specified and includes reference to the authoritative OID standard. It also allows for the possibility of using other assigned OIDs for a Carrier of Record. Although more than 35,000 Enterprise Numbers have been registered with IANA, there are many carriers who have OIDs that were registered with national authorities for Carrier of Record purposes. As long as there is a valid, globally unique OID, some flexibility should exist. For example, ATT has the OID 1.3.6.1.4.74 from IANA's OID block, but it also has 0.7.7223 that it uses for some services in Argentina. best, tony _______________________________________________ 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 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. _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From kcartwright@tnsi.com Thu May 20 07:16: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 6A87F3A6CCD; Thu, 20 May 2010 07:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[AWL=-0.600, 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 kDEXluBBPNRO; Thu, 20 May 2010 07:16:08 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id BAE1D3A6919; Thu, 20 May 2010 07:15:24 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.43814285; Thu, 20 May 2010 10:14:51 -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, 20 May 2010 10:14:51 -0400 From: "Cartwright, Kenneth" To: Richard Shockey , 'Sumanth Channabasappa' , "trutkowski@netmagic.com" , "'PFAUTZ, PENN L (ATTCORP)'" Date: Thu, 20 May 2010 10:14:49 -0400 Thread-Topic: [e2md] Problem statement, Requirements and Use Cases Thread-Index: Acr3a0oWVJhs61uMS1qbkx3qpv5RpgAEpNCgAAK1GJAAC9pR4AAbqJww Message-ID: <754963199212404AB8E9CFCA6C3D0CDA2446D2C44A@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <32FCCBEC-E8B1-45D9-A068-0B120AAADC55@rfc1035.com> <35FE871E2B085542A35726420E29DA6B040143F4@gaalpa1msgusr7a.ugd.att.com> <4BF40919.9000907@netmagic.com> <754963199212404AB8E9CFCA6C3D0CDA2446D2C041@TNS-MAIL-NA.win2k.corp.tnsi.com> <76AC5FEF83F1E64491446437EA81A61F7CF49FA0EF@srvxchg> <000801caf7b9$e9de9790$bd9bc6b0$@us> In-Reply-To: <000801caf7b9$e9de9790$bd9bc6b0$@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: "drinks@ietf.org" , 'IETF ENUM list' , list' , 'E.164 Subject: Re: [e2md] Problem statement, Requirements and Use Cases X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 14:16:11 -0000 Rich, fwiw, I can contribute to this effort. Ken -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: Wednesday, May 19, 2010 9:15 PM To: 'Sumanth Channabasappa'; Cartwright, Kenneth; trutkowski@netmagic.com; = 'PFAUTZ, PENN L (ATTCORP)' Cc: drinks@ietf.org; 'E.164 To MetaData BOF discussion list'; 'IETF ENUM li= st' Subject: RE: [e2md] Problem statement, Requirements and Use Cases Well .. as far as I'm concerned the discussion of what is the namespace is charming but ultimately another discussion. What is important is the definition of the use case and why opaque carrier identification methodologies is important (vs edge URI identification) and I'd like to cal= l for volunteers to help me or someone to write this up as a ID. There is no possible doubt that this is important to the global telecommunications industry and IMHO is principally utilized principally in private-carrier-infrastructure ENUM instantiations. Not to say that, by some for form of indirection, this could live in e164.arpa but either way it makes sense. It's the right thing to do and the timing is right now. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Sumanth Channabasappa Sent: Wednesday, May 19, 2010 3:45 PM To: Cartwright, Kenneth; trutkowski@netmagic.com; PFAUTZ, PENN L (ATTCORP) Cc: drinks@ietf.org; E.164 To MetaData BOF discussion list Subject: Re: [e2md] Problem statement, Requirements and Use Cases When we speak about OIDs here, we are speaking of OIDs formed via the IANA Enterprise Numbers, correct (1.3.6.1.4...)? If so, do we need an extra string for all enterprises (1.3...) or can we just use the enterprise number? And if we want a hierarchy, it can always be constructed underneath the IANA Enterprise number, no? - S -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Cartwright, Kenneth Sent: Wednesday, May 19, 2010 12:39 PM To: trutkowski@netmagic.com; PFAUTZ, PENN L (ATTCORP) Cc: drinks@ietf.org; E.164 To MetaData BOF discussion list Subject: Re: [drinks] [e2md] Problem statement, Requirements and Use Cases As Penn wisely points out, this can be discussed in detail in the appropriate forum at the appropriate time, however, .... The ITUs OID looks like a good option. It seems to meet the following requirements/advantages: 1) It already exists; no need to invent and debate a new scheme, approach, documentation set, etc. 2) It is hierarchical; organizations can optionally create sub-OIDs (or sub trees) under their main OID if they need to. 3) The sub-identifiers under the main identifier can be opaque; they need not have a known, or the same known, meaning to all parties that may use/se= e them 4) There is an existing urn that _might_ be useful "urn:oid" 5) If the set of existing OIDs already allocated under one of the existing OID trees (e.g. 1.3.6.1.4) are not appropriate then it seems that an organization (e.g. IANA) can be formally delegated the responsibility of dolling out (similar to the way that it doles out Enterprise Numbers) the OIDs under a new OID tree. IOW, the OID tree it centrally managed, but the management of sub-trees can be delegated. 6) They are cleanly parseable by a computer or a human; their form is standardized and well structured. A disadvantage, however, is that ITU OIDs can theoretically be fairly long (in contrast to the 4 characters that comprise a north american OCN or SPID= , or the handful of digits that comprise the IANA Enterprise Number). But it is not clear to me whether in practice, given our use case, if they will ever be as long as they can theoretically be. The spec for our usage would just need to address this point. http://www.itu.int/ITU-T/asn1/uuid.html http://www.oid-info.com/#oid Ken -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Ton= y Rutkowski Sent: Wednesday, May 19, 2010 11:52 AM To: PFAUTZ, PENN L (ATTCORP) Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] Problem statement, Requirements and Use Cases On 5/19/2010 11:03 AM, PFAUTZ, PENN L (ATTCORP) wrote: > Use RFC 3761 technology provide for the Carrier of Record for an E.164 > number (as defined in RFC 5067) to publish the mapping of that E.164 > to a globally defined identifier, specifically an IANA Enterprise > Number as defined in RFC 2578. > Hi Penn, Good choice. However, the text needs tweaking to read: Use RFC 3761 technology to provide for the Carrier of Record for an E.164 number (as defined in RFC 5067) to publish the mapping of that E.164 number using an assigned Carrier of Record Object Identifier (OID)) such as an IANA Enterprise Number as defined in RFC 2578. Ref. Rec. ITU-T Recs. X.660 and X.680. The changes clarify what identifier is being specified and includes reference to the authoritative OID standard. It also allows for the possibility of using other assigned OIDs for a Carrier of Record. Although more than 35,000 Enterprise Numbers have been registered with IANA, there are many carriers who have OIDs that were registered with national authorities for Carrier of Record purposes. As long as there is a valid, globally unique OID, some flexibility should exist. For example, ATT has the OID 1.3.6.1.4.74 from IANA's OID block, but it als= o has 0.7.7223 that it uses for some services in Argentina. best, tony _______________________________________________ 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 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. _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From bernie@ietf.hoeneisen.ch Sun May 23 04:28: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 A22B43A6BA5 for ; Sun, 23 May 2010 04:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[AWL=-1.178, BAYES_60=1, 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 1Ltl58UXb7Zu for ; Sun, 23 May 2010 04:28:46 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 3E0263A6BA3 for ; Sun, 23 May 2010 04:28:42 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1OG9M9-0005T4-6O for e2md@ietf.org; Sun, 23 May 2010 13:28:33 +0200 Date: Sun, 23 May 2010 13:28: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: MULTIPART/MIXED; BOUNDARY="37663318-76441418-1274613977=:20477" Content-ID: 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] Comments/questions on Requirements 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: Sun, 23 May 2010 11:28:47 -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-76441418-1274613977=:20477 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Hi E2MD:ers As a preparation to our next confernce call I went through the requirements we collected so far on the wiki page: http://trac.tools.ietf.org/bof/e2md/trac/wiki/RequirementsList Please find my questions/comments also inline below. cheers, Bernie PS: Thanks Jay Daley and Dean Wills for their work on the first set of=20 requirements! > 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. How about the dimension User ENUM vs. Infrastructure ENUM? See also: http://trac.tools.ietf.org/bof/e2md/trac/attachment/wiki/RequirementsList/E= NUM_forest.png > 1.1.2 Mechanisms for controlling access > > The alternate mechanisms for controlling access to data include: > > 1. indirection - some data is made public but only acts as a > key, possibly along with other known data, into a private > database. > > 2. source differentiation - a public or private database that > validates the source that makes the requests and returns > specific data for that source > > 3. 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). > > 4. selective encryption - private records are encrypted with a > key known to the authorized node. > > 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: > > 1. A producer may choose to provide different information to > different consumers. > > 2. A producer may choose to provide no usable information at > all to some consumers. > > 3. A producer 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.) This needs clarification! > 4. 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. Do we really need this? (e.g. if a call is originated in the PSTN, both might be relevant.) > 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: > > 1. A real-time response (in the order of milliseconds). > > 2. Scalable to hundreds of millions of keys. > > 3. Scalable to millions of querying clients. > > 4. Scalable to accommodate millions of changes per day. > > It does not need the following performance characteristics: > > 1. Deliver data greater that a few kilobytes in size. > > 2. Guaranteed consistency. > > 2 DNS Protocol considerations > > 2.1 Access to data > > The various 'pure' DNS mechanisms for controlling access are: > > 1. Private trees. Private trees as such do not implement access control. > 2. Only publishing an indirect key in DNS. > > The various DNS+ mechanisms for controlling access are: > > 1. Source-URI This term needs to be defined! > 2. Replicating DNS on a different port and confining it to > this data [Is this really what that proposal is about?] > > 2.2 Relevancy =B6 > > The various mechanisms for separating out relevancy domains are: > > 1. Private trees > > 2. 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. > > 3. Source-URI --37663318-76441418-1274613977=:20477-- From bernie@ietf.hoeneisen.ch Sun May 23 04:40:35 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 76F253A6AF0 for ; Sun, 23 May 2010 04:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.488 X-Spam-Level: X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[AWL=-0.489, 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 fv7Y1b7JBLJm for ; Sun, 23 May 2010 04:40:34 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 1D86E3A6BAE for ; Sun, 23 May 2010 04:40:30 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1OG9Xa-0005VC-Gh for e2md@ietf.org; Sun, 23 May 2010 13:40:22 +0200 Date: Sun, 23 May 2010 13:40:22 +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] Use Cases for review 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: Sun, 23 May 2010 11:40:35 -0000 Hi E2MD:ers I put the use cases known to me to a wiki page: http://trac.tools.ietf.org/bof/e2md/trac/wiki/UseCases Please check whether the use cases you had in mind for e2md are covered on that wiki page, and -- if not -- add any missing use cases directly to the Wiki (or report them to the mailing list). Within the next days we will choose a subset of use cases as candidates to start the "real" work about. Feel free to improve the E2MD WiKi-pages by editing actively and adding further information! cheers, Bernie -- http://ucom.ch/ Tech Consulting for Internet Standardization From bernie@ietf.hoeneisen.ch Mon May 24 11:42: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 9CD823A6EF7 for ; Mon, 24 May 2010 11:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.145 X-Spam-Level: X-Spam-Status: No, score=0.145 tagged_above=-999 required=5 tests=[AWL=-1.096, 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 Ue3K1Yz4TsrQ for ; Mon, 24 May 2010 11:42:48 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id A724A3A6EE3 for ; Mon, 24 May 2010 11:41:18 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1OGcaK-00027h-9h for e2md@ietf.org; Mon, 24 May 2010 20:41:08 +0200 Date: Mon, 24 May 2010 20:41:08 +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] Details for conf call, Thu 27 May, 19 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, 24 May 2010 18:42:51 -0000 Dear e2md:ers, Please find the details of the next e2md conference call below: * Date/Time: Thursday, 27 May 2010, 19:00 UT (20:00 BST, 21:00 CEST, 15:00 EDT, 07:00 NZST) Duration: 60-90 min * Dial-In: - SIP: sip:46@mcu-hd.switch.ch --> Conference ID: 46 # - H.323:h323:46@mcu-hd.switch.ch --> Conference ID: 46 # - PSTN: +41 44 250 96 46 * Collaboration Tool (we will use this during the call!): http://collab.switch.ch/ietf-e2md * Goal Get a clear understanding on the short term requirements. * Agenda: 1) Welcome / Roll-Call / Scribe 2) Discussion of the requirements: http://trac.tools.ietf.org/bof/e2md/trac/wiki/RequirementsList Please prepare the questions you would like to discuss! 3) Disussion and priorization of the Use Cases: http://trac.tools.ietf.org/bof/e2md/trac/wiki/UseCases Please think about which Use Cases we should start with _before_ the conf call! 4) Decide on plan for IETF-78 (Maastricht) The following options have been suggested so far: a) Request 2nd (WG forming) e2md BoF (on limited set of Use cases) b) Request 2nd (non-WG forming) e2md BoF c) Dispatch "side-meetings" (as proposed during the last conf call) d) Request ENUM WG meeting (to discuss/propose a re-charter) 5) AOB Note: The discussion was rather fuzzy in the recent conf calls. If during this call there is a need to structure the discussion and give also the less "dominant" participants a chance to speak, we will use the collaboration tool to maintain a speakers list, which has a built-in "Raise hand" function. cheers, Bernie PS: Please find previous minutes and presentations on: http://trac.tools.ietf.org/bof/e2md/trac/wiki/MeetingMinutes -- http://ucom.ch/ Tech Consulting for Internet Standardization From richard@shockey.us Mon May 24 13:54: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 ABCFC3A6882 for ; Mon, 24 May 2010 13:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.389 X-Spam-Level: X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[AWL=-0.725, BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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-Q+HbGB524X for ; Mon, 24 May 2010 13:54:42 -0700 (PDT) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id 7EFE73A684E for ; Mon, 24 May 2010 13:54:42 -0700 (PDT) Received: (qmail 21897 invoked by uid 0); 24 May 2010 20:47:51 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 24 May 2010 20:47:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=YXL0F3tMoK4O8ALS/Ps33/++FRSNJQLogWqWXd0hyzIiwGQ+W2aya9fyU/TrgsCveF40Tg4UiG0fAjOtYlThC0zAR7z+5BlXd81rifW8SNpbT9X+EFYKgGalv/0hhLR3; 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 1OGeYx-0001bX-4q; Mon, 24 May 2010 14:47:51 -0600 From: "Richard Shockey" To: "'E.164 To MetaData BOF discussion list'" Date: Mon, 24 May 2010 16:47:43 -0400 Message-ID: <00dc01cafb82$5c85e700$1591b500$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DD_01CAFB60.D5744700" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr7glu2pEX3hlx4SJmiAT9DU/trww== 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: drinks@ietf.org, 'IETF ENUM list' , speermint@ietf.org Subject: [e2md] On the issue of G-SPN's 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, 24 May 2010 20:54:42 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00DD_01CAFB60.D5744700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Though the use case for a G-SPN has been identified by this list and is on the TWKI, I want to make it abundantly clear that I do not believe that ENUM or a E2MD WG should actually define what is the appropriate namespace for G-SPN's. It is a requirement for DRINKS ( by ITU liaison) and touches on SPEERMINT ( which IMHO should shut down ). Consequently the logical thing to do is a individual submission. I've offered to try and rough cut a Use Case and Requirements document, which I will do in the not to distant future in collaboration with several others who have offered to help. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 http//www.sipforum.org ------=_NextPart_000_00DD_01CAFB60.D5744700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Though the use case for a G-SPN has been identified = by this list and is on the TWKI, I want to make it abundantly clear that I do = not believe that ENUM or a E2MD WG should actually define what is the appropriate = namespace for G-SPN’s.

 

It is a requirement for DRINKS ( by ITU liaison) = and touches on SPEERMINT ( which IMHO should shut down ). Consequently the logical = thing to do is a individual submission.

 

I’ve offered to try and rough cut a Use Case = and Requirements document, which I will do in the not to distant future in collaboration with several others who have offered to help. =

 

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype: rshockey101
LinkedIn : http://www.linkedin.com/in/rshockey101 http//www.sipforum.org

 

------=_NextPart_000_00DD_01CAFB60.D5744700-- From trutkowski@netmagic.com Mon May 24 14:07: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 144F03A6D10; Mon, 24 May 2010 14:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[AWL=-0.454, 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 WLbd-gLcLxEb; Mon, 24 May 2010 14:07:57 -0700 (PDT) Received: from vms173013pub.verizon.net (vms173013pub.verizon.net [206.46.173.13]) by core3.amsl.com (Postfix) with ESMTP id 0D2BB3A6D01; Mon, 24 May 2010 14:07:57 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=windows-1252; format=flowed Received: from [192.168.0.20] ([unknown] [173.71.223.14]) by vms173013.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L2Y00JXY00AT1D0@vms173013.mailsrvcs.net>; Mon, 24 May 2010 16:07:27 -0500 (CDT) Message-id: <4BFAEA8A.4010005@netmagic.com> Date: Mon, 24 May 2010 17:07:22 -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 To: Richard Shockey References: <00dc01cafb82$5c85e700$1591b500$@us> In-reply-to: <00dc01cafb82$5c85e700$1591b500$@us> Cc: drinks@ietf.org, 'IETF ENUM list' , "'E.164 To MetaData BOF discussion list'" , speermint@ietf.org Subject: Re: [e2md] On the issue of G-SPN's 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: Mon, 24 May 2010 21:07:58 -0000 Hi Richard, Could you amplify on the "by ITU liaision" parenthetical? Considering the G-SPN notion is being driven by a NeuStar input into ITU-T, that creates a substantial NeuStar new revenue opportunity/impact on providers, chaired by a NeuStar staff member in ITU-T, and sprinkled with NeuStar people in IETF, some care seems appropriate about the assertions and process. I'll offer to help as well. cheers, tony On 5/24/2010 4:47 PM, Richard Shockey wrote: > > Though the use case for a G-SPN has been identified by this list and > is on the TWKI, I want to make it abundantly clear that I do not > believe that ENUM or a E2MD WG should actually define what is the > appropriate namespace for G-SPN’s. > > It is a requirement for DRINKS ( by ITU liaison) and touches on > SPEERMINT ( which IMHO should shut down ). Consequently the logical > thing to do is a individual submission. > > I’ve offered to try and rough cut a Use Case and Requirements > document, which I will do in the not to distant future in > collaboration with several others who have offered to help. > From richard@shockey.us Tue May 25 07:13: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 3059B3A6BE7 for ; Tue, 25 May 2010 07:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.528 X-Spam-Level: X-Spam-Status: No, score=-0.528 tagged_above=-999 required=5 tests=[AWL=-0.529, 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 0n4bUQPbqnrH for ; Tue, 25 May 2010 07:13:12 -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 1E0C33A6BAF for ; Tue, 25 May 2010 07:13:09 -0700 (PDT) Received: (qmail 1230 invoked by uid 0); 25 May 2010 14:06:22 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 25 May 2010 14:06: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=IV4wFNLWwthEAvQ3xR64xbZuiquSbCPKN8Idxl71VXCu7UkMsaCSmWjzIJ754sRjNPnyoxGbQQZQz1vJEWcsx34VR+0OSWlY3ElaC+MZqv5zxj1zTItPDwJQcrccUcZh; 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 1OGulx-00045H-Kr; Tue, 25 May 2010 08:06:22 -0600 From: "Richard Shockey" To: References: <00dc01cafb82$5c85e700$1591b500$@us> <4BFAEA8A.4010005@netmagic.com> In-Reply-To: <4BFAEA8A.4010005@netmagic.com> Date: Tue, 25 May 2010 10:06:14 -0400 Message-ID: <015b01cafc13$71043600$530ca200$@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: Acr7hSOa0+g1vYQ0QSmDxtExSPc2QgAjVSiw 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: drinks@ietf.org, 'IETF ENUM list' , "'E.164 To MetaData BOF discussion list'" , speermint@ietf.org Subject: Re: [e2md] On the issue of G-SPN's 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, 25 May 2010 14:13:13 -0000 -----Original Message----- From: Tony Rutkowski [mailto:trutkowski@netmagic.com] Sent: Monday, May 24, 2010 5:07 PM To: Richard Shockey Cc: 'E.164 To MetaData BOF discussion list'; drinks@ietf.org; 'IETF ENUM list'; speermint@ietf.org Subject: Re: [e2md] On the issue of G-SPN's Hi Richard, Could you amplify on the "by ITU liaision" parenthetical? I'ts simple ITU wanted to make sure the DRINKS WG left open a field for SPN use. http://www.itu.int/md/T09-SG02-090324-TD-PLEN-0071/en Considering the G-SPN notion is being driven by a NeuStar input into ITU-T, that creates a substantial NeuStar new revenue opportunity/impact on providers, chaired by a NeuStar staff member in ITU-T, and sprinkled with NeuStar people in IETF, some care seems appropriate about the assertions and process. Well whether it creates any revenue for some company especially the one you mention is none of my concern. :-) Whatever form the SPN takes, its self evident that SPN create operational efficiencies for service providers both for internal as well as external session establishment. I'll offer to help as well. cheers, tony On 5/24/2010 4:47 PM, Richard Shockey wrote: > > Though the use case for a G-SPN has been identified by this list and > is on the TWKI, I want to make it abundantly clear that I do not > believe that ENUM or a E2MD WG should actually define what is the > appropriate namespace for G-SPN's. > > It is a requirement for DRINKS ( by ITU liaison) and touches on > SPEERMINT ( which IMHO should shut down ). Consequently the logical > thing to do is a individual submission. > > I've offered to try and rough cut a Use Case and Requirements > document, which I will do in the not to distant future in > collaboration with several others who have offered to help. > From trutkowski@netmagic.com Tue May 25 08:11:05 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 9D5B23A713E; Tue, 25 May 2010 08:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.408 X-Spam-Level: X-Spam-Status: No, score=-1.408 tagged_above=-999 required=5 tests=[AWL=0.591, BAYES_00=-2.599, J_CHICKENPOX_12=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 ZoGt32CSp6R1; Tue, 25 May 2010 08:11:04 -0700 (PDT) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) by core3.amsl.com (Postfix) with ESMTP id 3E7073A712B; Tue, 25 May 2010 08:11:03 -0700 (PDT) Received: from [192.168.0.20] ([unknown] [173.71.223.14]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L2Z00JVGE5BEJ00@vms173017.mailsrvcs.net>; Tue, 25 May 2010 10:10:29 -0500 (CDT) Message-id: <4BFBE85F.7050609@netmagic.com> Date: Tue, 25 May 2010 11:10:23 -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: <00dc01cafb82$5c85e700$1591b500$@us> <4BFAEA8A.4010005@netmagic.com> <015b01cafc13$71043600$530ca200$@us> In-reply-to: <015b01cafc13$71043600$530ca200$@us> Content-type: multipart/mixed; boundary=------------070708080107010805030604 Cc: drinks@ietf.org, 'IETF ENUM list' , "'E.164 To MetaData BOF discussion list'" , speermint@ietf.org Subject: Re: [e2md] On the issue of G-SPN's 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: Tue, 25 May 2010 15:11:05 -0000 This is a multi-part message in MIME format. --------------070708080107010805030604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit That's not really what the document says. Since many people may not be able to access the site and view it, the attached copy is edifying. Note particularly the highlighted text. It helps provide context and concern. --tony On 5/25/2010 10:06 AM, Richard Shockey wrote: > I'ts simple ITU wanted to make sure the DRINKS WG left open a field for SPN > use. > > http://www.itu.int/md/T09-SG02-090324-TD-PLEN-0071/en > --------------070708080107010805030604 Content-Type: application/pdf; name="T09-SG02-090324-TD-PLEN-0071!!MSW-E.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="T09-SG02-090324-TD-PLEN-0071!!MSW-E.pdf" JVBERi0xLjUNJeLjz9MNCjE0IDAgb2JqDTw8L0xpbmVhcml6ZWQgMS9MIDEzMTU2L08gMTYv RSA3NDQxL04gMi9UIDEyODQzL0ggWyA0NTUgMTY2XT4+DWVuZG9iag0gICAgICAgICAgICAg ICAgICAgDQoyMCAwIG9iag08PC9EZWNvZGVQYXJtczw8L0NvbHVtbnMgNC9QcmVkaWN0b3Ig MTI+Pi9GaWx0ZXIvRmxhdGVEZWNvZGUvSURbPEQ2QkYxM0MzRkQyQzBFQTY3MDlCMTA0NDdG NDhCQUQyPjxCRjcyOEM5RDgwMDE1QTQ1QUMzNjYwNzVERjcwMUMwMD5dL0luZGV4WzE0IDE1 XS9JbmZvIDEzIDAgUi9MZW5ndGggNTIvUHJldiAxMjg0NC9Sb290IDE1IDAgUi9TaXplIDI5 L1R5cGUvWFJlZi9XWzEgMiAxXT4+c3RyZWFtDQpo3mJiZBBgYGJgigUSDAFAgrEJxN0LJHgn Aol3zxmYGBnmgmQZGHET/xm3/QIIMAACqAfoDQplbmRzdHJlYW0NZW5kb2JqDXN0YXJ0eHJl Zg0KMA0KJSVFT0YNCiAgICAgICAgDQoyOCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUv SSA5NS9MIDc5L0xlbmd0aCA4Mi9TIDQ4Pj5zdHJlYW0NCmjeYmBgYGZgYBJnYGRgYElh4GVA AF6gGCMDCwNHw/oGBoYDDgwgCgmwQDEDQxMDDwOT9YFfTFBh211AGmggQycQszMw+PpD+IxK AAEGANn7CWcNCmVuZHN0cmVhbQ1lbmRvYmoNMTUgMCBvYmoNPDwvTWV0YWRhdGEgNSAwIFIv UGFnZUxhYmVscyAxMCAwIFIvUGFnZXMgMTIgMCBSL1R5cGUvQ2F0YWxvZz4+DWVuZG9iag0x NiAwIG9iag08PC9Db250ZW50cyAxOCAwIFIvQ3JvcEJveFswIDAgNTk1IDg0Ml0vTWVkaWFC b3hbMCAwIDU5NSA4NDJdL1BhcmVudCAxMiAwIFIvUmVzb3VyY2VzIDIxIDAgUi9Sb3RhdGUg MC9UeXBlL1BhZ2U+Pg1lbmRvYmoNMTcgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0Zp cnN0IDQ4L0xlbmd0aCA2MDYvTiA3L1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjepFRta9swEP4r 93H7kOnFtuxACSRp0xXWLtRmHYR80BItMTh2sFXW/vvdSVZeWspYi1DudM/p9Jz0OFIABylB 8ARkBAKnjEFkaBKIhQKpIIuHIFNMSRVcXLBpUzVtvtcrQ4tO0XYO96MRu3qy17nVloDrXFBB D8ya2mKsKCSVxRi6MdX08LxtVrmxCza/nLHCPNnlaLRgN9PpRHdmDWJIeUss8H0Ov3XVGXRu QbB83C/zW+BfuGTF894cWbBm7/HRCPeOu5WpLWRDwaZ6/9WUm63Fnjhnl8ZDAykUm1V600EU O86TSfO0GCRJBoOIpyAxG7dItXToTO/K6vlTUe5MB3fmD9w3O11/dtid3hnmEARcfJ4PJk21 vi0cntvW2NWW3TXtTlcu9OAppcjoxuqqXI3rTWWAs9ya3Q8QkfL9US5Rbsu9bVr286QV1yhd GuW8dfxVvWrWZb1hD2U9rrvysJ6VbWenW91CJF+cQqKgZ/um+wwh8foff1kiVLSPxjE70MPS a7vtFjLhcD6iKHLzuEL5pRkkeLNhhuF9+j3u8CNFySmVOht8JQSkWAmzMxIM+RQfxrHPo3Wf Q+skUYca3N3eSeHTwxwtTI6xULBEKMSlOzR4GSHoB5T7fKQUnSB93eVHlanOlcnT9ynzn6KM 3xBlJj+myXfLUb2QY6w+KMdE4R9S4iNkX4vytUfTv34YQyl6QQVpkeTo1X3UnxXiGaoiSDjk 0D4nTREqkYD52f6esePiVMnP7UGdPb/QC9n0RV/h8yKFnvbsOPV+7Bj8z8CKqO2/AgwATZqo 5g0KZW5kc3RyZWFtDWVuZG9iag0xOCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu Z3RoIDMxNDY+PnN0cmVhbQ0KaN6UWdt2m0gWffdX1COasQi3EpCnccfuLE3iS2y8emU6/YBQ WaKDQAFkj/sz5otnnzoFAqL09KysREhUnTrXffapvHn/4IpNc/ZTcvYmSTzhiuTpLBYO/sRC enYQiEVsh4Hji2R35ojN2dx2HCcUSYZvycvZr9ZF26rZ3LelVbZ5Vb6d/Zb8k4QFLCyw/WgR Ql5yeUZbfdpq60/aLZJt3ojZwl5Y+Cyrlp9TsT+sZqFV5FlKUsUuXSst2fVsP+jFuTGJI52k ZwSmz2kOGYFVpKtZBFnFbG77lhJtJWZzEt5u9e/KfKWT9Lo8m0k7tM7F6gA1jBnGJ65ru+ZY 7YFFZ0bMx6alyMtW1WVasAXL5HGeiMsqO+xU2U6cQkZI3/+xV0hWuYYD1FpUZfEqnqpaHBol yCmvpHdgiXarWM154NieJ+bQkaQa13QquiELvZ4FtmshVq7tWTso6VqrmUuOqMUD3gVWC0/B 961qZq5jR5ao4BjfesIq3xKw6BzLYkus9M9QQ0KGWM5C/Jhgb2zBZvgQO1mgytqq1q/Fn5yu FzT6vUjLtbjgZ/630ouyPIXcTsNOv3NarnUROqaIcm6OqxVv3/MZenPGh7f5M68VvMRY/fTE O3uRmd7E5xdIJmNJCpOMsnlpDtfmbPmovB57BKpoQUXKy4wL1jpy0rXjPhGcvqosMUt+P5t3 bymwAYqIA+ubJHmp6q+2WLai2aZFgdqB+NBqxUrpajGFhGqA7oX52lbnnDIuouQPMzA22eIF XUIj/bCDsm7Nm1f6Bx129v3wOy+pEIdQOxw6x1Yt9qOv+OIhrj75tWwEchq1kbc5BxQeZd1g RzzUTXa6RcbyvN1WqFF9mIdA7mucHll5xZ/ipc6BSiXrlOEoHGMUfBK6Mm0+KbR/4Pur5CyI AV0iRCiFHUT0F7WEaJ49DV8FMcR6o7cykDbgyOwM4/jU5mBBOEaCfdeWi+9fkWA3OCW426ol D3afej3cDpDvoR0uFn5kuxEjOxuNGDieXsFPelUopR0veBmhiYkFBYVisbxJAElXyH3Xur9B XSysi2SJz9C61d9uLj4iSohtcsUPV+/4xTXyIDb/Pt4s381gvHVBmRKgdmilEcNSxSOL4wWj E/j9FLEXvTH6KfAcO0RUJLBy0fWzPugPyePlZ+0Dv9+mn4JQ0sdwm3HWVH4Y2ZN17+9vH+9O CZU+tgR/Qaj0Y0L20ULvpEQdKg99zCyjLuXqYFlwPHx+fU1ORmxub/RRDvcLz+17WtD1UsfU 2UNycXN5cX+5/NfMpbrSwQktLeLh6l1yey+mje1UBi1iOVILBpluF3bnPF7O5hTEz+Lu6l7D 5BIZJRFg/fPljGIuPMchsPGseE6/S8tzXP7B+y76sY3s14rop8AJtSM9z3a9PpkHRMZKLkXo ii/W3cermzfel5nxcidFPwWhZ8ceDDr6ucdObZmWdFVuirzZ6satcRxnujImf8swDrr+rGNz W+ebHKThrTC79LHGhZ3/JLruQOlowL4+HVRDBAk1+MVqvszeTiMCAQADx+2w9BhkA/TuGzhv 7sZhIK33qlTP6blAE7hO62w798TFvs4L8nysBQMXpW9H8AFcAU0IpeByW/YQM4hBb4bnoQNi jy9778+HtKfjPcnV9d3t/cX9Z3F5++7x+grYAmbpm9qeu4EN4gU3LqTBbKrc6lBn6q3O6f/D 7IumqcAqWiXugTWBlaJbR9Z+X9WtOtTn4pOtHTPOqrkWSwos+qqRgxTK20K9HSsCpjdsMVzm 4EZup50uVE6cj3maNyC7YKrLq+RncXm/vPnwIH41Er2+xuKgF4ltl+MTCeXGbX1unrA2bVPN JcciPZAB+V0jvP+BXEul2TZd5UXevgo01LEseVy3nAjw40lPt4gyv2nrdD6W4aNWh/oA4n9s ok4iS7XgQ1OrvKhfxqBDngjZ2R/AUUdCkcTRkeG7/tERy7vfmJB5se0yHZPd6b1YU/y/gJXl 5Ua8r6vDHhAgUnEo828H1c0HVK0YEsAKqdLBjtyjKX2WEnmHsEbntg7YpqhW2Pag6uccP93V 1XO+VhzIOYvp9ZoPSmq5Jor1xHMUiKhvlQC5h7vl5ZfZNL1BZjFFkNvkd4OOs2B5H5cXywfC f0JgatSEzBcoXBSrGEOElKEdRiLyiNT0EOGKXJx9Ey5jA4CVAETKmIKV7fSvu7PA1RIcUXSP BJ745nQPT2efCG0mUCnR5KMBVLp9dFxW/2e4Ms30SNlWAI2577jSGlbbOIDaIueIOSexhIRm 1W6nQEQ85LQR7S4iaaAr+dugsHhDXiKsu3SginQHy/vMhpdlrBuldbHfI+zULHTYzSqXV4V+ bGbRS5Wui7wEJt5Uz2q3oiwJMMNbhOIDi7zwGGbvmO3vqrKFi/4HovaeNY79kNYg3NeHYjWj ma5+nXWUzJkk5uJ41I06PLQpJ7GL7AMqDGvreIYhCoki2+GqWNKs9XdXyNCdSy+chx6Y9PQ4 KvtFX/Ymga92NGsA8HPtR10B75qFyBqTkU1WAoD8aVma0H0lO+0dBj/PgrFk6T9KdWhghr3K /zAqbOjCIPCOcMJwJ7rZ4sSJaKTxQgSuZqmuHxJBtGVMJF7XDQnlugrwMjjVekfsPnDoUmDC GsgjhrjfFSptlFhX5X802TYDEpC93CgerSTNyG190I9Ze6gVwb15lTeixWDZzVHh6D4j7A4z TlfnLP13OAqZ39DQT4M3cTwWGOCskj9nRJisTDVNWpvrDmtYLnqVPQusCd4ETqTHp79ESXgC CgM7CgaExD3m5k9p9nUDDCjXk0JgNAhGjWxu7qJ0+R1qwg+6ndEkSpMnseM7B9Xi3bn4Zmhb I14UvFqn2hKAlx8N+96RjMPdGMNrtUnrdSc9qxXDB4LSdxnuUyxo1Kj8ScFO25HpNeAeK8VD /6jtcJwjEBc5aJLm0m3Sk6Y9Jxj0HFuIpFqnr4JIRMfrWGyvLkb2Q9nWr/o2KG8bUe1Vre9d xDZ9Rs4qQ869gS4eE5xnVWD1WjSmUe47pWCMEaM3A6k7S0Zt3NWYbgGfjREKp7bbtBUpBUpl 1abM/1Br42ik4uJHjuYWTDcp7E+6tshLbdQKdEUBL0tNW7422td0okHC2DuhmmO83bu2FPtD va8a1ZxT3JBiRGNdCm2amwvJrCpLxQ2vd3bsjTUO+/nF4Gxa10ABfRuqKHEBBGWLQ1TZEAhk lX5VwxutQIlQTmuzzFrVdtkigwmKDphEZ7xI12ukX0NCavXtkNeK4ZXOtMUvM1ADaztDFuUF 3XxGdJe7VY06GiQDviM7NhlTi11aN0L9O9fQo3Wka0VUI37gTMsVxVi96hjTJTQsYxNiO4gH Sdaxqi4JuDwKbGy4BJ+RLqiXLmEp68hMjZhkq1GZxY76ouTEO6adLY5z+kIOeSlNPe89CFbr hgKPGCMERDFRK3n5DGzhMdKOFkPlu7m7S6R8w1k0hpW10jW045s7sBmCFwSXjtN5mpbi5v1N Bw3GIj6rt2jIdqjwh0Fusq0i6VF3F0oGNFSk9PY5rfPqYAKWd7gYDP4LYULqLGxaJo/iGOuU YLUoujst71jnbl9MC+OD1HiMr5fzDdqUhympcwZb5+umPD/JTTo83VctRQ4eGTgw7h0I9730 k8AgxhMK7hyny/Fwib6SN9kBHkQDpIve6aA/aUvTuWSUMBjyiwPNvuv86QkNiHTccz/iC2MD Q0EgT7ndoATdKlM+DJKGhoLYGlt+zBZ+S+2EMuKI/cGfIyiCNE2eiC/S6b4+L7Pi0CfvE0hN fhxNs7or4272HMy3isPMoekr2cSob4hpUWERYbeZtbSskb49BeguRUmTtLtgWCP3ufvnfH9W IrGBDsAKsUfaSatmIlQR5dH3mmRaaDUdHHZoGnpjJBrdnawpsDg035QGiwlzUhZdpuB0zQEd N+0ts4U4xoDTe3GCeh/TB4wvLZqK+wowBpYBT8lW+p+pDGyy0Sej5Xb5M2yxUS/SeCmjqrMa NeivA6e9oJuR08EOpcZ8zDLgSeQelLae2E6zh1MQYWY73W6obRIpoEqi+CNN1qnhBCO8dHlv m+qS4dbHmpavJl8MwkTOEGb5Zo+TvKmKg8ZY8EhV90DHuMsUQtqL8M+1X72Kof+zqiK0Zi/B RR3WOyf5DMdPh0mbrxV5AQGDIeRFu5tJ/ivAAFJEiKkNCmVuZHN0cmVhbQ1lbmRvYmoNMTkg MCBvYmoNPDwvQWx0ZXJuYXRlL0RldmljZVJHQi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3Ro IDI1OTcvTiAzPj5zdHJlYW0NCmjenJZ3VFTXFofPvXd6oc0w0hl6ky4wgPQuIB0EURhmBhjK AMMMTWyIqEBEEREBRZCggAGjoUisiGIhKKhgD0gQUGIwiqioZEbWSnx5ee/l5ffHvd/aZ+9z 99l7n7UuACRPHy4vBZYCIJkn4Ad6ONNXhUfQsf0ABniAAaYAMFnpqb5B7sFAJC83F3q6yAn8 i94MAUj8vmXo6U+ng/9P0qxUvgAAyF/E5mxOOkvE+SJOyhSkiu0zIqbGJIoZRomZL0pQxHJi jlvkpZ99FtlRzOxkHlvE4pxT2clsMfeIeHuGkCNixEfEBRlcTqaIb4tYM0mYzBXxW3FsMoeZ DgCKJLYLOKx4EZuImMQPDnQR8XIAcKS4LzjmCxZwsgTiQ7mkpGbzuXHxArouS49uam3NoHty MpM4AoGhP5OVyOSz6S4pyalMXjYAi2f+LBlxbemiIluaWltaGpoZmX5RqP+6+Dcl7u0ivQr4 3DOI1veH7a/8UuoAYMyKarPrD1vMfgA6tgIgd/8Pm+YhACRFfWu/8cV5aOJ5iRcIUm2MjTMz M424HJaRuKC/6386/A198T0j8Xa/l4fuyollCpMEdHHdWClJKUI+PT2VyeLQDf88xP848K/z WBrIieXwOTxRRKhoyri8OFG7eWyugJvCo3N5/6mJ/zDsT1qca5Eo9Z8ANcoISN2gAuTnPoCi EAESeVDc9d/75oMPBeKbF6Y6sTj3nwX9+65wifiRzo37HOcSGExnCfkZi2viawnQgAAkARXI AxWgAXSBITADVsAWOAI3sAL4gWAQDtYCFogHyYAPMkEu2AwKQBHYBfaCSlAD6kEjaAEnQAc4 DS6Ay+A6uAnugAdgBIyD52AGvAHzEARhITJEgeQhVUgLMoDMIAZkD7lBPlAgFA5FQ3EQDxJC udAWqAgqhSqhWqgR+hY6BV2ArkID0D1oFJqCfoXewwhMgqmwMqwNG8MM2An2hoPhNXAcnAbn wPnwTrgCroOPwe3wBfg6fAcegZ/DswhAiAgNUUMMEQbigvghEUgswkc2IIVIOVKHtCBdSC9y CxlBppF3KAyKgqKjDFG2KE9UCIqFSkNtQBWjKlFHUe2oHtQt1ChqBvUJTUYroQ3QNmgv9Cp0 HDoTXYAuRzeg29CX0HfQ4+g3GAyGhtHBWGE8MeGYBMw6TDHmAKYVcx4zgBnDzGKxWHmsAdYO 64dlYgXYAux+7DHsOewgdhz7FkfEqeLMcO64CBwPl4crxzXhzuIGcRO4ebwUXgtvg/fDs/HZ +BJ8Pb4LfwM/jp8nSBN0CHaEYEICYTOhgtBCuER4SHhFJBLVidbEACKXuIlYQTxOvEIcJb4j yZD0SS6kSJKQtJN0hHSedI/0ikwma5MdyRFkAXknuZF8kfyY/FaCImEk4SXBltgoUSXRLjEo 8UISL6kl6SS5VjJHslzypOQNyWkpvJS2lIsUU2qDVJXUKalhqVlpirSptJ90snSxdJP0VelJ GayMtoybDFsmX+awzEWZMQpC0aC4UFiULZR6yiXKOBVD1aF6UROoRdRvqP3UGVkZ2WWyobJZ slWyZ2RHaAhNm+ZFS6KV0E7QhmjvlygvcVrCWbJjScuSwSVzcopyjnIcuUK5Vrk7cu/l6fJu 8onyu+U75B8poBT0FQIUMhUOKlxSmFakKtoqshQLFU8o3leClfSVApXWKR1W6lOaVVZR9lBO Vd6vfFF5WoWm4qiSoFKmclZlSpWiaq/KVS1TPaf6jC5Ld6In0SvoPfQZNSU1TzWhWq1av9q8 uo56iHqeeqv6Iw2CBkMjVqNMo1tjRlNV01czV7NZ874WXouhFa+1T6tXa05bRztMe5t2h/ak jpyOl06OTrPOQ12yroNumm6d7m09jB5DL1HvgN5NfVjfQj9ev0r/hgFsYGnANThgMLAUvdR6 KW9p3dJhQ5Khk2GGYbPhqBHNyMcoz6jD6IWxpnGE8W7jXuNPJhYmSSb1Jg9MZUxXmOaZdpn+ aqZvxjKrMrttTjZ3N99o3mn+cpnBMs6yg8vuWlAsfC22WXRbfLS0suRbtlhOWWlaRVtVWw0z qAx/RjHjijXa2tl6o/Vp63c2ljYCmxM2v9ga2ibaNtlOLtdZzllev3zMTt2OaVdrN2JPt4+2 P2Q/4qDmwHSoc3jiqOHIdmxwnHDSc0pwOub0wtnEme/c5jznYuOy3uW8K+Lq4Vro2u8m4xbi Vun22F3dPc692X3Gw8Jjncd5T7Snt+duz2EvZS+WV6PXzAqrFetX9HiTvIO8K72f+Oj78H26 fGHfFb57fB+u1FrJW9nhB/y8/Pb4PfLX8U/z/z4AE+AfUBXwNNA0MDewN4gSFBXUFPQm2Dm4 JPhBiG6IMKQ7VDI0MrQxdC7MNaw0bGSV8ar1q66HK4RzwzsjsBGhEQ0Rs6vdVu9dPR5pEVkQ ObRGZ03WmqtrFdYmrT0TJRnFjDoZjY4Oi26K/sD0Y9YxZ2O8YqpjZlgurH2s52xHdhl7imPH KeVMxNrFlsZOxtnF7YmbineIL4+f5rpwK7kvEzwTahLmEv0SjyQuJIUltSbjkqOTT/FkeIm8 nhSVlKyUgVSD1ILUkTSbtL1pM3xvfkM6lL4mvVNAFf1M9Ql1hVuFoxn2GVUZbzNDM09mSWfx svqy9bN3ZE/kuOd8vQ61jrWuO1ctd3Pu6Hqn9bUboA0xG7o3amzM3zi+yWPT0c2EzYmbf8gz ySvNe70lbEtXvnL+pvyxrR5bmwskCvgFw9tst9VsR23nbu/fYb5j/45PhezCa0UmReVFH4pZ xde+Mv2q4quFnbE7+0ssSw7uwuzi7Rra7bD7aKl0aU7p2B7fPe1l9LLCstd7o/ZeLV9WXrOP sE+4b6TCp6Jzv+b+Xfs/VMZX3qlyrmqtVqreUT13gH1g8KDjwZYa5ZqimveHuIfu1nrUttdp 15UfxhzOOPy0PrS+92vG140NCg1FDR+P8I6MHA082tNo1djYpNRU0gw3C5unjkUeu/mN6zed LYYtta201qLj4Ljw+LNvo78dOuF9ovsk42TLd1rfVbdR2grbofbs9pmO+I6RzvDOgVMrTnV3 2Xa1fW/0/ZHTaqerzsieKTlLOJt/duFczrnZ86nnpy/EXRjrjup+cHHVxds9AT39l7wvXbns fvlir1PvuSt2V05ftbl66hrjWsd1y+vtfRZ9bT9Y/NDWb9nffsPqRudN65tdA8sHzg46DF64 5Xrr8m2v29fvrLwzMBQydHc4cnjkLvvu5L2key/vZ9yff7DpIfph4SOpR+WPlR7X/aj3Y+uI 5ciZUdfRvidBTx6Mscae/5T+04fx/Kfkp+UTqhONk2aTp6fcp24+W/1s/Hnq8/npgp+lf65+ ofviu18cf+mbWTUz/pL/cuHX4lfyr468Xva6e9Z/9vGb5Dfzc4Vv5d8efcd41/s+7P3EfOYH 7IeKj3ofuz55f3q4kLyw8JsAAwD3hPP7DQplbmRzdHJlYW0NZW5kb2JqDTEgMCBvYmoNPDwv Q29udGVudHMgMiAwIFIvQ3JvcEJveFswIDAgNTk1IDg0Ml0vTWVkaWFCb3hbMCAwIDU5NSA4 NDJdL1BhcmVudCAxMiAwIFIvUmVzb3VyY2VzIDkgMCBSL1JvdGF0ZSAwL1R5cGUvUGFnZT4+ DWVuZG9iag0yIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNzU1Pj5zdHJl YW0NCmjebFRbb9owFH7PrziPjrS4zj153eiqblNVjexpnSYDBryldmcHUPfrd2wngbYDRBLw Of5ux1c3yxR2NnrfRVddV0AK3TZqgeG7haxlNK2gbmvaFCyH7jFisIsoYyyDbu1uciw4Rd9J AhkkcUVLAvGP7lOUZLQs8xySlKZFVUO38GXtWJYVoaxbQJ3CA7mPc1qTL9d3V1lc04o8xHjJ xl5p5vHgpaxoDXWFqFiAM0NJxjvX9Lb7lnSwvMnAiD8HYQcLt9ddXJGPcUoLAouvt3eflzBo eDL6KDcC5GD9ThmjLCtxL4TrOzahI+gnqaRWgJ9hL2CrTZxUtCGPcUP44J6Bw67XK973z7jt Wu+U/Cs2kxihrxOjnKQoZtijFsv72wVwCyfR9+7K1bMnII3AbVANoZDJsMf99vwoYCWECvq0 dMTsuqVT39z3JbARR9HrJwTja0/60COu7lfUoowXheUMqAyAVkKJrUR2RjsAOYHBsa7JPkaf xch3otjQil1QTOaWzMNw7KjfFnOWhZwxwJhgwC6Rkw9arfuDdWqPq4t5dUqrYlpd+bZnr6WF tVaDVAepds5RZGp+o8snbjbW2+b6pQ2t8wuHfX7J2gg+eIO3aORBSczNu4mgN8YKc5RrMUXG +GZJ6PbC13ySMfUyElyMqLYSS7z+a67QuouMeFQZbdr/eJjWwUOuNnCwaOFJDnup/PNKDCeM AEg1dWjKN8QGYZRnhjwUFjhJMAuGD9rY4EeSlbSuX6XzzVCNQ3MOJBFxkhIXSQfGy+JMc+Ij UqRpBVoQxgo7pwEam5n5vsSHEeXgcOT9ga96AVYfTIhnVl/Es54r24AIzdBbf25gxAcu+zHf sp8ymTOaN6+INTOxcba5tdLGJcFs+9PBZ0mdA6TjEgddxfjl9hHGzUJF8DxQ/p+dj5bTxT9K M80kenemzMJmKByepWGSR0/ti9MjhO2cGTpSCf3cAHgmJGS5ouGIHX/8+fLl11x30T8BBgCe zI89DQplbmRzdHJlYW0NZW5kb2JqDTMgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0Zp cnN0IDQvTGVuZ3RoIDgxL04gMS9UeXBlL09ialN0bT4+c3RyZWFtDQpo3rJUMFCwsdF3rShx Dy5JLEkFst2DDRWMjIHiQXZ2+m75eSVAsZAQIwUjU5AYkGmiYGQOlQ4oyk8OTi2J1g9wcdMP Sa0oibWzAwgwAIvzFmENCmVuZHN0cmVhbQ1lbmRvYmoNNCAwIG9iag08PC9GaWx0ZXIvRmxh dGVEZWNvZGUvRmlyc3QgMTEvTGVuZ3RoIDQ0L04gMi9UeXBlL09ialN0bT4+c3RyZWFtDQpo 3jI0UDBQMDRUMLRUsLHR9yvNLY4G8w0UgmLt7IBCwfoudnYAAQYAoaAIuQ0KZW5kc3RyZWFt DWVuZG9iag01IDAgb2JqDTw8L0xlbmd0aCAzNjI5L1N1YnR5cGUvWE1ML1R5cGUvTWV0YWRh dGE+PnN0cmVhbQ0KPD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6 TlRjemtjOWQiPz4KPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0 az0iQWRvYmUgWE1QIENvcmUgNC4yLjEtYzA0MyA1Mi4zNzI3MjgsIDIwMDkvMDEvMTgtMTU6 MDg6MDQgICAgICAgICI+CiAgIDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5v cmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24g cmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMv ZWxlbWVudHMvMS4xLyI+CiAgICAgICAgIDxkYzpmb3JtYXQ+YXBwbGljYXRpb24vcGRmPC9k Yzpmb3JtYXQ+CiAgICAgICAgIDxkYzp0aXRsZT4KICAgICAgICAgICAgPHJkZjpBbHQ+CiAg ICAgICAgICAgICAgIDxyZGY6bGkgeG1sOmxhbmc9IngtZGVmYXVsdCI+TWljcm9zb2Z0IFdv cmQgLSBUMDktU0cwMi0wOTAzMjQtVEQtUExFTi0wMDcxISFNU1ctRS5kb2M8L3JkZjpsaT4K ICAgICAgICAgICAgPC9yZGY6QWx0PgogICAgICAgICA8L2RjOnRpdGxlPgogICAgICAgICA8 ZGM6Y3JlYXRvcj4KICAgICAgICAgICAgPHJkZjpTZXE+CiAgICAgICAgICAgICAgIDxyZGY6 bGk+dHJ1dGtvd3NraTwvcmRmOmxpPgogICAgICAgICAgICA8L3JkZjpTZXE+CiAgICAgICAg IDwvZGM6Y3JlYXRvcj4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVz Y3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOnhtcD0iaHR0cDovL25z LmFkb2JlLmNvbS94YXAvMS4wLyI+CiAgICAgICAgIDx4bXA6Q3JlYXRlRGF0ZT4yMDEwLTA1 LTI1VDExOjA3OjMxLTA0OjAwPC94bXA6Q3JlYXRlRGF0ZT4KICAgICAgICAgPHhtcDpDcmVh dG9yVG9vbD5QU2NyaXB0NS5kbGwgVmVyc2lvbiA1LjIuMjwveG1wOkNyZWF0b3JUb29sPgog ICAgICAgICA8eG1wOk1vZGlmeURhdGU+MjAxMC0wNS0yNVQxMTowNzozMS0wNDowMDwveG1w Ok1vZGlmeURhdGU+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8cmRmOkRlc2Ny aXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczpwZGY9Imh0dHA6Ly9ucy5h ZG9iZS5jb20vcGRmLzEuMy8iPgogICAgICAgICA8cGRmOlByb2R1Y2VyPkFjcm9iYXQgRGlz dGlsbGVyIDkuMy4yIChXaW5kb3dzKTwvcGRmOlByb2R1Y2VyPgogICAgICA8L3JkZjpEZXNj cmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAg ICAgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iPgogICAg ICAgICA8eG1wTU06RG9jdW1lbnRJRD51dWlkOjg5MmU1MmI5LTA1YjgtNDVlOS04YmYxLTM4 NmI5ZGVlNzZlNzwveG1wTU06RG9jdW1lbnRJRD4KICAgICAgICAgPHhtcE1NOkluc3RhbmNl SUQ+dXVpZDpmZjA3ZjIyMC02NmYwLTQ5YTUtYjA1Ni0zNzZmMTFkNjJhMzg8L3htcE1NOklu c3RhbmNlSUQ+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3JkZjpSREY+CjwveDp4 bXBtZXRhPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgCjw/eHBhY2tldCBlbmQ9InciPz4NCmVuZHN0cmVhbQ1lbmRvYmoNNiAwIG9iag08PC9G aWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNS9MZW5ndGggNTQvTiAxL1R5cGUvT2JqU3RtPj5z dHJlYW0NCmjeMjRSMFCwsdF3zi/NK1Ew0vfOTCmONjQDCgYpGILIWP2QyoJU/YDE9NRiOzuA AAMAJDMM8A0KZW5kc3RyZWFtDWVuZG9iag03IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29k ZS9GaXJzdCA1L0xlbmd0aCAxOTcvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjefI6xasMw EEB/5TJFGiSf5JjgEgKhDl3qYrCplyyupVIRkSvnM/39eujc/b3HcyUgnE7FZZUvYiW8yp1+ lnvSxTPHSRI9mkmiap48OsTKV87hsXQGD3vE/R+1mV0/c/qWyoac4T3ysplQWW+9LloK/0c6 prDOkdVlZvqYBJq0SMo5MtS2tB5uakyPsI3dtC6GJDmqNm3sQp8CI3EAAwPWpn9Bb7DG0h/M 0Jju9fpmEI9ut2v70VxtoFmfz78CDAAI2Ed6DQplbmRzdHJlYW0NZW5kb2JqDTggMCBvYmoN PDwvRGVjb2RlUGFybXM8PC9Db2x1bW5zIDQvUHJlZGljdG9yIDEyPj4vRmlsdGVyL0ZsYXRl RGVjb2RlL0lEWzxENkJGMTNDM0ZEMkMwRUE2NzA5QjEwNDQ3RjQ4QkFEMj48QkY3MjhDOUQ4 MDAxNUE0NUFDMzY2MDc1REY3MDFDMDA+XS9JbmZvIDEzIDAgUi9MZW5ndGggNTgvUm9vdCAx NSAwIFIvU2l6ZSAxNC9UeXBlL1hSZWYvV1sxIDIgMV0+PnN0cmVhbQ0KaN5iYgACJkZZQQYm BoZ6IMFsASQY14K4nUCCvwrEnQQilIDqzl0HSTCCCAZGIMH0H8wFCDAAw70GJg0KZW5kc3Ry ZWFtDWVuZG9iag1zdGFydHhyZWYNCjExNg0KJSVFT0YNCjEgMCBvYmoNPDwvQW5ub3RzIDI5 IDAgUi9Db250ZW50cyAyIDAgUi9Dcm9wQm94WzAgMCA1OTUgODQyXS9NZWRpYUJveFswIDAg NTk1IDg0Ml0vUGFyZW50IDEyIDAgUi9SZXNvdXJjZXMgOSAwIFIvUm90YXRlIDAvVHlwZS9Q YWdlPj4NZW5kb2JqDTUgMCBvYmoNPDwvTGVuZ3RoIDM3MDEvU3VidHlwZS9YTUwvVHlwZS9N ZXRhZGF0YT4+c3RyZWFtDQo8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlI enJlU3pOVGN6a2M5ZCI/Pgo8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA0LjIuMS1jMDQzIDUyLjM3MjcyOCwgMjAwOS8wMS8x OC0xNTowODowNCAgICAgICAgIj4KICAgPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3 LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICAgICAgPHJkZjpEZXNjcmlw dGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9y Zy9kYy9lbGVtZW50cy8xLjEvIj4KICAgICAgICAgPGRjOmZvcm1hdD5hcHBsaWNhdGlvbi9w ZGY8L2RjOmZvcm1hdD4KICAgICAgICAgPGRjOnRpdGxlPgogICAgICAgICAgICA8cmRmOkFs dD4KICAgICAgICAgICAgICAgPHJkZjpsaSB4bWw6bGFuZz0ieC1kZWZhdWx0Ij5NaWNyb3Nv ZnQgV29yZCAtIFQwOS1TRzAyLTA5MDMyNC1URC1QTEVOLTAwNzEhIU1TVy1FLmRvYzwvcmRm OmxpPgogICAgICAgICAgICA8L3JkZjpBbHQ+CiAgICAgICAgIDwvZGM6dGl0bGU+CiAgICAg ICAgIDxkYzpjcmVhdG9yPgogICAgICAgICAgICA8cmRmOlNlcT4KICAgICAgICAgICAgICAg PHJkZjpsaT50cnV0a293c2tpPC9yZGY6bGk+CiAgICAgICAgICAgIDwvcmRmOlNlcT4KICAg ICAgICAgPC9kYzpjcmVhdG9yPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJk ZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6eG1wPSJodHRw Oi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIj4KICAgICAgICAgPHhtcDpDcmVhdGVEYXRlPjIw MTAtMDUtMjVUMTE6MDc6MzEtMDQ6MDA8L3htcDpDcmVhdGVEYXRlPgogICAgICAgICA8eG1w OkNyZWF0b3JUb29sPlBTY3JpcHQ1LmRsbCBWZXJzaW9uIDUuMi4yPC94bXA6Q3JlYXRvclRv b2w+CiAgICAgICAgIDx4bXA6TW9kaWZ5RGF0ZT4yMDEwLTA1LTI1VDExOjA4OjAxLTA0OjAw PC94bXA6TW9kaWZ5RGF0ZT4KICAgICAgICAgPHhtcDpNZXRhZGF0YURhdGU+MjAxMC0wNS0y NVQxMTowODowMS0wNDowMDwveG1wOk1ldGFkYXRhRGF0ZT4KICAgICAgPC9yZGY6RGVzY3Jp cHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAg IHhtbG5zOnBkZj0iaHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLyI+CiAgICAgICAgIDxw ZGY6UHJvZHVjZXI+QWNyb2JhdCBEaXN0aWxsZXIgOS4zLjIgKFdpbmRvd3MpPC9wZGY6UHJv ZHVjZXI+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0aW9u IHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2Jl LmNvbS94YXAvMS4wL21tLyI+CiAgICAgICAgIDx4bXBNTTpEb2N1bWVudElEPnV1aWQ6ODky ZTUyYjktMDViOC00NWU5LThiZjEtMzg2YjlkZWU3NmU3PC94bXBNTTpEb2N1bWVudElEPgog ICAgICAgICA8eG1wTU06SW5zdGFuY2VJRD51dWlkOmJiMzBhYzhjLThiNTctNDg5Ny05Y2Zk LTg2YzE0MGU1YmI0YjwveG1wTU06SW5zdGFuY2VJRD4KICAgICAgPC9yZGY6RGVzY3JpcHRp b24+CiAgIDwvcmRmOlJERj4KPC94OnhtcG1ldGE+CiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAKPD94cGFja2V0IGVuZD0idyI/Pg0KZW5kc3Ry ZWFtDWVuZG9iag0yOSAwIG9iag1bMzAgMCBSIDMxIDAgUiAzMiAwIFIgMzMgMCBSXQ1lbmRv YmoNMzAgMCBvYmoNPDwvQVA8PC9OIDM3IDAgUj4+L0NbMS4wIDEuMCAwLjBdL0NyZWF0aW9u RGF0ZShEOjIwMTAwNTI1MTEwNzQ3LTA0JzAwJykvRiA0L00oRDoyMDEwMDUyNTExMDc0Ny0w NCcwMCcpL05NKGYyZGIwNzcyLThlMjItNDFmYy1hMGJhLWFhNDk1MWJlYmVjMCkvUCAxIDAg Ui9Qb3B1cCAzMSAwIFIvUXVhZFBvaW50c1s1Ni43IDc3Mi4xODQgNTI3LjY0OSA3NzIuMTg0 IDU2LjcgNzU2LjQxNiA1MjcuNjQ5IDc1Ni40MTYgNTYuNyA3NTguMzg0IDk1LjcyMzggNzU4 LjM4NCA1Ni43IDc0Mi42MTYgOTUuNzIzOCA3NDIuNjE2XS9SZWN0WzUyLjQ5MDggNzQyLjEy NCA1MzEuODU4IDc3Mi42NzddL1N1YmooSGlnaGxpZ2h0KS9TdWJ0eXBlL0hpZ2hsaWdodC9U KHRydXRrb3dza2kpL1R5cGUvQW5ub3Q+Pg1lbmRvYmoNMzEgMCBvYmoNPDwvRiAyOC9PcGVu IGZhbHNlL1BhcmVudCAzMCAwIFIvUmVjdFs1OTUuMCA2NTIuMTg0IDc3NS4wIDc3Mi4xODRd L1N1YnR5cGUvUG9wdXAvVHlwZS9Bbm5vdD4+DWVuZG9iag0zMiAwIG9iag08PC9BUDw8L04g MzQgMCBSPj4vQ1sxLjAgMS4wIDAuMF0vQ3JlYXRpb25EYXRlKEQ6MjAxMDA1MjUxMTA3NTkt MDQnMDAnKS9GIDQvTShEOjIwMTAwNTI1MTEwNzU5LTA0JzAwJykvTk0oZDgyNDYzOWQtNjE3 Zi00YWE0LWExZGMtZWVmZWQ1NWNlMGFlKS9QIDEgMCBSL1BvcHVwIDMzIDAgUi9RdWFkUG9p bnRzWzk4LjcyODYgNzU4LjM4NCA1MTAuMzY1IDc1OC4zODQgOTguNzI4NiA3NDIuNjE2IDUx MC4zNjUgNzQyLjYxNiA1Ni43IDc0NC41ODQgODUuNjc5OCA3NDQuNTg0IDU2LjcgNzI4Ljgx NiA4NS42Nzk4IDcyOC44MTYgNTYuNyA3MTguODkyIDExNC4wNiA3MTguODkyIDU2LjcgNzAy Ljg5NiAxMTQuMDYgNzAyLjg5NiA1Ni43IDY5OC45ODQgNTIyLjc5NyA2OTguOTg0IDU2Ljcg NjgzLjIxNiA1MjIuNzk3IDY4My4yMTYgNTYuNyA2ODUuMTg0IDUxMC4zMzQgNjg1LjE4NCA1 Ni43IDY2OS40MTYgNTEwLjMzNCA2NjkuNDE2IDU2LjcgNjcxLjM4NCA1MTcuMzQ5IDY3MS4z ODQgNTYuNyA2NTUuNjE2IDUxNy4zNDkgNjU1LjYxNiA1Ni43IDY1Ny41ODQgNTAxLjk1IDY1 Ny41ODQgNTYuNyA2NDEuODE2IDUwMS45NSA2NDEuODE2XS9SZWN0WzUyLjQyOTkgNjQxLjMy NCA1MjcuMDA3IDc1OC44NzddL1N1YmooSGlnaGxpZ2h0KS9TdWJ0eXBlL0hpZ2hsaWdodC9U KHRydXRrb3dza2kpL1R5cGUvQW5ub3Q+Pg1lbmRvYmoNMzMgMCBvYmoNPDwvRiAyOC9PcGVu IGZhbHNlL1BhcmVudCAzMiAwIFIvUmVjdFs1OTUuMCA2MzguMzg0IDc3NS4wIDc1OC4zODRd L1N1YnR5cGUvUG9wdXAvVHlwZS9Bbm5vdD4+DWVuZG9iag0zNCAwIG9iag08PC9CQm94WzAu MCAwLjAgNDc0LjU3NyAxMTcuNTUzXS9Gb3JtVHlwZSAxL0xlbmd0aCAyMC9NYXRyaXhbMS4w IDAuMCAwLjAgMS4wIDAuMCAwLjBdL1Jlc291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlT IGZhbHNlL0JNL011bHRpcGx5L1R5cGUvRXh0R1N0YXRlPj4+Pi9Qcm9jU2V0Wy9QREZdL1hP YmplY3Q8PC9NV0ZPRm9ybSAzNSAwIFI+Pj4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+ PnN0cmVhbQ0KL1IwIGdzCi9NV0ZPRm9ybSBEbwoNCmVuZHN0cmVhbQ1lbmRvYmoNMzUgMCBv YmoNPDwvQkJveFswLjAgMC4wIDQ3NC41NzcgMTE3LjU1M10vRm9ybVR5cGUgMS9Hcm91cDw8 L1MvVHJhbnNwYXJlbmN5Pj4vTGVuZ3RoIDkvTWF0cml4WzEuMCAwLjAgMC4wIDEuMCAwLjAg MC4wXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdL1hPYmplY3Q8PC9Gb3JtIDM2IDAgUj4+ Pj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQovRm9ybSBEbwoNCmVuZHN0 cmVhbQ1lbmRvYmoNMzYgMCBvYmoNPDwvQkJveFs1Mi40Mjk5IDY0MS4zMjQgNTI3LjAwNyA3 NTguODc3XS9GaWx0ZXJbL0ZsYXRlRGVjb2RlXS9Gb3JtVHlwZSAxL0xlbmd0aCAzNTYvTWF0 cml4WzEuMCAwLjAgMC4wIDEuMCAtNTIuNDI5OSAtNjQxLjMyNF0vUmVzb3VyY2VzPDwvUHJv Y1NldFsvUERGXT4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIlckjty xTAIRXuvQitghPgI1pOZpHlp0mT7QbYFfmnP+MIxutiw9fbzdXRwE2m/hxvMYdomD1BUbt+H C3QcGEiBaHhLIAyqc7YMiQEZj/ZxCHYgZSv2CsbQDamCRfbsym2Bj+PzEIXZYgXYpSQjfEna pAFyxjbgDnZOPhPMIJePCeh0K/Q6zIFcqTIJ9tQM7c3LJU7lPuNU14o+wDylxvq6a/ydzpYA BeJefkthDPOxpHD9vrgWewWbYMO9UkX24Mrt7bfY9YbnGjWC8X4tNQV/XkvjJUdeS+MZ/X69 MWD65GLxekNBkPyRSlKDd25vz9dTdeB/PpMA33wMgcsnzo+PNhFzsbtN0v2RSpKDM7e3l4/I 6pekjwbyu4Qb6Lx7eiYmVrsnEJsXW/dB6Cr8SCXJwZnb28uHcXXszYclekilI/Qot8rc5ZaO 4NKpWOh0WWWxRyrJnpuxvXvZ/AkwAPcUzOgNCmVuZHN0cmVhbQ1lbmRvYmoNMzcgMCBvYmoN PDwvQkJveFswLjAgMC4wIDQ3OS4zNjcgMzAuNTUzM10vRm9ybVR5cGUgMS9MZW5ndGggMjAv TWF0cml4WzEuMCAwLjAgMC4wIDEuMCAwLjAgMC4wXS9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8 PC9SMDw8L0FJUyBmYWxzZS9CTS9NdWx0aXBseS9UeXBlL0V4dEdTdGF0ZT4+Pj4vUHJvY1Nl dFsvUERGXS9YT2JqZWN0PDwvTVdGT0Zvcm0gMzggMCBSPj4+Pi9TdWJ0eXBlL0Zvcm0vVHlw ZS9YT2JqZWN0Pj5zdHJlYW0NCi9SMCBncwovTVdGT0Zvcm0gRG8KDQplbmRzdHJlYW0NZW5k b2JqDTM4IDAgb2JqDTw8L0JCb3hbMC4wIDAuMCA0NzkuMzY3IDMwLjU1MzNdL0Zvcm1UeXBl IDEvR3JvdXA8PC9TL1RyYW5zcGFyZW5jeT4+L0xlbmd0aCA5L01hdHJpeFsxLjAgMC4wIDAu MCAxLjAgMC4wIDAuMF0vUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGXS9YT2JqZWN0PDwvRm9y bSAzOSAwIFI+Pj4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KL0Zvcm0g RG8KDQplbmRzdHJlYW0NZW5kb2JqDTM5IDAgb2JqDTw8L0JCb3hbNTIuNDkwOCA3NDIuMTI0 IDUzMS44NTggNzcyLjY3N10vRmlsdGVyWy9GbGF0ZURlY29kZV0vRm9ybVR5cGUgMS9MZW5n dGggMTQwL01hdHJpeFsxLjAgMC4wIDAuMCAxLjAgLTUyLjQ5MDggLTc0Mi4xMjRdL1Jlc291 cmNlczw8L1Byb2NTZXRbL1BERl0+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJl YW0NCkiJXI47EgIhEAVzTjEneMUwX86zVZqsiYnXF0sBNSFoqt80E1Ol+7VU9DSjRzFHUIxX 2ZVuxdr4EaPwCpbWaYOEegS9jWjgVKZjGAHX7JudxYQhbvplbbKGpzevH+Xy6dEG/+tRh/z0 mMJ3jyUktY2NbogmudFZeodqle0sMFeXNC+/Wp4CDAA0UjtaDQplbmRzdHJlYW0NZW5kb2Jq DTQwIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA1L0xlbmd0aCAyMDEvTiAx L1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeZI6xasMwFAB/5WWKNEh+kmNShxAIdchSF4NNvWRx LIWIiKg8P5Pfr4dCh+53x5kcEPb77DjzPZFgmvmRXtMjyOyd/MAhPauBvah2Fg1iYQtjcJsb hZs14vqXWsymHSl8c6FdjPDlaVpMKLTVVmZ1cv8jb/gXaSi5efQkjiOl68BQhYlDjJ6g1Lm2 cBF9eLpl7CJl1gWOXtRhYad0Y+gTOVDQYanaM1qFJeZ2o7pKNR+nT4W4NatV3fbqpF0a5eHw I8AAB+VHeA0KZW5kc3RyZWFtDWVuZG9iag00MSAwIG9iag08PC9EZWNvZGVQYXJtczw8L0Nv bHVtbnMgMy9QcmVkaWN0b3IgMTI+Pi9GaWx0ZXIvRmxhdGVEZWNvZGUvSURbPEQ2QkYxM0Mz RkQyQzBFQTY3MDlCMTA0NDdGNDhCQUQyPjwwRkM2RTRFNzVENERGNjQ5OEJEM0E5MDE2Q0Ex RTQ4Mj5dL0luZGV4WzEgMSA1IDEgMTMgMSAyOSAxM10vSW5mbyAxMyAwIFIvTGVuZ3RoIDU4 L1ByZXYgMTE2L1Jvb3QgMTUgMCBSL1NpemUgNDIvVHlwZS9YUmVmL1dbMSAyIDBdPj5zdHJl YW0NCmjeYmI0TmFiYOhlYjxrzvTfqRvI1mNiYJoBpPOYGJj3MDEwAmlGaSB+BRS3RbAZU4FY HSDAAFVyCVYNCmVuZHN0cmVhbQ1lbmRvYmoNc3RhcnR4cmVmDQoyMDcwOA0KJSVFT0YNCg== --------------070708080107010805030604-- From richard@shockey.us Tue May 25 15:03: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 5717E3A6FD7 for ; Tue, 25 May 2010 15:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] 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 PBQvZun8JkKD for ; Tue, 25 May 2010 15:03:43 -0700 (PDT) Received: from outbound-mail-313.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id E78843A74F9 for ; Tue, 25 May 2010 14:09:35 -0700 (PDT) Received: (qmail 7641 invoked by uid 0); 25 May 2010 21:08:56 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy3.bluehost.com with SMTP; 25 May 2010 21:08:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=ZDipj8VKXo/OHlwWfjkwgAxBIAXd5UUjsneTwpBSXddFqwQ+4efXVKXZtu+0Ds4ITG25r5gqCRV2Q2SpYohmY/+Cj9bOTUe3rIzxKBDD0g6GBTZbwmI+L2/h0F2Bx/96; 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 1OH1Mu-0003cX-8P; Tue, 25 May 2010 15:08:56 -0600 From: "Richard Shockey" To: "'E.164 To MetaData BOF discussion list'" , Date: Tue, 25 May 2010 17:08:49 -0400 Message-ID: <000001cafc4e$793f7150$6bbe53f0$@us> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01CAFC2C.F22DD150" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrVxeKSAdvv5BFDQo6tAndWkYEjuAmhTlpQ 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} Subject: [e2md] FW: I-D ACTION:draft-holsten-about-uri-scheme-04.txt 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, 25 May 2010 22:03:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01CAFC2C.F22DD150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Did anyone see this? -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, April 06, 2010 4:15 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-holsten-about-uri-scheme-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The 'about' URI scheme Author(s) : J. Holsten, L. Hunt Filename : draft-holsten-about-uri-scheme-04.txt Pages : 6 Date : 2010-4-6 A URI using the "about:" scheme, henceforth referred to as an "about" URI, is designed to be used internally by applications for almost any desired purpose. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-holsten-about-uri-scheme-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0001_01CAFC2C.F22DD150 Content-Type: Message/External-body; name="draft-holsten-about-uri-scheme-04.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-holsten-about-uri-scheme-04.txt" Content-Type: text/plain Content-ID: <2010-4-6130209.I-D@ietf.org> ------=_NextPart_000_0001_01CAFC2C.F22DD150 Content-Type: text/plain; name="ATT00004.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00004.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------=_NextPart_000_0001_01CAFC2C.F22DD150-- From bernie@ietf.hoeneisen.ch Wed May 26 12:08: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 3CF2A3A69DC for ; Wed, 26 May 2010 12:08:13 -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 tQWJAh5jvIOy for ; Wed, 26 May 2010 12:08:12 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 0D4543A6890 for ; Wed, 26 May 2010 12:08:11 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1OHLxR-0005Im-3x for e2md@ietf.org; Wed, 26 May 2010 21:08:01 +0200 Date: Wed, 26 May 2010 21:08:01 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "E.164 To MetaData BOF discussion list" In-Reply-To: <1274132277.2972.4.camel@damnableubu> Message-ID: References: <35FE871E2B085542A35726420E29DA6B03F95813@gaalpa1msgusr7a.ugd.att.com> <35FE871E2B085542A35726420E29DA6B03F959AB@gaalpa1msgusr7a.ugd.att.com> <1274132277.2972.4.camel@damnableubu> 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] Shall we go this way? (was Re: Problem statement, Requirements and Use Cases (was RFC 5507 & RFC 5395)) 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, 26 May 2010 19:08:13 -0000 Hi E2MD:ers IMHO something along the lines of what Penn and Dean proposed "agree to analyze the problem(s) and solve each appropriately" (see below) is a viable strategy to get a E2MD WG approved. This implies a lot of wordsmithing to a charter... We'd need to make a careful selection of initial use cases to be assessed in that WG. Furthermore we need a sophisticated strategy to drop certain use cases (from the initial list) during the WG forming BoF, if those are causing too much harm to the WG approval process. And we need Internet-Drafts describing the Use Cases before the WG forming BoF takes place. My questions to all of you: a) Do you also see this as a viable strategy? b) Which timeframe do your believe is sensible (Maastricht or Beijing?) c) Who is willing to actively assist the work on an agreeable charter? d) Who is willing to write Internet-Drafts describing certain Use Cases? We'll discuss this as part of tomorrow's conference call. However, some initial discussion on this list is most helpful to keep this discussion during the call as short as possible. Besides this, your opinion will be understood better if it is stated in written. In case you do not agree with this strategy, please indicate to the list, how you believe we should go on with this matter! cheers, Bernie -- http://ucom.ch/ Tech Consulting for Internet Standardization On Mon, 17 May 2010, Dean Willis wrote: > On Mon, 2010-05-17 at 13:31 -0400, PFAUTZ, PENN L (ATTCORP) wrote: > >> Please sirs, may we have an e2md WG that will analyze proposed use >> cases guided by RFC 5507 & RFC 5395 and propose appropriate >> implementations? > > > That probably would work. I think all we need to do is agree to analyze > the problem(s) and solve each appropriately while respecting the > "rules", rather than insisting on one-size-fits-all hack/slash on ENUM > to define a framework for adding arbitrary metadata into NAPTR records. > > -- > Dean > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > From dhc2@dcrocker.net Thu May 27 11:58:09 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EEE63A692E for ; Thu, 27 May 2010 11:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.828 X-Spam-Level: X-Spam-Status: No, score=-3.828 tagged_above=-999 required=5 tests=[AWL=-1.472, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_PROXY=1.643] 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 QfP2TgGIUfip for ; Thu, 27 May 2010 11:58:08 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 6C31D3A68D0 for ; Thu, 27 May 2010 11:58:08 -0700 (PDT) Received: from [192.168.1.36] (adsl-67-127-57-244.dsl.pltn13.pacbell.net [67.127.57.244]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o4RIvm9i006209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 May 2010 11:57:54 -0700 Message-ID: <4BFEC0AB.6080800@dcrocker.net> Date: Thu, 27 May 2010 11:57:47 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking 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: Bernie Hoeneisen References: <35FE871E2B085542A35726420E29DA6B03F95813@gaalpa1msgusr7a.ugd.att.com> <35FE871E2B085542A35726420E29DA6B03F959AB@gaalpa1msgusr7a.ugd.att.com> <1274132277.2972.4.camel@damnableubu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 27 May 2010 11:57:54 -0700 (PDT) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Shall we go this way? (was Re: Problem statement, Requirements and Use Cases (was RFC 5507 & RFC 5395)) X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net 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, 27 May 2010 18:58:09 -0000 (a few minutes before the call...) On 5/26/2010 12:08 PM, Bernie Hoeneisen wrote: > a) Do you also see this as a viable strategy? On review the Use Cases file, I think it has 'useful' content but really does not provide 'use cases'. I think of "uses cases" as starting with a description of a problem or activity that one wants to accomplish. The current document seems to start with particular features to add. Most of these do have a subordinate entry that cites a usage, but it's in passing, rather than as a focus. To take an example from the current file, I'd expect a Use Case to say: Assist in better call routing It would have a statement about the current call routing limitations or problems and discuss the kinds of things that would make call routing better. For example, perhaps an organization has multiple VOIP gateways to the open Internet. How does an inbound caller know which to route through. (I'm fantasizing here; I've no idea if this is a real issue of concern to you folk.) Only after all that might the use case start citing possible solution paths, such as parameters that need to be added to an (existing) ENUM record. > b) Which timeframe do your believe is sensible (Maastricht or Beijing?) > > c) Who is willing to actively assist the work on an agreeable charter? yes. i enjoy charter bashing and believe that a well-draft charter sets the, ummm, course for the working group. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dean.willis@softarmor.com Thu May 27 12:01: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 96AAF3A698A for ; Thu, 27 May 2010 12:01:20 -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 4eGBM1aqgEkY for ; Thu, 27 May 2010 12:01:19 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 14C1C3A69A2 for ; Thu, 27 May 2010 12:01:15 -0700 (PDT) Received: from [10.129.27.223] (mobile-032-168-081-113.mycingular.net [32.168.81.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4RJ0sPR014116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 27 May 2010 14:01:04 -0500 X-User-Agent: K-9 Mail for Android MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit From: Dean Willis Date: Thu, 27 May 2010 14:00:35 -0500 To: e2md@ietf.org Message-ID: Subject: [e2md] Not attending today's 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, 27 May 2010 19:01:20 -0000 Due to a thing that came up at work, I will not be attending today's call. I think that recent discussion about how to construct a charter that will pass inspection has been useful, and hope the group can reach a rough consensus today. -- Dean Willis From gonzalo.camarillo@ericsson.com Mon May 31 06:52: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 9863B3A68F2 for ; Mon, 31 May 2010 06:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.759 X-Spam-Level: X-Spam-Status: No, score=-102.759 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, 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 SB2GZjewHoMI for ; Mon, 31 May 2010 06:52:42 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id CBAF43A684D for ; Mon, 31 May 2010 06:52:41 -0700 (PDT) X-AuditID: c1b4fb3d-b7b13ae0000071b2-79-4c03bf1c0d65 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 97.9E.29106.C1FB30C4; Mon, 31 May 2010 15:52:28 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 May 2010 15:52:28 +0200 Received: from [131.160.126.212] ([131.160.126.212]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 May 2010 15:52:27 +0200 Message-ID: <4C039B93.9050206@ericsson.com> Date: Mon, 31 May 2010 14:20:51 +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: 31 May 2010 13:52:27.0957 (UTC) FILETIME=[81B1E650:01CB00C8] X-Brightmail-Tracker: AAAAAA== Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Details for conf call, Thu 27 May, 19 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, 31 May 2010 13:52:43 -0000 Hi, unfortunately, I could not attend this call because of the IESG retreat. Are the minutes of the meeting available somewhere. Also, there have been a number of messages sent to several mailing lists (e.g., DRINKS, ENUM, and E2MD). Cross posting can make following discussions difficult (depending on how people filter their email) and has been traditionally discouraged (at least within the RAI area). Thanks, Gonzalo On 24/05/2010 9:41 PM, Bernie Hoeneisen wrote: > Dear e2md:ers, > > Please find the details of the next e2md conference call below: > > > * Date/Time: > > Thursday, 27 May 2010, 19:00 UT > (20:00 BST, 21:00 CEST, 15:00 EDT, 07:00 NZST) > Duration: 60-90 min > > > * Dial-In: > > - SIP: sip:46@mcu-hd.switch.ch --> Conference ID: 46 # > - H.323:h323:46@mcu-hd.switch.ch --> Conference ID: 46 # > - PSTN: +41 44 250 96 46 > > > * Collaboration Tool (we will use this during the call!): > > http://collab.switch.ch/ietf-e2md > > > * Goal > > Get a clear understanding on the short term requirements. > > > * Agenda: > > 1) Welcome / Roll-Call / Scribe > > > 2) Discussion of the requirements: > > http://trac.tools.ietf.org/bof/e2md/trac/wiki/RequirementsList > > Please prepare the questions you would like to discuss! > > > 3) Disussion and priorization of the Use Cases: > > http://trac.tools.ietf.org/bof/e2md/trac/wiki/UseCases > > Please think about which Use Cases we should start with > _before_ the conf call! > > > 4) Decide on plan for IETF-78 (Maastricht) > > The following options have been suggested so far: > > a) Request 2nd (WG forming) e2md BoF (on limited set of Use cases) > b) Request 2nd (non-WG forming) e2md BoF > c) Dispatch "side-meetings" (as proposed during the last conf call) > d) Request ENUM WG meeting (to discuss/propose a re-charter) > > > 5) AOB > > > Note: The discussion was rather fuzzy in the recent conf calls. > If during this call there is a need to structure the discussion > and give also the less "dominant" participants a chance to speak, > we will use the collaboration tool to maintain a speakers list, > which has a built-in "Raise hand" function. > > > cheers, > Bernie > > > PS: Please find previous minutes and presentations on: > http://trac.tools.ietf.org/bof/e2md/trac/wiki/MeetingMinutes > > > -- > > http://ucom.ch/ > Tech Consulting for Internet Standardization > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > From bernie@ietf.hoeneisen.ch Mon May 31 12:51: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 496A43A6845 for ; Mon, 31 May 2010 12:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.121 X-Spam-Level: X-Spam-Status: No, score=0.121 tagged_above=-999 required=5 tests=[AWL=-1.120, 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 4M5eqU1FG-tP for ; Mon, 31 May 2010 12:51:33 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 19FE13A681B for ; Mon, 31 May 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 1OJB15-0005OV-1U for e2md@ietf.org; Mon, 31 May 2010 21:51:19 +0200 Date: Mon, 31 May 2010 21:51:19 +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] Draft version minutes Conf call 27 May 2010 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, 31 May 2010 19:51:34 -0000 Hi E2MD:ers Below the draft version of the minutes of the e2md Conference call from 27 May 2010. Those are based on Ray Bellis' notes and my adjustments/enhancements. In case we missed something or got something wrong, please holler asap (or latest by Thursday noon UT). cheers, Bernie -- http://ucom.ch/ Tech Consulting for Internet Standardization ----------------------------------------------------------------------- Minutes of the e2md Conference call from 27 May 2010 (DRAFT VERSION) ==================================================== Date/Time --------- Thursday, 27 May 2010, 19:00 UT (20:00 BST, 21:00 CEST, 15:00 EDT) Duration: 80 min Attendees --------- - Bernie Hoeneisen (chair) - Ray Bellis (minutes) - Dave Crocker - Jay Carpenter - Penn Pfautz Goal ---- Get a clear understanding on the short term requirements. Agenda ------ 1) Welcome / Roll-Call / Scribe 2) Discussion of the requirements: http://trac.tools.ietf.org/bof/e2md/trac/wiki/RequirementsList Please prepare the questions you would like to discuss! 3) Discussion and prioritization of the Use Cases: http://trac.tools.ietf.org/bof/e2md/trac/wiki/UseCases Please think about which Use Cases we should start with _before_ the conf call! 4) Decide on plan for IETF-78 (Maastricht) 5) AOB Minutes ------- (Notes from Ray Bellis adjusted/enhanced by Bernie Hoeneisen) Requirements: Looking at Jay Daley's Requirements document - no comments received on list - 1.1.3d unclear - requires on list clarification - 1.2 merits keeping in at this stage - 1.3 - unclear what consistency means - 2.1 - private trees, or private networks? DC - the requirements documentation needs justification RB - the requirements doc is primarily about alternatives, and only 1.3 gives specific requirements Use Cases: DC - use case docs aren't really use cases PP - offer to update g-spid and/or g-spn as proper use cases BH - Poll on which initial use cases we start working --> Clear favorites are: g-spid, cnam, service capabilities In addition to those there was a proposal to add also unused and send-n, as those are documented in an Internet-Drafts already. Strategy: The participant agreed to _not_ to ask for a WG-forming BoF at IETF-78 (Maastricht). IETF-78 will be used to discuss the proposal further and prepare an agreeable charter (as discussed during the previous conference call). A WG-forming BoF is planned for IETF-79 (Beijing). All participants (except JC who had to leave the call early) agreed to assist the work on an agreeable charter. Some folks promised to write Internet-Drafts, including Penn, who volunteered to describe the g-spid use case in an Internet-Draft. AOB: JC: Twitter and ENUM might be an case to look at Action Points: - Penn: Write I-D about g-spid use case (2-3 weeks) - Bernie: Discuss with AD the possibilities for e2md meetings/venues in Maastricht (asap) - Bernie: Arrange next Conference Call within 2-3 weeks