From richard@shockey.us Fri Mar 2 13:08:41 2012 Return-Path: X-Original-To: enum@ietfa.amsl.com Delivered-To: enum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961EF21E803B for ; Fri, 2 Mar 2012 13:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.572 X-Spam-Level: X-Spam-Status: No, score=-99.572 tagged_above=-999 required=5 tests=[AWL=0.923, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jza17EBgw7I9 for ; Fri, 2 Mar 2012 13:08:41 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 200EE21E8010 for ; Fri, 2 Mar 2012 13:08:41 -0800 (PST) Received: (qmail 30057 invoked by uid 0); 2 Mar 2012 21:08:40 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com with SMTP; 2 Mar 2012 21:08:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=OjICDVIJ0Bb7MD16yHD99NXjBdgfYbZb4qj2KIUQmhw=; b=h+8S3/a21E7KiLoGwkNZK4L0+NJwcYOfgXtGjVhR2GRmkZanFZ5Cxamg6hKW4Ap6oAzzEXrz9r+32mfm6gJOQt9KpA7+q1x57k8VkSvFVpyjlk+CS44pt0R6LYN67mMc; Received: from pool-108-48-10-220.washdc.fios.verizon.net ([108.48.10.220] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1S3ZiR-0001TN-Tl for enum@ietf.org; Fri, 02 Mar 2012 14:08:40 -0700 From: "Richard Shockey" To: "'IETF ENUM list'" Date: Fri, 2 Mar 2012 16:08:39 -0500 Message-ID: <01da01ccf8b8$a535d020$efa17060$@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: Acz4jAktTNVQaAORRmiGYzHtlNxlDgALJT7Q Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.48.10.220 authed with richard@shockey.us} Subject: [Enum] FW: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 21:08:41 -0000 -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Friday, March 02, 2012 10:49 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ENUM Service Registration for Social Networking (SN) Services Author(s) : Laurent-Walter Goix Kepeng Li Filename : draft-goix-appsawg-enum-sn-service-00.txt Pages : 7 Date : 2012-03-02 This document registers a Telephone Number Mapping (ENUM) service for Social Networking (SN). Specifically, this document focuses on provisioning 'acct:' URIs (Uniform Resource Identifiers) in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-goix-appsawg-enum-sn-service-00.tx t Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-goix-appsawg-enum-sn-service-00.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 From lconroy@insensate.co.uk Sat Mar 3 04:06:38 2012 Return-Path: X-Original-To: enum@ietfa.amsl.com Delivered-To: enum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E334721F873B for ; Sat, 3 Mar 2012 04:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GE6sZ8bpETj8 for ; Sat, 3 Mar 2012 04:06:38 -0800 (PST) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by ietfa.amsl.com (Postfix) with ESMTP id 2C15721F873A for ; Sat, 3 Mar 2012 04:06:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 9097A58EF8D; Sat, 3 Mar 2012 12:06:35 +0000 (GMT) X-Virus-Scanned: amavisd-new at insensate.co.uk Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0r6xvII57vR; Sat, 3 Mar 2012 12:06:34 +0000 (GMT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 39A8858EF82; Sat, 3 Mar 2012 12:06:34 +0000 (GMT) From: Lawrence Conroy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 3 Mar 2012 12:06:33 +0000 Message-Id: <2A45B5D5-FEAD-4813-96D3-55FA757ADD8C@insensate.co.uk> To: Gonzalo Camarillo Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: IETF ENUM list Subject: [Enum] Enumservice registrations X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 12:06:39 -0000 Hi esteemed AD, ENUMers, As a process issue: - Section 4.1 of RFC6117 suggests that authors of Enumservices should = look for existing work in the Enum mailing list. - Section 6.3 of RFC6117 states that authors MUST send a mail to the = enum list with a link to the registration doc. In the current case, Richard forwarded the id-announce mail for = draft-goix-appsawg-enum-sn-service-00.txt to the list; the authors have = not. So ... Can someone ensure at least that I-Ds for Enumservices are = ALWAYS/Automatically sent to the enum mailing list? (i.e., if it's an Enumservice, the enum mailing list is an interested = party) The application detail for Enumservices may well be covered in other = WGs, but there must be a link the ENUM mailing list. Otherwise 6117 needs an update -- please, no! all the best, Lawrence From lconroy@insensate.co.uk Sat Mar 3 05:00:20 2012 Return-Path: X-Original-To: enum@ietfa.amsl.com Delivered-To: enum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4852621F86E2 for ; Sat, 3 Mar 2012 05:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDvSh2G+6ZOp for ; Sat, 3 Mar 2012 05:00:19 -0800 (PST) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by ietfa.amsl.com (Postfix) with ESMTP id 8136E21F869E for ; Sat, 3 Mar 2012 05:00:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 9969458F3B6; Sat, 3 Mar 2012 13:00:10 +0000 (GMT) X-Virus-Scanned: amavisd-new at insensate.co.uk Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiuqLm8KhEaY; Sat, 3 Mar 2012 13:00:09 +0000 (GMT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id F095258F3AB; Sat, 3 Mar 2012 13:00:08 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <01da01ccf8b8$a535d020$efa17060$@us> Date: Sat, 3 Mar 2012 13:00:08 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <35C11485-CA99-49CB-908A-BF74C4CB24E9@insensate.co.uk> References: <01da01ccf8b8$a535d020$efa17060$@us> To: laurentwalter.goix@telecomitalia.it X-Mailer: Apple Mail (2.1084) Cc: IETF ENUM list Subject: Re: [Enum] FW: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 13:00:20 -0000 Hi Laurent-Walter, Richard, folks, As one of the authors of RFC6116, I'm intrigued with section 4 of this = draft. AFAICT, section 4 of this draft specifically states that E2U+acct can be = used in an entirely different namespace from ENUM. That's an = interpretation of 6116 section 2 that I don't recognise. The second paragraph of Section 5 is ambivalent on this, but section 4 = spells out that a separate apex may be used. That directly contradicts its example, and in any case the Enumservice = template is incorrect for such private use (in that case, it would need = to be "limited", not "common" -- see RFC6117 section 5.2.7 **). =3D> Was that intended -- does that first paragraph of section 4 of this = draft help? As I understand the second paragraph of section 4, the intention is that = an implementation will chase pstn:tel records looking for a domain with = an appropriate E2U+acct record. That looks like it's stretching the = pstn:tel use given in RFC4769 section 3.1, but ... The last bullet of section 5.5 of RFC6117 states that the registration = doc needs to cover loop mitigation. It may be unfair, but RFC4769 was not covered by the current rules, so = they dodged the bullet of that requirement. This draft can't, so you will have to spell out the rules for loop = mitigation. Merely referring to RFC4694 is not enough; see the last sentence of = section 5 of RFC4694. Finally, section 5 mentions an "activity wall". I wonder if anyone will = know what that means in 10 years time. It is not mentioned directly in the webfinger draft, so if it's spelt = out in the referenced OMA service document, from where can one get that = spec? all the best, Lawrence ** [E2U+pstn:tel was registered under the "old" rules; this one is = covered by 6117] On 2 Mar 2012, at 21:08, Richard Shockey wrote: > -----Original Message----- > From: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of internet-drafts@ietf.org > Sent: Friday, March 02, 2012 10:49 AM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > Title : ENUM Service Registration for Social = Networking > (SN) Services > Author(s) : Laurent-Walter Goix > Kepeng Li > Filename : draft-goix-appsawg-enum-sn-service-00.txt > Pages : 7 > Date : 2012-03-02 >=20 > This document registers a Telephone Number Mapping (ENUM) service = for > Social Networking (SN). Specifically, this document focuses on > provisioning 'acct:' URIs (Uniform Resource Identifiers) in ENUM. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-goix-appsawg-enum-sn-service-00.= tx > t >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-goix-appsawg-enum-sn-service-00.t= xt From bernie@ietf.hoeneisen.ch Sat Mar 3 05:06:46 2012 Return-Path: X-Original-To: enum@ietfa.amsl.com Delivered-To: enum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18BA21F874F; Sat, 3 Mar 2012 05:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqeeM6iWPkg6; Sat, 3 Mar 2012 05:06:45 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by ietfa.amsl.com (Postfix) with ESMTP id DCFA921F8749; Sat, 3 Mar 2012 05:06:44 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.71) (envelope-from ) id 1S3ofZ-0002w0-Ll; Sat, 03 Mar 2012 14:06:41 +0100 Date: Sat, 3 Mar 2012 14:06:41 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Lawrence Conroy In-Reply-To: <2A45B5D5-FEAD-4813-96D3-55FA757ADD8C@insensate.co.uk> Message-ID: References: <2A45B5D5-FEAD-4813-96D3-55FA757ADD8C@insensate.co.uk> 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: IETF ENUM list , Gonzalo Camarillo , "apps-discuss@ietf.org" Subject: Re: [Enum] Enumservice registrations X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 13:06:46 -0000 Hi Lawrence Thanks for sharing your view on the Enumservice registration process wrt. draft-goix-appsawg-enum-sn-service-00.txt. And thanks Rich for spotting this I/D and forwarding it to the ENUM list. It appears to me that the authors simply have not read RFC 6117 too thoroughly, and therefore don't follow the RFC-6117-process. However, I am not worried at this point in time, as the I/D is a -00 individual submission. Furthermore, before any Enumservice advances, it has to go through my hands, and I will ensure each proposal gets sufficient community review (in particular ENUM community), before any decision is made. Thus, not-follow-the-process simply results in delay, which the authors otherwise could avoid. Should I happen to meet the authors in Paris, I'll talk to them about this. I hope this addresses your concerns. cheers, Bernie, IESG Designated Expert for ENUM PS: And no, we are not intending to update RFC 6117 any time soon... ;-) -- http://ucom.ch/ Tech Consulting for Internet Technology On Sat, 3 Mar 2012, Lawrence Conroy wrote: > Hi esteemed AD, ENUMers, > As a process issue: > - Section 4.1 of RFC6117 suggests that authors of Enumservices should > look for existing work in the Enum mailing list. > - Section 6.3 of RFC6117 states that authors MUST send a mail to the > enum list with a link to the registration doc. > > In the current case, Richard forwarded the id-announce mail for > draft-goix-appsawg-enum-sn-service-00.txt to the list; the authors have > not. > > So ... > Can someone ensure at least that I-Ds for Enumservices are > ALWAYS/Automatically sent to the enum mailing list? (i.e., if it's an > Enumservice, the enum mailing list is an interested party) > > The application detail for Enumservices may well be covered in other > WGs, but there must be a link the ENUM mailing list. Otherwise 6117 > needs an update -- please, no! > > all the best, > Lawrence > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum > From richard@shockey.us Sat Mar 3 07:38:37 2012 Return-Path: X-Original-To: enum@ietfa.amsl.com Delivered-To: enum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853F521F86AF for ; Sat, 3 Mar 2012 07:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.387 X-Spam-Level: X-Spam-Status: No, score=-99.387 tagged_above=-999 required=5 tests=[AWL=0.508, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_43=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnFtTqfwAtkN for ; Sat, 3 Mar 2012 07:38:36 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id A58FD21F86AD for ; Sat, 3 Mar 2012 07:38:36 -0800 (PST) Received: (qmail 330 invoked by uid 0); 3 Mar 2012 15:38:35 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 3 Mar 2012 15:38:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=yent/r30SuQZhf/XJWnLfDyDhVtElrONXNU98sz3Dms=; b=ip1ZhGKrmccr2a/c1TcCMwBzQ7PEJOKMF9V9RxCdAKXXQRrgZZz5PmeiBCYu/e8cV7iEv/u4mP8ysKx3ASnb0yqQPn7Tth15nWzgh2rtunm5HGWiQZW8dTMyC6JjkRfb; Received: from pool-108-48-10-220.washdc.fios.verizon.net ([108.48.10.220] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1S3r2Y-0003IF-T5; Sat, 03 Mar 2012 08:38:35 -0700 From: "Richard Shockey" To: "'Lawrence Conroy'" References: <01da01ccf8b8$a535d020$efa17060$@us> <35C11485-CA99-49CB-908A-BF74C4CB24E9@insensate.co.uk> In-Reply-To: <35C11485-CA99-49CB-908A-BF74C4CB24E9@insensate.co.uk> Date: Sat, 3 Mar 2012 10:38:34 -0500 Message-ID: <00a201ccf953$b2842bf0$178c83d0$@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: Acz5PZJQhla2+jLYRieUJpBriFCuhQAFPF7w Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.48.10.220 authed with richard@shockey.us} Cc: 'IETF ENUM list' Subject: Re: [Enum] FW: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 15:38:37 -0000 What's the big deal here. Sure they can clean up some text, but the intent of the process was to make these things simple. This is another Carrier ENUM concept probably in association with RCS or some other scheme. And there are lot more coming. I certainly have no objection to this registration moving forward. FYI I have it on good authority that the meta data issue is coming back. -----Original Message----- From: Lawrence Conroy [mailto:lconroy@insensate.co.uk] Sent: Saturday, March 03, 2012 8:00 AM To: laurentwalter.goix@telecomitalia.it Cc: Richard Shockey; IETF ENUM list Subject: Re: [Enum] FW: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt Hi Laurent-Walter, Richard, folks, As one of the authors of RFC6116, I'm intrigued with section 4 of this draft. AFAICT, section 4 of this draft specifically states that E2U+acct can be used in an entirely different namespace from ENUM. That's an interpretation of 6116 section 2 that I don't recognise. The second paragraph of Section 5 is ambivalent on this, but section 4 spells out that a separate apex may be used. That directly contradicts its example, and in any case the Enumservice template is incorrect for such private use (in that case, it would need to be "limited", not "common" -- see RFC6117 section 5.2.7 **). => Was that intended -- does that first paragraph of section 4 of this draft help? As I understand the second paragraph of section 4, the intention is that an implementation will chase pstn:tel records looking for a domain with an appropriate E2U+acct record. That looks like it's stretching the pstn:tel use given in RFC4769 section 3.1, but ... The last bullet of section 5.5 of RFC6117 states that the registration doc needs to cover loop mitigation. It may be unfair, but RFC4769 was not covered by the current rules, so they dodged the bullet of that requirement. This draft can't, so you will have to spell out the rules for loop mitigation. Merely referring to RFC4694 is not enough; see the last sentence of section 5 of RFC4694. Finally, section 5 mentions an "activity wall". I wonder if anyone will know what that means in 10 years time. It is not mentioned directly in the webfinger draft, so if it's spelt out in the referenced OMA service document, from where can one get that spec? all the best, Lawrence ** [E2U+pstn:tel was registered under the "old" rules; this one is covered by 6117] On 2 Mar 2012, at 21:08, Richard Shockey wrote: > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of internet-drafts@ietf.org > Sent: Friday, March 02, 2012 10:49 AM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : ENUM Service Registration for Social Networking > (SN) Services > Author(s) : Laurent-Walter Goix > Kepeng Li > Filename : draft-goix-appsawg-enum-sn-service-00.txt > Pages : 7 > Date : 2012-03-02 > > This document registers a Telephone Number Mapping (ENUM) service for > Social Networking (SN). Specifically, this document focuses on > provisioning 'acct:' URIs (Uniform Resource Identifiers) in ENUM. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-goix-appsawg-enum-sn-service-00.tx > t > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-goix-appsawg-enum-sn-service-00.txt From lconroy@insensate.co.uk Sat Mar 3 10:09:59 2012 Return-Path: X-Original-To: enum@ietfa.amsl.com Delivered-To: enum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2CD21F8505 for ; Sat, 3 Mar 2012 10:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caqVlNA1DWCG for ; Sat, 3 Mar 2012 10:09:57 -0800 (PST) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by ietfa.amsl.com (Postfix) with ESMTP id ECECA21F84E0 for ; Sat, 3 Mar 2012 10:09:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id E8137590B4F; Sat, 3 Mar 2012 18:09:54 +0000 (GMT) X-Virus-Scanned: amavisd-new at insensate.co.uk Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5m6NOh8tKiM; Sat, 3 Mar 2012 18:09:53 +0000 (GMT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 45309590B44; Sat, 3 Mar 2012 18:09:53 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <00a201ccf953$b2842bf0$178c83d0$@us> Date: Sat, 3 Mar 2012 18:09:53 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1561BE22-A7C2-474E-9C35-D3858661BD56@insensate.co.uk> References: <01da01ccf8b8$a535d020$efa17060$@us> <35C11485-CA99-49CB-908A-BF74C4CB24E9@insensate.co.uk> <00a201ccf953$b2842bf0$178c83d0$@us> To: Richard Shockey X-Mailer: Apple Mail (2.1084) Cc: 'IETF ENUM list' Subject: Re: [Enum] FW: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 18:09:59 -0000 Hi Richard, folks, Um -- yeah? Just in case there was some misunderstanding, neither do I. If someone = wants to use this stuff, bring it on. (considering the welter of stuff I've put into ENUM, I'm hardly in a = position to complain :). I don't think the comments I put in were unreasonable -- these will need = to be fixed, so rather than slow things down later I put in comments on = the ENUM-y bits now. The registration process of 6117 is designed to (i) make the = registration process easier and (ii) cover the bases that need to be = covered so folk can build/use this stuff (not just put it in a document = and forget it). This is one of the first ones through that new process, and its from = apps area/W3C/OMA-led work. Helping folk to ensure it does actually tick = the 6117 boxes is hardly meant to be awkward. all the best from a bemused Lawrence On 3 Mar 2012, at 15:38, Richard Shockey wrote: > What's the big deal here. Sure they can clean up some text, but the = intent > of the process was to make these things simple. This is another = Carrier > ENUM concept probably in association with RCS or some other scheme. = And > there are lot more coming. >=20 > I certainly have no objection to this registration moving forward. >=20 > FYI I have it on good authority that the meta data issue is coming = back. From richard@shockey.us Sat Mar 3 10:25:30 2012 Return-Path: X-Original-To: enum@ietfa.amsl.com Delivered-To: enum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC4421F8678 for ; Sat, 3 Mar 2012 10:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.744 X-Spam-Level: X-Spam-Status: No, score=-100.744 tagged_above=-999 required=5 tests=[AWL=1.751, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GWOxgyJQ74n for ; Sat, 3 Mar 2012 10:25:29 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 71D6C21F864A for ; Sat, 3 Mar 2012 10:25:29 -0800 (PST) Received: (qmail 28744 invoked by uid 0); 3 Mar 2012 18:25:29 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy3.bluehost.com with SMTP; 3 Mar 2012 18:25:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=ARMQFaYwstqw1yj7h36xnrqsQBrF2p65UPc99fEKiJk=; b=kWhCFoB8Lfuu1tvUgaoVsoY1BC++ryz0Kncpqk+qN5g3xZpPPd23m4vPgZkh/O1EEUn/ptk20RDFiQuCzXBcHxAhMNnE1fyneigjOptOoQmrc7UDg85d66cgZpYwfoaU; Received: from pool-108-48-10-220.washdc.fios.verizon.net ([108.48.10.220] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1S3te4-0004Sv-O1; Sat, 03 Mar 2012 11:25:28 -0700 From: "Richard Shockey" To: "'Lawrence Conroy'" References: <01da01ccf8b8$a535d020$efa17060$@us> <35C11485-CA99-49CB-908A-BF74C4CB24E9@insensate.co.uk> <00a201ccf953$b2842bf0$178c83d0$@us> <1561BE22-A7C2-474E-9C35-D3858661BD56@insensate.co.uk> In-Reply-To: <1561BE22-A7C2-474E-9C35-D3858661BD56@insensate.co.uk> Date: Sat, 3 Mar 2012 13:25:28 -0500 Message-ID: <00e601ccf96b$03345540$099cffc0$@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: Acz5aNfWu/dyUH2ATyKw6eYWTAZwNAAAWNQw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.48.10.220 authed with richard@shockey.us} Cc: 'IETF ENUM list' Subject: Re: [Enum] FW: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 18:25:30 -0000 Don't get me wrong. I thought your comments were excellent and completely in line with the intent and letter of 6117. If the authors make these changes than its good to go IMHO. As for MetaData Note mandate for Carrier ENUM. Paragraph 70 http://www.crtc.gc.ca/eng/archive/2012/2012-24.htm -----Original Message----- From: Lawrence Conroy [mailto:lconroy@insensate.co.uk] Sent: Saturday, March 03, 2012 1:10 PM To: Richard Shockey Cc: 'IETF ENUM list' Subject: Re: [Enum] FW: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt Hi Richard, folks, Um -- yeah? Just in case there was some misunderstanding, neither do I. If someone wants to use this stuff, bring it on. (considering the welter of stuff I've put into ENUM, I'm hardly in a position to complain :). I don't think the comments I put in were unreasonable -- these will need to be fixed, so rather than slow things down later I put in comments on the ENUM-y bits now. The registration process of 6117 is designed to (i) make the registration process easier and (ii) cover the bases that need to be covered so folk can build/use this stuff (not just put it in a document and forget it). This is one of the first ones through that new process, and its from apps area/W3C/OMA-led work. Helping folk to ensure it does actually tick the 6117 boxes is hardly meant to be awkward. all the best from a bemused Lawrence On 3 Mar 2012, at 15:38, Richard Shockey wrote: > What's the big deal here. Sure they can clean up some text, but the intent > of the process was to make these things simple. This is another Carrier > ENUM concept probably in association with RCS or some other scheme. And > there are lot more coming. > > I certainly have no objection to this registration moving forward. > > FYI I have it on good authority that the meta data issue is coming back. From peter@denic.de Mon Mar 5 04:51:43 2012 Return-Path: X-Original-To: enum@ietfa.amsl.com Delivered-To: enum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48DF21F86E3 for ; Mon, 5 Mar 2012 04:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05RxXNdqgaEZ for ; Mon, 5 Mar 2012 04:51:43 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 5E44521F865E for ; Mon, 5 Mar 2012 04:51:43 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1S4XOA-0005lN-CT; Mon, 05 Mar 2012 13:51:42 +0100 Received: from localhost by x27.adm.denic.de with local id 1S4XOA-0002Sm-8H; Mon, 05 Mar 2012 13:51:42 +0100 Date: Mon, 5 Mar 2012 13:51:42 +0100 From: Peter Koch To: IETF ENUM list Message-ID: <20120305125142.GG22296@x27.adm.denic.de> Mail-Followup-To: IETF ENUM list References: <2A45B5D5-FEAD-4813-96D3-55FA757ADD8C@insensate.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A45B5D5-FEAD-4813-96D3-55FA757ADD8C@insensate.co.uk> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [Enum] Enumservice registrations X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 12:51:44 -0000 On Sat, Mar 03, 2012 at 12:06:33PM +0000, Lawrence Conroy wrote: > So ... > Can someone ensure at least that I-Ds for Enumservices are ALWAYS/Automatically sent to the enum mailing list? > (i.e., if it's an Enumservice, the enum mailing list is an interested party) i'd suggest not to install any magic or automated action here. Maybe the process wasn't followed, but then we do probably not know what the current status of the draft is. Ideally, it would benefit from review on this list even as a -00, but in that regard there's nothing wrong with further discussion. Automated action would lead to undesired effects and also educate authors in the wrong direction. -Peter From lconroy@insensate.co.uk Mon Mar 5 06:07:30 2012 Return-Path: X-Original-To: enum@ietfa.amsl.com Delivered-To: enum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C7E21F861B for ; Mon, 5 Mar 2012 06:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNwhRnGFyoiS for ; Mon, 5 Mar 2012 06:07:30 -0800 (PST) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by ietfa.amsl.com (Postfix) with ESMTP id 04EBD21F85B7 for ; Mon, 5 Mar 2012 06:07:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 63AA959DC51; Mon, 5 Mar 2012 14:07:23 +0000 (GMT) X-Virus-Scanned: amavisd-new at insensate.co.uk Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A30aML7IMI4z; Mon, 5 Mar 2012 14:07:22 +0000 (GMT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 8211D59DC46; Mon, 5 Mar 2012 14:07:22 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <20120305125142.GG22296@x27.adm.denic.de> Date: Mon, 5 Mar 2012 14:07:22 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2A45B5D5-FEAD-4813-96D3-55FA757ADD8C@insensate.co.uk> <20120305125142.GG22296@x27.adm.denic.de> To: Peter Koch X-Mailer: Apple Mail (2.1084) Cc: IETF ENUM list Subject: Re: [Enum] Enumservice registrations X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 14:07:30 -0000 On 5 Mar 2012, at 12:51, Peter Koch wrote: > On Sat, Mar 03, 2012 at 12:06:33PM +0000, Lawrence Conroy wrote: >> So ... >> Can someone ensure at least that I-Ds for Enumservices are = ALWAYS/Automatically sent to the enum mailing list? >> (i.e., if it's an Enumservice, the enum mailing list is an interested = party) >=20 > i'd suggest not to install any magic or automated action here. Maybe = the process > wasn't followed, but then we do probably not know what the current = status > of the draft is. Ideally, it would benefit from review on this list = even as a -00, > but in that regard there's nothing wrong with further discussion. = Automated action > would lead to undesired effects and also educate authors in the wrong = direction. >=20 > -Peter To which I reply: Hi Peter, Richard, folks, Fair enough. This was *not* a dig at these specific authors -- lord knows I've made = enough mistakes and had drafts not marked for the WG in which they were = being considered, let alone this case where there are two separate = groups that have an interest. I do recall some confusion in the past that was caused by lack of = communication between groups when NAPTRs were being [re-]defined. The URN folk went their way, the ENUM-URI folk went their way with the = SIP folk roughly in allignment, and as for (u)SNAPTRs folk, they were = somewhere else again. I contend that coordination between those groups would have made life = easier for all, and certainly would have led to fewer bugs in ENUM code = from people looking at examples in entirely unrelated drafts (and so = made my life easier). Given that even the best of us (i.e., me :), make mistakes, how that = coordination is arranged at an early enough state to make life easy for = the authors is the trick. Taking your point, automation is the wrong kind of education; = conversely, so are cattle prods. Let's see if this is a common issue (especially with Richard's dark = threats of tilting at the E2MD windmill again). all the best, Lawrence From jon.peterson@neustar.biz Mon Mar 5 15:34:36 2012 Return-Path: X-Original-To: enum@ietfa.amsl.com Delivered-To: enum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC7821E8045 for ; Mon, 5 Mar 2012 15:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.043 X-Spam-Level: X-Spam-Status: No, score=-106.043 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdhG8y1vgtbN for ; Mon, 5 Mar 2012 15:34:35 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id DC78D21F8517 for ; Mon, 5 Mar 2012 15:34:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1330990502; x=1646346262; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=LN6Q4MIvtT8P1i7kL7fQAMj1b4iKWQ+4nQDFZIycNa0=; b=WoMwAETsNDeQh6DjqkdZPtOCym4kAHcAoM8HrJ4KMsclYKs0T6TzQeRealji3F 3Kv7Zglt9BZ1/b6uMVuNRGUw== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.5313396; Mon, 05 Mar 2012 18:35:01 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Mon, 5 Mar 2012 18:34:31 -0500 From: "Peterson, Jon" To: "enum@ietf.org" Date: Mon, 5 Mar 2012 18:34:28 -0500 Thread-Topic: [dispatch] New Proposal for Telephone-Related Queries Thread-Index: Acz7KIM0barbWfHgT5+aMYrRMzALnw== Message-ID: <0127682F-7383-4E94-A6EB-EC91DAA87934@neustar.biz> References: <55A5A9A87506CB4BA580BF9D531957DA239D6332@STNTEXCH01.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: x-ems-stamp: ibyQrCOmhESolL0FF1Yksg== Content-Type: multipart/alternative; boundary="_000_0127682F73834E94A6EBEC91DAA87934neustarbiz_" MIME-Version: 1.0 Subject: [Enum] Fwd: [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 23:34:36 -0000 --_000_0127682F73834E94A6EBEC91DAA87934neustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This proposal may be of interest to the remnants of this working group. Jon Peterson NeuStar, Inc. Begin forwarded message: From: "Peterson, Jon" > Date: March 5, 2012 1:51:00 PM PST To: "dispatch@ietf.org" > Subject: [dispatch] New Proposal for Telephone-Related Queries I have a proposal to bounce off the group. Basically, this is a re-examinat= ion of some of the problems we've previously considered in the telephony-sp= ecific cluster of work surrounding ENUM, DRINKS and SPEERMINT. Through disc= ussions in the past couple years, it's become clear that we would need to s= ignificantly extend ENUM to get it to handle all of the sorts of sources, s= ubjects, and attributes that people want to factor into queries about telep= hone number routing and administration. Most of these discussions have gott= en wrapped around the axle on questions of the underlying syntax and semant= ics of the DNS, which were a good match for the original vision of a public= , user-driven ENUM, but don't seem to be such a good match for the uses peo= ple actually want to make of these protocols, in federated, service-provide= r-driven environments like those envisioned in SPEERMINT and provisioned in= DRINKS. While the discussion may have died down a bit, the requirements th= at motivated th e discussion definitely aren't going away. Rather than continue to debate the applicability of the DNS and the probity= of various extensions to it, we might make more progress if we work toward= s agreement on the semantics of queries for telephone-related data independ= ently of any underlying protocols. In other words, focus on what kinds of q= uestions about telephone numbers we want to be able to ask, and what kinds = of information needs to go into the answers, and incorporate all this into = an abstract data model. So for example, we know that we want to be able to = express the source of a request in a query. What do we mean by source? I ca= n think of a bunch of different kinds of source: the logical originator of = the query (the administrative entity asking), the logical identity of any i= ntermediary or aggregator forwarding the query, or even the point at the ne= twork from which the call originates (the originating trunk group, SBC or w= hat have you). All three of those concepts of source seem important when it= comes to answe ring questions about telephone numbers, so a data model would treat those a= s separate elements which can vary independently - then we can then try to = figure out what's mandatory or optional, etc. We follow this same method fo= r all the elements of queries and responses. Figure out what the attributes= are of telephone numbers that we care about, sort them into buckets of rou= ting data and administrative data, and so on. Once we have an agreement on the data model, then people can map the model = to whatever underlying protocol they'd like - or just build it into a web A= PI, or what have you. Those proposals could advance as separate documents. = Having that flexibility would make it a lot easier to figure out what we re= ally want the questions and answers to be, rather than thinking about what = they realistically can be within the constraints of some existing underlyin= g protocol. That's the idea. I'm not going to present a proposed charter for work or an= ything like that in Paris, but I am interested in hearing if people think t= his is a promising approach, and if so, perhaps we'd put a charter on the a= genda for Vancouver. I have however submitted a -00 draft for this time whi= ch gives a high-level proposal for a data model and at least enumerates wha= t some of the elements might be that would be populated in queries and resp= onses. This is a pretty broad sketch, but it should convey the basic idea. = You can check it out here: https://datatracker.ietf.org/doc/draft-peterson-terq/ Any thoughts about the direction or the specifics of the data model are wel= come. Thanks! Jon Peterson NeuStar, Inc. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_0127682F73834E94A6EBEC91DAA87934neustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This propos= al may be of interest to the remnants of this working group.

=
Jon Peterson
NeuStar, Inc.

Begin forwarded = message:

From: "Peterson, Jon" <jon.peterson@neustar.biz>
Date: March 5, 2012 1:51:00 PM PST
Subject: [dispatch] New Proposal for Telepho= ne-Related Queries


I have a proposal to bo= unce off the group. Basically, this is a re-examination of some of the prob= lems we've previously considered in the telephony-specific cluster of work = surrounding ENUM, DRINKS and SPEERMINT. Through discussions in the past cou= ple years, it's become clear that we would need to significantly extend ENU= M to get it to handle all of the sorts of sources, subjects, and attributes= that people want to factor into queries about telephone number routing and= administration. Most of these discussions have gotten wrapped around the a= xle on questions of the underlying syntax and semantics of the DNS, which w= ere a good match for the original vision of a public, user-driven ENUM, but= don't seem to be such a good match for the uses people actually want to ma= ke of these protocols, in federated, service-provider-driven environments l= ike those envisioned in SPEERMINT and provisioned in DRINKS. While the disc= ussion may have died down a bit, the requirements that motivated th
e d= iscussion definitely aren't going away.

Rather than continue to deba= te the applicability of the DNS and the probity of various extensions to it= , we might make more progress if we work towards agreement on the semantics= of queries for telephone-related data independently of any underlying prot= ocols. In other words, focus on what kinds of questions about telephone num= bers we want to be able to ask, and what kinds of information needs to go i= nto the answers, and incorporate all this into an abstract data model. So f= or example, we know that we want to be able to express the source of a requ= est in a query. What do we mean by source? I can think of a bunch of differ= ent kinds of source: the logical originator of the query (the administrativ= e entity asking), the logical identity of any intermediary or aggregator fo= rwarding the query, or even the point at the network from which the call or= iginates (the originating trunk group, SBC or what have you). All three of = those concepts of source seem important when it comes to answe
ring que= stions about telephone numbers, so a data model would treat those as separa= te elements which can vary independently - then we can then try to figure o= ut what's mandatory or optional, etc. We follow this same method for all th= e elements of queries and responses. Figure out what the attributes are of = telephone numbers that we care about, sort them into buckets of routing dat= a and administrative data, and so on.

Once we have an agreement on t= he data model, then people can map the model to whatever underlying protoco= l they'd like - or just build it into a web API, or what have you. Those pr= oposals could advance as separate documents. Having that flexibility would = make it a lot easier to figure out what we really want the questions and an= swers to be, rather than thinking about what they realistically can be with= in the constraints of some existing underlying protocol.

That's the = idea. I'm not going to present a proposed charter for work or anything like= that in Paris, but I am interested in hearing if people think this is a pr= omising approach, and if so, perhaps we'd put a charter on the agenda for V= ancouver. I have however submitted a -00 draft for this time which gives a = high-level proposal for a data model and at least enumerates what some of t= he elements might be that would be populated in queries and responses. This= is a pretty broad sketch, but it should convey the basic idea. You can che= ck it out here:

https://datatracker.ietf.org/doc/draft-pet= erson-terq/

Any thoughts a= bout the direction or the specifics of the data model are welcome. Thanks!<= br>
Jon Peterson
NeuStar, Inc.
___________________________________= ____________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch<= br>

= --_000_0127682F73834E94A6EBEC91DAA87934neustarbiz_-- From laurentwalter.goix@telecomitalia.it Mon Mar 5 09:13:10 2012 Return-Path: X-Original-To: enum@ietfa.amsl.com Delivered-To: enum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8DF21F886E; Mon, 5 Mar 2012 09:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8cUqJ8LFM0i; Mon, 5 Mar 2012 09:13:09 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 198EA21F886C; Mon, 5 Mar 2012 09:13:08 -0800 (PST) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 5 Mar 2012 18:13:06 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Mon, 5 Mar 2012 18:13:06 +0100 From: Goix Laurent Walter To: Bernie Hoeneisen , Lawrence Conroy Date: Mon, 5 Mar 2012 18:13:04 +0100 Thread-Topic: [apps-discuss] [Enum] Enumservice registrations Thread-Index: Acz5PoDYAF2r5NokSzu5qkZOyao4lwBtEpGw Message-ID: References: <2A45B5D5-FEAD-4813-96D3-55FA757ADD8C@insensate.co.uk> In-Reply-To: Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 06 Mar 2012 08:05:51 -0800 Cc: IETF ENUM list , Marocco Enrico , Gonzalo Camarillo , "apps-discuss@ietf.org" , Likepeng Subject: [Enum] R: [apps-discuss] Enumservice registrations X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 17:13:10 -0000 Thank you Bernie and Lawrence for the exhaustive comments. The notification= to the enum list (and its first feedback) was faster than expected... We will produce a revision accordingly and based on other comments we recei= ve. Cheers walter -----Messaggio originale----- Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Pe= r conto di Bernie Hoeneisen Inviato: sabato 3 marzo 2012 14.07 A: Lawrence Conroy Cc: IETF ENUM list; Gonzalo Camarillo; apps-discuss@ietf.org Oggetto: Re: [apps-discuss] [Enum] Enumservice registrations Hi Lawrence Thanks for sharing your view on the Enumservice registration process wrt. draft-goix-appsawg-enum-sn-service-00.txt. And thanks Rich for spotting this I/D and forwarding it to the ENUM list. It appears to me that the authors simply have not read RFC 6117 too thoroughly, and therefore don't follow the RFC-6117-process. However, I am not worried at this point in time, as the I/D is a -00 individual submission. Furthermore, before any Enumservice advances, it has to go through my hands, and I will ensure each proposal gets sufficient community review (in particular ENUM community), before any decision is made. Thus, not-follow-the-process simply results in delay, which the authors otherwise could avoid. Should I happen to meet the authors in Paris, I'll talk to them about this. I hope this addresses your concerns. cheers, Bernie, IESG Designated Expert for ENUM PS: And no, we are not intending to update RFC 6117 any time soon... ;-) -- http://ucom.ch/ Tech Consulting for Internet Technology On Sat, 3 Mar 2012, Lawrence Conroy wrote: > Hi esteemed AD, ENUMers, > As a process issue: > - Section 4.1 of RFC6117 suggests that authors of Enumservices should > look for existing work in the Enum mailing list. > - Section 6.3 of RFC6117 states that authors MUST send a mail to the > enum list with a link to the registration doc. > > In the current case, Richard forwarded the id-announce mail for > draft-goix-appsawg-enum-sn-service-00.txt to the list; the authors have > not. > > So ... > Can someone ensure at least that I-Ds for Enumservices are > ALWAYS/Automatically sent to the enum mailing list? (i.e., if it's an > Enumservice, the enum mailing list is an interested party) > > The application detail for Enumservices may well be covered in other > WGs, but there must be a link the ENUM mailing list. Otherwise 6117 > needs an update -- please, no! > > all the best, > Lawrence > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum > _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From richard@shockey.us Tue Mar 6 09:08:21 2012 Return-Path: X-Original-To: enum@ietfa.amsl.com Delivered-To: enum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A59021F87A9 for ; Tue, 6 Mar 2012 09:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOPw+FHNeT8g for ; Tue, 6 Mar 2012 09:08:21 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 6CF2921F87BA for ; Tue, 6 Mar 2012 09:08:18 -0800 (PST) Received: (qmail 1362 invoked by uid 0); 6 Mar 2012 17:08:16 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy3.bluehost.com with SMTP; 6 Mar 2012 17:08:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=+zqwqo8ry+DSJf/Tbmvar9zQWvXBG713nqpP0vHmgzM=; b=BWdZvaNLWALyQZ3sCRbdBJqBvP+/ODTMX3vWqRJk0T64Woik6p4ViEBGzRivRxLdo8J/zmv5YOvHbYRjMDI+BG+lWI3YzkMFAQMuCBoXcnxPOh/q4NAI4sq0PpuC8pvd; Received: from host249-111.cablelabs.com ([192.160.73.249] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1S4xrz-0005z6-3e; Tue, 06 Mar 2012 10:08:15 -0700 From: "Richard Shockey" To: "'Peterson, Jon'" , References: <55A5A9A87506CB4BA580BF9D531957DA23914ED0@STNTEXCH01.cis.neustar.com> In-Reply-To: <55A5A9A87506CB4BA580BF9D531957DA23914ED0@STNTEXCH01.cis.neustar.com> Date: Tue, 6 Mar 2012 12:08:13 -0500 Message-ID: <01e501ccfbbb$b8af8af0$2a0ea0d0$@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: AQHM+xQ7UaE2MYlCb0+6Ly0bNplLX5ZcQduAgAE4D9A= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 192.160.73.249 authed with richard@shockey.us} Cc: 'IETF ENUM list' Subject: Re: [Enum] [dispatch] New Proposal for Telephone-Related Queries X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 17:08:21 -0000 I think this a perfectly reasonable proposal. I'd like to see it move forward. It would be useful not to get into any Layer 10 issues of what people have used 6116 for. The simple fact is that its there, it scales, its fully deployed in private instantiations in major carrier networks and is baked into multiple NNI profiles. That said we know two things. 6116 has limitations due to its use of underlying DNS technology. Jon is right that the problem of determinate response based on source of the query in DNS has forced us to look at some duct tape and wire solutions that may be sub optimal. Though source-URI does work. Speaking of Layer 9, the other issue is phone numbers are not going away and any transition from POTS to FOO is going to have to deal with multiple types of data associated with those identifiers. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Monday, March 05, 2012 5:05 PM To: 'dispatch@ietf.org' Subject: Re: [dispatch] New Proposal for Telephone-Related Queries Oops, sorry, my mailer did not like the URL I submitted. The correct URL for the draft is: https://datatracker.ietf.org/doc/draft-peterson-terq/ Jon Peterson Neustar, Inc. -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Monday, March 05, 2012 04:51 PM Eastern Standard Time To: dispatch@ietf.org Subject: [dispatch] New Proposal for Telephone-Related Queries I have a proposal to bounce off the group. Basically, this is a re-examination of some of the problems we've previously considered in the telephony-specific cluster of work surrounding ENUM, DRINKS and SPEERMINT. Through discussions in the past couple years, it's become clear that we would need to significantly extend ENUM to get it to handle all of the sorts of sources, subjects, and attributes that people want to factor into queries about telephone number routing and administration. Most of these discussions have gotten wrapped around the axle on questions of the underlying syntax and semantics of the DNS, which were a good match for the original vision of a public, user-driven ENUM, but don't seem to be such a good match for the uses people actually want to make of these protocols, in federated, service-provider-driven environments like those envisioned in SPEERMINT and provisioned in DRINKS. While the discussion may have died down a bit, the requirements that motivated th e discussion definitely aren't going away. Rather than continue to debate the applicability of the DNS and the probity of various extensions to it, we might make more progress if we work towards agreement on the semantics of queries for telephone-related data independently of any underlying protocols. In other words, focus on what kinds of questions about telephone numbers we want to be able to ask, and what kinds of information needs to go into the answers, and incorporate all this into an abstract data model. So for example, we know that we want to be able to express the source of a request in a query. What do we mean by source? I can think of a bunch of different kinds of source: the logical originator of the query (the administrative entity asking), the logical identity of any intermediary or aggregator forwarding the query, or even the point at the network from which the call originates (the originating trunk group, SBC or what have you). All three of those concepts of source seem important when it comes to answe ring questions about telephone numbers, so a data model would treat those as separate elements which can vary independently - then we can then try to figure out what's mandatory or optional, etc. We follow this same method for all the elements of queries and responses. Figure out what the attributes are of telephone numbers that we care about, sort them into buckets of routing data and administrative data, and so on. Once we have an agreement on the data model, then people can map the model to whatever underlying protocol they'd like - or just build it into a web API, or what have you. Those proposals could advance as separate documents. Having that flexibility would make it a lot easier to figure out what we really want the questions and answers to be, rather than thinking about what they realistically can be within the constraints of some existing underlying protocol. That's the idea. I'm not going to present a proposed charter for work or anything like that in Paris, but I am interested in hearing if people think this is a promising approach, and if so, perhaps we'd put a charter on the agenda for Vancouver. I have however submitted a -00 draft for this time which gives a high-level proposal for a data model and at least enumerates what some of the elements might be that would be populated in queries and responses. This is a pretty broad sketch, but it should convey the basic idea. You can check it out here: https://exchcas.va.neustar.com/owa/thoughts about the direction or the specifics of the data model are welcome. Thanks! Jon Peterson NeuStar, Inc. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From bernie@ietf.hoeneisen.ch Sun Mar 11 13:21:36 2012 Return-Path: X-Original-To: enum@ietfa.amsl.com Delivered-To: enum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9C721F86C6; Sun, 11 Mar 2012 13:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pc1DZiWQjl5Y; Sun, 11 Mar 2012 13:21:35 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by ietfa.amsl.com (Postfix) with ESMTP id EC88A21F86AD; Sun, 11 Mar 2012 13:21:34 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.71) (envelope-from ) id 1S6pGn-00024P-CT; Sun, 11 Mar 2012 21:21:33 +0100 Date: Sun, 11 Mar 2012 21:21:33 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: IETF ENUM 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 Cc: apps-discuss@ietf.org Subject: [Enum] New Version Notification for draft-hoeneisen-rfc5333bis-01.txt (fwd) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 20:21:37 -0000 FYI ---------- Forwarded message ---------- Date: Sun, 11 Mar 2012 21:18:32 From: internet-drafts@ietf.org To: bernie@ietf.hoeneisen.ch Subject: New Version Notification for draft-hoeneisen-rfc5333bis-01.txt A new version of I-D, draft-hoeneisen-rfc5333bis-01.txt has been successfully submitted by Bernie Hoeneisen and posted to the IETF repository. Filename: draft-hoeneisen-rfc5333bis Revision: 01 Title: IANA Registration of Enumservices for Internet Calendaring Creation date: 2012-03-11 WG ID: Individual Submission Number of pages: 20 Abstract: This document registers and obsoletes Enumservices for Internet calendaring. Specifically, this document focuses on Enumservices for iMIP (iCalendar Message-Based Interoperability Protocol), CalDAV (Calendaring Extensions to WebDAV), and iSchedule (Internet Calendar Scheduling Protocol). -- http://ucom.ch/ Tech Consulting for Internet Technology From laurentwalter.goix@telecomitalia.it Wed Mar 21 09:45:04 2012 Return-Path: X-Original-To: enum@ietfa.amsl.com Delivered-To: enum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F18121E8087 for ; Wed, 21 Mar 2012 09:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.776 X-Spam-Level: X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLx6AaHL4h+B for ; Wed, 21 Mar 2012 09:45:03 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id C019B21E805D for ; Wed, 21 Mar 2012 09:45:02 -0700 (PDT) Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 21 Mar 2012 17:44:59 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Wed, 21 Mar 2012 17:44:59 +0100 From: Goix Laurent Walter To: Lawrence Conroy Date: Wed, 21 Mar 2012 17:44:57 +0100 Thread-Topic: [Enum] FW: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt Thread-Index: Acz5PZKOmAsKt8qTRaKW9euiLoSs9AOP7MmQ Message-ID: References: <01da01ccf8b8$a535d020$efa17060$@us> <35C11485-CA99-49CB-908A-BF74C4CB24E9@insensate.co.uk> In-Reply-To: <35C11485-CA99-49CB-908A-BF74C4CB24E9@insensate.co.uk> Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF ENUM list , "likepeng@huawei.com" Subject: [Enum] R: FW: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 16:45:04 -0000 Hello lawrence, all, I'd like to resume the discussion on the draft in this list, as at this sta= ge it seems more appropriate. I could see that a couple of points (mostly in section 4) have triggered so= me concerns that I'd like to clarify and seek for your guidance: - the first paragraph of section 4, despite its poor wording, wants t= o point out that this service may be *also* used in enum "infrastructures" = other than "e164.arpa", for example in cases where such infrastructure is r= estricted to CSPs (e.g. "e164.gprs" or others). My feeling is that rfc6116 = does mentions this possibility somehow (e.g. see section 3.6) but I can't f= ind a clear section where to refer to more formally (I agree that the refer= ence to section 2 was a bad choice for it). Is there any other reference th= at could be used for this? - regarding loop mitigation it was my intention to address it in para= graph 2 of section 4, but the wording was not appropriate neither (and I re= alized there is no clear mention on when the process should stop). The inte= ntion here would be to clarify that if no "acct" record is found, subsequen= t enum queries could apply recursively to any e164 number found in records = containing tel URIs independently from the specific service, still aiming a= t identifying an "acct" uri. I could further imagine that the idea to mitig= ate loops would be based on rfc4759 principles so that when the same number= is found, or another one containing a dip indicator the recursion should b= e stopped and the process considered completed with no acct uri found. Do y= ou have any recommendation based on your experience of similar enum service= s? Thank you Walter -----Messaggio originale----- Da: Lawrence Conroy [mailto:lconroy@insensate.co.uk] Inviato: sabato 3 marzo 2012 14.00 A: Goix Laurent Walter Cc: Richard Shockey; IETF ENUM list Oggetto: Re: [Enum] FW: I-D Action: draft-goix-appsawg-enum-sn-service-00.t= xt Hi Laurent-Walter, Richard, folks, As one of the authors of RFC6116, I'm intrigued with section 4 of this dra= ft. AFAICT, section 4 of this draft specifically states that E2U+acct can be us= ed in an entirely different namespace from ENUM. That's an interpretation o= f 6116 section 2 that I don't recognise. The second paragraph of Section 5 is ambivalent on this, but section 4 spel= ls out that a separate apex may be used. That directly contradicts its example, and in any case the Enumservice temp= late is incorrect for such private use (in that case, it would need to be "= limited", not "common" -- see RFC6117 section 5.2.7 **). =3D> Was that intended -- does that first paragraph of section 4 of this dr= aft help? As I understand the second paragraph of section 4, the intention is that an= implementation will chase pstn:tel records looking for a domain with an ap= propriate E2U+acct record. That looks like it's stretching the pstn:tel use= given in RFC4769 section 3.1, but ... The last bullet of section 5.5 of RFC6117 states that the registration doc = needs to cover loop mitigation. It may be unfair, but RFC4769 was not covered by the current rules, so they= dodged the bullet of that requirement. This draft can't, so you will have to spell out the rules for loop mitigati= on. Merely referring to RFC4694 is not enough; see the last sentence of section= 5 of RFC4694. Finally, section 5 mentions an "activity wall". I wonder if anyone will kno= w what that means in 10 years time. It is not mentioned directly in the webfinger draft, so if it's spelt out i= n the referenced OMA service document, from where can one get that spec? all the best, Lawrence ** [E2U+pstn:tel was registered under the "old" rules; this one is covered = by 6117] On 2 Mar 2012, at 21:08, Richard Shockey wrote: > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] > On Behalf Of internet-drafts@ietf.org > Sent: Friday, March 02, 2012 10:49 AM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : ENUM Service Registration for Social Networking > (SN) Services > Author(s) : Laurent-Walter Goix > Kepeng Li > Filename : draft-goix-appsawg-enum-sn-service-00.txt > Pages : 7 > Date : 2012-03-02 > > This document registers a Telephone Number Mapping (ENUM) service for > Social Networking (SN). Specifically, this document focuses on > provisioning 'acct:' URIs (Uniform Resource Identifiers) in ENUM. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-goix-appsawg-enum-sn-service-00= .tx > t > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-goix-appsawg-enum-sn-service-00.= txt Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From lconroy@insensate.co.uk Mon Mar 26 07:30:00 2012 Return-Path: X-Original-To: enum@ietfa.amsl.com Delivered-To: enum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91DC21E80A1 for ; Mon, 26 Mar 2012 07:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.317 X-Spam-Level: X-Spam-Status: No, score=-1.317 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_05=-1.11, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mDDF5yugcEf for ; Mon, 26 Mar 2012 07:29:59 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by ietfa.amsl.com (Postfix) with ESMTP id EFE8321E8096 for ; Mon, 26 Mar 2012 07:29:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 33D6D636CF2; Mon, 26 Mar 2012 15:29:57 +0100 (BST) X-Virus-Scanned: amavisd-new at insensate.co.uk Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPYXCUQGNvh8; Mon, 26 Mar 2012 15:29:55 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 151F9636CE7; Mon, 26 Mar 2012 15:29:54 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: Date: Mon, 26 Mar 2012 15:29:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8F408DE1-00A8-414E-9A41-1E09ED4B0685@insensate.co.uk> References: <01da01ccf8b8$a535d020$efa17060$@us> <35C11485-CA99-49CB-908A-BF74C4CB24E9@insensate.co.uk> To: Goix Laurent Walter X-Mailer: Apple Mail (2.1084) Cc: IETF ENUM list , "likepeng@huawei.com" Subject: Re: [Enum] R: FW: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 14:30:00 -0000 Hi Walter, folks, - Hmm ... to spell this out: see RFC6116, section 3, para.2, 2nd sentence, parenthetic phrase; ENUM = use is within the e164.arpa apex. =3D> please don't cover different apexes in an ENUM spec; remove section 4 para 1 of your draft entirely as it does't help, and = it DOES hinder. =3D> Likewise, the last sentence of section 5, paragraph 2 doesn't = appear to help. This security mechanism would require changing the position of groups = of regulators, potentially the esteemed members of ITU study groups, and would take = years to arrange; boiling the ocean would be easier. Re. the implied question on RFC 6116;=20 6116, section 3.6 talks about ENUM use in networks that are not = directly connected to the Internet; the assumption is that these closed networks would/could still use = e164.arpa, but with a private root. There's nothing stopping a CSP or anyone deploying NAPTRs holding = ENUM-specified Enumservices inside any apex; this is spelt out in (for example) the *Informational* RFC 5526. - Re. loop control -- 6116 section 5.2.1, paragraphs 6&7&8 (and before = it RFC5483) already gives one way to do loop mitigation for non-terminal = NAPTRs (basically, count to 5 and give up). However, now you have explained your section 4, para 2, this looks = like it will need quite a bit of work to be a detailed and clear = specification; (so clients can behave the same way). Right now, I'm not sure if and how this would work whilst keeping = within the processing rules of the ENUM specification (i.e. 6116 plus = 340x). Is it really useful to include this recursive behaviour? Personally I would discard section 4, paragraph 2 as well, and forget = about standardising complex behaviour that seems to be outside the ENUM = protocol spec. In summary, lose section 4, para.1 and the last sentence of section 5, = para.2. Then, if you really, really, really want to go there, work out what = clients that understand this Enumservice are supposed to do if there are = no ENUM NAPTRs with acct Enumservice (as that functional specification = would seem to be needed by rfc6117 section 3.1). Otherwise, remove the = proposed "recursive behaviour" by removing section 4 para 2. all the best, Lawrence On 21 Mar 2012, at 16:44, Goix Laurent Walter wrote: > Hello lawrence, all, >=20 > I'd like to resume the discussion on the draft in this list, as at = this stage it seems more appropriate. >=20 > I could see that a couple of points (mostly in section 4) have = triggered some concerns that I'd like to clarify and seek for your = guidance: >=20 > - the first paragraph of section 4, despite its poor wording, = wants to point out that this service may be *also* used in enum = "infrastructures" other than "e164.arpa", for example in cases where = such infrastructure is restricted to CSPs (e.g. "e164.gprs" or others). = My feeling is that rfc6116 does mentions this possibility somehow (e.g. = see section 3.6) but I can't find a clear section where to refer to more = formally (I agree that the reference to section 2 was a bad choice for = it). Is there any other reference that could be used for this? >=20 > - regarding loop mitigation it was my intention to address it in = paragraph 2 of section 4, but the wording was not appropriate neither = (and I realized there is no clear mention on when the process should = stop). The intention here would be to clarify that if no "acct" record = is found, subsequent enum queries could apply recursively to any e164 = number found in records containing tel URIs independently from the = specific service, still aiming at identifying an "acct" uri. I could = further imagine that the idea to mitigate loops would be based on = rfc4759 principles so that when the same number is found, or another one = containing a dip indicator the recursion should be stopped and the = process considered completed with no acct uri found. Do you have any = recommendation based on your experience of similar enum services? >=20 > Thank you > Walter >=20 >=20 > -----Messaggio originale----- > Da: Lawrence Conroy [mailto:lconroy@insensate.co.uk] > Inviato: sabato 3 marzo 2012 14.00 > A: Goix Laurent Walter > Cc: Richard Shockey; IETF ENUM list > Oggetto: Re: [Enum] FW: I-D Action: = draft-goix-appsawg-enum-sn-service-00.txt >=20 > Hi Laurent-Walter, Richard, folks, > As one of the authors of RFC6116, I'm intrigued with section 4 of this = draft. >=20 > AFAICT, section 4 of this draft specifically states that E2U+acct can = be used in an entirely different namespace from ENUM. That's an = interpretation of 6116 section 2 that I don't recognise. >=20 > The second paragraph of Section 5 is ambivalent on this, but section 4 = spells out that a separate apex may be used. > That directly contradicts its example, and in any case the Enumservice = template is incorrect for such private use (in that case, it would need = to be "limited", not "common" -- see RFC6117 section 5.2.7 **). > =3D> Was that intended -- does that first paragraph of section 4 of = this draft help? >=20 > As I understand the second paragraph of section 4, the intention is = that an implementation will chase pstn:tel records looking for a domain = with an appropriate E2U+acct record. That looks like it's stretching the = pstn:tel use given in RFC4769 section 3.1, but ... >=20 > The last bullet of section 5.5 of RFC6117 states that the registration = doc needs to cover loop mitigation. > It may be unfair, but RFC4769 was not covered by the current rules, so = they dodged the bullet of that requirement. > This draft can't, so you will have to spell out the rules for loop = mitigation. > Merely referring to RFC4694 is not enough; see the last sentence of = section 5 of RFC4694. >=20 > Finally, section 5 mentions an "activity wall". I wonder if anyone = will know what that means in 10 years time. > It is not mentioned directly in the webfinger draft, so if it's spelt = out in the referenced OMA service document, from where can one get that = spec? >=20 > all the best, > Lawrence > ** [E2U+pstn:tel was registered under the "old" rules; this one is = covered by 6117] >=20 >=20 > On 2 Mar 2012, at 21:08, Richard Shockey wrote: >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] >> On Behalf Of internet-drafts@ietf.org >> Sent: Friday, March 02, 2012 10:49 AM >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>=20 >> Title : ENUM Service Registration for Social = Networking >> (SN) Services >> Author(s) : Laurent-Walter Goix >> Kepeng Li >> Filename : draft-goix-appsawg-enum-sn-service-00.txt >> Pages : 7 >> Date : 2012-03-02 >>=20 >> This document registers a Telephone Number Mapping (ENUM) service = for >> Social Networking (SN). Specifically, this document focuses on >> provisioning 'acct:' URIs (Uniform Resource Identifiers) in ENUM. >>=20 >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-goix-appsawg-enum-sn-service-00.= tx >> t >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> = ftp://ftp.ietf.org/internet-drafts/draft-goix-appsawg-enum-sn-service-00.t= xt >=20 >=20 > Questo messaggio e i suoi allegati sono indirizzati esclusivamente = alle persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie. >=20 > This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks. >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum From laurentwalter.goix@telecomitalia.it Tue Mar 27 09:54:06 2012 Return-Path: X-Original-To: enum@ietfa.amsl.com Delivered-To: enum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E9A21E80CF for ; Tue, 27 Mar 2012 09:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.232 X-Spam-Level: X-Spam-Status: No, score=-0.232 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2GVAE3piitA for ; Tue, 27 Mar 2012 09:54:05 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id A54E921E80A4 for ; Tue, 27 Mar 2012 09:53:43 -0700 (PDT) Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 27 Mar 2012 18:53:33 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Tue, 27 Mar 2012 18:53:33 +0200 From: Goix Laurent Walter To: Lawrence Conroy Date: Tue, 27 Mar 2012 18:53:31 +0200 Thread-Topic: [Enum] R: FW: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt Thread-Index: Ac0LXPSbpPO/zzYuTwuH/PGJJ5+tQQA2p+Ow Message-ID: References: <01da01ccf8b8$a535d020$efa17060$@us> <35C11485-CA99-49CB-908A-BF74C4CB24E9@insensate.co.uk> <8F408DE1-00A8-414E-9A41-1E09ED4B0685@insensate.co.uk> In-Reply-To: <8F408DE1-00A8-414E-9A41-1E09ED4B0685@insensate.co.uk> Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF ENUM list , "likepeng@huawei.com" Subject: [Enum] R: R: FW: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 16:54:06 -0000 Thank you lawrence for your accurate feedback, [snip] - Hmm ... to spell this out: see RFC6116, section 3, para.2, 2nd sentence, parenthetic phrase; ENUM us= e is within the e164.arpa apex. =3D> please don't cover different apexes in an ENUM spec; remove section 4 para 1 of your draft entirely as it does't help, and it= DOES hinder. =3D> Likewise, the last sentence of section 5, paragraph 2 doesn't appear t= o help. This security mechanism would require changing the position of groups of= regulators, potentially the esteemed members of ITU study groups, and would take yea= rs to arrange; boiling the ocean would be easier. Re. the implied question on RFC 6116; 6116, section 3.6 talks about ENUM use in networks that are not directly = connected to the Internet; the assumption is that these closed networks would/could still use e164.a= rpa, but with a private root. There's nothing stopping a CSP or anyone deploying NAPTRs holding ENUM-sp= ecified Enumservices inside any apex; this is spelt out in (for example) the *Informational* RFC 5526. [walter] ok I got your point and will update removing the references you po= inted you - Re. loop control -- 6116 section 5.2.1, paragraphs 6&7&8 (and before it R= FC5483) already gives one way to do loop mitigation for non-terminal NAPTRs (basically, count to 5 and give up). However, now you have explained your section 4, para 2, this looks like i= t will need quite a bit of work to be a detailed and clear specification; (so clients can behave the same way). Right now, I'm not sure if and how this would work whilst keeping within = the processing rules of the ENUM specification (i.e. 6116 plus 340x). Is it really useful to include this recursive behaviour? Personally I would discard section 4, paragraph 2 as well, and forget abo= ut standardising complex behaviour that seems to be outside the ENUM protoc= ol spec. [walter] i tried to better capture the loop mitigation process in the follo= wing text for section 4: " If no "E2U+sn" NAPTR record exist for the requested number, the resolutio= n process over issuing ENUM queries may be recursively performed over E.164= numbers identified by other NAPTR records for the requested number pointin= g to "tel" URIs [RFC3966]. Whilst this process is useful to support, amongs= t others, number portability as per [RFC4769], Section 4., this may also cr= eate potential loops in this resolution process. As such ENUM clients perfo= rming such ENUM queries over "tel" URIs to identify "acct" URIs SHOULD unde= rstand the "enumdi" indicator defined in [RFC4759]. In particular, if the r= esult of the query does not include "E2U+sn" NAPTR records, and includes a = NAPTR resource record containing a "tel" URI that has the same E.164 number= , or a "tel" URI with the "enumdi" parameter set, that client SHOULD NOT pe= rform subsequent ENUM queries over such numbers and SHOULD consider that th= e original requested number cannot be mapped. Furthermore the client MAY stop performing subsequent ENUM queries after= the fifth recursive query as suggested in [RFC6116] section 5.2.1." I would appreciate any further feedback on this proposal or other aspects o= f the draft. Thank you walter Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From laurentwalter.goix@telecomitalia.it Fri Mar 30 03:46:09 2012 Return-Path: X-Original-To: enum@ietfa.amsl.com Delivered-To: enum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6F321F867F for ; Fri, 30 Mar 2012 03:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+9uHzWcgXrc for ; Fri, 30 Mar 2012 03:46:08 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id DADB221F8643 for ; Fri, 30 Mar 2012 03:46:07 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 30 Mar 2012 12:46:03 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Fri, 30 Mar 2012 12:46:03 +0200 From: Goix Laurent Walter To: Lawrence Conroy Date: Fri, 30 Mar 2012 12:46:00 +0200 Thread-Topic: Draft enum webfinger revised Thread-Index: Ac0LXPSbpPO/zzYuTwuH/PGJJ5+tQQDBDa5g Message-ID: References: <01da01ccf8b8$a535d020$efa17060$@us> <35C11485-CA99-49CB-908A-BF74C4CB24E9@insensate.co.uk> <8F408DE1-00A8-414E-9A41-1E09ED4B0685@insensate.co.uk> In-Reply-To: <8F408DE1-00A8-414E-9A41-1E09ED4B0685@insensate.co.uk> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF ENUM list , "likepeng@huawei.com" Subject: [Enum] Draft enum webfinger revised X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 10:46:09 -0000 Hello Lawrence, all, I have just submitted a revision of the enum draft for webfinger based on t= he various feedback received so far. You can find it at [1]. Comments are welcome. Walter [1] http://tools.ietf.org/html/draft-goix-appsawg-enum-sn-service-01=20 -----Messaggio originale----- Da: Lawrence Conroy [mailto:lconroy@insensate.co.uk]=20 Inviato: luned=EC 26 marzo 2012 16.30 A: Goix Laurent Walter Cc: IETF ENUM list; likepeng@huawei.com Oggetto: Re: [Enum] R: FW: I-D Action: draft-goix-appsawg-enum-sn-service-0= 0.txt Hi Walter, folks, - Hmm ... to spell this out: see RFC6116, section 3, para.2, 2nd sentence, parenthetic phrase; ENUM us= e is within the e164.arpa apex. =3D> please don't cover different apexes in an ENUM spec; remove section 4 para 1 of your draft entirely as it does't help, and it= DOES hinder. =3D> Likewise, the last sentence of section 5, paragraph 2 doesn't appear t= o help. This security mechanism would require changing the position of groups of= regulators, potentially the esteemed members of ITU study groups, and would take yea= rs to arrange; boiling the ocean would be easier. Re. the implied question on RFC 6116;=20 6116, section 3.6 talks about ENUM use in networks that are not directly = connected to the Internet; the assumption is that these closed networks would/could still use e164.a= rpa, but with a private root. There's nothing stopping a CSP or anyone deploying NAPTRs holding ENUM-sp= ecified Enumservices inside any apex; this is spelt out in (for example) the *Informational* RFC 5526. - Re. loop control -- 6116 section 5.2.1, paragraphs 6&7&8 (and before it R= FC5483) already gives one way to do loop mitigation for non-terminal NAPTRs (basically, count to 5 and give up). However, now you have explained your section 4, para 2, this looks like i= t will need quite a bit of work to be a detailed and clear specification; (so clients can behave the same way). Right now, I'm not sure if and how this would work whilst keeping within = the processing rules of the ENUM specification (i.e. 6116 plus 340x). Is it really useful to include this recursive behaviour? Personally I would discard section 4, paragraph 2 as well, and forget abo= ut standardising complex behaviour that seems to be outside the ENUM protoc= ol spec. In summary, lose section 4, para.1 and the last sentence of section 5, para= .2. Then, if you really, really, really want to go there, work out what clients= that understand this Enumservice are supposed to do if there are no ENUM N= APTRs with acct Enumservice (as that functional specification would seem to= be needed by rfc6117 section 3.1). Otherwise, remove the proposed "recursi= ve behaviour" by removing section 4 para 2. all the best, Lawrence On 21 Mar 2012, at 16:44, Goix Laurent Walter wrote: > Hello lawrence, all, >=20 > I'd like to resume the discussion on the draft in this list, as at this s= tage it seems more appropriate. >=20 > I could see that a couple of points (mostly in section 4) have triggered = some concerns that I'd like to clarify and seek for your guidance: >=20 > - the first paragraph of section 4, despite its poor wording, wants= to point out that this service may be *also* used in enum "infrastructures= " other than "e164.arpa", for example in cases where such infrastructure is= restricted to CSPs (e.g. "e164.gprs" or others). My feeling is that rfc611= 6 does mentions this possibility somehow (e.g. see section 3.6) but I can't= find a clear section where to refer to more formally (I agree that the ref= erence to section 2 was a bad choice for it). Is there any other reference = that could be used for this? >=20 > - regarding loop mitigation it was my intention to address it in pa= ragraph 2 of section 4, but the wording was not appropriate neither (and I = realized there is no clear mention on when the process should stop). The in= tention here would be to clarify that if no "acct" record is found, subsequ= ent enum queries could apply recursively to any e164 number found in record= s containing tel URIs independently from the specific service, still aiming= at identifying an "acct" uri. I could further imagine that the idea to mit= igate loops would be based on rfc4759 principles so that when the same numb= er is found, or another one containing a dip indicator the recursion should= be stopped and the process considered completed with no acct uri found. Do= you have any recommendation based on your experience of similar enum servi= ces? >=20 > Thank you > Walter >=20 >=20 > -----Messaggio originale----- > Da: Lawrence Conroy [mailto:lconroy@insensate.co.uk] > Inviato: sabato 3 marzo 2012 14.00 > A: Goix Laurent Walter > Cc: Richard Shockey; IETF ENUM list > Oggetto: Re: [Enum] FW: I-D Action: draft-goix-appsawg-enum-sn-service-00= .txt >=20 > Hi Laurent-Walter, Richard, folks, > As one of the authors of RFC6116, I'm intrigued with section 4 of this dr= aft. >=20 > AFAICT, section 4 of this draft specifically states that E2U+acct can be = used in an entirely different namespace from ENUM. That's an interpretation= of 6116 section 2 that I don't recognise. >=20 > The second paragraph of Section 5 is ambivalent on this, but section 4 sp= ells out that a separate apex may be used. > That directly contradicts its example, and in any case the Enumservice te= mplate is incorrect for such private use (in that case, it would need to be= "limited", not "common" -- see RFC6117 section 5.2.7 **). > =3D> Was that intended -- does that first paragraph of section 4 of this = draft help? >=20 > As I understand the second paragraph of section 4, the intention is that = an implementation will chase pstn:tel records looking for a domain with an = appropriate E2U+acct record. That looks like it's stretching the pstn:tel u= se given in RFC4769 section 3.1, but ... >=20 > The last bullet of section 5.5 of RFC6117 states that the registration do= c needs to cover loop mitigation. > It may be unfair, but RFC4769 was not covered by the current rules, so th= ey dodged the bullet of that requirement. > This draft can't, so you will have to spell out the rules for loop mitiga= tion. > Merely referring to RFC4694 is not enough; see the last sentence of secti= on 5 of RFC4694. >=20 > Finally, section 5 mentions an "activity wall". I wonder if anyone will k= now what that means in 10 years time. > It is not mentioned directly in the webfinger draft, so if it's spelt out= in the referenced OMA service document, from where can one get that spec? >=20 > all the best, > Lawrence > ** [E2U+pstn:tel was registered under the "old" rules; this one is covere= d by 6117] >=20 >=20 > On 2 Mar 2012, at 21:08, Richard Shockey wrote: >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.or= g] >> On Behalf Of internet-drafts@ietf.org >> Sent: Friday, March 02, 2012 10:49 AM >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>=20 >> Title : ENUM Service Registration for Social Networking >> (SN) Services >> Author(s) : Laurent-Walter Goix >> Kepeng Li >> Filename : draft-goix-appsawg-enum-sn-service-00.txt >> Pages : 7 >> Date : 2012-03-02 >>=20 >> This document registers a Telephone Number Mapping (ENUM) service for >> Social Networking (SN). Specifically, this document focuses on >> provisioning 'acct:' URIs (Uniform Resource Identifiers) in ENUM. >>=20 >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-goix-appsawg-enum-sn-service-0= 0.tx >> t >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-goix-appsawg-enum-sn-service-00= .txt >=20 >=20 > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle p= ersone indicate. La diffusione, copia o qualsiasi altra azione derivante da= lla conoscenza di queste informazioni sono rigorosamente vietate. Qualora a= bbiate ricevuto questo documento per errore siete cortesemente pregati di d= arne immediata comunicazione al mittente e di provvedere alla sua distruzio= ne, Grazie. >=20 > This e-mail and any attachments is confidential and may contain privilege= d information intended for the addressee(s) only. Dissemination, copying, p= rinting or use by anybody else is unauthorised. If you are not the intended= recipient, please delete this message and any attachments and advise the s= ender by return e-mail, Thanks. >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum