From iptel-bounces@ietf.org Thu Mar 3 12:30:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21639 for ; Thu, 3 Mar 2005 12:30:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6uBW-0006eB-Pj for iptel-web-archive@ietf.org; Thu, 03 Mar 2005 12:32:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6u7h-00051X-9I; Thu, 03 Mar 2005 12:28:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6u7g-000511-1y for iptel@megatron.ietf.org; Thu, 03 Mar 2005 12:28:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21237 for ; Thu, 3 Mar 2005 12:28:25 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6u94-0006Wh-40 for iptel@ietf.org; Thu, 03 Mar 2005 12:29:55 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 03 Mar 2005 09:34:31 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,133,1107763200"; d="scan'208"; a="164850143:sNHT17368732" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j23HSFTM014050 for ; Thu, 3 Mar 2005 09:28:16 -0800 (PST) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 3 Mar 2005 09:28:15 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 03 Mar 2005 09:28:11 -0800 From: Cullen Jennings To: "iptel@ietf.org" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Mar 2005 17:28:15.0758 (UTC) FILETIME=[62204AE0:01C52016] X-Spam-Score: 1.1 (+) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: 7bit Subject: [Iptel] WGLC for draft-ietf-iptel-tel-enumdi-00 X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Please post any comments by end of Thursday March 10th, which is a week from today a day after this will be discussed in the ENUM WG meeting. This draft is very very short. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Mar 3 12:31:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21737 for ; Thu, 3 Mar 2005 12:31:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6uBm-0006f2-Cx for iptel-web-archive@ietf.org; Thu, 03 Mar 2005 12:32:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6u7L-0004rv-4s; Thu, 03 Mar 2005 12:28:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6u7J-0004ro-HA for iptel@megatron.ietf.org; Thu, 03 Mar 2005 12:28:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21162 for ; Thu, 3 Mar 2005 12:28:02 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6u8g-0006Vi-GS for iptel@ietf.org; Thu, 03 Mar 2005 12:29:32 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 03 Mar 2005 09:34:07 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,133,1107763200"; d="scan'208"; a="164850088:sNHT19583244" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j23HRpYO001366 for ; Thu, 3 Mar 2005 09:27:51 -0800 (PST) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 3 Mar 2005 09:27:51 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 03 Mar 2005 09:27:42 -0800 Subject: Re: [Iptel] draft-ietf-iptel-tel-np-02.txt adopted as WG item From: Cullen Jennings To: Cullen Jennings , "iptel@ietf.org" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Mar 2005 17:27:51.0398 (UTC) FILETIME=[539B4060:01C52016] X-Spam-Score: 1.1 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit On 2/2/05 11:32 AM, "Cullen Jennings" wrote: > > I have not got any objections to adopting this draft as a WG draft and we > had strong consensus at the last meeting so I am going to consider this > adopted. > > Thanks, Cullen > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel Sorry for this clueless email from long ago. I had cut and paste the wrong draft name into the title. I had meant to put draft-stastny-iptel-tel-enumdi-00.txt _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Fri Mar 4 04:13:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17237 for ; Fri, 4 Mar 2005 04:13:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D78tp-0004Y6-63 for iptel-web-archive@ietf.org; Fri, 04 Mar 2005 04:15:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D78qo-0003IU-Rk; Fri, 04 Mar 2005 04:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D78qk-0003IK-E0 for iptel@megatron.ietf.org; Fri, 04 Mar 2005 04:11:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17101 for ; Fri, 4 Mar 2005 04:11:54 -0500 (EST) Received: from 213-152-49-126.dsl.eclipse.net.uk ([213.152.49.126] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D78sE-0004Us-JH for iptel@ietf.org; Fri, 04 Mar 2005 04:13:31 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 10C54630EC for ; Fri, 4 Mar 2005 09:14:13 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: iptel@ietf.org From: lconroy Date: Fri, 4 Mar 2005 09:11:44 +0000 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Iptel] Fwd: [Enum] To Err is stupid, but to do it twice X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Hi Folks, For those people who didn't see my comment on the ENUM list, there will be an update to draft-ietf-iptel-enumdi coming out of shadow to fix my cock-up. Content will be exactly the same, but this time with both Richards as authors. I can't do XML, and I forget to CC the IPTEL list when I notice. hey ho. all the best, Lawrence --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Sun Mar 6 20:02:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18017 for ; Sun, 6 Mar 2005 20:02:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D86fs-0002tz-3v for iptel-web-archive@ietf.org; Sun, 06 Mar 2005 20:04:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D86dY-00041I-QL; Sun, 06 Mar 2005 20:02:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D86dW-000418-SC for iptel@megatron.ietf.org; Sun, 06 Mar 2005 20:02:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17990 for ; Sun, 6 Mar 2005 20:02:14 -0500 (EST) Received: from stun.tutpro.com ([192.98.100.8] helo=lohi.tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D86fa-0002tW-WF for iptel@ietf.org; Sun, 06 Mar 2005 20:04:28 -0500 Received: from www-data by lohi.tutpro.com with local (Exim 4.34) id 1D7UP3-0002X8-JV for iptel@ietf.org; Sat, 05 Mar 2005 10:12:49 +0200 Received: from 202.73.194.26 (SquirrelMail authenticated user jh); by lohi.tutpro.com with HTTP; Sat, 5 Mar 2005 10:12:49 +0200 (EET) Message-ID: <32855.202.73.194.26.1110010369.squirrel@lohi.tutpro.com> Date: Sat, 5 Mar 2005 10:12:49 +0200 (EET) From: "Juha Heinanen" To: iptel@ietf.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 8bit Subject: [Iptel] comments on draft-ietf-iptel-tel-enumdi-00.txt X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jh@tutpro.com List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 8bit i saw that comments were asked on draft-ietf-iptel-tel-enumdi-00.txt. i therefore read the draft and have a couple of questions: 1) is it now a common/allowed practise that an enum query can result a tel uri containing another e.164 number so that enum query on that can result a third e.164 number, etc? i thought that at some point it was recommended that enum query on an e.164 number should return the final result. 2) if so, how can the draft help in preventing loops a -> b -> a? i didn't see any mentioning about that, because according to the draft, enumdi indicator is only added if enum query doesn't produce any result or produces the same e.164 as result. 3) should there also be an indicator telling that an enum query was made that resulted in this tel uri, which would allow a proxy, for example, to implement a non-looping policy? -- juha _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Sun Mar 6 20:04:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18222 for ; Sun, 6 Mar 2005 20:04:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D86hd-0002yI-9H for iptel-web-archive@ietf.org; Sun, 06 Mar 2005 20:06:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D86db-00041Q-BB; Sun, 06 Mar 2005 20:02:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D86dY-00041D-4C for iptel@megatron.ietf.org; Sun, 06 Mar 2005 20:02:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17993 for ; Sun, 6 Mar 2005 20:02:16 -0500 (EST) Received: from stun.tutpro.com ([192.98.100.8] helo=lohi.tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D86fd-0002tb-EW for iptel@ietf.org; Sun, 06 Mar 2005 20:04:29 -0500 Received: from www-data by lohi.tutpro.com with local (Exim 4.34) id 1D7UuO-0002YE-Hl for iptel@ietf.org; Sat, 05 Mar 2005 10:45:12 +0200 Received: from 202.73.194.26 (SquirrelMail authenticated user jh); by lohi.tutpro.com with HTTP; Sat, 5 Mar 2005 10:45:12 +0200 (EET) Message-ID: <32869.202.73.194.26.1110012312.squirrel@lohi.tutpro.com> Date: Sat, 5 Mar 2005 10:45:12 +0200 (EET) From: "Juha Heinanen" To: iptel@ietf.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 8bit Subject: [Iptel] comments on draft-ietf-iptel-tel-np-02.txt X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jh@tutpro.com List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 8bit i also started to read "New Parameters for the "tel" URI to Support Number Portability" draft, but didn't get all the way through. the reason was that i got pissed off by the narrow scope of "number portability" in the draft. why does it only deal with number portability related to "geographical telephone numbers and freephone numbers"? also mobile numbers and 700 numbers can and are heavily ported all over the world. in some countries it is also possible to port either a landline or mobile phone number to internet. why can't there be a general number portability indication mechanish covering any kind of number portability? i vote for junking this draft until it covers any kind of number portability. i get a feeling that this draft tries to solve some narrow problem that the author or his company has. at minimum, its name must be changed because it is highly misleading. -- juha _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Sun Mar 6 21:08:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23700 for ; Sun, 6 Mar 2005 21:08:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D87hw-0004V6-5j for iptel-web-archive@ietf.org; Sun, 06 Mar 2005 21:10:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D87eu-0001Kz-TB; Sun, 06 Mar 2005 21:07:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D87eu-0001Ku-1D for iptel@megatron.ietf.org; Sun, 06 Mar 2005 21:07:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23648 for ; Sun, 6 Mar 2005 21:07:43 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D87gx-0004U0-1g for iptel@ietf.org; Sun, 06 Mar 2005 21:09:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Iptel] comments on draft-ietf-iptel-tel-enumdi-00.txt Date: Mon, 7 Mar 2005 03:10:03 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D46FBDF@oefeg-s04.oefeg.loc> Thread-Topic: [Iptel] comments on draft-ietf-iptel-tel-enumdi-00.txt Thread-Index: AcUisgkcVEipbbjQQRmQOP70POX4TAABGQM3 From: "Stastny Richard" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: quoted-printable Juha, >1) is it now a common/allowed practise that an enum query can result a = tel >uri containing another e.164 number so that enum query on that can = result >a third e.164 number, etc?=20 =20 Who is the authority allowing an end-user what he is entering in his = domain? =20 >i thought that at some point it was >recommended that enum query on an e.164 number should return the final >result. If a tel: URI is allowed in in ENUM, it may point to a different number, since this number may also be in ENUM, an ENUM query makes sense. I agree with you that this may result in an endless loop. There is two ways to break this. See below. >2) if so, how can the draft help in preventing loops a -> b -> a? i >didn't see any mentioning about that, because according to the draft, >enumdi indicator is only added if enum query doesn't produce any result = or >produces the same e.164 as result. >3) should there also be an indicator telling that an enum query was = made >that resulted in this tel uri, which would allow a proxy, for example, = to >implement a non-looping policy? This is exactly what enumdi does if provided with a tel URI in ENUM, see my second answer: My first answer is of course politically incorrect at this list, because it is using language considered offensive ;-) One way to break the loop is not documented in IETF because this is client behaviour, it is instead documented in ETSI TS 102 172 "Minimum Requirements for Interoperability of ENUM Implementations" http://enum.nic.at/documents/ETSI/Drafts/05TD142r3%20DTS_102172v020006.pd= f It says basically that a client should do only 5 such quireies, e.g in = Section 10.3.1 Full citation: A gateway from the PSTN to the Internet may be ENUM enabled to route=20 calls to destinations potentially "published" in ENUM. This gateway MAY=20 support only a limited range of ENUMservices, which can be accessed by = the PSTN.. =20 After processing the information retrieved from ENUM according to=20 section 10.1., the ENUM enabled application client looks for the = specific=20 ENUMservices it supports. This MAY be e.g. "sip", "h323", "voice:sip",=20 "voice:h323", "voice:tel", "ifax:mailto", ...=20 If a "voice:tel" is chosen, and the E.164 contained in the "tel" URI is=20 different from the number originally queried, the ENUM enabled = application=20 client SHALL launch another ENUM query for the number given (as if it = had=20 received a NAPTR containing the 'enum' Enumservice, as described in=20 section 9.4.1.7). To prevent endless loops, the client SHALL make only a = maximum of 5 such redirections. In the subsequent queries only "voice",=20 "sip" or "h323" ENUMservices SHALL be considered.=20 If any of these queries returns any "voice" ENUMservice except = "voice:tel",=20 this ENUMservice SHALL be used.=20 If any of these queries returns a "voice:tel" with the same number as = queried=20 or an NXDOMAIN, the call SHOULD be processed further by querying = infrastructure=20 ENUM, another database or by routing the call directly to the PSTN, if = the gateway=20 is providing this. If the gateway is not providing this functionality, = "no such service"=20 SHALL be indicated.=20 If the call is passed on to another network element, the "enumdi" = parameter SHALL be set.=20 End of citation. The second way to prevent an end-less loop is descibed in the draft = itself in Section 4.2 in the second bullet point: Citation When a VoIP network element accesses ENUM in e164.arpa for a given E.164 number and either: o the result of the query includes a NAPTR RR containing a "tel" URI that has the same E.164 number, or o the result of the query includes a NAPTR RR containing a "tel" URI with the "enumdi" parameter set, then if that retrieved "tel" URI is chosen to be passed to the next network element, the sending VoIP network element MUST pass on the retrieved URI with the "enumdi" parameter set. End of citation I hope this answers your questions -richard >-- juha _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Mar 7 04:22:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19160 for ; Mon, 7 Mar 2005 04:22:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8ETu-0005Vl-9P for iptel-web-archive@ietf.org; Mon, 07 Mar 2005 04:24:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8EQt-0007ZQ-K2; Mon, 07 Mar 2005 04:21:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8EQr-0007ZL-7U for iptel@megatron.ietf.org; Mon, 07 Mar 2005 04:21:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19125 for ; Mon, 7 Mar 2005 04:21:43 -0500 (EST) Received: from 213-152-49-126.dsl.eclipse.net.uk ([213.152.49.126] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8ESz-0005UA-Vi for iptel@ietf.org; Mon, 07 Mar 2005 04:23:59 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id D0A8F637D8; Mon, 7 Mar 2005 09:23:56 +0000 (GMT) In-Reply-To: <32855.202.73.194.26.1110010369.squirrel@lohi.tutpro.com> References: <32855.202.73.194.26.1110010369.squirrel@lohi.tutpro.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Iptel] comments on draft-ietf-iptel-tel-enumdi-00.txt Date: Mon, 7 Mar 2005 09:21:34 +0000 To: jh@tutpro.com X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Hi Juha, folks, Re. point 1. Strictly, an ENUM query terminates when a URI is returned. It isn't just recommended, it's required. A "human" may be "in the loop" to resolve a "tie", but this is still part of the same ENUM query, selecting one result. The only situation in which another domain is queried is if a "non-final" NAPTR is processed; this has no URI, but does have another domain in which the query continues. In practice, the calling application (such as a SIP proxy or a set of SIP proxies) may make a sequence of separate ENUM queries, running on its own internal (non-ENUM) logic. That is not, however, anything to do with the core ENUM algorithm running on a machine. all the best, Lawrence On 5 Mar 2005, at 08:12, Juha Heinanen wrote: > 1) is it now a common/allowed practise that an enum query can result a > tel > uri containing another e.164 number so that enum query on that can > result > a third e.164 number, etc? i thought that at some point it was > recommended that enum query on an e.164 number should return the final > result. --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Mar 8 05:22:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07355 for ; Tue, 8 Mar 2005 05:22:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8bts-0000NY-Nf for iptel-web-archive@ietf.org; Tue, 08 Mar 2005 05:25:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8bqo-0006p7-DG; Tue, 08 Mar 2005 05:22:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8bqj-0006oh-6w for iptel@megatron.ietf.org; Tue, 08 Mar 2005 05:22:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07325 for ; Tue, 8 Mar 2005 05:21:58 -0500 (EST) Received: from stun.tutpro.com ([192.98.100.8] helo=lohi.tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8bt5-0000MU-4U for iptel@ietf.org; Tue, 08 Mar 2005 05:24:28 -0500 Received: from www-data by lohi.tutpro.com with local (Exim 4.44) id 1D8bqd-00059h-Uj; Tue, 08 Mar 2005 12:21:55 +0200 Received: from 213.212.6.106 (SquirrelMail authenticated user jh); by lohi.tutpro.com with HTTP; Tue, 8 Mar 2005 12:21:55 +0200 (EET) Message-ID: <14355.213.212.6.106.1110277315.squirrel@lohi.tutpro.com> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FBDF@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D46FBDF@oefeg-s04.oefeg.loc> Date: Tue, 8 Mar 2005 12:21:55 +0200 (EET) Subject: Re: [Iptel] comments on draft-ietf-iptel-tel-enumdi-00.txt From: "Juha Heinanen" To: "Stastny Richard" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 8bit Cc: iptel@ietf.org, jh@tutpro.com X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jh@tutpro.com List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 8bit Stastny Richard said: > Who is the authority allowing an end-user what he is entering in his > domain? no authority is needed. if someone enters an enum entry that results in e.164 number that is not the final one, then that final one will never be reached if only one enum query is done by other parties. > It says basically that a client should do only 5 such quireies, e.g in > Section 10.3.1 where does number 5 come from? looks like someone just made it up. i argue that 1 is better than 5. > When a VoIP network element accesses ENUM in e164.arpa for a given > E.164 number and either: > o the result of the query includes a NAPTR RR containing a "tel" URI > that has the same E.164 number, or > o the result of the query includes a NAPTR RR containing a "tel" URI > with the "enumdi" parameter set, this makes sense, but the 5 thing doesn't. -- juha _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Mar 8 07:47:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18333 for ; Tue, 8 Mar 2005 07:47:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8eAK-0003FK-7f for iptel-web-archive@ietf.org; Tue, 08 Mar 2005 07:50:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8e6r-0005xJ-U3; Tue, 08 Mar 2005 07:46:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8e6n-0005vr-GY for iptel@megatron.ietf.org; Tue, 08 Mar 2005 07:46:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18227 for ; Tue, 8 Mar 2005 07:46:43 -0500 (EST) Received: from 213-152-49-126.dsl.eclipse.net.uk ([213.152.49.126] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8e9A-0003DV-2y for iptel@ietf.org; Tue, 08 Mar 2005 07:49:13 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id A2003644F1; Tue, 8 Mar 2005 12:49:49 +0000 (GMT) In-Reply-To: <14355.213.212.6.106.1110277315.squirrel@lohi.tutpro.com> References: <32755D354E6B65498C3BD9FD496C7D46FBDF@oefeg-s04.oefeg.loc> <14355.213.212.6.106.1110277315.squirrel@lohi.tutpro.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9ca25e9d676e841e4f5f7a27a9ceb268@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Iptel] comments on draft-ietf-iptel-tel-enumdi-00.txt Date: Tue, 8 Mar 2005 12:46:26 +0000 To: jh@tutpro.com X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org, Stastny Richard X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Juha whilst I'm glad that you noticed this and have finally decided to comment, please could you discuss ENUM issues on the ENUM list. The loop detection and recovery text has been in the ENUM experiences draft - since 2003. Now, if your application chooses not to do only one lookup, that's fine. It's your program logic, not the ENUM client. However, that ENUM client will need to be resilient to misconfiguration of the DNS zone content. That's what the loop detection is about. That's a "pure" ENUM topic, not one for IPTEL. We return you to your normal program. atb, L On 8 Mar 2005, at 10:21, Juha Heinanen wrote: > Stastny Richard said: >> Who is the authority allowing an end-user what he is entering in his >> domain? > > no authority is needed. if someone enters an enum entry that results > in > e.164 number that is not the final one, then that final one will never > be > reached if only one enum query is done by other parties. > >> It says basically that a client should do only 5 such quireies, e.g in >> Section 10.3.1 > > where does number 5 come from? looks like someone just made it up. i > argue that 1 is better than 5. > >> When a VoIP network element accesses ENUM in e164.arpa for a given >> E.164 number and either: >> o the result of the query includes a NAPTR RR containing a "tel" >> URI >> that has the same E.164 number, or >> o the result of the query includes a NAPTR RR containing a "tel" >> URI >> with the "enumdi" parameter set, > > this makes sense, but the 5 thing doesn't. > > -- juha > > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > > --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Mar 8 11:27:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14008 for ; Tue, 8 Mar 2005 11:27:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8hab-0000Tj-CA for iptel-web-archive@ietf.org; Tue, 08 Mar 2005 11:29:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8hWc-0002YJ-U0; Tue, 08 Mar 2005 11:25:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8hWW-0002XO-9T for iptel@megatron.ietf.org; Tue, 08 Mar 2005 11:25:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13728 for ; Tue, 8 Mar 2005 11:25:29 -0500 (EST) Received: from harjus.tutpro.com ([192.98.100.3] ident=Debian-exim) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8hYv-0000PB-CM for iptel@ietf.org; Tue, 08 Mar 2005 11:28:02 -0500 Received: from jh by harjus.tutpro.com with local (Exim 4.34) id 1D8hWM-0000T6-6K; Tue, 08 Mar 2005 18:25:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16941.53746.142905.922039@harjus.tutpro.com> Date: Tue, 8 Mar 2005 18:25:22 +0200 To: lconroy Subject: Re: [Iptel] comments on draft-ietf-iptel-tel-enumdi-00.txt In-Reply-To: <9ca25e9d676e841e4f5f7a27a9ceb268@insensate.co.uk> References: <32755D354E6B65498C3BD9FD496C7D46FBDF@oefeg-s04.oefeg.loc> <14355.213.212.6.106.1110277315.squirrel@lohi.tutpro.com> <9ca25e9d676e841e4f5f7a27a9ceb268@insensate.co.uk> X-Mailer: VM 7.19 under Emacs 21.3.1 From: Juha Heinanen X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org, Stastny Richard X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit lconroy writes: > Now, if your application chooses not to do only one lookup, that's fine. > It's your program logic, not the ENUM client. i'm not getting your point. draft-ietf-iptel-tel-enumdi-00.txt does not allow the entity that makes enum query to add ;enumdi param whenever enum query was done. it can only be done, if the same e.164 number was returned or if dns gave negative answer. even if enum query was done 5 times, it still does not allow addition of ;enumdi param. so the next entity has again needs to do its query or queries, etc. -- juha _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Mar 10 10:01:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21267 for ; Thu, 10 Mar 2005 10:01:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9PDc-00048P-EM for iptel-web-archive@ietf.org; Thu, 10 Mar 2005 10:04:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9P8o-0006hT-HE; Thu, 10 Mar 2005 09:59:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9P8m-0006h0-5i; Thu, 10 Mar 2005 09:59:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21021; Thu, 10 Mar 2005 09:59:51 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D9PBX-0003yC-9A; Thu, 10 Mar 2005 10:02:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Mar 2005 16:01:57 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D46FC11@oefeg-s04.oefeg.loc> Thread-Topic: tel loop detection and prevention Thread-Index: AcUlghriNdND5wtiTc2Ylp5Za+eQcw== From: "Stastny Richard" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Subject: [Iptel] tel loop detection and prevention X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Dear all, =20 in yesterday's ENUM wg in conjunction with the enumdi draft the issue of loop detection and prevention with Enumservices featuring a tel URI was raised. =20 It was decided to put some text for clarification into the enumdi draft. =20 Although I am still not 100% convinced that this is the perfect place to clarify the issue, I myself do currently not know of a better place, since tel URIs are dealt with in different places (msg, vovi). (maybe it should in addition also be mentioned in the experiences) =20 So I propose to add a section 4.3 to the enumdi draft with the=20 following text below:. I include also the existing text of section 4.2 to get the idea: =20 existing text in section 4.2: =20 4.2 Adding the "enumdi" parameter to URIs When a VoIP network element accesses ENUM in e164.arpa for a given E.164 number and the result of the query is NXDOMAIN, and the network element chooses to pass the call to the next network element by using a "tel" URI, the "enumdi" parameter MUST be set. When a VoIP network element accesses ENUM in e164.arpa for a given E.164 number and either: o the result of the query includes a NAPTR RR containing a "tel" URI that has the same E.164 number, or o the result of the query includes a NAPTR RR containing a "tel" URI with the "enumdi" parameter set, then if that retrieved "tel" URI is chosen to be passed to the next network element, the sending VoIP network element MUST pass on the retrieved URI with the "enumdi" parameter set. =20 New text to be added 4.3 Loop detection and prevention =20 If the result of the query contains another tel: URI with a different E.164 number, the VoIP network element may either choose to pass the retrieved "tel:" URI to the next network element with the "enumdi"=20 indicator set or the network element may choose to make another ENUM=20 query with the "tel" URI retrieved, looking for the same Enumservice. = =20 To prevent endless loops, the network element MUST do only up to 5 = such queries=20 until the result is resolved as described in section 4.2. If this is = not=20 the case, or a number already queried should be queried again, the = call=20 should be dropped by the VoIP network element by signaling back = service=20 not available. =20 End of new text =20 regards Richard _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Mar 10 13:35:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15702 for ; Thu, 10 Mar 2005 13:35:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9SY8-0006yj-Kh for iptel-web-archive@ietf.org; Thu, 10 Mar 2005 13:38:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9SU9-0003ds-7T; Thu, 10 Mar 2005 13:34:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9SU5-0003dj-EY; Thu, 10 Mar 2005 13:34:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15592; Thu, 10 Mar 2005 13:34:06 -0500 (EST) Received: from harjus.tutpro.com ([192.98.100.3] ident=Debian-exim) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9SWv-0006x1-AA; Thu, 10 Mar 2005 13:37:06 -0500 Received: from jh by harjus.tutpro.com with local (Exim 4.44) id 1D9SU0-0000YM-Bd; Thu, 10 Mar 2005 20:34:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16944.37660.336373.79823@harjus.tutpro.com> Date: Thu, 10 Mar 2005 20:34:04 +0200 To: "Stastny Richard" Subject: [Iptel] tel loop detection and prevention In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FC11@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D46FC11@oefeg-s04.oefeg.loc> X-Mailer: VM 7.19 under Emacs 21.3.1 From: Juha Heinanen X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Stastny Richard writes: > New text to be added > 4.3 Loop detection and prevention > > If the result of the query contains another tel: URI with a different > E.164 number, the VoIP network element may either choose to pass the > retrieved "tel:" URI to the next network element with the "enumdi" > indicator set ... thanks for taking my comment into account by allowing this. -- juha _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Mar 10 14:33:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22219 for ; Thu, 10 Mar 2005 14:33:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9TS5-0001V4-3e for iptel-web-archive@ietf.org; Thu, 10 Mar 2005 14:36:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9TOb-0005D0-W4; Thu, 10 Mar 2005 14:32:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9TOa-0005Cs-Pz; Thu, 10 Mar 2005 14:32:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22147; Thu, 10 Mar 2005 14:32:31 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9TRQ-0001SN-3O; Thu, 10 Mar 2005 14:35:30 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 10 Mar 2005 12:49:40 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,154,1107734400"; d="scan'208"; a="233627423:sNHT196713996" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2AJW6q8009899; Thu, 10 Mar 2005 11:32:07 -0800 (PST) Received: from [130.129.133.35] (sjc-vpn6-261.cisco.com [10.21.121.5]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j2AJPbnq014993; Thu, 10 Mar 2005 11:25:38 -0800 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FC11@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D46FC11@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Iptel] tel loop detection and prevention Date: Thu, 10 Mar 2005 14:32:04 -0500 To: "Stastny Richard" X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1110482740.286635"; x:"432200"; a:"rsa-sha1"; b:"nofws:2397"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"Txj/qUdhWK+OOjcOerc/MtzaOJVZAAgJPXfg84cTRYhByDpXD2CGKWb7sfieNspQauKjvlF3" "oy0ZhwnAHUfKetkEZ/cLXKgemoo+C5iXsDXzoEQzP0ImszvFj/YBufe0qbuOwjS2CxqAx2KO6y/" "G46666bOYuk/2vHlaGzDZvk8="; c:"From: David R Oran "; c:"Subject: Re: [Iptel] tel loop detection and prevention"; c:"Date: Thu, 10 Mar 2005 14:32:04 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org, enum@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit There are MUCH better ways to deal with the loop issue. See below. On Mar 10, 2005, at 10:01 AM, Stastny Richard wrote: > Dear all, > New text to be added > 4.3 Loop detection and prevention > > If the result of the query contains another tel: URI with a > different > E.164 number, the VoIP network element may either choose to pass the > retrieved "tel:" URI to the next network element with the "enumdi" > indicator set or the network element may choose to make another ENUM > query with the "tel" URI retrieved, looking for the same > Enumservice. > > To prevent endless loops, the network element MUST do only up to 5 > such queries > until the result is resolved as described in section 4.2. This is unreasonable (or at least incredibly ugly). Magic numbers should be avoided like the plague. Not to mention that it does not solve the problem in the distributed case... Two suggestions: 1) make the enumdi a counter rather than a boolean. It would hold the translation count. Note that this is *not* the number of calls to some enum resolution service, but rather then number of translations that have been done. This will be the same if the caller is querying directly via a dns resolver, but may result in a count higher than 1 if there is some kind of recursive lookup client API on the system doing the enum translations. 2) Base the loop detect on the counter. A dumb client can just decide on a maximum value as part of its configuration. We could suggest a default value, but that is different from mandating a constant value as a magic number. However, this is actually not necessary - those interested read on. I mentioned privately to a few people that there is a really elegant way to detect loops of the sort introduced by cyclic database pointers in a distributed database (like DNS). I used in a distributed naming service I designed about 20 years ago, and it worked like a charm. It's based on an algorithm in Vol.1 of Knuth which everybody reads and then promptly forgets in their CS training. It's called "even-odd iteration counting" - go look it up. It has the following wonderful properties. a) works in constant memory (two string variables) b) never falsely detects a loop in a long translation chain c) detects all loops of degree 2 immediately d) detects all loops of degree 3 after one time around the loop e) detects a loop of arbitrary degree after traversing the loop no more than 3 times. Dave. > If this is not > the case, or a number already queried should be queried again, the > call > should be dropped by the VoIP network element by signaling back > service > not available. > > End of new text > > regards > Richard > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Mar 10 14:47:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25545 for ; Thu, 10 Mar 2005 14:47:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Tfw-0002kV-BL for iptel-web-archive@ietf.org; Thu, 10 Mar 2005 14:50:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Tbs-0000DI-Au; Thu, 10 Mar 2005 14:46:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Tbq-0000Cz-Tg; Thu, 10 Mar 2005 14:46:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25049; Thu, 10 Mar 2005 14:46:12 -0500 (EST) Received: from harjus.tutpro.com ([192.98.100.3] ident=Debian-exim) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Teh-0002bm-2n; Thu, 10 Mar 2005 14:49:12 -0500 Received: from jh by harjus.tutpro.com with local (Exim 4.44) id 1D9Tbb-0000gk-54; Thu, 10 Mar 2005 21:45:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16944.41975.130953.361116@harjus.tutpro.com> Date: Thu, 10 Mar 2005 21:45:59 +0200 To: David R Oran Subject: Re: [Iptel] tel loop detection and prevention In-Reply-To: References: <32755D354E6B65498C3BD9FD496C7D46FC11@oefeg-s04.oefeg.loc> X-Mailer: VM 7.19 under Emacs 21.3.1 From: Juha Heinanen X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org, enum@ietf.org, Stastny Richard X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit David R Oran writes: > This is unreasonable (or at least incredibly ugly). Magic numbers > should be avoided like the plague. Not to mention that it does not > solve the problem in the distributed case... this was also my point. someone had arbitrarily made up number 5 and i argued against it. i'll configure my proxy to make exactly one lookup and mark the query done. it is then up to the next guy to decide it wants to make more queries. giving enumdi a count parameter would also be ok with me. -- juha _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Mar 10 14:49:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26135 for ; Thu, 10 Mar 2005 14:49:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Thi-00030D-2w for iptel-web-archive@ietf.org; Thu, 10 Mar 2005 14:52:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9TbB-0008IM-9a; Thu, 10 Mar 2005 14:45:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Tb9-0008HK-Vp; Thu, 10 Mar 2005 14:45:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24834; Thu, 10 Mar 2005 14:45:29 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D9Te0-0002Uz-Qn; Thu, 10 Mar 2005 14:48:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Iptel] tel loop detection and prevention Date: Thu, 10 Mar 2005 20:47:41 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D46FC18@oefeg-s04.oefeg.loc> Thread-Topic: [Iptel] tel loop detection and prevention Thread-Index: AcUlqDzgseVde0enR42kruNksaBFoQAAPJZ8 From: "Stastny Richard" To: "David R Oran" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable Cc: iptel@ietf.org, enum@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable David, =20 On the counter in enumdi: =20 Basically the enumdi is used in signalling between VoIP network elements the loop need to be detected WITHIN a VoIP network element before the enumdi is set, so this counter does not help there In addition the counter issue was discussed last meeting and rejected. =20 On the "magic" solution: Please propose text to be put into the draft and not home work for editors =20 Or should we put the following text in the I-D: =20 If you want to detect loops, go read Vol.1 of Knuth ? =20 Richard =20 ________________________________ Von: David R Oran [mailto:oran@cisco.com] Gesendet: Do 10.03.2005 20:32 An: Stastny Richard Cc: iptel@ietf.org; enum@ietf.org Betreff: Re: [Iptel] tel loop detection and prevention There are MUCH better ways to deal with the loop issue. See below. On Mar 10, 2005, at 10:01 AM, Stastny Richard wrote: > Dear all, > New text to be added > 4.3 Loop detection and prevention > > If the result of the query contains another tel: URI with a > different > E.164 number, the VoIP network element may either choose to pass = the > retrieved "tel:" URI to the next network element with the "enumdi" > indicator set or the network element may choose to make another = ENUM > query with the "tel" URI retrieved, looking for the same > Enumservice. > > To prevent endless loops, the network element MUST do only up to 5 > such queries > until the result is resolved as described in section 4.2. This is unreasonable (or at least incredibly ugly). Magic numbers should be avoided like the plague. Not to mention that it does not solve the problem in the distributed case... Two suggestions: 1) make the enumdi a counter rather than a boolean. It would hold the translation count. Note that this is *not* the number of calls to some enum resolution service, but rather then number of translations that have been done. This will be the same if the caller is querying directly via a dns resolver, but may result in a count higher than 1 if there is some kind of recursive lookup client API on the system doing the enum translations. 2) Base the loop detect on the counter. A dumb client can just decide on a maximum value as part of its configuration. We could suggest a default value, but that is different from mandating a constant value as a magic number. However, this is actually not necessary - those interested read on. I mentioned privately to a few people that there is a really elegant way to detect loops of the sort introduced by cyclic database pointers in a distributed database (like DNS). I used in a distributed naming service I designed about 20 years ago, and it worked like a charm. It's based on an algorithm in Vol.1 of Knuth which everybody reads and then promptly forgets in their CS training. It's called "even-odd iteration counting" - go look it up. It has the following wonderful properties. a) works in constant memory (two string variables) b) never falsely detects a loop in a long translation chain c) detects all loops of degree 2 immediately d) detects all loops of degree 3 after one time around the loop e) detects a loop of arbitrary degree after traversing the loop no more than 3 times. Dave. > If this is not > the case, or a number already queried should be queried again, the > call > should be dropped by the VoIP network element by signaling back > service > not available. > > End of new text > > regards > Richard > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Mar 10 15:18:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01336 for ; Thu, 10 Mar 2005 15:18:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9U9V-0004xB-DD for iptel-web-archive@ietf.org; Thu, 10 Mar 2005 15:21:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9U4C-0002UN-5d; Thu, 10 Mar 2005 15:15:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9U4A-0002Tv-CT; Thu, 10 Mar 2005 15:15:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00618; Thu, 10 Mar 2005 15:15:26 -0500 (EST) Received: from 213-152-49-126.dsl.eclipse.net.uk ([213.152.49.126] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9U6z-0004hz-9C; Thu, 10 Mar 2005 15:18:26 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 4BA1F64A59; Thu, 10 Mar 2005 20:18:25 +0000 (GMT) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FC18@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D46FC18@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7ba08e54ace96acf95842a162f6b3b90@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Iptel] tel loop detection and prevention Date: Thu, 10 Mar 2005 20:15:09 +0000 To: "Stastny Richard" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org, enum@ietf.org, David R Oran X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Content-Transfer-Encoding: 7bit Hi Dave, Richard, Juha, folks, I'm also glad that someone else has finally commented on something that's been in the ENUM Experiences draft since 2003 - I'm very happy if we can improve that, as the "depth limit" of 5 is (and always has been) a kludge. ---- Re. the even-odd solution: I had thought that "even-odd" required distributed control - in the case of ENUM the nasty cases occur when the zones are under completely independent control and the NAPTRs they contain may not include this flag -at all-. I'd greatly appreciate a clarification one the use of this algorithm, as it is an *awful* long time since I looked at that fine book, and I obviously didn't understand it (or have miss-remembered it). ---- I'm afraid that I disagree with my learned co-author on the proposed text. (i) The broken behaviour is a proxy that does an ENUM look up when it receives a tel: URI but then stops and just passes the result onwards. It either handles a tel: URI or it doesn't. If it re-tried until it found a URI it liked, or detected a loop (NXDOMAIN is already covered), the problem wouldn't occur. (ii) This is an ENUM "Dip" Indicator flag. It indicates that the element has done an ENUM query on this telephone number, or otherwise KNOWS that there is no useful data associated with it in ENUM. Of course, the sending element may always lie. It may not have done an ENUM query at all on the number. It might choose to do this to force the receiving element to place a call to the PSTN or fail. However, that is not a compliant use of this flag - you can lie, but it's a lie. Thus, if we MUST allow broken proxies to push the problem onwards, then I believe that the 1st paragraph for 4.3 will have to be: ------------ If the result of the query contains another tel: URI with a different E.164 number, the VoIP network element MAY either choose to pass the original "tel:" URI to the next network element with the "enumdi" indicator set or the network element MAY choose to make another ENUM query with the "tel" URI retrieved, looking for the same Enumservice. ------------ i.e. the proxy MUST NOT pass on a request with the TEL: URI it has retrieved from ENUM with the enumdi flag set, as that would be a lie. Instead, the original TEL: URI is passed on, with the flag set. This is the number it HAS checked in ENUM. all the best, Lawrence On 10 Mar 2005, at 19:47, Stastny Richard wrote: > David, > > On the counter in enumdi: > > Basically the enumdi is used in signalling between VoIP network > elements > the loop need to be detected WITHIN a VoIP network element before the > enumdi is set, so this counter does not help there > In addition the counter issue was discussed last meeting and rejected. > > On the "magic" solution: > Please propose text to be put into the draft > and not home work for editors > > Or should we put the following text in the I-D: > > If you want to detect loops, go read Vol.1 of Knuth ? > > Richard > > > ________________________________ > > Von: David R Oran [mailto:oran@cisco.com] > Gesendet: Do 10.03.2005 20:32 > An: Stastny Richard > Cc: iptel@ietf.org; enum@ietf.org > Betreff: Re: [Iptel] tel loop detection and prevention > > > > There are MUCH better ways to deal with the loop issue. See below. > > On Mar 10, 2005, at 10:01 AM, Stastny Richard wrote: > >> Dear all, >> New text to be added >> 4.3 Loop detection and prevention >> >> If the result of the query contains another tel: URI with a >> different >> E.164 number, the VoIP network element may either choose to pass >> the >> retrieved "tel:" URI to the next network element with the "enumdi" >> indicator set or the network element may choose to make another >> ENUM >> query with the "tel" URI retrieved, looking for the same >> Enumservice. >> >> To prevent endless loops, the network element MUST do only up to 5 >> such queries >> until the result is resolved as described in section 4.2. > This is unreasonable (or at least incredibly ugly). Magic numbers > should be avoided like the plague. Not to mention that it does not > solve the problem in the distributed case... > > Two suggestions: > 1) make the enumdi a counter rather than a boolean. It would hold the > translation count. Note that this is *not* the number of calls to some > enum resolution service, but rather then number of translations that > have been done. This will be the same if the caller is querying > directly via a dns resolver, but may result in a count higher than 1 if > there is some kind of recursive lookup client API on the system doing > the enum translations. > 2) Base the loop detect on the counter. > > A dumb client can just decide on a maximum value as part of its > configuration. We could suggest a default value, but that is different > from mandating a constant value as a magic number. However, this is > actually not necessary - those interested read on. > > I mentioned privately to a few people that there is a really elegant > way to detect loops of the sort introduced by cyclic database pointers > in a distributed database (like DNS). I used in a distributed naming > service I designed about 20 years ago, and it worked like a charm. It's > based on an algorithm in Vol.1 of Knuth which everybody reads and then > promptly forgets in their CS training. It's called "even-odd iteration > counting" - go look it up. > > It has the following wonderful properties. > a) works in constant memory (two string variables) > b) never falsely detects a loop in a long translation chain > c) detects all loops of degree 2 immediately > d) detects all loops of degree 3 after one time around the loop > e) detects a loop of arbitrary degree after traversing the loop no more > than 3 times. > > Dave. > >> If this is not >> the case, or a number already queried should be queried again, the >> call >> should be dropped by the VoIP network element by signaling back >> service >> not available. >> >> End of new text >> >> regards >> Richard >> >> _______________________________________________ >> Iptel mailing list >> Iptel@ietf.org >> https://www1.ietf.org/mailman/listinfo/iptel >> > David R. Oran > Cisco Fellow > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 USA > Tel: +1 978 264 2048 > Email: oran@cisco.com > > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > > --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Mar 10 15:31:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03248 for ; Thu, 10 Mar 2005 15:31:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9UMT-0005sD-MU for iptel-web-archive@ietf.org; Thu, 10 Mar 2005 15:34:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9UHr-00084L-60; Thu, 10 Mar 2005 15:29:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9UHp-00084D-EZ; Thu, 10 Mar 2005 15:29:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03038; Thu, 10 Mar 2005 15:29:35 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9UKh-0005kB-21; Thu, 10 Mar 2005 15:32:35 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 10 Mar 2005 12:43:53 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2AKTPZV004325; Thu, 10 Mar 2005 12:29:25 -0800 (PST) Received: from [130.129.133.35] (syd-vpn-client-254-109.cisco.com [10.66.254.109]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j2AKMkmJ015724; Thu, 10 Mar 2005 12:22:49 -0800 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FC18@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D46FC18@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <06b95eb9c88be8cf68489e6aac616867@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Iptel] tel loop detection and prevention Date: Thu, 10 Mar 2005 15:24:27 -0500 To: "Stastny Richard" X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1110486176.19286"; x:"432200"; a:"rsa-sha1"; b:"nofws:4443"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"QHXvTfPhaBRdgrg/guz5ADq0/XDjYgmmjzlGPQGQjbZoN1ZA0vfWOfOIzK0ezq08Ay3QnPbq" "Hzj+UoLla0HK8ok2HuPYOGetDaeV9xO7BwpgVM7t3mZ5WN2v2KL5pLOoE5oIWaZclB+dX++5b1f" "yEUSV0AesNWvkGdogPcr4c84="; c:"From: David R Oran "; c:"Subject: Re: [Iptel] tel loop detection and prevention"; c:"Date: Thu, 10 Mar 2005 15:24:27 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org, enum@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: 7bit On Mar 10, 2005, at 2:47 PM, Stastny Richard wrote: > David, > > On the counter in enumdi: > > Basically the enumdi is used in signalling between VoIP network > elements > the loop need to be detected WITHIN a VoIP network element before the > enumdi is set, so this counter does not help there I disagree. If the translator does not traverse the entire cycle before stopping and forwarding the invite, you can still get loops. If you don't want to have a counter, the spec then has to say that a translator MUST continue doing translations until it either gets a non-TEL url or detects a loop and gives up. > In addition the counter issue was discussed last meeting and rejected. > I remember the discussion and recall that we did not consider the distributed case at that time. Now that Juha has brought up the need to support the distributed case, the distributed loop detect question needs to be revisited since now loops are not automagically suppressed by a boolean dip indicator. > On the "magic" solution: > Please propose text to be put into the draft > and not home work for editors > What I suggested is that the loop max be either a) configured on the proxy b) rendered unnecessary by implementing a loop-detect algorithm that does not require configuration of a maximum degree parameter. > Or should we put the following text in the I-D: > > If you want to detect loops, go read Vol.1 of Knuth ? > Sort of. Say you MUST detect loops. Say that there is no architecturally-mandated translation chain maximum. Say that if you can live with occasional false loop detections for the (hopefully uncommon) case of high-degree loops, you can implement a translation-max which you compare with the enumdi count, but that if you want to avoid false detections, you can implement something fancier, such as the scheme in Vol.1 or Knuth. Cheers, Dave. > Richard > > > ________________________________ > > Von: David R Oran [mailto:oran@cisco.com] > Gesendet: Do 10.03.2005 20:32 > An: Stastny Richard > Cc: iptel@ietf.org; enum@ietf.org > Betreff: Re: [Iptel] tel loop detection and prevention > > > > There are MUCH better ways to deal with the loop issue. See below. > > On Mar 10, 2005, at 10:01 AM, Stastny Richard wrote: > >> Dear all, >> New text to be added >> 4.3 Loop detection and prevention >> >> If the result of the query contains another tel: URI with a >> different >> E.164 number, the VoIP network element may either choose to pass >> the >> retrieved "tel:" URI to the next network element with the "enumdi" >> indicator set or the network element may choose to make another >> ENUM >> query with the "tel" URI retrieved, looking for the same >> Enumservice. >> >> To prevent endless loops, the network element MUST do only up to 5 >> such queries >> until the result is resolved as described in section 4.2. > This is unreasonable (or at least incredibly ugly). Magic numbers > should be avoided like the plague. Not to mention that it does not > solve the problem in the distributed case... > > Two suggestions: > 1) make the enumdi a counter rather than a boolean. It would hold the > translation count. Note that this is *not* the number of calls to some > enum resolution service, but rather then number of translations that > have been done. This will be the same if the caller is querying > directly via a dns resolver, but may result in a count higher than 1 if > there is some kind of recursive lookup client API on the system doing > the enum translations. > 2) Base the loop detect on the counter. > > A dumb client can just decide on a maximum value as part of its > configuration. We could suggest a default value, but that is different > from mandating a constant value as a magic number. However, this is > actually not necessary - those interested read on. > > I mentioned privately to a few people that there is a really elegant > way to detect loops of the sort introduced by cyclic database pointers > in a distributed database (like DNS). I used in a distributed naming > service I designed about 20 years ago, and it worked like a charm. It's > based on an algorithm in Vol.1 of Knuth which everybody reads and then > promptly forgets in their CS training. It's called "even-odd iteration > counting" - go look it up. > > It has the following wonderful properties. > a) works in constant memory (two string variables) > b) never falsely detects a loop in a long translation chain > c) detects all loops of degree 2 immediately > d) detects all loops of degree 3 after one time around the loop > e) detects a loop of arbitrary degree after traversing the loop no more > than 3 times. > > Dave. > >> If this is not >> the case, or a number already queried should be queried again, the >> call >> should be dropped by the VoIP network element by signaling back >> service >> not available. >> >> End of new text >> >> regards >> Richard >> >> _______________________________________________ >> Iptel mailing list >> Iptel@ietf.org >> https://www1.ietf.org/mailman/listinfo/iptel >> > David R. Oran > Cisco Fellow > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 USA > Tel: +1 978 264 2048 > Email: oran@cisco.com > > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Mar 10 15:52:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05352 for ; Thu, 10 Mar 2005 15:52:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Uh3-0006tL-VY for iptel-web-archive@ietf.org; Thu, 10 Mar 2005 15:55:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9UXr-0004Cg-UU; Thu, 10 Mar 2005 15:46:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9UXn-0004CX-O1; Thu, 10 Mar 2005 15:46:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04712; Thu, 10 Mar 2005 15:46:05 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Uae-0006Z7-8t; Thu, 10 Mar 2005 15:49:05 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 10 Mar 2005 13:01:33 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,154,1107763200"; d="scan'208"; a="618806841:sNHT26016324" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2AKjpuC028350; Thu, 10 Mar 2005 12:45:51 -0800 (PST) Received: from [130.129.133.35] (rtp-vpn2-67.cisco.com [10.82.240.67]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j2AKdKXr015838; Thu, 10 Mar 2005 12:39:21 -0800 In-Reply-To: <7ba08e54ace96acf95842a162f6b3b90@insensate.co.uk> References: <32755D354E6B65498C3BD9FD496C7D46FC18@oefeg-s04.oefeg.loc> <7ba08e54ace96acf95842a162f6b3b90@insensate.co.uk> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Iptel] tel loop detection and prevention Date: Thu, 10 Mar 2005 15:44:04 -0500 To: lconroy X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1110487164.698684"; x:"432200"; a:"rsa-sha1"; b:"nofws:6436"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"HrR0M0l90TCa7/KewMlFHsar0j/bwZRmMPS+laCXjhJE5QSwNuEnPD+ZDW2epsXA/0nWiklV" "RJEAGKltJodR7ZBdz775qe05TRr2ms4vbFTr3j0FGHGtxJUVU1uRH0ulfI1eMu7C0eWHIziD9tn" "l8DYd2hEFx25lOtFArtPrI0w="; c:"From: David R Oran "; c:"Subject: Re: [Iptel] tel loop detection and prevention"; c:"Date: Thu, 10 Mar 2005 15:44:04 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org, enum@ietf.org, Stastny Richard X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Content-Transfer-Encoding: 7bit On Mar 10, 2005, at 3:15 PM, lconroy wrote: > Hi Dave, Richard, Juha, folks, > I'm also glad that someone else has finally commented on something > that's > been in the ENUM Experiences draft since 2003 - I'm very happy if we > can > improve that, as the "depth limit" of 5 is (and always has been) a > kludge. > ---- > Re. the even-odd solution: > I had thought that "even-odd" required distributed control - in the > case It works better if you send the values of the two memory cells instead of the count (since the count has only tell you if you are in the even or odd part of the chain when you forward). Since you are in fact forwarding MAx-forwards will eventually suppress the chain. In the absence of max-forwards as a backup you would be right that a counter is insufficient state to encode into the forwarded message. > of ENUM the nasty cases occur when the zones are under completely > independent > control and the NAPTRs they contain may not include this flag -at all-. > Sure. > I'd greatly appreciate a clarification one the use of this algorithm, > as it > is an *awful* long time since I looked at that fine book, and I > obviously > didn't understand it (or have miss-remembered it). > Did the above help? > ---- > I'm afraid that I disagree with my learned co-author on the proposed > text. > > (i) The broken behaviour is a proxy that does an ENUM look up when it > receives a tel: URI but then stops and just passes the result > onwards. > It either handles a tel: URI or it doesn't. If it re-tried until > it > found a URI it liked, or detected a loop (NXDOMAIN is already > covered), > the problem wouldn't occur. > Correct. This was the point I made in a message I sent a little while ago. > (ii) This is an ENUM "Dip" Indicator flag. It indicates that the > element > has done an ENUM query on this telephone number, or otherwise > KNOWS > that there is no useful data associated with it in ENUM. Of > course, > the sending element may always lie. It may not have done an ENUM > query at all on the number. It might choose to do this to force > the > receiving element to place a call to the PSTN or fail. However, > that > is not a compliant use of this flag - you can lie, but it's a lie. > > Thus, if we MUST allow broken proxies to push the problem onwards, then > I believe that the 1st paragraph for 4.3 will have to be: > ------------ > If the result of the query contains another tel: URI with a > different > E.164 number, the VoIP network element MAY either choose to pass the > original "tel:" URI to the next network element with the "enumdi" > indicator set or the network element MAY choose to make another ENUM > query with the "tel" URI retrieved, looking for the same > Enumservice. > ------------ > i.e. the proxy MUST NOT pass on a request with the TEL: URI it has > retrieved > from ENUM with the enumdi flag set, as that would be a lie. > Unless we change it to a count... > Instead, the original TEL: URI is passed on, with the flag set. This > is the > number it HAS checked in ENUM. > > What does this mean, exactly? Your above says is means "the number in the uri was input to an enum query". I thought it was supposed to mean "the number in the uri was the RESULT of an enum query. I don't see what good this does Juha if it's the input, not the output. Or perhaps I misunderstood what Juha was asking for. Dave. > all the best, > Lawrence > > On 10 Mar 2005, at 19:47, Stastny Richard wrote: >> David, >> >> On the counter in enumdi: >> >> Basically the enumdi is used in signalling between VoIP network >> elements >> the loop need to be detected WITHIN a VoIP network element before the >> enumdi is set, so this counter does not help there >> In addition the counter issue was discussed last meeting and rejected. >> >> On the "magic" solution: >> Please propose text to be put into the draft >> and not home work for editors >> >> Or should we put the following text in the I-D: >> >> If you want to detect loops, go read Vol.1 of Knuth ? >> >> Richard >> >> >> ________________________________ >> >> Von: David R Oran [mailto:oran@cisco.com] >> Gesendet: Do 10.03.2005 20:32 >> An: Stastny Richard >> Cc: iptel@ietf.org; enum@ietf.org >> Betreff: Re: [Iptel] tel loop detection and prevention >> >> >> >> There are MUCH better ways to deal with the loop issue. See below. >> >> On Mar 10, 2005, at 10:01 AM, Stastny Richard wrote: >> >>> Dear all, >>> New text to be added >>> 4.3 Loop detection and prevention >>> >>> If the result of the query contains another tel: URI with a >>> different >>> E.164 number, the VoIP network element may either choose to pass >>> the >>> retrieved "tel:" URI to the next network element with the "enumdi" >>> indicator set or the network element may choose to make another >>> ENUM >>> query with the "tel" URI retrieved, looking for the same >>> Enumservice. >>> >>> To prevent endless loops, the network element MUST do only up to 5 >>> such queries >>> until the result is resolved as described in section 4.2. >> This is unreasonable (or at least incredibly ugly). Magic numbers >> should be avoided like the plague. Not to mention that it does not >> solve the problem in the distributed case... >> >> Two suggestions: >> 1) make the enumdi a counter rather than a boolean. It would hold the >> translation count. Note that this is *not* the number of calls to some >> enum resolution service, but rather then number of translations that >> have been done. This will be the same if the caller is querying >> directly via a dns resolver, but may result in a count higher than 1 >> if >> there is some kind of recursive lookup client API on the system doing >> the enum translations. >> 2) Base the loop detect on the counter. >> >> A dumb client can just decide on a maximum value as part of its >> configuration. We could suggest a default value, but that is different >> from mandating a constant value as a magic number. However, this is >> actually not necessary - those interested read on. >> >> I mentioned privately to a few people that there is a really elegant >> way to detect loops of the sort introduced by cyclic database pointers >> in a distributed database (like DNS). I used in a distributed naming >> service I designed about 20 years ago, and it worked like a charm. >> It's >> based on an algorithm in Vol.1 of Knuth which everybody reads and then >> promptly forgets in their CS training. It's called "even-odd iteration >> counting" - go look it up. >> >> It has the following wonderful properties. >> a) works in constant memory (two string variables) >> b) never falsely detects a loop in a long translation chain >> c) detects all loops of degree 2 immediately >> d) detects all loops of degree 3 after one time around the loop >> e) detects a loop of arbitrary degree after traversing the loop no >> more >> than 3 times. >> >> Dave. >> >>> If this is not >>> the case, or a number already queried should be queried again, the >>> call >>> should be dropped by the VoIP network element by signaling back >>> service >>> not available. >>> >>> End of new text >>> >>> regards >>> Richard >>> >>> _______________________________________________ >>> Iptel mailing list >>> Iptel@ietf.org >>> https://www1.ietf.org/mailman/listinfo/iptel >>> >> David R. Oran >> Cisco Fellow >> Cisco Systems >> 7 Ladyslipper Lane >> Acton, MA 01720 USA >> Tel: +1 978 264 2048 >> Email: oran@cisco.com >> >> >> >> _______________________________________________ >> Iptel mailing list >> Iptel@ietf.org >> https://www1.ietf.org/mailman/listinfo/iptel >> >> > --------------------------------------- > lawrence conroy |tel:+44-1794-833666 > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Mar 10 16:28:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08503 for ; Thu, 10 Mar 2005 16:28:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9VFP-0000Mq-Sp for iptel-web-archive@ietf.org; Thu, 10 Mar 2005 16:31:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9VBO-0006kH-Sq; Thu, 10 Mar 2005 16:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9VBN-0006k9-EB; Thu, 10 Mar 2005 16:27:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08432; Thu, 10 Mar 2005 16:26:59 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D9VEF-0000Fb-Nk; Thu, 10 Mar 2005 16:30:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Enum] Re: [Iptel] tel loop detection and prevention Date: Thu, 10 Mar 2005 22:29:13 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D46FC1A@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Re: [Iptel] tel loop detection and prevention Thread-Index: AcUltDYwHC2Qkb5JQaWLf7sSF4pMqwAAes42 From: "Stastny Richard" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "David R Oran" X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: iptel@ietf.org, enum@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Thank you Patrik for getting this dicusion back on track, I was getting lost already =20 I agree with you that we have to sepate the issues again and there are three separate topics =20 1. the prorpose of the enumdi is basically to tell the NEXT network = element that an ENUM query has been done on the E.164 number. period. It may do another ENUM query or not. A counter does not add anything = here. =20 2. Loop detection is necessary, and each network elemnt has to do this on his own. the enumdi may just prevent the next network element to run into a loop again, but if it chosses ignore the enumdi, it is up to this = network elemnt to detect a loop. =20 I am fine with Davids text if this is agreed =20 3. the last issue also mixed in was the action the network element = should take if it detects a loop. If have not heard a clear answer to this yet I see two options here: a. signal back service not available b. take the original tel URI (the one sent in in most cases by the client) and act the same way as decribed for NXDOMAIN or same number. =20 option c to take the last number queried is not a good chioce, because this may depend on the loop detection algorithm. =20 If this approach is agreed I will try tp formulate a new text proposal =20 richard =20 ________________________________ Von: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] Gesendet: Do 10.03.2005 21:57 An: David R Oran Cc: Stastny Richard; iptel@ietf.org; enum@ietf.org Betreff: Re: [Enum] Re: [Iptel] tel loop detection and prevention On Mar 10, 2005, at 14:24, David R Oran wrote: >> If you want to detect loops, go read Vol.1 of Knuth ? >> > Sort of. Say you MUST detect loops. Say that there is no > architecturally-mandated translation chain maximum. Say that if you > can live with occasional false loop detections for the (hopefully > uncommon) case of high-degree loops, you can implement a > translation-max which you compare with the enumdi count, but that if > you want to avoid false detections, you can implement something > fancier, such as the scheme in Vol.1 or Knuth. Yes. We have to disconnect the existence of the protocol parameter enumdi (in the future) and the need for loop detection. Loop detection can possibly be done in many ways. I.e. a network element that receive some signalling and know how to do ENUM lookup can use the enumdi parameter for what it is, that enum lookup has been done. It doesn't say doing yet another enum lookup is forbidden. Loop detection is a MUST. I agree with this. paf _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Mar 10 16:54:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11388 for ; Thu, 10 Mar 2005 16:54:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Vf6-0001is-5x for iptel-web-archive@ietf.org; Thu, 10 Mar 2005 16:57:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9VaW-0005YU-9H; Thu, 10 Mar 2005 16:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9VaQ-0005V4-Ga; Thu, 10 Mar 2005 16:52:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11286; Thu, 10 Mar 2005 16:52:51 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D9VdI-0001Y5-2X; Thu, 10 Mar 2005 16:55:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Iptel] tel loop detection and prevention Date: Thu, 10 Mar 2005 22:53:28 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D46FC1E@oefeg-s04.oefeg.loc> Thread-Topic: Re: [Iptel] tel loop detection and prevention Thread-Index: AcUluubTY4E2HKRFTbuVV72FaM1W0AAALEDT From: "Stastny Richard" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: iptel@ietf.org, enum@ietf.org, David R Oran X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable >Is this not a local policy that is highly dependent on context? >I.e. that all of the above is possible. Agree, we may also offer the two options to choose from Richard ________________________________ Von: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] Gesendet: Do 10.03.2005 22:39 An: Stastny Richard Cc: David R Oran; iptel@ietf.org; enum@ietf.org Betreff: Re: AW: [Enum] Re: [Iptel] tel loop detection and prevention On Mar 10, 2005, at 15:29, Stastny Richard wrote: > 3. the last issue also mixed in was the action the network element > should take > if it detects a loop. If have not heard a clear answer to this yet > I see two options here: > a. signal back service not available > b. take the original tel URI (the one sent in in most cases by the > client) and act the same way as decribed for NXDOMAIN or same number. Is this not a local policy that is highly dependent on context? I.e. that all of the above is possible. paf _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Mar 10 17:17:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13380 for ; Thu, 10 Mar 2005 17:17:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9W0p-0002mE-JL for iptel-web-archive@ietf.org; Thu, 10 Mar 2005 17:20:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9VsB-0001tc-S5; Thu, 10 Mar 2005 17:11:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Vs9-0001tB-QN; Thu, 10 Mar 2005 17:11:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12848; Thu, 10 Mar 2005 17:11:11 -0500 (EST) Received: from 213-152-49-126.dsl.eclipse.net.uk ([213.152.49.126] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Vv2-0002TT-3f; Thu, 10 Mar 2005 17:14:12 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 281B064B36; Thu, 10 Mar 2005 22:14:21 +0000 (GMT) In-Reply-To: <0335a40d97378bb6f5d04c1edea3cfbb@ag-projects.com> References: <32755D354E6B65498C3BD9FD496C7D46FC1A@oefeg-s04.oefeg.loc> <0335a40d97378bb6f5d04c1edea3cfbb@ag-projects.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <55d4f12d9815ac51961c50e3fbcc80cd@insensate.co.uk> Content-Transfer-Encoding: quoted-printable From: lconroy Subject: Re: AW: [Enum] Re: [Iptel] tel loop detection and prevention Date: Thu, 10 Mar 2005 22:11:05 +0000 To: Adrian Georgescu X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, David R Oran , Stastny Richard , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Content-Transfer-Encoding: quoted-printable Hi Everyone, this is slightly tangled. There are two cases: (i) The application that requests the ENUM lookup(s) has to do loop =20 detection if if chooses to re-query ENUM based on the content of an initial ENUM = =20 query. This was Juha's original issue. (ii) The ENUM client itself has to deal with a potential loop, when =20 processing non-final NAPTRs. It's this second case that's covered in the ENUM Experiences draft =20 already - we recommended a Max-Queries value as a vary basic "loop quencher" for =20 THIS case. It's ugly, but it does work, and I defy anyone to produce a =20 provisioning system that handles a greater depth of ENUM domains and remain sane, so false =20= positives are unlikely and/or a sign of serious strangeness on the part of the =20 ENUM zones being searched. ---- The first case (Application using ENUM) is a separate issue - the ENUM =20= client can't really help, as it doesn't retain state beyond the end of each final =20 look up. I think that we're converging on an agreement that each individual =20 element MUST deal with this kind of loop detection on its own. How it does loop detection is a local issue and is out of scope of the =20= ENUMDI draft. ";enumdi" only states that an ENUM query has been done *on this number* =20= (i.e. the number is the input to an ENUM query). No - it doesn't help a distributed set of elements from breaking the =20 loop - but this is not its job. Each element must do this detection. It can be =20 done, and is being done, but if an element doesn't deal with this problem, it's =20 broken. is this all correct? all the best, Lawrence ------------------------------------------------------------------------=20= --------- On 10 Mar 2005, at 21:45, Adrian Georgescu wrote: > On Mar 10, 2005, at 3:29 PM, Stastny Richard wrote: >> Thank you Patrik for getting this dicusion back on track, >> I was getting lost already >> >> I agree with you that we have to sepate the issues again and there >> are three separate topics >> >> 1. the prorpose of the enumdi is basically to tell the NEXT network =20= >> element >> that an ENUM query has been done on the E.164 number. period. >> It may do another ENUM query or not. A counter does not add anything =20= >> here. > > I think the same > >> 2. Loop detection is necessary, and each network elemnt has to do = this >> on his own. the enumdi may just prevent the next network element to =20= >> run >> into a loop again, but if it chosses ignore the enumdi, it is up to =20= >> this network >> elemnt to detect a loop. > > I like this approach. ENUM is not the only way we can enter an endless = =20 > loop and counting the ENUM lookups is not the solution. There are =20 > aliases, conditional or unconditional redirections that may be =20 > combined with ENUM look-ups. Each routing element should detect a loop = =20 > across multiple type of lookups, it is up to the application to do =20 > this. > >> I am fine with Davids text if this is agreed >> >> 3. the last issue also mixed in was the action the network element =20= >> should take >> if it detects a loop. If have not heard a clear answer to this yet >> I see two options here: >> a. signal back service not available > > This is good, we use a similar setup and we currently send Loop =20 > detected as release status back. > > Adrian > >> b. take the original tel URI (the one sent in in most cases by the >> client) and act the same way as decribed for NXDOMAIN or same number. >> >> option c to take the last number queried is not a good chioce, = because >> this may depend on the loop detection algorithm. >> >> If this approach is agreed I will try tp formulate a new text = proposal >> >> richard >> >> ________________________________ >> >> Von: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] >> Gesendet: Do 10.03.2005 21:57 >> An: David R Oran >> Cc: Stastny Richard; iptel@ietf.org; enum@ietf.org >> Betreff: Re: [Enum] Re: [Iptel] tel loop detection and prevention >> >> >> >> On Mar 10, 2005, at 14:24, David R Oran wrote: >> >>>> If you want to detect loops, go read Vol.1 of Knuth ? >>>> >>> Sort of. Say you MUST detect loops. Say that there is no >>> architecturally-mandated translation chain maximum. Say that if you >>> can live with occasional false loop detections for the (hopefully >>> uncommon) case of high-degree loops, you can implement a >>> translation-max which you compare with the enumdi count, but that if >>> you want to avoid false detections, you can implement something >>> fancier, such as the scheme in Vol.1 or Knuth. >> >> Yes. >> >> We have to disconnect the existence of the protocol parameter enumdi >> (in the future) and the need for loop detection. Loop detection can >> possibly be done in many ways. >> >> I.e. a network element that receive some signalling and know how to = do >> ENUM lookup can use the enumdi parameter for what it is, that enum >> lookup has been done. It doesn't say doing yet another enum lookup is >> forbidden. >> >> Loop detection is a MUST. I agree with this. >> >> paf >> >> >> >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> https://www1.ietf.org/mailman/listinfo/enum > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Mar 10 17:28:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14261 for ; Thu, 10 Mar 2005 17:28:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9WBk-0003KT-KD for iptel-web-archive@ietf.org; Thu, 10 Mar 2005 17:31:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9W6K-00069B-3e; Thu, 10 Mar 2005 17:25:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9W6H-00068l-Co; Thu, 10 Mar 2005 17:25:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14088; Thu, 10 Mar 2005 17:25:46 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D9W9A-0003By-71; Thu, 10 Mar 2005 17:28:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Mar 2005 23:24:24 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D46FC1F@oefeg-s04.oefeg.loc> Thread-Topic: Loop detection and prevention - 2nd try Thread-Index: AcUlvmems4zY8OSXSKK6NS2NOeaALAAAYKSe From: "Stastny Richard" To: "lconroy" , "Adrian Georgescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, David R Oran , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , iptel@ietf.org Subject: [Iptel] Loop detection and prevention - 2nd try X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Folks, =20 here the 2nd text proposal: =20 4.2 Adding the "enumdi" parameter to URIs =20 When a VoIP network element accesses ENUM in e164.arpa for a given E.164 number and the result of the query is NXDOMAIN, and the network element chooses to pass the call to the next network element by using a "tel" URI, the "enumdi" parameter MUST be set. =20 When a VoIP network element accesses ENUM in e164.arpa for a given E.164 number and either: o the result of the query includes a NAPTR RR containing a "tel" URI that has the same E.164 number, or o the result of the query includes a NAPTR RR containing a "tel" URI with the "enumdi" parameter set, then if that retrieved "tel" URI is chosen to be passed to the next network element, the sending VoIP network element MUST pass on the retrieved URI with the "enumdi" parameter set. =20 4.3 Loop detection and prevention =20 If the result of the query contains another tel: URI with a different E.164 number, and the network element chooses to make another ENUM=20 query with the "tel" URI retrieved in the previous query, an endless loop may occur.=20 =20 The VoIP network element MUST be able to detect such loops. The = implementation of a proper algorithm is left to the VoIP network element. This could = be a simple algorithm such as upper limit of the number queries or=20 sophisticated ones as described e.g. in [KNUTH]. =20 If a loop is detected, the VoIP network element may either drop the = call and signal back to the previous network element with the proper = signaling available (e.g. loop detected or service not available) or it may = take the original received tel URI and act in the same way as described above = if the=20 result of the query is NXDOMAIN. =20 [KNUTHl Algoritmos Fundamentales - Vol. I by D. E. Knuth (out of print) _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Fri Mar 11 00:39:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20268 for ; Fri, 11 Mar 2005 00:39:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9cvI-0006gy-Sb for iptel-web-archive@ietf.org; Fri, 11 Mar 2005 00:42:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9cpZ-0004SE-IO; Fri, 11 Mar 2005 00:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9cpU-0004S6-Hy; Fri, 11 Mar 2005 00:36:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20111; Fri, 11 Mar 2005 00:36:53 -0500 (EST) Received: from harjus.tutpro.com ([192.98.100.3] ident=Debian-exim) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9csQ-0006Z5-8r; Fri, 11 Mar 2005 00:39:59 -0500 Received: from jh by harjus.tutpro.com with local (Exim 4.44) id 1D9cpO-0002gZ-E9; Fri, 11 Mar 2005 07:36:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16945.11890.335078.531252@harjus.tutpro.com> Date: Fri, 11 Mar 2005 07:36:50 +0200 To: David R Oran Subject: Re: [Iptel] tel loop detection and prevention In-Reply-To: References: <32755D354E6B65498C3BD9FD496C7D46FC18@oefeg-s04.oefeg.loc> <7ba08e54ace96acf95842a162f6b3b90@insensate.co.uk> X-Mailer: VM 7.19 under Emacs 21.3.1 From: Juha Heinanen X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org, enum@ietf.org, Stastny Richard , lconroy X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit David R Oran writes: > I don't see what good this does Juha if it's the input, not the > output. Or perhaps I misunderstood what Juha was asking for. no you didn't misunderstood me. i have written an enum module for a high-performance open source sip proxy and don't want that proxy to be subject to enum dos attacks that would force the proxy to make several enum queries (and analyze the result) for each sip request. i would therefore like to be able to mark that a tel uri was a result of an enum query and if i see that kind of tel uri, i would not do another enum query on it. so i very much like your count idea. -- juha _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Fri Mar 11 05:19:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03863 for ; Fri, 11 Mar 2005 05:19:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9hIF-0002fn-DE for iptel-web-archive@ietf.org; Fri, 11 Mar 2005 05:22:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9hDf-0000C5-Sz; Fri, 11 Mar 2005 05:18:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9hDW-0000BW-GE for iptel@megatron.ietf.org; Fri, 11 Mar 2005 05:18:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03725 for ; Fri, 11 Mar 2005 05:18:00 -0500 (EST) Received: from 213-152-49-126.dsl.eclipse.net.uk ([213.152.49.126] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9hGU-0002Xt-IY for iptel@ietf.org; Fri, 11 Mar 2005 05:21:08 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 2365D64C9F; Fri, 11 Mar 2005 10:21:08 +0000 (GMT) In-Reply-To: <16945.11890.335078.531252@harjus.tutpro.com> References: <32755D354E6B65498C3BD9FD496C7D46FC18@oefeg-s04.oefeg.loc> <7ba08e54ace96acf95842a162f6b3b90@insensate.co.uk> <16945.11890.335078.531252@harjus.tutpro.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4075fd0d31be9b70bd0f117ddde646ab@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Iptel] tel loop detection and prevention Date: Fri, 11 Mar 2005 10:17:53 +0000 To: Juha Heinanen X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org, Stastny Richard X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Hi Juha, Richard, folks, [Trimmed to IPTEL only as poster is not registered on other MLs] (i) With Richard's proposed text, ";enumdi" does what is intended. ";enumdi" is not a "Query To Live" (QTL) parameter, so if you want one to make the algorithm YOUR proxy runs easier, write a new draft. BUT... (ii) IMHO, if you choose to only ever do one query in ENUM, you lose. A small set of linked domains can be a perfectly valid ENUM setup (where small is a maximum of three or four). If your code doesn't like the URI it gets, then IMHO it should either fail the INVITE immediately with a 5xx response, or try again and detect loops itself, rather than propagate the problem "down" a chain. [BTW, a mail loop is often a miss-configuration and not *intended* as a DOS attack, and likewise it may be unwise to assume that it is an attack if you detect an ENUM loop]. (iii) AFAICT, the only way that such a QTL count would work is if it were to be a ->mandatory<- parameter in tel: URIs sent by all SIP devices, AND ->mandatory<- to be re-written (to reduce the QTL count) at every ENUM-querying proxy in the chain. As an evil proxy, I think I could set this count to 64000 and point the next proxy at a looped domain, so the chain would still spin its wheels. This is starting to look like the discussions on SIP URI "loop vs. spiral detection" of a few years back - my head has just stopped hurting after that last thread, so please don't start that up again (and if so, on the SIP ML, not here :). all the best, Lawrence On 11 Mar 2005, at 05:36, Juha Heinanen wrote: > David R Oran writes: >> I don't see what good this does Juha if it's the input, not the >> output. Or perhaps I misunderstood what Juha was asking for. > no you didn't misunderstood me. i have written an enum module for a > high-performance open source sip proxy and don't want that proxy to be > subject to enum dos attacks that would force the proxy to make several > enum queries (and analyze the result) for each sip request. i would > therefore like to be able to mark that a tel uri was a result of an > enum > query and if i see that kind of tel uri, i would not do another enum > query on it. so i very much like your count idea. --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Fri Mar 11 09:38:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26850 for ; Fri, 11 Mar 2005 09:38:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9lKE-0006WB-M1 for iptel-web-archive@ietf.org; Fri, 11 Mar 2005 09:41:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9lG1-0008RD-Mr; Fri, 11 Mar 2005 09:36:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Uy0-0002xh-2A; Thu, 10 Mar 2005 16:13:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07474; Thu, 10 Mar 2005 16:13:09 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9V0s-00087w-6G; Thu, 10 Mar 2005 16:16:10 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 10 Mar 2005 22:27:51 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2AL6Llw009360; Thu, 10 Mar 2005 22:06:24 +0100 (MET) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Mar 2005 22:06:19 +0100 Received: from [127.0.0.1] ([144.254.226.40]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Mar 2005 22:06:18 +0100 In-Reply-To: References: <32755D354E6B65498C3BD9FD496C7D46FC11@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4efd525e1d7d640d62f7bbe35e597751@cisco.com> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] Re: [Iptel] tel loop detection and prevention Date: Thu, 10 Mar 2005 15:06:16 -0600 To: David R Oran X-Mailer: Apple Mail (2.619.2) X-OriginalArrivalTime: 10 Mar 2005 21:06:18.0563 (UTC) FILETIME=[00FA2930:01C525B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 11 Mar 2005 09:36:51 -0500 Cc: iptel@ietf.org, enum@ietf.org, Stastny Richard X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Good suggestion. paf On Mar 10, 2005, at 13:32, David R Oran wrote: > There are MUCH better ways to deal with the loop issue. See below. > > On Mar 10, 2005, at 10:01 AM, Stastny Richard wrote: > >> Dear all, >> New text to be added >> 4.3 Loop detection and prevention >> >> If the result of the query contains another tel: URI with a >> different >> E.164 number, the VoIP network element may either choose to pass >> the >> retrieved "tel:" URI to the next network element with the "enumdi" >> indicator set or the network element may choose to make another >> ENUM >> query with the "tel" URI retrieved, looking for the same >> Enumservice. >> >> To prevent endless loops, the network element MUST do only up to 5 >> such queries >> until the result is resolved as described in section 4.2. > This is unreasonable (or at least incredibly ugly). Magic numbers > should be avoided like the plague. Not to mention that it does not > solve the problem in the distributed case... > > Two suggestions: > 1) make the enumdi a counter rather than a boolean. It would hold the > translation count. Note that this is *not* the number of calls to some > enum resolution service, but rather then number of translations that > have been done. This will be the same if the caller is querying > directly via a dns resolver, but may result in a count higher than 1 > if there is some kind of recursive lookup client API on the system > doing the enum translations. > 2) Base the loop detect on the counter. > > A dumb client can just decide on a maximum value as part of its > configuration. We could suggest a default value, but that is different > from mandating a constant value as a magic number. However, this is > actually not necessary - those interested read on. > > I mentioned privately to a few people that there is a really elegant > way to detect loops of the sort introduced by cyclic database pointers > in a distributed database (like DNS). I used in a distributed naming > service I designed about 20 years ago, and it worked like a charm. > It's based on an algorithm in Vol.1 of Knuth which everybody reads and > then promptly forgets in their CS training. It's called "even-odd > iteration counting" - go look it up. > > It has the following wonderful properties. > a) works in constant memory (two string variables) > b) never falsely detects a loop in a long translation chain > c) detects all loops of degree 2 immediately > d) detects all loops of degree 3 after one time around the loop > e) detects a loop of arbitrary degree after traversing the loop no > more than 3 times. > > Dave. > >> If this is not >> the case, or a number already queried should be queried again, the >> call >> should be dropped by the VoIP network element by signaling back >> service >> not available. >> >> End of new text >> >> regards >> Richard >> >> _______________________________________________ >> Iptel mailing list >> Iptel@ietf.org >> https://www1.ietf.org/mailman/listinfo/iptel >> > David R. Oran > Cisco Fellow > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 USA > Tel: +1 978 264 2048 > Email: oran@cisco.com > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Fri Mar 11 09:38:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26906 for ; Fri, 11 Mar 2005 09:38:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9lKg-0006Wz-4S for iptel-web-archive@ietf.org; Fri, 11 Mar 2005 09:41:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9lG1-0008Qn-9W; Fri, 11 Mar 2005 09:36:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9UjX-0006yL-G1; Thu, 10 Mar 2005 15:58:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06208; Thu, 10 Mar 2005 15:58:13 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9UmP-0007Lh-Gm; Thu, 10 Mar 2005 16:01:13 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 10 Mar 2005 12:58:27 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,154,1107763200"; d="scan'208"; a="166560985:sNHT4275828332" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j2AKuxYo029920; Thu, 10 Mar 2005 12:57:40 -0800 (PST) Received: from xbh-ams-331.cisco.com ([144.254.231.71]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Mar 2005 15:57:31 -0500 Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Mar 2005 21:57:27 +0100 Received: from [127.0.0.1] ([144.254.226.40]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Mar 2005 21:57:25 +0100 In-Reply-To: <06b95eb9c88be8cf68489e6aac616867@cisco.com> References: <32755D354E6B65498C3BD9FD496C7D46FC18@oefeg-s04.oefeg.loc> <06b95eb9c88be8cf68489e6aac616867@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] Re: [Iptel] tel loop detection and prevention Date: Thu, 10 Mar 2005 14:57:21 -0600 To: David R Oran X-Mailer: Apple Mail (2.619.2) X-OriginalArrivalTime: 10 Mar 2005 20:57:25.0738 (UTC) FILETIME=[C36384A0:01C525B3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 11 Mar 2005 09:36:51 -0500 Cc: iptel@ietf.org, enum@ietf.org, Stastny Richard X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit On Mar 10, 2005, at 14:24, David R Oran wrote: >> If you want to detect loops, go read Vol.1 of Knuth ? >> > Sort of. Say you MUST detect loops. Say that there is no > architecturally-mandated translation chain maximum. Say that if you > can live with occasional false loop detections for the (hopefully > uncommon) case of high-degree loops, you can implement a > translation-max which you compare with the enumdi count, but that if > you want to avoid false detections, you can implement something > fancier, such as the scheme in Vol.1 or Knuth. Yes. We have to disconnect the existence of the protocol parameter enumdi (in the future) and the need for loop detection. Loop detection can possibly be done in many ways. I.e. a network element that receive some signalling and know how to do ENUM lookup can use the enumdi parameter for what it is, that enum lookup has been done. It doesn't say doing yet another enum lookup is forbidden. Loop detection is a MUST. I agree with this. paf _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Fri Mar 11 09:38:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26984 for ; Fri, 11 Mar 2005 09:38:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9lKw-0006XW-DX for iptel-web-archive@ietf.org; Fri, 11 Mar 2005 09:41:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9lG3-0008Ra-0o; Fri, 11 Mar 2005 09:36:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9eHk-0004rn-3e; Fri, 11 Mar 2005 02:10:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07086; Fri, 11 Mar 2005 02:10:10 -0500 (EST) Received: from bartok.nlnetlabs.nl ([213.154.224.50]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9eKg-0002M7-Nz; Fri, 11 Mar 2005 02:13:15 -0500 Received: from bartok.nlnetlabs.nl (localhost.nlnetlabs.nl [127.0.0.1]) by bartok.nlnetlabs.nl (8.13.3/8.13.1) with ESMTP id j2B79oi2067804; Fri, 11 Mar 2005 08:09:50 +0100 (CET) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200503110709.j2B79oi2067804@bartok.nlnetlabs.nl> To: Juha Heinanen Subject: Re: [Enum] Re: [Iptel] tel loop detection and prevention In-reply-to: Your message of Fri, 11 Mar 2005 07:36:50 +0200. <16945.11890.335078.531252@harjus.tutpro.com> Date: Fri, 11 Mar 2005 08:09:50 +0100 From: Jaap Akkerhuis X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Fri, 11 Mar 2005 09:36:51 -0500 Cc: iptel@ietf.org, enum@ietf.org, David R Oran X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 David R Oran writes: and juha writes: [Messages deleted]. There are a stream of messages which needed to be approved by hand. Probably due to the cross posting with iptel@ietf.org. Note that these messages are easely missed due to the enormous amount of spam to filter and/or will might be delayed because the enum maillist admins have day job beside filtering spam from the enum list. So please, subscribe to the enum list or don't cross post. Thanks in advance, jaap _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Fri Mar 11 09:39:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27002 for ; Fri, 11 Mar 2005 09:39:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9lL6-0006cq-V5 for iptel-web-archive@ietf.org; Fri, 11 Mar 2005 09:42:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9lG2-0008RN-IF; Fri, 11 Mar 2005 09:36:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9VUk-0003Ka-9U; Thu, 10 Mar 2005 16:47:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10814; Thu, 10 Mar 2005 16:46:59 -0500 (EST) Received: from mail1.dns-hosting.info ([81.23.228.144] helo=vm02.dns-hosting.info) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9VXc-0001JU-Ez; Thu, 10 Mar 2005 16:50:00 -0500 Received: from [130.129.66.103] (wired-130-129-66-103.ietf62.ietf.org [130.129.66.103]) (authenticated bits=0) by vm02.dns-hosting.info (8.13.1/8.13.1/Debian-16) with ESMTP id j2ALjlv6019305; Thu, 10 Mar 2005 22:45:49 +0100 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FC1A@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D46FC1A@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <0335a40d97378bb6f5d04c1edea3cfbb@ag-projects.com> Content-Transfer-Encoding: quoted-printable From: Adrian Georgescu Subject: Re: AW: [Enum] Re: [Iptel] tel loop detection and prevention Date: Thu, 10 Mar 2005 15:45:45 -0600 To: "Stastny Richard" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 11 Mar 2005 09:36:51 -0500 Cc: iptel@ietf.org, =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , David R Oran , enum@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable On Mar 10, 2005, at 3:29 PM, Stastny Richard wrote: > Thank you Patrik for getting this dicusion back on track, > I was getting lost already > > I agree with you that we have to sepate the issues again and there > are three separate topics > > 1. the prorpose of the enumdi is basically to tell the NEXT network=20= > element > that an ENUM query has been done on the E.164 number. period. > It may do another ENUM query or not. A counter does not add anything=20= > here. I think the same > 2. Loop detection is necessary, and each network elemnt has to do this > on his own. the enumdi may just prevent the next network element to = run > into a loop again, but if it chosses ignore the enumdi, it is up to=20 > this network > elemnt to detect a loop. I like this approach. ENUM is not the only way we can enter an endless=20= loop and counting the ENUM lookups is not the solution. There are=20 aliases, conditional or unconditional redirections that may be combined=20= with ENUM look-ups. Each routing element should detect a loop across=20 multiple type of lookups, it is up to the application to do this. > I am fine with Davids text if this is agreed > > 3. the last issue also mixed in was the action the network element=20 > should take > if it detects a loop. If have not heard a clear answer to this yet > I see two options here: > a. signal back service not available This is good, we use a similar setup and we currently send Loop=20 detected as release status back. Adrian > b. take the original tel URI (the one sent in in most cases by the > client) and act the same way as decribed for NXDOMAIN or same number. > > option c to take the last number queried is not a good chioce, because > this may depend on the loop detection algorithm. > > If this approach is agreed I will try tp formulate a new text proposal > > richard > > ________________________________ > > Von: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] > Gesendet: Do 10.03.2005 21:57 > An: David R Oran > Cc: Stastny Richard; iptel@ietf.org; enum@ietf.org > Betreff: Re: [Enum] Re: [Iptel] tel loop detection and prevention > > > > On Mar 10, 2005, at 14:24, David R Oran wrote: > >>> If you want to detect loops, go read Vol.1 of Knuth ? >>> >> Sort of. Say you MUST detect loops. Say that there is no >> architecturally-mandated translation chain maximum. Say that if you >> can live with occasional false loop detections for the (hopefully >> uncommon) case of high-degree loops, you can implement a >> translation-max which you compare with the enumdi count, but that if >> you want to avoid false detections, you can implement something >> fancier, such as the scheme in Vol.1 or Knuth. > > Yes. > > We have to disconnect the existence of the protocol parameter enumdi > (in the future) and the need for loop detection. Loop detection can > possibly be done in many ways. > > I.e. a network element that receive some signalling and know how to do > ENUM lookup can use the enumdi parameter for what it is, that enum > lookup has been done. It doesn't say doing yet another enum lookup is > forbidden. > > Loop detection is a MUST. I agree with this. > > paf > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Fri Mar 11 09:40:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27123 for ; Fri, 11 Mar 2005 09:40:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9lM7-0006eF-9y for iptel-web-archive@ietf.org; Fri, 11 Mar 2005 09:43:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9lG2-0008RI-25; Fri, 11 Mar 2005 09:36:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9VTx-0002tn-Iy; Thu, 10 Mar 2005 16:46:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10699; Thu, 10 Mar 2005 16:46:11 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9VWn-0001Ha-0q; Thu, 10 Mar 2005 16:49:12 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 10 Mar 2005 23:01:06 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2ALcxmK025725; Thu, 10 Mar 2005 22:39:37 +0100 (MET) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 10 Mar 2005 22:39:29 +0100 Received: from [127.0.0.1] ([144.254.226.40]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Mar 2005 22:39:28 +0100 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FC1A@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D46FC1A@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <035f050cbc021b6b9df56b2057efce13@cisco.com> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: AW: [Enum] Re: [Iptel] tel loop detection and prevention Date: Thu, 10 Mar 2005 15:39:27 -0600 To: "Stastny Richard" X-Mailer: Apple Mail (2.619.2) X-OriginalArrivalTime: 10 Mar 2005 21:39:29.0070 (UTC) FILETIME=[A3696CE0:01C525B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 11 Mar 2005 09:36:51 -0500 Cc: iptel@ietf.org, enum@ietf.org, David R Oran X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit On Mar 10, 2005, at 15:29, Stastny Richard wrote: > 3. the last issue also mixed in was the action the network element > should take > if it detects a loop. If have not heard a clear answer to this yet > I see two options here: > a. signal back service not available > b. take the original tel URI (the one sent in in most cases by the > client) and act the same way as decribed for NXDOMAIN or same number. Is this not a local policy that is highly dependent on context? I.e. that all of the above is possible. paf _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Fri Mar 11 10:47:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06429 for ; Fri, 11 Mar 2005 10:47:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9mPa-0001vL-Aw for iptel-web-archive@ietf.org; Fri, 11 Mar 2005 10:50:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9mFI-0008I5-N4; Fri, 11 Mar 2005 10:40:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9mFE-0008Hc-29; Fri, 11 Mar 2005 10:40:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05282; Fri, 11 Mar 2005 10:40:06 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9mIE-0001VK-V5; Fri, 11 Mar 2005 10:43:16 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 11 Mar 2005 07:54:40 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j2BFe1TM017792; Fri, 11 Mar 2005 07:40:03 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 11 Mar 2005 10:40:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Re: [Iptel] tel loop detection and prevention Date: Fri, 11 Mar 2005 10:39:59 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E304DA01@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Enum] Re: [Iptel] tel loop detection and prevention Thread-Index: AcUmSApycHt4R/ZcQGeYfgGxA8szTwAAnYJg From: "Michael Hammer \(mhammer\)" To: "Patrik Faltstrom \(pfaltstr\)" , "Dave Oran \(oran\)" X-OriginalArrivalTime: 11 Mar 2005 15:40:00.0935 (UTC) FILETIME=[9636F370:01C52650] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: iptel@ietf.org, enum@ietf.org, Stastny Richard X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: quoted-printable Patrik, I think we all agree that ENUM is extremely important to routing and that loops in dereferencing ENUM dips is a very bad thing. Thus we need to get this right the first time. What I haven't seen in this discussion anywhere is the notion of *Time Scale*, that is WHEN should the resolution of the dereferencing be done. Also, the primary purpose of ENUM was to enable an IP-based terminal to be reached using an E.164 telephone number. So, if a trade-off requires something to suffer, it should be translations in the opposite direction. Correct me if I am wrong, but ENUM registrations are on the order of hours or days and not likely to change often; while ENUM dips are on the order of milliseconds. Also, doing many ENUM dips also becomes a "post-dial delay" issue. That tells me that loop detection and correction should occur during the registration process, *NOT* during ENUM dips during session setup. This leads me to a simple rule: ENUM NAPTR records should be validated to ensure that an ENUM dip against any included tel:URI results in a negative hit. The consequence of this is that an ENUM client can safely be assured that it need only do a single dip against a tel:URI. =20 Of course, such a PSTN-based E.164 could later be migrated to an IP terminal and an ENUM record created. Registrars could periodically, during off-hours, test records that have tel:URI entries by doing a second dip. If a hit occurs, it would be a violation and 3 actions could be taken: 1) remove the tel:URI from the record, 2) replace the tel:URI with the results of the second ENUM dip (optional), 3) notify the first record holder of the problem and fix made. (That person may have an alternate registration solution.) Such checking is not a big deal during registration, but is during session setup. I found the idea that a node would do a single dip, then pass the message on to a second node that then will do a dip because the tel:URI would not have the ENUMDI set to be a recipe for looping via distributing the ENUM lookup process. To avoid this, I would suggest that a second ENUMPDI (ENUM Parent Dip Indicator) be created. The intent is to tell subsequent session processing nodes that this tel:URI resulted from an ENUM dip and should therefore be located in the PSTN. If the second node chooses to do an ENUM dip on a tel:URI with ENUMPDI, then it should also assume responsibility for reporting the presence of this registration error to the ENUM police, and likely should also fail the call until the registry is corrected. (This may fall to PSTN GWs to protect themselves as potential bottlenecks between the PSTN and IP domains.) That might also suggest an additional error or warning code for SIP, but so be it. Better to get the routing databases cleaned up immediately than sit there looping ENUM dips or calls. Mike >-----Original Message----- >From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org]=20 >On Behalf Of Patrik Faltstrom (pfaltstr) >Sent: Thursday, March 10, 2005 3:57 PM >To: Dave Oran (oran) >Cc: iptel@ietf.org; enum@ietf.org; Stastny Richard >Subject: Re: [Enum] Re: [Iptel] tel loop detection and prevention > > >On Mar 10, 2005, at 14:24, David R Oran wrote: > >>> If you want to detect loops, go read Vol.1 of Knuth ? >>> >> Sort of. Say you MUST detect loops. Say that there is no=20 >> architecturally-mandated translation chain maximum. Say that if you=20 >> can live with occasional false loop detections for the (hopefully >> uncommon) case of high-degree loops, you can implement a=20 >> translation-max which you compare with the enumdi count, but that if=20 >> you want to avoid false detections, you can implement something=20 >> fancier, such as the scheme in Vol.1 or Knuth. > >Yes. > >We have to disconnect the existence of the protocol parameter=20 >enumdi (in the future) and the need for loop detection. Loop=20 >detection can possibly be done in many ways. > >I.e. a network element that receive some signalling and know=20 >how to do ENUM lookup can use the enumdi parameter for what it=20 >is, that enum lookup has been done. It doesn't say doing yet=20 >another enum lookup is forbidden. > >Loop detection is a MUST. I agree with this. > > paf > >_______________________________________________ >Iptel mailing list >Iptel@ietf.org >https://www1.ietf.org/mailman/listinfo/iptel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Mar 30 14:37:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02482 for ; Wed, 30 Mar 2005 14:37:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGj7b-0000Nb-Uc for iptel-web-archive@ietf.org; Wed, 30 Mar 2005 14:45:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGiyh-0007JC-5L; Wed, 30 Mar 2005 14:35:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGiyf-0007J7-Dk for iptel@megatron.ietf.org; Wed, 30 Mar 2005 14:35:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02299 for ; Wed, 30 Mar 2005 14:35:43 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGj5d-0000LG-BX for iptel@ietf.org; Wed, 30 Mar 2005 14:42:57 -0500 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id j2UJYPKD006541; Wed, 30 Mar 2005 19:34:25 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Mar 2005 14:34:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Mar 2005 14:34:24 -0500 Message-ID: <165FCC93A820D240A62F98E028CEFED00145115D@stntexch01.cis.neustar.com> Thread-Topic: Scope of *rn* parameter in the context of LNP Thread-Index: AcU1SfirsyuAG88xSuaHFAznr/QTdgAE31Og From: "Yu, James" To: X-OriginalArrivalTime: 30 Mar 2005 19:34:25.0709 (UTC) FILETIME=[7B5265D0:01C5355F] X-Spam-Score: 0.3 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Cc: iptel@ietf.org, Gonzalo.Camarillo@Ericsson.com, "Peterson, Jon" Subject: [Iptel] RE: Scope of *rn* parameter in the context of LNP X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0857357900==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 This is a multi-part message in MIME format. --===============0857357900== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5355F.7AE2914E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5355F.7AE2914E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Chella, =20 There is no conflict . For example, a national routing number of = "202-533-0000" under country code 1 can be represented by a global = routing number as "+1-202-533-0000". Nodes outside the country code 1 = can route based on "+1" to a node that understands (e.g., be able to = route) the national routing numbers under country code 1. =20 For a PSTN international call to a ported number in another country, the = call is routed to the international switch of the destination country. = Number portability database dip will then be performed to determine the = national routing number within the destination PSTN. For an IP call, = it is possible that a node may learn the "global" routing number (e.g., = from the carrier/operator/infrastructure ENUM). My I-D would allow = that the global routing number be carried in the tel URI and be used for = routing within the IP domain. Whether the routing is based on the = country code, portion of the global routing number or the whole global = routing number is up to the node that processes the received tel URI. =20 James =20 -----Original Message----- From: Chelliah Sivachelvan (chelliah) [mailto:chelliah@cisco.com] Sent: Wednesday, March 30, 2005 12:00 PM To: Yu, James " =20 Cc: iptel@ietf.org; Gonzalo.Camarillo@Ericsson.com; Peterson, Jon Subject: Scope of *rn* parameter in the context of LNP=20 James: The current draft (draft-ietf-iptel-tel-np-04.txt) implies that the *rn* = parameter can contain global numbers (i.e., E.164 numbers) in the = context of LNP. This has also been illustrated in one of the examples in = section 6(c).=20 =20 But the scope of LNP is national; as such the scope of routing number = (LRN) is not a globally reachable number. Therefore, it must be treated = as a national number. RFC-3388 also makes a strong statement on this = very subject. Here is the excerpts from RFC-3388 (section 8.2.1.1 )=20 =20 "LRNs are necessarily national in scope, and consequently they MUST = NOT be preceded by a '+' in the 'rn=3D' field." =20 =20 We need to resolve the discrepancies between the two specs. =20 =20 Thanks! Chella =20 =20 Cisco Systems, 2200 East President George Bush Turnpike , Richardson, TX 75082 Tel: 469.255.1169 =20 ------_=_NextPart_001_01C5355F.7AE2914E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Chella,
 
There=20 is no conflict .  For example, a national routing number of = "202-533-0000"=20 under country code 1 can be represented by a global routing = number as=20 "+1-202-533-0000".  Nodes outside the country code 1 can route = based on=20 "+1" to a node that understands (e.g., be able to route) the national = routing=20 numbers under country code 1.
 
For a PSTN international call to a ported number in = another country,=20 the call is routed to the international switch of the destination = country. =20 Number portability database dip will then be performed to determine the = national=20 routing number within the destination PSTN.   For an IP call, = it is=20 possible that a node may learn the "global" routing number (e.g., from = the=20 carrier/operator/infrastructure ENUM).   My I-D would allow = that the=20 global routing number be carried in the tel URI and be used for routing = within=20 the IP domain.  Whether the routing is based on the country code, = portion=20 of the global routing number or the whole global routing number is up to = the=20 node that processes the received tel URI.
 
James
 
-----Original = Message-----
From:=20 Chelliah Sivachelvan (chelliah) = [mailto:chelliah@cisco.com]
Sent:=20 Wednesday, March 30, 2005 12:00 PM
To: Yu, James "
 
Cc:=20 iptel@ietf.org; Gonzalo.Camarillo@Ericsson.com; Peterson,=20 Jon
Subject: Scope of *rn* parameter in the context of = LNP 

James:
The current=20 draft (draft-ietf-iptel-tel-np-04.txt) implies that the *rn*=20 parameter can contain global numbers (i.e., E.164 = numbers) in the=20 context of LNP. This has also been illustrated in one of the examples = in=20 section 6(c). 
 
But the scope of LNP is national; as such the scope = of routing=20 number (LRN) is not a globally reachable number. Therefore, it = must be=20 treated as a national number. RFC-3388 also makes a strong statement = on this=20 very subject. Here is the excerpts from RFC-3388 (section=20 8.2.1.1 )
 
  =20 "LRNs are necessarily national in scope, and = consequently they=20 MUST NOT be preceded by a '+' in the 'rn=3D'=20 field."
 
 
We need to resolve the discrepancies = between the two=20 specs.
 
  
Thanks!
Chella
           &n= bsp;=20
 
Cisco = Systems,
2200 East=20 President George Bush Turnpike ,
Richardson, TX 75082
Tel: 469.255.1169
 
------_=_NextPart_001_01C5355F.7AE2914E-- --===============0857357900== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============0857357900==-- From iptel-bounces@ietf.org Wed Mar 30 20:24:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19380 for ; Wed, 30 Mar 2005 20:24:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGoX5-0004lN-7P for iptel-web-archive@ietf.org; Wed, 30 Mar 2005 20:31:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGoN9-0002sR-Ev; Wed, 30 Mar 2005 20:21:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGgdS-0006Ep-HC for iptel@megatron.ietf.org; Wed, 30 Mar 2005 12:05:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18972 for ; Wed, 30 Mar 2005 12:05:40 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGgkO-0005Rb-CU for iptel@ietf.org; Wed, 30 Mar 2005 12:12:53 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 30 Mar 2005 12:05:32 -0500 Received: from chelliahw2k02 (chelliah-w2k02.cisco.com [64.101.149.168]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2UH5TjI028758; Wed, 30 Mar 2005 12:05:29 -0500 (EST) Message-Id: <200503301705.j2UH5TjI028758@rtp-core-2.cisco.com> From: "Chelliah Sivachelvan \(chelliah\)" To: , Date: Wed, 30 Mar 2005 11:05:28 -0600 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Thread-Index: AcU1SfirsyuAG88xSuaHFAznr/QTdgAAHVdg X-Spam-Score: 1.0 (+) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e X-Mailman-Approved-At: Wed, 30 Mar 2005 20:21:21 -0500 Cc: iptel@ietf.org, Gonzalo.Camarillo@Ericsson.com, jon.peterson@neustar.biz Subject: [Iptel] RE: Scope of *rn* parameter in the context of LNP X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: chelliah@cisco.com List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0125006822==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 This is a multi-part message in MIME format. --===============0125006822== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01C53518.62B259F0" This is a multi-part message in MIME format. ------=_NextPart_000_0041_01C53518.62B259F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Correction: The referenced RFC is 3398 not 3388. Thanks! Chella _____ From: Chelliah Sivachelvan (chelliah) [mailto:chelliah@cisco.com] Sent: Wednesday, March 30, 2005 11:00 AM To: 'james.yu@neustar.biz' Cc: 'iptel@ietf.org'; 'Gonzalo.Camarillo@Ericsson.com'; 'jon.peterson@neustar.biz' Subject: Scope of *rn* parameter in the context of LNP James: The current draft (draft-ietf-iptel-tel-np-04.txt) implies that the *rn* parameter can contain global numbers (i.e., E.164 numbers) in the context of LNP. This has also been illustrated in one of the examples in section 6(c). But the scope of LNP is national; as such the scope of routing number (LRN) is not a globally reachable number. Therefore, it must be treated as a national number. RFC-3388 also makes a strong statement on this very subject. Here is the excerpts from RFC-3388 (section 8.2.1.1 ) "LRNs are necessarily national in scope, and consequently they MUST NOT be preceded by a '+' in the 'rn=' field." We need to resolve the discrepancies between the two specs. Thanks! Chella Cisco Systems, 2200 East President George Bush Turnpike , Richardson, TX 75082 Tel: 469.255.1169 ------=_NextPart_000_0041_01C53518.62B259F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Correction: The referenced RFC is 3398 not=20 3388.
 
Thanks!
Chella

From: Chelliah Sivachelvan = (chelliah)=20 [mailto:chelliah@cisco.com]
Sent: Wednesday, March 30, 2005 = 11:00=20 AM
To: 'james.yu@neustar.biz'
Cc: 'iptel@ietf.org';=20 'Gonzalo.Camarillo@Ericsson.com'; = 'jon.peterson@neustar.biz'
Subject:=20 Scope of *rn* parameter in the context of LNP

James:
The current=20 draft (draft-ietf-iptel-tel-np-04.txt) implies that the *rn*=20 parameter can contain global numbers (i.e., E.164 numbers) in = the=20 context of LNP. This has also been illustrated in one of the examples in = section=20 6(c). 
 
But the scope of LNP is national; as such the scope of = routing=20 number (LRN) is not a globally reachable number. Therefore, it must = be=20 treated as a national number. RFC-3388 also makes a strong statement on = this=20 very subject. Here is the excerpts from RFC-3388 (section = 8.2.1.1 )=20
 
  =20 "LRNs are necessarily national in scope, and consequently = they MUST=20 NOT be preceded by a '+' in the 'rn=3D' = field."
 
 
We need to resolve the discrepancies between = the two=20 specs.
 
  
Thanks!
Chella
           &n= bsp;=20
 
Cisco = Systems,
2200 = East President=20 George Bush Turnpike ,
Richardson, TX 75082
Tel: 469.255.1169
 
------=_NextPart_000_0041_01C53518.62B259F0-- --===============0125006822== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============0125006822==-- From iptel-bounces@ietf.org Wed Mar 30 20:24:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19473 for ; Wed, 30 Mar 2005 20:24:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGoXe-0004mG-KY for iptel-web-archive@ietf.org; Wed, 30 Mar 2005 20:32:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGoN9-0002sM-38; Wed, 30 Mar 2005 20:21:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGgYZ-0005Yh-F3 for iptel@megatron.ietf.org; Wed, 30 Mar 2005 12:00:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18382 for ; Wed, 30 Mar 2005 12:00:37 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGgfW-0005Hh-9J for iptel@ietf.org; Wed, 30 Mar 2005 12:07:50 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 30 Mar 2005 12:20:35 -0500 X-IronPort-AV: i="3.91,135,1110171600"; d="scan'208,217"; a="42495833:sNHT54968604" Received: from chelliahw2k02 (chelliah-w2k02.cisco.com [64.101.149.168]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2UH0R1j019334; Wed, 30 Mar 2005 12:00:28 -0500 (EST) Message-Id: <200503301700.j2UH0R1j019334@rtp-core-1.cisco.com> From: "Chelliah Sivachelvan \(chelliah\)" To: Date: Wed, 30 Mar 2005 11:00:27 -0600 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Thread-Index: AcU1SfirsyuAG88xSuaHFAznr/QTdg== X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de X-Mailman-Approved-At: Wed, 30 Mar 2005 20:21:20 -0500 Cc: iptel@ietf.org, Gonzalo.Camarillo@Ericsson.com, jon.peterson@neustar.biz Subject: [Iptel] Scope of *rn* parameter in the context of LNP X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: chelliah@cisco.com List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1222173155==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 This is a multi-part message in MIME format. --===============1222173155== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01C53517.AF1B2980" This is a multi-part message in MIME format. ------=_NextPart_000_003D_01C53517.AF1B2980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit James: The current draft (draft-ietf-iptel-tel-np-04.txt) implies that the *rn* parameter can contain global numbers (i.e., E.164 numbers) in the context of LNP. This has also been illustrated in one of the examples in section 6(c). But the scope of LNP is national; as such the scope of routing number (LRN) is not a globally reachable number. Therefore, it must be treated as a national number. RFC-3388 also makes a strong statement on this very subject. Here is the excerpts from RFC-3388 (section 8.2.1.1 ) "LRNs are necessarily national in scope, and consequently they MUST NOT be preceded by a '+' in the 'rn=' field." We need to resolve the discrepancies between the two specs. Thanks! Chella Cisco Systems, 2200 East President George Bush Turnpike , Richardson, TX 75082 Tel: 469.255.1169 ------=_NextPart_000_003D_01C53517.AF1B2980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
James:
The current=20 draft (draft-ietf-iptel-tel-np-04.txt) implies that the *rn*=20 parameter can contain global numbers (i.e., E.164 numbers) in = the=20 context of LNP. This has also been illustrated in one of the examples in = section=20 6(c). 
 
But the scope of LNP is national; as such the scope of = routing=20 number (LRN) is not a globally reachable number. Therefore, it must = be=20 treated as a national number. RFC-3388 also makes a strong statement on = this=20 very subject. Here is the excerpts from RFC-3388 (section = 8.2.1.1 )=20
 
  =20 "LRNs are necessarily national in scope, and consequently = they MUST=20 NOT be preceded by a '+' in the 'rn=3D' = field."
 
 
We need to resolve the discrepancies between = the two=20 specs.
 
  
Thanks!
Chella
           &n= bsp;=20
 
Cisco = Systems,
2200 = East President=20 George Bush Turnpike ,
Richardson, TX 75082
Tel: 469.255.1169
 
------=_NextPart_000_003D_01C53517.AF1B2980-- --===============1222173155== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============1222173155==--