From enum-bounces@ietf.org Thu Jun 01 09:04:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flmr4-0001Uo-2G; Thu, 01 Jun 2006 09:04:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flmqe-0000pX-RX; Thu, 01 Jun 2006 09:04:24 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FlmoQ-0007XG-QH; Thu, 01 Jun 2006 09:02:08 -0400 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 Date: Thu, 1 Jun 2006 15:06:07 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4FF8@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDA== From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: enum@ietf.org Subject: [Enum] How to correctly set up the request URI? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Folks, Question for clarification: In the discussions here on how to populate sip URI in Infrastructure=20 ENUM to derive the Call Routing data for SPEERMINT two lines of thought exist: The Enumservice SIP in Infrastructure ENUM should contain=20 1. the address-of-record of the user: e.g. sip:+4319793321@provB.net 2. the ingress point into the provider network: e.g. sip:+4319793321@sbc4711.provB.net The originating UAC has in this case set the To: field to=20 tel:+4319793321 and the Request-URI to e.g.=20 sip:+4319793321provA.net;user=3Dphone. This caused the ENUM query at the proxy of provider A The question is how the proxy of provider A is now setting up the request URI in cases mentioned above? Does the UAS from provider B accept calls to sbc7411.provB.net, or must the request URI set to the proper AoR as described in 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. I would also like to draw the attention to section 3 of RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. Regards -sta _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jun 01 10:37:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FloI1-0000AB-Ta; Thu, 01 Jun 2006 10:36:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FloI0-00009q-N1; Thu, 01 Jun 2006 10:36:44 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FloHz-00013C-F5; Thu, 01 Jun 2006 10:36:44 -0400 Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.20722102; Thu, 01 Jun 2006 10:36:21 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 10:36:20 -0400 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] How to correctly set up the request URI? Date: Thu, 1 Jun 2006 10:36:19 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96624E68@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OA From: "Creighton, Tom" To: "Stastny Richard" , X-OriginalArrivalTime: 01 Jun 2006 14:36:20.0474 (UTC) FILETIME=[BFB11DA0:01C68588] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 09:06 > To: speermint@ietf.org > Cc: enum@ietf.org > Subject: [Enum] How to correctly set up the request URI? >=20 > Folks, >=20 > Question for clarification: >=20 > In the discussions here on how to populate sip URI in Infrastructure > ENUM to derive the Call Routing data for SPEERMINT two > lines of thought exist: >=20 > The Enumservice SIP in Infrastructure ENUM should contain > 1. the address-of-record of the user: e.g. sip:+4319793321@provB.net > 2. the ingress point into the provider network: > e.g. sip:+4319793321@sbc4711.provB.net >=20 > The originating UAC has in this case set the To: field to > tel:+4319793321 and the Request-URI to e.g. > sip:+4319793321provA.net;user=3Dphone. This caused the > ENUM query at the proxy of provider A >=20 > The question is how the proxy of provider A is now > setting up the request URI in cases mentioned above? >=20 > Does the UAS from provider B accept calls to sbc7411.provB.net, > or must the request URI set to the proper AoR as described in > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. [Tom Creighton wrote:]=20 >From section 8.2.2.1 of RFC3261: "If the Request-URI does not identify an address that the UAS is willing to accept requests for, it SHOULD reject the request with a 404 (Not Found) response." As long as the UAS from provider B is "willing" to accept the request, either should work. Since provider B is populating Infrastructure ENUM, one would hope that they would coordinate this data with the configuration of their proxies. Besides, how do you actually know that sbc4441.provB.net is actually a hostname and isn't a subdomain? In either case, after the provider A proxy performs an ENUM query and rewrites the request URI, it should behave as a UAC and follow the procedures outlined in Section 4 of RFC3263 to determine the IP address, port, and transport protocol for the provider B UAS. >=20 > I would also like to draw the attention to section 3 of > RFC3761 (SIP Enumservice) explaining the usage of AoR in > ENUM. >=20 > Regards >=20 > -sta >=20 >=20 > _______________________________________________ > 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 From enum-bounces@ietf.org Thu Jun 01 11:26:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flp3z-0000gj-4L; Thu, 01 Jun 2006 11:26:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flp3x-0000gF-Mp; Thu, 01 Jun 2006 11:26:17 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Flp3w-0006i2-6L; Thu, 01 Jun 2006 11:26:17 -0400 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] How to correctly set up the request URI? Date: Thu, 1 Jun 2006 17:30:19 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4FF9@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARA= From: "Stastny Richard" To: "Creighton, Tom" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Thank you, Tom just a minor additional question: > In either case, after the provider A proxy performs an ENUM query and > rewrites the request URI, it should behave as a UAC and follow the > procedures outlined in Section 4 of RFC3263 to determine the IP address, > port, and transport protocol for the provider B UAS. If I have to do this according to RFC3263 anyway, why put the sbc4711.provB.net into ENUM in the first place? -sta > -----Original Message----- > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Sent: Thursday, June 01, 2006 4:36 PM > To: Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Enum] How to correctly set up the request URI? >=20 >=20 >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 09:06 > > To: speermint@ietf.org > > Cc: enum@ietf.org > > Subject: [Enum] How to correctly set up the request URI? > > > > Folks, > > > > Question for clarification: > > > > In the discussions here on how to populate sip URI in Infrastructure > > ENUM to derive the Call Routing data for SPEERMINT two > > lines of thought exist: > > > > The Enumservice SIP in Infrastructure ENUM should contain > > 1. the address-of-record of the user: e.g. sip:+4319793321@provB.net > > 2. the ingress point into the provider network: > > e.g. sip:+4319793321@sbc4711.provB.net > > > > The originating UAC has in this case set the To: field to > > tel:+4319793321 and the Request-URI to e.g. > > sip:+4319793321provA.net;user=3Dphone. This caused the > > ENUM query at the proxy of provider A > > > > The question is how the proxy of provider A is now > > setting up the request URI in cases mentioned above? > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, > > or must the request URI set to the proper AoR as described in > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. >=20 > [Tom Creighton wrote:] > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > identify an address that the UAS is willing to accept requests for, it > SHOULD reject the request with a 404 (Not Found) response." >=20 > As long as the UAS from provider B is "willing" to accept the request, > either should work. Since provider B is populating Infrastructure ENUM, > one would hope that they would coordinate this data with the > configuration of their proxies. >=20 > Besides, how do you actually know that sbc4441.provB.net is actually a > hostname and isn't a subdomain? >=20 > In either case, after the provider A proxy performs an ENUM query and > rewrites the request URI, it should behave as a UAC and follow the > procedures outlined in Section 4 of RFC3263 to determine the IP address, > port, and transport protocol for the provider B UAS. >=20 > > > > I would also like to draw the attention to section 3 of > > RFC3761 (SIP Enumservice) explaining the usage of AoR in > > ENUM. > > > > Regards > > > > -sta > > > > > > _______________________________________________ > > 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 From enum-bounces@ietf.org Thu Jun 01 11:58:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpYg-0001oM-Gj; Thu, 01 Jun 2006 11:58:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpYf-0001mR-2g; Thu, 01 Jun 2006 11:58:01 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlpYe-00013z-OR; Thu, 01 Jun 2006 11:58:01 -0400 Received: from ([10.20.9.172]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.20617794; Thu, 01 Jun 2006 11:57:35 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 11:57:35 -0400 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] How to correctly set up the request URI? Date: Thu, 1 Jun 2006 11:57:34 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96624F21@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4A== From: "Creighton, Tom" To: "Stastny Richard" , X-OriginalArrivalTime: 01 Jun 2006 15:57:35.0373 (UTC) FILETIME=[195BABD0:01C68594] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Maybe the service provider has some sort of segregated network (physically or logically) and wants/needs to associate each its subscribers with a particular network segment. If the provider went with the flat model of provB.net, each of its proxies would have to accept requests destined to all of its customers and would then have to route the request to the appropriate region or division of its network. If the provider went with the hierarchical approach of sbc4711.provB.net, all of the requests would already be routed to the appropriate ingress point. This could very well save a service provider a lot of money in route proxy equipment although might cost more on the provisioning side. That is my guess. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 11:30 > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Enum] How to correctly set up the request URI? >=20 > Thank you, Tom >=20 > just a minor additional question: >=20 > > In either case, after the provider A proxy performs an ENUM query and > > rewrites the request URI, it should behave as a UAC and follow the > > procedures outlined in Section 4 of RFC3263 to determine the IP > address, > > port, and transport protocol for the provider B UAS. >=20 > If I have to do this according to RFC3263 anyway, why put > the sbc4711.provB.net into ENUM in the first place? >=20 > -sta >=20 >=20 > > -----Original Message----- > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Sent: Thursday, June 01, 2006 4:36 PM > > To: Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 09:06 > > > To: speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > Folks, > > > > > > Question for clarification: > > > > > > In the discussions here on how to populate sip URI in Infrastructure > > > ENUM to derive the Call Routing data for SPEERMINT two > > > lines of thought exist: > > > > > > The Enumservice SIP in Infrastructure ENUM should contain > > > 1. the address-of-record of the user: e.g. sip:+4319793321@provB.net > > > 2. the ingress point into the provider network: > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > The originating UAC has in this case set the To: field to > > > tel:+4319793321 and the Request-URI to e.g. > > > sip:+4319793321provA.net;user=3Dphone. This caused the > > > ENUM query at the proxy of provider A > > > > > > The question is how the proxy of provider A is now > > > setting up the request URI in cases mentioned above? > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, > > > or must the request URI set to the proper AoR as described in > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > [Tom Creighton wrote:] > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > identify an address that the UAS is willing to accept requests for, it > > SHOULD reject the request with a 404 (Not Found) response." > > > > As long as the UAS from provider B is "willing" to accept the request, > > either should work. Since provider B is populating Infrastructure > ENUM, > > one would hope that they would coordinate this data with the > > configuration of their proxies. > > > > Besides, how do you actually know that sbc4441.provB.net is actually a > > hostname and isn't a subdomain? > > > > In either case, after the provider A proxy performs an ENUM query and > > rewrites the request URI, it should behave as a UAC and follow the > > procedures outlined in Section 4 of RFC3263 to determine the IP > address, > > port, and transport protocol for the provider B UAS. > > > > > > > > I would also like to draw the attention to section 3 of > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in > > > ENUM. > > > > > > Regards > > > > > > -sta > > > > > > > > > _______________________________________________ > > > 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 From enum-bounces@ietf.org Thu Jun 01 13:11:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flqhm-0007aT-VY; Thu, 01 Jun 2006 13:11:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flqhm-0007aA-5n; Thu, 01 Jun 2006 13:11:30 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Flqhl-0002Ma-GQ; Thu, 01 Jun 2006 13:11:30 -0400 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: [Enum] How to correctly set up the request URI? Date: Thu, 1 Jun 2006 19:12:44 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A9D@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVby From: "Stastny Richard" To: "Creighton, Tom" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I see, =20 but how do you solve this problem if the users can also be reached by = AoRs direct? =20 -sta ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Do 01.06.2006 17:57 An: Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Enum] How to correctly set up the request URI? Maybe the service provider has some sort of segregated network (physically or logically) and wants/needs to associate each its subscribers with a particular network segment. If the provider went with the flat model of provB.net, each of its proxies would have to accept requests destined to all of its customers and would then have to route the request to the appropriate region or division of its network. If the provider went with the hierarchical approach of sbc4711.provB.net, all of the requests would already be routed to the appropriate ingress point. This could very well save a service provider a lot of money in route proxy equipment although might cost more on the provisioning side. That is my guess. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 11:30 > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Enum] How to correctly set up the request URI? > > Thank you, Tom > > just a minor additional question: > > > In either case, after the provider A proxy performs an ENUM query and > > rewrites the request URI, it should behave as a UAC and follow the > > procedures outlined in Section 4 of RFC3263 to determine the IP > address, > > port, and transport protocol for the provider B UAS. > > If I have to do this according to RFC3263 anyway, why put > the sbc4711.provB.net into ENUM in the first place? > > -sta > > > > -----Original Message----- > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Sent: Thursday, June 01, 2006 4:36 PM > > To: Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 09:06 > > > To: speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > Folks, > > > > > > Question for clarification: > > > > > > In the discussions here on how to populate sip URI in Infrastructure > > > ENUM to derive the Call Routing data for SPEERMINT two > > > lines of thought exist: > > > > > > The Enumservice SIP in Infrastructure ENUM should contain > > > 1. the address-of-record of the user: e.g. sip:+4319793321@provB.net > > > 2. the ingress point into the provider network: > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > The originating UAC has in this case set the To: field to > > > tel:+4319793321 and the Request-URI to e.g. > > > sip:+4319793321provA.net;user=3Dphone. This caused the > > > ENUM query at the proxy of provider A > > > > > > The question is how the proxy of provider A is now > > > setting up the request URI in cases mentioned above? > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, > > > or must the request URI set to the proper AoR as described in > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > [Tom Creighton wrote:] > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > identify an address that the UAS is willing to accept requests for, it > > SHOULD reject the request with a 404 (Not Found) response." > > > > As long as the UAS from provider B is "willing" to accept the request, > > either should work. Since provider B is populating Infrastructure > ENUM, > > one would hope that they would coordinate this data with the > > configuration of their proxies. > > > > Besides, how do you actually know that sbc4441.provB.net is actually a > > hostname and isn't a subdomain? > > > > In either case, after the provider A proxy performs an ENUM query and > > rewrites the request URI, it should behave as a UAC and follow the > > procedures outlined in Section 4 of RFC3263 to determine the IP > address, > > port, and transport protocol for the provider B UAS. > > > > > > > > I would also like to draw the attention to section 3 of > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in > > > ENUM. > > > > > > Regards > > > > > > -sta > > > > > > > > > _______________________________________________ > > > 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 From enum-bounces@ietf.org Thu Jun 01 13:46:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlrFC-0007dc-36; Thu, 01 Jun 2006 13:46:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlrFA-0007dA-Of; Thu, 01 Jun 2006 13:46:00 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlrFA-0004lF-Cx; Thu, 01 Jun 2006 13:46:00 -0400 Received: from ([10.20.62.13]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.20623581; Thu, 01 Jun 2006 13:45:42 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 13:45:42 -0400 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: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Thu, 1 Jun 2006 13:45:40 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96624FF0@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMA== From: "Creighton, Tom" To: "Lee, Yiu" , "Stastny Richard" , X-OriginalArrivalTime: 01 Jun 2006 17:45:42.0210 (UTC) FILETIME=[33D07220:01C685A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Agreed, in this case the proxy associated with provB.net would be an intermediate device that would have to perform some sort of internal lookup in order to route the request to the next hop.=20 > -----Original Message----- > From: Lee, Yiu > Sent: Thursday, June 01, 2006 13:34 > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > In this case, I guess when the originating proxy resolves the domain part > of the AOR (sip:+4319793321@provB.net), it will return the IP address of > the root domain "provB.net" which may be a redirect proxy. So "provB.net" > has two choices: >=20 > (1) It accesses its local routing table and sends a 305 to the originating > proxy with "sbc4711.provB.net" in the contact header. >=20 > (2) It replaces the domain part in the r-uri to more specific like > "proxy.austria.provB.net" and forward the message to the next-hop. >=20 > Either case, the assumption is provB.net will have a way to find out where > the home proxy of user +4319793321. >=20 > This is only my guess. >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 1:13 PM > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? >=20 > I see, >=20 > but how do you solve this problem if the users can also be reached by AoRs > direct? >=20 > -sta >=20 > ________________________________ >=20 > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 17:57 > An: Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Enum] How to correctly set up the request URI? >=20 >=20 >=20 > Maybe the service provider has some sort of segregated network (physically > or logically) and wants/needs to associate each its subscribers with a > particular network segment. If the provider went with the flat model of > provB.net, each of its proxies would have to accept requests destined to > all of its customers and would then have to route the request to the > appropriate region or division of its network. > If the provider went with the hierarchical approach of sbc4711.provB.net, > all of the requests would already be routed to the appropriate ingress > point. This could very well save a service provider a lot of money in > route proxy equipment although might cost more on the provisioning side. >=20 > That is my guess. >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 11:30 > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > Thank you, Tom > > > > just a minor additional question: > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > If I have to do this according to RFC3263 anyway, why put the > > sbc4711.provB.net into ENUM in the first place? > > > > -sta > > > > > > > -----Original Message----- > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Sent: Thursday, June 01, 2006 4:36 PM > > > To: Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 09:06 > > > > To: speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > Folks, > > > > > > > > Question for clarification: > > > > > > > > In the discussions here on how to populate sip URI in > Infrastructure > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of > > > > thought exist: > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the > > > > address-of-record of the user: e.g. > sip:+4319793321@provB.net > > > > 2. the ingress point into the provider network: > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > The originating UAC has in this case set the To: field to > > > > tel:+4319793321 and the Request-URI to e.g. > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM = query at > > > > the proxy of provider A > > > > > > > > The question is how the proxy of provider A is now setting up the > > > > request URI in cases mentioned above? > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, or > > > > must the request URI set to the proper AoR as described in > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > [Tom Creighton wrote:] > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > identify an address that the UAS is willing to accept requests for, > it > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > As long as the UAS from provider B is "willing" to accept the > request, > > > either should work. Since provider B is populating Infrastructure > > ENUM, > > > one would hope that they would coordinate this data with the > > > configuration of their proxies. > > > > > > Besides, how do you actually know that sbc4441.provB.net is actually > a > > > hostname and isn't a subdomain? > > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > Regards > > > > > > > > -sta > > > > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jun 01 14:04:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlrWW-0000IN-8X; Thu, 01 Jun 2006 14:03:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlrWV-0000I4-2W; Thu, 01 Jun 2006 14:03:55 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FlrWU-0006Dt-9F; Thu, 01 Jun 2006 14:03:55 -0400 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: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Thu, 1 Jun 2006 20:06:48 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AA1@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTD From: "Stastny Richard" To: "Creighton, Tom" , "Lee, Yiu" , X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org so basically the IMS I-CSCF - HSS - S-CSCF way? =20 Richard ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Do 01.06.2006 19:45 An: Lee, Yiu; Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? Agreed, in this case the proxy associated with provB.net would be an intermediate device that would have to perform some sort of internal lookup in order to route the request to the next hop. > -----Original Message----- > From: Lee, Yiu > Sent: Thursday, June 01, 2006 13:34 > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > In this case, I guess when the originating proxy resolves the domain part > of the AOR (sip:+4319793321@provB.net), it will return the IP address of > the root domain "provB.net" which may be a redirect proxy. So "provB.net" > has two choices: > > (1) It accesses its local routing table and sends a 305 to the originating > proxy with "sbc4711.provB.net" in the contact header. > > (2) It replaces the domain part in the r-uri to more specific like > "proxy.austria.provB.net" and forward the message to the next-hop. > > Either case, the assumption is provB.net will have a way to find out where > the home proxy of user +4319793321. > > This is only my guess. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 1:13 PM > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? > > I see, > > but how do you solve this problem if the users can also be reached by AoRs > direct? > > -sta > > ________________________________ > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 17:57 > An: Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > Maybe the service provider has some sort of segregated network (physically > or logically) and wants/needs to associate each its subscribers with a > particular network segment. If the provider went with the flat model of > provB.net, each of its proxies would have to accept requests destined to > all of its customers and would then have to route the request to the > appropriate region or division of its network. > If the provider went with the hierarchical approach of sbc4711.provB.net, > all of the requests would already be routed to the appropriate ingress > point. This could very well save a service provider a lot of money in > route proxy equipment although might cost more on the provisioning side. > > That is my guess. > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 11:30 > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > Thank you, Tom > > > > just a minor additional question: > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > If I have to do this according to RFC3263 anyway, why put the > > sbc4711.provB.net into ENUM in the first place? > > > > -sta > > > > > > > -----Original Message----- > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Sent: Thursday, June 01, 2006 4:36 PM > > > To: Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 09:06 > > > > To: speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > Folks, > > > > > > > > Question for clarification: > > > > > > > > In the discussions here on how to populate sip URI in > Infrastructure > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of > > > > thought exist: > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the > > > > address-of-record of the user: e.g. > sip:+4319793321@provB.net > > > > 2. the ingress point into the provider network: > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > The originating UAC has in this case set the To: field to > > > > tel:+4319793321 and the Request-URI to e.g. > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM = query at > > > > the proxy of provider A > > > > > > > > The question is how the proxy of provider A is now setting up the > > > > request URI in cases mentioned above? > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, or > > > > must the request URI set to the proper AoR as described in > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > [Tom Creighton wrote:] > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > identify an address that the UAS is willing to accept requests for, > it > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > As long as the UAS from provider B is "willing" to accept the > request, > > > either should work. Since provider B is populating Infrastructure > > ENUM, > > > one would hope that they would coordinate this data with the > > > configuration of their proxies. > > > > > > Besides, how do you actually know that sbc4441.provB.net is actually > a > > > hostname and isn't a subdomain? > > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > Regards > > > > > > > > -sta > > > > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jun 01 14:18:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flrkj-0003Ru-5M; Thu, 01 Jun 2006 14:18:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flrkh-0003Rj-NW; Thu, 01 Jun 2006 14:18:35 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flrkf-0007GH-9p; Thu, 01 Jun 2006 14:18:35 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FlrkW-0006av-Mn; Thu, 01 Jun 2006 13:18:24 -0500 From: "Brian Rosen" To: "'Creighton, Tom'" , "'Stastny Richard'" , Subject: RE: [Enum] How to correctly set up the request URI? Date: Thu, 1 Jun 2006 14:18:27 -0400 Message-ID: <08be01c685a7$c990f1f0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4884CD6C1DF0A8429DD8DAD942BF9D96624F21@PACDCEXCMB03.cable.comcast.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AAFSVvw X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I think this is not correct. If the AoR is provB.net, then Provider B has technology to route incoming calls addressed to provB.net to the sbc4711.provB.net, and it will use its existing mechanism to do so. The same AoR would be used for on-net as well as off-net routing and the same routing path would be used. The same routing proxies would be used. Capacity issues shouldn't be an issue with this technology. Brian -----Original Message----- From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Sent: Thursday, June 01, 2006 11:58 AM To: Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Subject: RE: [Enum] How to correctly set up the request URI? Maybe the service provider has some sort of segregated network (physically or logically) and wants/needs to associate each its subscribers with a particular network segment. If the provider went with the flat model of provB.net, each of its proxies would have to accept requests destined to all of its customers and would then have to route the request to the appropriate region or division of its network. If the provider went with the hierarchical approach of sbc4711.provB.net, all of the requests would already be routed to the appropriate ingress point. This could very well save a service provider a lot of money in route proxy equipment although might cost more on the provisioning side. That is my guess. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 11:30 > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Enum] How to correctly set up the request URI? > > Thank you, Tom > > just a minor additional question: > > > In either case, after the provider A proxy performs an ENUM query and > > rewrites the request URI, it should behave as a UAC and follow the > > procedures outlined in Section 4 of RFC3263 to determine the IP > address, > > port, and transport protocol for the provider B UAS. > > If I have to do this according to RFC3263 anyway, why put > the sbc4711.provB.net into ENUM in the first place? > > -sta > > > > -----Original Message----- > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Sent: Thursday, June 01, 2006 4:36 PM > > To: Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 09:06 > > > To: speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > Folks, > > > > > > Question for clarification: > > > > > > In the discussions here on how to populate sip URI in Infrastructure > > > ENUM to derive the Call Routing data for SPEERMINT two > > > lines of thought exist: > > > > > > The Enumservice SIP in Infrastructure ENUM should contain > > > 1. the address-of-record of the user: e.g. sip:+4319793321@provB.net > > > 2. the ingress point into the provider network: > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > The originating UAC has in this case set the To: field to > > > tel:+4319793321 and the Request-URI to e.g. > > > sip:+4319793321provA.net;user=phone. This caused the > > > ENUM query at the proxy of provider A > > > > > > The question is how the proxy of provider A is now > > > setting up the request URI in cases mentioned above? > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, > > > or must the request URI set to the proper AoR as described in > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > [Tom Creighton wrote:] > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > identify an address that the UAS is willing to accept requests for, it > > SHOULD reject the request with a 404 (Not Found) response." > > > > As long as the UAS from provider B is "willing" to accept the request, > > either should work. Since provider B is populating Infrastructure > ENUM, > > one would hope that they would coordinate this data with the > > configuration of their proxies. > > > > Besides, how do you actually know that sbc4441.provB.net is actually a > > hostname and isn't a subdomain? > > > > In either case, after the provider A proxy performs an ENUM query and > > rewrites the request URI, it should behave as a UAC and follow the > > procedures outlined in Section 4 of RFC3263 to determine the IP > address, > > port, and transport protocol for the provider B UAS. > > > > > > > > I would also like to draw the attention to section 3 of > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in > > > ENUM. > > > > > > Regards > > > > > > -sta > > > > > > > > > _______________________________________________ > > > 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jun 01 14:41:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fls73-0001sQ-K0; Thu, 01 Jun 2006 14:41:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fls72-0001s7-1W; Thu, 01 Jun 2006 14:41:40 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fls70-0002Ck-Bk; Thu, 01 Jun 2006 14:41:40 -0400 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: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Thu, 1 Jun 2006 20:43:15 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AA4@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAAw2+HA== From: "Stastny Richard" To: "Lee, Yiu" , "Creighton, Tom" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Just out of curiosity: =20 (2) It replaces the domain part in the r-uri to more specific like "proxy.austria.provB.net" and forward the message to the next-hop. Do I have to replace the request URI with "proxy.austria.provB.net, or could I just leave it to "provB.net", assuming that = "proxy.austria.provB.net accepts "provB.net"? =20 -sta ________________________________ Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Gesendet: Do 01.06.2006 19:34 An: Stastny Richard; Creighton, Tom; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? In this case, I guess when the originating proxy resolves the domain part of the AOR (sip:+4319793321@provB.net), it will return the IP address of the root domain "provB.net" which may be a redirect proxy. So "provB.net" has two choices: (1) It accesses its local routing table and sends a 305 to the originating proxy with "sbc4711.provB.net" in the contact header. (2) It replaces the domain part in the r-uri to more specific like "proxy.austria.provB.net" and forward the message to the next-hop. Either case, the assumption is provB.net will have a way to find out where the home proxy of user +4319793321. This is only my guess. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, June 01, 2006 1:13 PM To: Creighton, Tom; speermint@ietf.org Cc: enum@ietf.org Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? I see, but how do you solve this problem if the users can also be reached by AoRs direct? -sta ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Do 01.06.2006 17:57 An: Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Enum] How to correctly set up the request URI? Maybe the service provider has some sort of segregated network (physically or logically) and wants/needs to associate each its subscribers with a particular network segment. If the provider went with the flat model of provB.net, each of its proxies would have to accept requests destined to all of its customers and would then have to route the request to the appropriate region or division of its network. If the provider went with the hierarchical approach of sbc4711.provB.net, all of the requests would already be routed to the appropriate ingress point. This could very well save a service provider a lot of money in route proxy equipment although might cost more on the provisioning side. That is my guess. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 11:30 > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Enum] How to correctly set up the request URI? > > Thank you, Tom > > just a minor additional question: > > > In either case, after the provider A proxy performs an ENUM query and > > rewrites the request URI, it should behave as a UAC and follow the > > procedures outlined in Section 4 of RFC3263 to determine the IP > address, > > port, and transport protocol for the provider B UAS. > > If I have to do this according to RFC3263 anyway, why put the > sbc4711.provB.net into ENUM in the first place? > > -sta > > > > -----Original Message----- > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Sent: Thursday, June 01, 2006 4:36 PM > > To: Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 09:06 > > > To: speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > Folks, > > > > > > Question for clarification: > > > > > > In the discussions here on how to populate sip URI in Infrastructure > > > ENUM to derive the Call Routing data for SPEERMINT two lines of > > > thought exist: > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the > > > address-of-record of the user: e.g. sip:+4319793321@provB.net > > > 2. the ingress point into the provider network: > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > The originating UAC has in this case set the To: field to > > > tel:+4319793321 and the Request-URI to e.g. > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM query = at > > > the proxy of provider A > > > > > > The question is how the proxy of provider A is now setting up the > > > request URI in cases mentioned above? > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, or > > > must the request URI set to the proper AoR as described in > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > [Tom Creighton wrote:] > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > identify an address that the UAS is willing to accept requests for, it > > SHOULD reject the request with a 404 (Not Found) response." > > > > As long as the UAS from provider B is "willing" to accept the request, > > either should work. Since provider B is populating Infrastructure > ENUM, > > one would hope that they would coordinate this data with the > > configuration of their proxies. > > > > Besides, how do you actually know that sbc4441.provB.net is actually a > > hostname and isn't a subdomain? > > > > In either case, after the provider A proxy performs an ENUM query and > > rewrites the request URI, it should behave as a UAC and follow the > > procedures outlined in Section 4 of RFC3263 to determine the IP > address, > > port, and transport protocol for the provider B UAS. > > > > > > > > I would also like to draw the attention to section 3 of > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > Regards > > > > > > -sta > > > > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jun 01 14:50:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlsFd-0007ja-AO; Thu, 01 Jun 2006 14:50:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlsFb-0007jH-UG; Thu, 01 Jun 2006 14:50:31 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlsFb-0003UF-5f; Thu, 01 Jun 2006 14:50:31 -0400 Received: from ([10.20.62.13]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.20735439; Thu, 01 Jun 2006 14:50:04 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 14:50:04 -0400 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: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Thu, 1 Jun 2006 14:50:03 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96625085@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAO9LA= From: "Creighton, Tom" To: "Stastny Richard" , "Lee, Yiu" , X-OriginalArrivalTime: 01 Jun 2006 18:50:04.0398 (UTC) FILETIME=[31DB90E0:01C685AC] X-Spam-Score: 0.0 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Provider B could be using an internal ENUM database, an HSS-like database, an LDAP database, or even static route table. I was merely using this as an example and certainly did not mean to imply or suggest that provider B was or had to follow any particular religion. ;-) Another way to look at it would be the case of a city government in the U.S. that acted as its own PSTN provider and wanted to use its .us TLD to provision its records into Infrastructure ENUM. For example: 1. The originating UAC has the To: field set to tel:+12155551234 and the Request-URI to sip:+12155551234@provA.net;user=3Dphone. 2. The provider A proxy performs a query to Infrastructure ENUM. 3. Infrastructure ENUM returns the following AoR: sip:+12155551234@langhorne.pa.us In this fictitious example, the entity that manages pa.us sub-delegated langhorne.pa.us to the Township of Langhorne which gives them full administrative and technical control of their domain. They in turn provision RFC3263 compliant NAPTR and SRV records that point to their SIP proxy. =20 I am just trying to point out that it is impossible to determine the difference between a hostname and a domain name if a provider's ingress sip proxy is configured to accept what is provisioned on the right side of the @ in Infrastructure ENUM. Tom > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 14:07 > To: Creighton, Tom; Lee, Yiu; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > so basically the IMS I-CSCF - HSS - S-CSCF way? >=20 > Richard >=20 > ________________________________ >=20 > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 19:45 > An: Lee, Yiu; Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 >=20 >=20 > Agreed, in this case the proxy associated with provB.net would be an > intermediate device that would have to perform some sort of internal > lookup in order to route the request to the next hop. >=20 > > -----Original Message----- > > From: Lee, Yiu > > Sent: Thursday, June 01, 2006 13:34 > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > In this case, I guess when the originating proxy resolves the domain > part > > of the AOR (sip:+4319793321@provB.net), it will return the IP address > of > > the root domain "provB.net" which may be a redirect proxy. So > "provB.net" > > has two choices: > > > > (1) It accesses its local routing table and sends a 305 to the > originating > > proxy with "sbc4711.provB.net" in the contact header. > > > > (2) It replaces the domain part in the r-uri to more specific like > > "proxy.austria.provB.net" and forward the message to the next-hop. > > > > Either case, the assumption is provB.net will have a way to find out > where > > the home proxy of user +4319793321. > > > > This is only my guess. > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 1:13 PM > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > > > I see, > > > > but how do you solve this problem if the users can also be reached by > AoRs > > direct? > > > > -sta > > > > ________________________________ > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Gesendet: Do 01.06.2006 17:57 > > An: Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > > > > > Maybe the service provider has some sort of segregated network > (physically > > or logically) and wants/needs to associate each its subscribers with a > > particular network segment. If the provider went with the flat model > of > > provB.net, each of its proxies would have to accept requests destined > to > > all of its customers and would then have to route the request to the > > appropriate region or division of its network. > > If the provider went with the hierarchical approach of > sbc4711.provB.net, > > all of the requests would already be routed to the appropriate ingress > > point. This could very well save a service provider a lot of money in > > route proxy equipment although might cost more on the provisioning > side. > > > > That is my guess. > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 11:30 > > > To: Creighton, Tom; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > Thank you, Tom > > > > > > just a minor additional question: > > > > > > > In either case, after the provider A proxy performs an ENUM query > > and > > > > rewrites the request URI, it should behave as a UAC and follow the > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > address, > > > > port, and transport protocol for the provider B UAS. > > > > > > If I have to do this according to RFC3263 anyway, why put the > > > sbc4711.provB.net into ENUM in the first place? > > > > > > -sta > > > > > > > > > > -----Original Message----- > > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > > Sent: Thursday, June 01, 2006 4:36 PM > > > > To: Stastny Richard; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Thursday, June 01, 2006 09:06 > > > > > To: speermint@ietf.org > > > > > Cc: enum@ietf.org > > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > > > Folks, > > > > > > > > > > Question for clarification: > > > > > > > > > > In the discussions here on how to populate sip URI in > > Infrastructure > > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of > > > > > thought exist: > > > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the > > > > > address-of-record of the user: e.g. > > sip:+4319793321@provB.net > > > > > 2. the ingress point into the provider network: > > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > > > The originating UAC has in this case set the To: field to > > > > > tel:+4319793321 and the Request-URI to e.g. > > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM query > at > > > > > the proxy of provider A > > > > > > > > > > The question is how the proxy of provider A is now setting up > the > > > > > request URI in cases mentioned above? > > > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, > or > > > > > must the request URI set to the proper AoR as described in > > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > > > [Tom Creighton wrote:] > > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > > identify an address that the UAS is willing to accept requests > for, > > it > > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > > > As long as the UAS from provider B is "willing" to accept the > > request, > > > > either should work. Since provider B is populating Infrastructure > > > ENUM, > > > > one would hope that they would coordinate this data with the > > > > configuration of their proxies. > > > > > > > > Besides, how do you actually know that sbc4441.provB.net is > actually > > a > > > > hostname and isn't a subdomain? > > > > > > > > In either case, after the provider A proxy performs an ENUM query > > and > > > > rewrites the request URI, it should behave as a UAC and follow the > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > address, > > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > > > Regards > > > > > > > > > > -sta > > > > > > > > > > > > > > > _______________________________________________ > > > > > enum mailing list > > > > > enum@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jun 02 09:34:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm9nC-0004EZ-8F; Fri, 02 Jun 2006 09:34:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flr4O-0001Io-Tm; Thu, 01 Jun 2006 13:34:52 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flr4M-0003md-H2; Thu, 01 Jun 2006 13:34:52 -0400 Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.20731536; Thu, 01 Jun 2006 13:34:29 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 13:34:29 -0400 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: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Thu, 1 Jun 2006 13:34:24 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96624FDD@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobA= From: "Lee, Yiu" To: "Stastny Richard" , "Creighton, Tom" , X-OriginalArrivalTime: 01 Jun 2006 17:34:29.0430 (UTC) FILETIME=[A2CE5D60:01C685A1] X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 X-Mailman-Approved-At: Fri, 02 Jun 2006 09:34:20 -0400 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org In this case, I guess when the originating proxy resolves the domain part of the AOR (sip:+4319793321@provB.net), it will return the IP address of the root domain "provB.net" which may be a redirect proxy. So "provB.net" has two choices: (1) It accesses its local routing table and sends a 305 to the originating proxy with "sbc4711.provB.net" in the contact header. (2) It replaces the domain part in the r-uri to more specific like "proxy.austria.provB.net" and forward the message to the next-hop. Either case, the assumption is provB.net will have a way to find out where the home proxy of user +4319793321. This is only my guess. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Thursday, June 01, 2006 1:13 PM To: Creighton, Tom; speermint@ietf.org Cc: enum@ietf.org Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? I see, =20 but how do you solve this problem if the users can also be reached by AoRs direct? =20 -sta ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Do 01.06.2006 17:57 An: Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Enum] How to correctly set up the request URI? Maybe the service provider has some sort of segregated network (physically or logically) and wants/needs to associate each its subscribers with a particular network segment. If the provider went with the flat model of provB.net, each of its proxies would have to accept requests destined to all of its customers and would then have to route the request to the appropriate region or division of its network. If the provider went with the hierarchical approach of sbc4711.provB.net, all of the requests would already be routed to the appropriate ingress point. This could very well save a service provider a lot of money in route proxy equipment although might cost more on the provisioning side. That is my guess. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 11:30 > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Enum] How to correctly set up the request URI? > > Thank you, Tom > > just a minor additional question: > > > In either case, after the provider A proxy performs an ENUM query and > > rewrites the request URI, it should behave as a UAC and follow the=20 > > procedures outlined in Section 4 of RFC3263 to determine the IP > address, > > port, and transport protocol for the provider B UAS. > > If I have to do this according to RFC3263 anyway, why put the=20 > sbc4711.provB.net into ENUM in the first place? > > -sta > > > > -----Original Message----- > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Sent: Thursday, June 01, 2006 4:36 PM > > To: Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 09:06 > > > To: speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > Folks, > > > > > > Question for clarification: > > > > > > In the discussions here on how to populate sip URI in Infrastructure > > > ENUM to derive the Call Routing data for SPEERMINT two lines of=20 > > > thought exist: > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the=20 > > > address-of-record of the user: e.g. sip:+4319793321@provB.net > > > 2. the ingress point into the provider network: > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > The originating UAC has in this case set the To: field to > > > tel:+4319793321 and the Request-URI to e.g. > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM query = at > > > the proxy of provider A > > > > > > The question is how the proxy of provider A is now setting up the=20 > > > request URI in cases mentioned above? > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, or > > > must the request URI set to the proper AoR as described in > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > [Tom Creighton wrote:] > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > identify an address that the UAS is willing to accept requests for, it > > SHOULD reject the request with a 404 (Not Found) response." > > > > As long as the UAS from provider B is "willing" to accept the request, > > either should work. Since provider B is populating Infrastructure > ENUM, > > one would hope that they would coordinate this data with the=20 > > configuration of their proxies. > > > > Besides, how do you actually know that sbc4441.provB.net is actually a > > hostname and isn't a subdomain? > > > > In either case, after the provider A proxy performs an ENUM query and > > rewrites the request URI, it should behave as a UAC and follow the=20 > > procedures outlined in Section 4 of RFC3263 to determine the IP > address, > > port, and transport protocol for the provider B UAS. > > > > > > > > I would also like to draw the attention to section 3 of > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > Regards > > > > > > -sta > > > > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jun 02 15:25:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFGa-00022q-TV; Fri, 02 Jun 2006 15:25:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFGZ-00022H-II; Fri, 02 Jun 2006 15:25:03 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmFBV-0000Ki-GJ; Fri, 02 Jun 2006 15:19:51 -0400 Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.20674403; Fri, 02 Jun 2006 15:19:23 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 15:19:22 -0400 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] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 15:19:21 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96705418@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAA1DG0w From: "Creighton, Tom" To: "Stastny Richard" , X-OriginalArrivalTime: 02 Jun 2006 19:19:22.0599 (UTC) FILETIME=[743D7F70:01C68679] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Richard: All examples aside, I attempted to craft some words that would not set any limitations on what can or cannot be used in the host portion of a SIP URI while maintaining a consistent method for resolving whatever is used in the host portion of a SIP URI. When a SIP URI is used in Infrastructure ENUM, the procedures outlined in RFC3263 MUST be followed for locating a UAS that will accept a request for the given URI. For providers assuming the role of a UAS, this means that they MUST provision RFC3263 compliant NAPTR records and SRV records that correspond to the host portion of the SIP URI provisioned in Infrastructure ENUM. For providers assuming the role of a UAC, when a query to Infrastructure ENUM returns a SIP URI, they MUST follow the procedures outlined in Section 4 of RFC3263 to determine the IP address, port, and transport protocol of a UAS that will accept a request for the given URI. Please let me know what you think. Regards, Tom > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 09:06 > To: speermint@ietf.org > Cc: enum@ietf.org > Subject: [Enum] How to correctly set up the request URI? >=20 > Folks, >=20 > Question for clarification: >=20 > In the discussions here on how to populate sip URI in Infrastructure > ENUM to derive the Call Routing data for SPEERMINT two > lines of thought exist: >=20 > The Enumservice SIP in Infrastructure ENUM should contain > 1. the address-of-record of the user: e.g. sip:+4319793321@provB.net > 2. the ingress point into the provider network: > e.g. sip:+4319793321@sbc4711.provB.net >=20 > The originating UAC has in this case set the To: field to > tel:+4319793321 and the Request-URI to e.g. > sip:+4319793321provA.net;user=3Dphone. This caused the > ENUM query at the proxy of provider A >=20 > The question is how the proxy of provider A is now > setting up the request URI in cases mentioned above? >=20 > Does the UAS from provider B accept calls to sbc7411.provB.net, > or must the request URI set to the proper AoR as described in > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. >=20 > I would also like to draw the attention to section 3 of > RFC3761 (SIP Enumservice) explaining the usage of AoR in > ENUM. >=20 > Regards >=20 > -sta >=20 >=20 > _______________________________________________ > 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 From enum-bounces@ietf.org Fri Jun 02 15:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFH0-0002X2-Ur; Fri, 02 Jun 2006 15:25:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFH0-0002Vl-7d; Fri, 02 Jun 2006 15:25:30 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmF3v-00082y-5T; Fri, 02 Jun 2006 15:11:59 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k52JBrJ28731; Fri, 2 Jun 2006 15:11:54 -0400 (EDT) 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: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 15:11:42 -0400 Message-ID: In-Reply-To: <4884CD6C1DF0A8429DD8DAD942BF9D96625047@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmA= From: "James McEachern" To: "Lee, Yiu" , "Stastny Richard" , "Creighton, Tom" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org In the past it has been suggested that if Infrastructure ENUM is openly = accessible, then for data privacy reasons it would not be acceptable to = list the user AOR. Do we still believe this is the case, or do we now = think providing the user AOR would be acceptable? James -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]=20 Sent: Thursday, June 01, 2006 2:22 PM To: Stastny Richard; Creighton, Tom; speermint@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? Actually, I think it is sufficient for the Enum to return the user AOR because the routing decision should happen in the provB.net network. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Thursday, June 01, 2006 2:18 PM To: Lee, Yiu; Creighton, Tom; speermint@ietf.org Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI? Ok, so I am back to my original question: =20 if I implement both types of public user identities: E.164 numbers and SIP AoRs, why doing the mapping to different hosting proxies in two places (in this case ENUM and the HSS), if I can do it only in one place? -sta ________________________________ Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Gesendet: Do 01.06.2006 20:10 An: Stastny Richard; Creighton, Tom; speermint@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Yes. IMS is using Option 2. Option 1 is also possible if the operator decides to use just a redirect proxy. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, June 01, 2006 2:07 PM To: Creighton, Tom; Lee, Yiu; speermint@ietf.org Cc: enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? so basically the IMS I-CSCF - HSS - S-CSCF way? Richard ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Do 01.06.2006 19:45 An: Lee, Yiu; Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Agreed, in this case the proxy associated with provB.net would be an intermediate device that would have to perform some sort of internal lookup in order to route the request to the next hop. > -----Original Message----- > From: Lee, Yiu > Sent: Thursday, June 01, 2006 13:34 > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > In this case, I guess when the originating proxy resolves the domain part > of the AOR (sip:+4319793321@provB.net), it will return the IP address of > the root domain "provB.net" which may be a redirect proxy. So "provB.net" > has two choices: > > (1) It accesses its local routing table and sends a 305 to the originating > proxy with "sbc4711.provB.net" in the contact header. > > (2) It replaces the domain part in the r-uri to more specific like=20 > "proxy.austria.provB.net" and forward the message to the next-hop. > > Either case, the assumption is provB.net will have a way to find out where > the home proxy of user +4319793321. > > This is only my guess. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 1:13 PM > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? > > I see, > > but how do you solve this problem if the users can also be reached by AoRs > direct? > > -sta > > ________________________________ > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 17:57 > An: Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > Maybe the service provider has some sort of segregated network (physically > or logically) and wants/needs to associate each its subscribers with a > particular network segment. If the provider went with the flat model of > provB.net, each of its proxies would have to accept requests destined to > all of its customers and would then have to route the request to the=20 > appropriate region or division of its network. > If the provider went with the hierarchical approach of sbc4711.provB.net, > all of the requests would already be routed to the appropriate ingress > point. This could very well save a service provider a lot of money in > route proxy equipment although might cost more on the provisioning side. > > That is my guess. > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 11:30 > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > Thank you, Tom > > > > just a minor additional question: > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > If I have to do this according to RFC3263 anyway, why put the=20 > > sbc4711.provB.net into ENUM in the first place? > > > > -sta > > > > > > > -----Original Message----- > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Sent: Thursday, June 01, 2006 4:36 PM > > > To: Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 09:06 > > > > To: speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > Folks, > > > > > > > > Question for clarification: > > > > > > > > In the discussions here on how to populate sip URI in > Infrastructure > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of > > > > thought exist: > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the > > > > address-of-record of the user: e.g. > sip:+4319793321@provB.net > > > > 2. the ingress point into the provider network: > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > The originating UAC has in this case set the To: field to > > > > tel:+4319793321 and the Request-URI to e.g. > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM = query at > > > > the proxy of provider A > > > > > > > > The question is how the proxy of provider A is now setting up the > > > > request URI in cases mentioned above? > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, or > > > > must the request URI set to the proper AoR as described in > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > [Tom Creighton wrote:] > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > identify an address that the UAS is willing to accept requests for, > it > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > As long as the UAS from provider B is "willing" to accept the > request, > > > either should work. Since provider B is populating Infrastructure > > ENUM, > > > one would hope that they would coordinate this data with the=20 > > > configuration of their proxies. > > > > > > Besides, how do you actually know that sbc4441.provB.net is actually > a > > > hostname and isn't a subdomain? > > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > Regards > > > > > > > > -sta > > > > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jun 02 15:37:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFSD-00086V-EW; Fri, 02 Jun 2006 15:37:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFSC-000828-EC; Fri, 02 Jun 2006 15:37:04 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmFSA-0002x6-Tr; Fri, 02 Jun 2006 15:37:04 -0400 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: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 21:41:07 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AA7@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAA1DG0wAArcX1A= From: "Stastny Richard" To: "Creighton, Tom" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Tom, =20 being in favor of the usage of an AoR in Infrastructure ENUM, I have no problems with your proposed words. There are only two issues: =20 1. There will be some people objecting, I assume. 2. Where should this words go? -in the ENUM requirements or in the SPEERMINT requirements? =20 could the esteemed chairs of the two WGs please give their advice? =20 -sta ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Fr 02.06.2006 21:19 An: Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Enum] How to correctly set up the request URI? Richard: All examples aside, I attempted to craft some words that would not set any limitations on what can or cannot be used in the host portion of a SIP URI while maintaining a consistent method for resolving whatever is used in the host portion of a SIP URI. When a SIP URI is used in Infrastructure ENUM, the procedures outlined in RFC3263 MUST be followed for locating a UAS that will accept a request for the given URI. For providers assuming the role of a UAS, this means that they MUST provision RFC3263 compliant NAPTR records and SRV records that correspond to the host portion of the SIP URI provisioned in Infrastructure ENUM. For providers assuming the role of a UAC, when a query to Infrastructure ENUM returns a SIP URI, they MUST follow the procedures outlined in Section 4 of RFC3263 to determine the IP address, port, and transport protocol of a UAS that will accept a request for the given URI. Please let me know what you think. Regards, Tom > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 09:06 > To: speermint@ietf.org > Cc: enum@ietf.org > Subject: [Enum] How to correctly set up the request URI? > > Folks, > > Question for clarification: > > In the discussions here on how to populate sip URI in Infrastructure > ENUM to derive the Call Routing data for SPEERMINT two > lines of thought exist: > > The Enumservice SIP in Infrastructure ENUM should contain > 1. the address-of-record of the user: e.g. sip:+4319793321@provB.net > 2. the ingress point into the provider network: > e.g. sip:+4319793321@sbc4711.provB.net > > The originating UAC has in this case set the To: field to > tel:+4319793321 and the Request-URI to e.g. > sip:+4319793321provA.net;user=3Dphone. This caused the > ENUM query at the proxy of provider A > > The question is how the proxy of provider A is now > setting up the request URI in cases mentioned above? > > Does the UAS from provider B accept calls to sbc7411.provB.net, > or must the request URI set to the proper AoR as described in > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > I would also like to draw the attention to section 3 of > RFC3761 (SIP Enumservice) explaining the usage of AoR in > ENUM. > > Regards > > -sta > > > _______________________________________________ > 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 From enum-bounces@ietf.org Fri Jun 02 15:46:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFb3-0000Fb-An; Fri, 02 Jun 2006 15:46:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFb1-0000FI-ML; Fri, 02 Jun 2006 15:46:11 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmFb0-0003xd-OD; Fri, 02 Jun 2006 15:46:11 -0400 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: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 21:50:17 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AA8@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAATCo4AAAf0N2 From: "Stastny Richard" To: "Pfautz, Penn L, GBLAM" , "James McEachern" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Penn, =20 I just wanted to give a similar reply: the user part of the SIP URI should either be the E.164 phone number and = an identifier not allowing to derive any information about the identity of = the user e.g. an internal number or so. =20 Regarding this issue, we need to add a security section to draft-ietf-enum-infrastructure anyway, so this issue should be covered there. =20 -sta ________________________________ Von: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Gesendet: Fr 02.06.2006 21:30 An: James McEachern; Lee, Yiu; Stastny Richard; Creighton, Tom; = speermint@ietf.org; enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? James I think what this means is that a provider should not provision an AoR that would a) provide personally identifiable information beyond the called phone number or b) allow direct access to the user's CPE. Or are you referring to a user supplied SIP URI? Penn -----Original Message----- From: James McEachern [mailto:jmce@nortel.com] Sent: Friday, June 02, 2006 3:12 PM To: Lee, Yiu; Stastny Richard; Creighton, Tom; speermint@ietf.org; enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? In the past it has been suggested that if Infrastructure ENUM is openly accessible, then for data privacy reasons it would not be acceptable to list the user AOR. Do we still believe this is the case, or do we now think providing the user AOR would be acceptable? James -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Sent: Thursday, June 01, 2006 2:22 PM To: Stastny Richard; Creighton, Tom; speermint@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Actually, I think it is sufficient for the Enum to return the user AOR because the routing decision should happen in the provB.net network. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, June 01, 2006 2:18 PM To: Lee, Yiu; Creighton, Tom; speermint@ietf.org Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI? Ok, so I am back to my original question: if I implement both types of public user identities: E.164 numbers and SIP AoRs, why doing the mapping to different hosting proxies in two places (in this case ENUM and the HSS), if I can do it only in one place? -sta ________________________________ Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Gesendet: Do 01.06.2006 20:10 An: Stastny Richard; Creighton, Tom; speermint@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Yes. IMS is using Option 2. Option 1 is also possible if the operator decides to use just a redirect proxy. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, June 01, 2006 2:07 PM To: Creighton, Tom; Lee, Yiu; speermint@ietf.org Cc: enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? so basically the IMS I-CSCF - HSS - S-CSCF way? Richard ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Do 01.06.2006 19:45 An: Lee, Yiu; Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Agreed, in this case the proxy associated with provB.net would be an intermediate device that would have to perform some sort of internal lookup in order to route the request to the next hop. > -----Original Message----- > From: Lee, Yiu > Sent: Thursday, June 01, 2006 13:34 > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > In this case, I guess when the originating proxy resolves the domain part > of the AOR (sip:+4319793321@provB.net), it will return the IP address of > the root domain "provB.net" which may be a redirect proxy. So "provB.net" > has two choices: > > (1) It accesses its local routing table and sends a 305 to the originating > proxy with "sbc4711.provB.net" in the contact header. > > (2) It replaces the domain part in the r-uri to more specific like > "proxy.austria.provB.net" and forward the message to the next-hop. > > Either case, the assumption is provB.net will have a way to find out where > the home proxy of user +4319793321. > > This is only my guess. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 1:13 PM > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? > > I see, > > but how do you solve this problem if the users can also be reached by AoRs > direct? > > -sta > > ________________________________ > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 17:57 > An: Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > Maybe the service provider has some sort of segregated network (physically > or logically) and wants/needs to associate each its subscribers with a > particular network segment. If the provider went with the flat model of > provB.net, each of its proxies would have to accept requests destined to > all of its customers and would then have to route the request to the > appropriate region or division of its network. > If the provider went with the hierarchical approach of sbc4711.provB.net, > all of the requests would already be routed to the appropriate ingress > point. This could very well save a service provider a lot of money in > route proxy equipment although might cost more on the provisioning side. > > That is my guess. > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 11:30 > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > Thank you, Tom > > > > just a minor additional question: > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > If I have to do this according to RFC3263 anyway, why put the > > sbc4711.provB.net into ENUM in the first place? > > > > -sta > > > > > > > -----Original Message----- > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Sent: Thursday, June 01, 2006 4:36 PM > > > To: Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 09:06 > > > > To: speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > Folks, > > > > > > > > Question for clarification: > > > > > > > > In the discussions here on how to populate sip URI in > Infrastructure > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of > > > > thought exist: > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the > > > > address-of-record of the user: e.g. > sip:+4319793321@provB.net > > > > 2. the ingress point into the provider network: > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > The originating UAC has in this case set the To: field to > > > > tel:+4319793321 and the Request-URI to e.g. > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM = query at > > > > the proxy of provider A > > > > > > > > The question is how the proxy of provider A is now setting up the > > > > request URI in cases mentioned above? > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, or > > > > must the request URI set to the proper AoR as described in > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > [Tom Creighton wrote:] > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > identify an address that the UAS is willing to accept requests for, > it > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > As long as the UAS from provider B is "willing" to accept the > request, > > > either should work. Since provider B is populating Infrastructure > > ENUM, > > > one would hope that they would coordinate this data with the > > > configuration of their proxies. > > > > > > Besides, how do you actually know that sbc4441.provB.net is actually > a > > > hostname and isn't a subdomain? > > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > Regards > > > > > > > > -sta > > > > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ 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 From enum-bounces@ietf.org Fri Jun 02 15:49:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFeC-0000gL-A0; Fri, 02 Jun 2006 15:49:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFeA-0000fx-O1; Fri, 02 Jun 2006 15:49:26 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmFe9-0004Ef-7m; Fri, 02 Jun 2006 15:49:26 -0400 Received: from ([10.52.116.10]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.20781747; Fri, 02 Jun 2006 15:49:00 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 15:49:00 -0400 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: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 15:48:59 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D96705448@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0A== From: "Creighton, Tom" To: "James McEachern" , "Lee, Yiu" , "Stastny Richard" , , X-OriginalArrivalTime: 02 Jun 2006 19:49:00.0462 (UTC) FILETIME=[97EDDCE0:01C6867D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I think we have two separate issues: 1. An issue of misunderstanding of the term AoR. Section 6 of RFC3261 defines an Address-of-Record as: "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the "public address" of the user." Based on that definition and the examples provided by Richard, a user's privacy would not be compromised because it doesn't directly reach or identify the customer. 2. There is confusion around what is or is not acceptable in the host portion of a SIP URI. As long as RFC3263 is followed, it shouldn't matter what is placed in the host portion of the SIP URI as long as it doesn't compromise a user's privacy. So in the examples Richard provided earlier, either are acceptable and would resolve in an identical manner. Tom > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Friday, June 02, 2006 15:12 > To: Lee, Yiu; Stastny Richard; Creighton, Tom; speermint@ietf.org; > enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > In the past it has been suggested that if Infrastructure ENUM is openly > accessible, then for data privacy reasons it would not be acceptable to > list the user AOR. Do we still believe this is the case, or do we now > think providing the user AOR would be acceptable? >=20 > James >=20 > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Sent: Thursday, June 01, 2006 2:22 PM > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > Actually, I think it is sufficient for the Enum to return the user AOR > because the routing decision should happen in the provB.net network. >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 2:18 PM > To: Lee, Yiu; Creighton, Tom; speermint@ietf.org > Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > Ok, so I am back to my original question: >=20 > if I implement both types of public user identities: > E.164 numbers and SIP AoRs, why doing the mapping to different hosting > proxies in two places (in this case ENUM and the HSS), if I can do it > only in one place? >=20 > -sta >=20 >=20 >=20 > ________________________________ >=20 > Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Gesendet: Do 01.06.2006 20:10 > An: Stastny Richard; Creighton, Tom; speermint@ietf.org > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 >=20 >=20 > Yes. IMS is using Option 2. Option 1 is also possible if the operator > decides to use just a redirect proxy. >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 2:07 PM > To: Creighton, Tom; Lee, Yiu; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > so basically the IMS I-CSCF - HSS - S-CSCF way? >=20 > Richard >=20 > ________________________________ >=20 > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 19:45 > An: Lee, Yiu; Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 >=20 >=20 > Agreed, in this case the proxy associated with provB.net would be an > intermediate device that would have to perform some sort of internal > lookup in order to route the request to the next hop. >=20 > > -----Original Message----- > > From: Lee, Yiu > > Sent: Thursday, June 01, 2006 13:34 > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > In this case, I guess when the originating proxy resolves the domain > part > > of the AOR (sip:+4319793321@provB.net), it will return the IP address > of > > the root domain "provB.net" which may be a redirect proxy. So > "provB.net" > > has two choices: > > > > (1) It accesses its local routing table and sends a 305 to the > originating > > proxy with "sbc4711.provB.net" in the contact header. > > > > (2) It replaces the domain part in the r-uri to more specific like > > "proxy.austria.provB.net" and forward the message to the next-hop. > > > > Either case, the assumption is provB.net will have a way to find out > where > > the home proxy of user +4319793321. > > > > This is only my guess. > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 1:13 PM > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > > > I see, > > > > but how do you solve this problem if the users can also be reached by > AoRs > > direct? > > > > -sta > > > > ________________________________ > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Gesendet: Do 01.06.2006 17:57 > > An: Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > > > > > Maybe the service provider has some sort of segregated network > (physically > > or logically) and wants/needs to associate each its subscribers with a >=20 > > particular network segment. If the provider went with the flat model > of > > provB.net, each of its proxies would have to accept requests destined > to > > all of its customers and would then have to route the request to the > > appropriate region or division of its network. > > If the provider went with the hierarchical approach of > sbc4711.provB.net, > > all of the requests would already be routed to the appropriate ingress >=20 > > point. This could very well save a service provider a lot of money in >=20 > > route proxy equipment although might cost more on the provisioning > side. > > > > That is my guess. > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 11:30 > > > To: Creighton, Tom; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > Thank you, Tom > > > > > > just a minor additional question: > > > > > > > In either case, after the provider A proxy performs an ENUM query > > and > > > > rewrites the request URI, it should behave as a UAC and follow the >=20 > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > address, > > > > port, and transport protocol for the provider B UAS. > > > > > > If I have to do this according to RFC3263 anyway, why put the > > > sbc4711.provB.net into ENUM in the first place? > > > > > > -sta > > > > > > > > > > -----Original Message----- > > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > > Sent: Thursday, June 01, 2006 4:36 PM > > > > To: Stastny Richard; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Thursday, June 01, 2006 09:06 > > > > > To: speermint@ietf.org > > > > > Cc: enum@ietf.org > > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > > > Folks, > > > > > > > > > > Question for clarification: > > > > > > > > > > In the discussions here on how to populate sip URI in > > Infrastructure > > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of >=20 > > > > > thought exist: > > > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the >=20 > > > > > address-of-record of the user: e.g. > > sip:+4319793321@provB.net > > > > > 2. the ingress point into the provider network: > > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > > > The originating UAC has in this case set the To: field to > > > > > tel:+4319793321 and the Request-URI to e.g. > > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM query > at > > > > > the proxy of provider A > > > > > > > > > > The question is how the proxy of provider A is now setting up > the > > > > > request URI in cases mentioned above? > > > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, > or > > > > > must the request URI set to the proper AoR as described in > > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > > > [Tom Creighton wrote:] > > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > > identify an address that the UAS is willing to accept requests > for, > > it > > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > > > As long as the UAS from provider B is "willing" to accept the > > request, > > > > either should work. Since provider B is populating Infrastructure > > > ENUM, > > > > one would hope that they would coordinate this data with the > > > > configuration of their proxies. > > > > > > > > Besides, how do you actually know that sbc4441.provB.net is > actually > > a > > > > hostname and isn't a subdomain? > > > > > > > > In either case, after the provider A proxy performs an ENUM query > > and > > > > rewrites the request URI, it should behave as a UAC and follow the >=20 > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > address, > > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > > > Regards > > > > > > > > > > -sta > > > > > > > > > > > > > > > _______________________________________________ > > > > > enum mailing list > > > > > enum@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jun 02 15:59:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFnT-0002OE-UK; Fri, 02 Jun 2006 15:59:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFnS-0002Nv-F3; Fri, 02 Jun 2006 15:59:02 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmFnQ-0005ld-Nk; Fri, 02 Jun 2006 15:59:02 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-6.tower-120.messagelabs.com!1149276628!9622849!4 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 30182 invoked from network); 2 Jun 2006 19:30:56 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-6.tower-120.messagelabs.com with SMTP; 2 Jun 2006 19:30:56 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 44708FE9001BEB82; Fri, 2 Jun 2006 15:30:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 15:30:48 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0CEFF776@ACCLUST02EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAATCo4A== From: "Pfautz, Penn L, GBLAM" To: "James McEachern" , "Lee, Yiu" , "Stastny Richard" , "Creighton, Tom" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org James I think what this means is that a provider should not provision an AoR that would a) provide personally identifiable information beyond the called phone number or b) allow direct access to the user's CPE. Or are you referring to a user supplied SIP URI? Penn=20 -----Original Message----- From: James McEachern [mailto:jmce@nortel.com]=20 Sent: Friday, June 02, 2006 3:12 PM To: Lee, Yiu; Stastny Richard; Creighton, Tom; speermint@ietf.org; enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? In the past it has been suggested that if Infrastructure ENUM is openly accessible, then for data privacy reasons it would not be acceptable to list the user AOR. Do we still believe this is the case, or do we now think providing the user AOR would be acceptable? James -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]=20 Sent: Thursday, June 01, 2006 2:22 PM To: Stastny Richard; Creighton, Tom; speermint@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Actually, I think it is sufficient for the Enum to return the user AOR because the routing decision should happen in the provB.net network. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Thursday, June 01, 2006 2:18 PM To: Lee, Yiu; Creighton, Tom; speermint@ietf.org Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI? Ok, so I am back to my original question: =20 if I implement both types of public user identities: E.164 numbers and SIP AoRs, why doing the mapping to different hosting proxies in two places (in this case ENUM and the HSS), if I can do it only in one place? -sta ________________________________ Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Gesendet: Do 01.06.2006 20:10 An: Stastny Richard; Creighton, Tom; speermint@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Yes. IMS is using Option 2. Option 1 is also possible if the operator decides to use just a redirect proxy. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, June 01, 2006 2:07 PM To: Creighton, Tom; Lee, Yiu; speermint@ietf.org Cc: enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? so basically the IMS I-CSCF - HSS - S-CSCF way? Richard ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Do 01.06.2006 19:45 An: Lee, Yiu; Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Agreed, in this case the proxy associated with provB.net would be an intermediate device that would have to perform some sort of internal lookup in order to route the request to the next hop. > -----Original Message----- > From: Lee, Yiu > Sent: Thursday, June 01, 2006 13:34 > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > In this case, I guess when the originating proxy resolves the domain part > of the AOR (sip:+4319793321@provB.net), it will return the IP address of > the root domain "provB.net" which may be a redirect proxy. So "provB.net" > has two choices: > > (1) It accesses its local routing table and sends a 305 to the originating > proxy with "sbc4711.provB.net" in the contact header. > > (2) It replaces the domain part in the r-uri to more specific like=20 > "proxy.austria.provB.net" and forward the message to the next-hop. > > Either case, the assumption is provB.net will have a way to find out where > the home proxy of user +4319793321. > > This is only my guess. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 1:13 PM > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? > > I see, > > but how do you solve this problem if the users can also be reached by AoRs > direct? > > -sta > > ________________________________ > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 17:57 > An: Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > Maybe the service provider has some sort of segregated network (physically > or logically) and wants/needs to associate each its subscribers with a > particular network segment. If the provider went with the flat model of > provB.net, each of its proxies would have to accept requests destined to > all of its customers and would then have to route the request to the=20 > appropriate region or division of its network. > If the provider went with the hierarchical approach of sbc4711.provB.net, > all of the requests would already be routed to the appropriate ingress > point. This could very well save a service provider a lot of money in > route proxy equipment although might cost more on the provisioning side. > > That is my guess. > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 11:30 > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > Thank you, Tom > > > > just a minor additional question: > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > If I have to do this according to RFC3263 anyway, why put the=20 > > sbc4711.provB.net into ENUM in the first place? > > > > -sta > > > > > > > -----Original Message----- > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Sent: Thursday, June 01, 2006 4:36 PM > > > To: Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 09:06 > > > > To: speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > Folks, > > > > > > > > Question for clarification: > > > > > > > > In the discussions here on how to populate sip URI in > Infrastructure > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of > > > > thought exist: > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the > > > > address-of-record of the user: e.g. > sip:+4319793321@provB.net > > > > 2. the ingress point into the provider network: > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > The originating UAC has in this case set the To: field to > > > > tel:+4319793321 and the Request-URI to e.g. > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM = query at > > > > the proxy of provider A > > > > > > > > The question is how the proxy of provider A is now setting up the > > > > request URI in cases mentioned above? > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, or > > > > must the request URI set to the proper AoR as described in > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > [Tom Creighton wrote:] > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > identify an address that the UAS is willing to accept requests for, > it > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > As long as the UAS from provider B is "willing" to accept the > request, > > > either should work. Since provider B is populating Infrastructure > > ENUM, > > > one would hope that they would coordinate this data with the=20 > > > configuration of their proxies. > > > > > > Besides, how do you actually know that sbc4441.provB.net is actually > a > > > hostname and isn't a subdomain? > > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > Regards > > > > > > > > -sta > > > > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ 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 From enum-bounces@ietf.org Fri Jun 02 15:59:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFoI-0002eh-MB; Fri, 02 Jun 2006 15:59:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFoI-0002eO-1Z; Fri, 02 Jun 2006 15:59:54 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmFoG-0005xD-N5; Fri, 02 Jun 2006 15:59:54 -0400 Received: from ([10.52.116.31]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.20676753; Fri, 02 Jun 2006 15:59:35 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 15:59:35 -0400 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] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 15:59:34 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D9670545E@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAA1DG0wAArcX1AAAHkt4A== From: "Creighton, Tom" To: "Stastny Richard" , X-OriginalArrivalTime: 02 Jun 2006 19:59:35.0450 (UTC) FILETIME=[126957A0:01C6867F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Comments below. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, June 02, 2006 15:41 > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: Re: [Enum] How to correctly set up the request URI? >=20 > Tom, >=20 > being in favor of the usage of an AoR in Infrastructure ENUM, I have no > problems with your proposed words. There are only two issues: >=20 > 1. There will be some people objecting, I assume. [Tom Creighton wrote:]=20 I welcome any comments or recommendations that anyone has to help move beyond this discussion. =20 > 2. Where should this words go? > -in the ENUM requirements or in the SPEERMINT requirements? [Tom Creighton wrote:]=20 My initial reaction would be to keep it in SPEERMINT as this is a peering architecture issue and not a specific ENUM protocol issue, but as you said, advice from the 4 chairs would be appreciated. >=20 > could the esteemed chairs of the two WGs please give their advice? >=20 > -sta >=20 > ________________________________ >=20 > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Fr 02.06.2006 21:19 > An: Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Enum] How to correctly set up the request URI? >=20 >=20 >=20 > Richard: >=20 > All examples aside, I attempted to craft some words that would not set > any limitations on what can or cannot be used in the host portion of a > SIP URI while maintaining a consistent method for resolving whatever is > used in the host portion of a SIP URI. >=20 > When a SIP URI is used in Infrastructure ENUM, the procedures outlined > in RFC3263 MUST be followed for locating a UAS that will accept a > request for the given URI. For providers assuming the role of a UAS, > this means that they MUST provision RFC3263 compliant NAPTR records and > SRV records that correspond to the host portion of the SIP URI > provisioned in Infrastructure ENUM. For providers assuming the role of > a UAC, when a query to Infrastructure ENUM returns a SIP URI, they MUST > follow the procedures outlined in Section 4 of RFC3263 to determine the > IP address, port, and transport protocol of a UAS that will accept a > request for the given URI. >=20 > Please let me know what you think. >=20 > Regards, >=20 > Tom >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 09:06 > > To: speermint@ietf.org > > Cc: enum@ietf.org > > Subject: [Enum] How to correctly set up the request URI? > > > > Folks, > > > > Question for clarification: > > > > In the discussions here on how to populate sip URI in Infrastructure > > ENUM to derive the Call Routing data for SPEERMINT two > > lines of thought exist: > > > > The Enumservice SIP in Infrastructure ENUM should contain > > 1. the address-of-record of the user: e.g. sip:+4319793321@provB.net > > 2. the ingress point into the provider network: > > e.g. sip:+4319793321@sbc4711.provB.net > > > > The originating UAC has in this case set the To: field to > > tel:+4319793321 and the Request-URI to e.g. > > sip:+4319793321provA.net;user=3Dphone. This caused the > > ENUM query at the proxy of provider A > > > > The question is how the proxy of provider A is now > > setting up the request URI in cases mentioned above? > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, > > or must the request URI set to the proper AoR as described in > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > I would also like to draw the attention to section 3 of > > RFC3761 (SIP Enumservice) explaining the usage of AoR in > > ENUM. > > > > Regards > > > > -sta > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jun 02 16:40:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGRE-0000RS-5p; Fri, 02 Jun 2006 16:40:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGRC-0000R1-Ic; Fri, 02 Jun 2006 16:40:06 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmGRC-0002fc-2D; Fri, 02 Jun 2006 16:40:06 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k52KYpx21698; Fri, 2 Jun 2006 16:34:52 -0400 (EDT) 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: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 16:39:55 -0400 Message-ID: In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0CEFF776@ACCLUST02EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAATCo4AACUnHw From: "James McEachern" To: "Pfautz, Penn L, GBLAM" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Penn, I'm thinking of either user supplied SIP URIs, or carrier supplied SIP = URIs other than those that are simply based on the E.164 number. (e.g. sip:+4319793321provA.net;user=3Dphone) I am assuming that these = are possible, and that therefore we must provide a solution that deals = with them. James -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com]=20 Sent: Friday, June 02, 2006 3:31 PM To: McEachern, James [CAR:5N00:EXCH]; Lee, Yiu; Stastny Richard; = Creighton, Tom; speermint@ietf.org; enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? James I think what this means is that a provider should not provision an AoR that would a) provide personally identifiable information beyond the called phone number or b) allow direct access to the user's CPE. Or are you referring to a user supplied SIP URI? Penn=20 -----Original Message----- From: James McEachern [mailto:jmce@nortel.com]=20 Sent: Friday, June 02, 2006 3:12 PM To: Lee, Yiu; Stastny Richard; Creighton, Tom; speermint@ietf.org; enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? In the past it has been suggested that if Infrastructure ENUM is openly accessible, then for data privacy reasons it would not be acceptable to list the user AOR. Do we still believe this is the case, or do we now think providing the user AOR would be acceptable? James -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]=20 Sent: Thursday, June 01, 2006 2:22 PM To: Stastny Richard; Creighton, Tom; speermint@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Actually, I think it is sufficient for the Enum to return the user AOR because the routing decision should happen in the provB.net network. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Thursday, June 01, 2006 2:18 PM To: Lee, Yiu; Creighton, Tom; speermint@ietf.org Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI? Ok, so I am back to my original question: =20 if I implement both types of public user identities: E.164 numbers and SIP AoRs, why doing the mapping to different hosting proxies in two places (in this case ENUM and the HSS), if I can do it only in one place? -sta ________________________________ Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Gesendet: Do 01.06.2006 20:10 An: Stastny Richard; Creighton, Tom; speermint@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Yes. IMS is using Option 2. Option 1 is also possible if the operator decides to use just a redirect proxy. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, June 01, 2006 2:07 PM To: Creighton, Tom; Lee, Yiu; speermint@ietf.org Cc: enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? so basically the IMS I-CSCF - HSS - S-CSCF way? Richard ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Do 01.06.2006 19:45 An: Lee, Yiu; Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Agreed, in this case the proxy associated with provB.net would be an intermediate device that would have to perform some sort of internal lookup in order to route the request to the next hop. > -----Original Message----- > From: Lee, Yiu > Sent: Thursday, June 01, 2006 13:34 > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > In this case, I guess when the originating proxy resolves the domain part > of the AOR (sip:+4319793321@provB.net), it will return the IP address of > the root domain "provB.net" which may be a redirect proxy. So "provB.net" > has two choices: > > (1) It accesses its local routing table and sends a 305 to the originating > proxy with "sbc4711.provB.net" in the contact header. > > (2) It replaces the domain part in the r-uri to more specific like=20 > "proxy.austria.provB.net" and forward the message to the next-hop. > > Either case, the assumption is provB.net will have a way to find out where > the home proxy of user +4319793321. > > This is only my guess. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 1:13 PM > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? > > I see, > > but how do you solve this problem if the users can also be reached by AoRs > direct? > > -sta > > ________________________________ > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 17:57 > An: Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > Maybe the service provider has some sort of segregated network (physically > or logically) and wants/needs to associate each its subscribers with a > particular network segment. If the provider went with the flat model of > provB.net, each of its proxies would have to accept requests destined to > all of its customers and would then have to route the request to the=20 > appropriate region or division of its network. > If the provider went with the hierarchical approach of sbc4711.provB.net, > all of the requests would already be routed to the appropriate ingress > point. This could very well save a service provider a lot of money in > route proxy equipment although might cost more on the provisioning side. > > That is my guess. > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 11:30 > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > Thank you, Tom > > > > just a minor additional question: > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > If I have to do this according to RFC3263 anyway, why put the=20 > > sbc4711.provB.net into ENUM in the first place? > > > > -sta > > > > > > > -----Original Message----- > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Sent: Thursday, June 01, 2006 4:36 PM > > > To: Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 09:06 > > > > To: speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > Folks, > > > > > > > > Question for clarification: > > > > > > > > In the discussions here on how to populate sip URI in > Infrastructure > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of > > > > thought exist: > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the > > > > address-of-record of the user: e.g. > sip:+4319793321@provB.net > > > > 2. the ingress point into the provider network: > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > The originating UAC has in this case set the To: field to > > > > tel:+4319793321 and the Request-URI to e.g. > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM = query at > > > > the proxy of provider A > > > > > > > > The question is how the proxy of provider A is now setting up the > > > > request URI in cases mentioned above? > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, or > > > > must the request URI set to the proper AoR as described in > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > [Tom Creighton wrote:] > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > identify an address that the UAS is willing to accept requests for, > it > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > As long as the UAS from provider B is "willing" to accept the > request, > > > either should work. Since provider B is populating Infrastructure > > ENUM, > > > one would hope that they would coordinate this data with the=20 > > > configuration of their proxies. > > > > > > Besides, how do you actually know that sbc4441.provB.net is actually > a > > > hostname and isn't a subdomain? > > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > Regards > > > > > > > > -sta > > > > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ 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 From enum-bounces@ietf.org Fri Jun 02 16:50:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGap-0004AN-Fj; Fri, 02 Jun 2006 16:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGan-00049o-4x; Fri, 02 Jun 2006 16:50:01 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmGam-0004oP-Kv; Fri, 02 Jun 2006 16:50:01 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-11.tower-121.messagelabs.com!1149281314!7603740!27 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 20250 invoked from network); 2 Jun 2006 20:49:59 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-11.tower-121.messagelabs.com with SMTP; 2 Jun 2006 20:49:59 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 44708FE9001C275B; Fri, 2 Jun 2006 16:49:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 16:49:58 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0CEFF8CE@ACCLUST02EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAATCo4AACUnHwAABdhAA= From: "Pfautz, Penn L, GBLAM" To: "James McEachern" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org If a carrier agrees to provision a user-supplied URI and the user chooses to use one including PII after proper caution, that's their lookout.=20 I see no privacy issue with a carrier URI like the one you show below as long as it points to a carrier network element rather than directly to say, the user's terminal adapter. If the pointer is direct to CPE I'd have some concerns, which is not to say a provider can be forbidden (except by regulators) to do so. -----Original Message----- From: James McEachern [mailto:jmce@nortel.com]=20 Sent: Friday, June 02, 2006 4:40 PM To: Pfautz, Penn L, GBLAM; speermint@ietf.org; enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Penn, I'm thinking of either user supplied SIP URIs, or carrier supplied SIP URIs other than those that are simply based on the E.164 number. (e.g. sip:+4319793321provA.net;user=3Dphone) I am assuming that these = are possible, and that therefore we must provide a solution that deals with them. James -----Original Message----- From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com]=20 Sent: Friday, June 02, 2006 3:31 PM To: McEachern, James [CAR:5N00:EXCH]; Lee, Yiu; Stastny Richard; Creighton, Tom; speermint@ietf.org; enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? James I think what this means is that a provider should not provision an AoR that would a) provide personally identifiable information beyond the called phone number or b) allow direct access to the user's CPE. Or are you referring to a user supplied SIP URI? Penn=20 -----Original Message----- From: James McEachern [mailto:jmce@nortel.com]=20 Sent: Friday, June 02, 2006 3:12 PM To: Lee, Yiu; Stastny Richard; Creighton, Tom; speermint@ietf.org; enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? In the past it has been suggested that if Infrastructure ENUM is openly accessible, then for data privacy reasons it would not be acceptable to list the user AOR. Do we still believe this is the case, or do we now think providing the user AOR would be acceptable? James -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]=20 Sent: Thursday, June 01, 2006 2:22 PM To: Stastny Richard; Creighton, Tom; speermint@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Actually, I think it is sufficient for the Enum to return the user AOR because the routing decision should happen in the provB.net network. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Thursday, June 01, 2006 2:18 PM To: Lee, Yiu; Creighton, Tom; speermint@ietf.org Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI? Ok, so I am back to my original question: =20 if I implement both types of public user identities: E.164 numbers and SIP AoRs, why doing the mapping to different hosting proxies in two places (in this case ENUM and the HSS), if I can do it only in one place? -sta ________________________________ Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Gesendet: Do 01.06.2006 20:10 An: Stastny Richard; Creighton, Tom; speermint@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Yes. IMS is using Option 2. Option 1 is also possible if the operator decides to use just a redirect proxy. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, June 01, 2006 2:07 PM To: Creighton, Tom; Lee, Yiu; speermint@ietf.org Cc: enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? so basically the IMS I-CSCF - HSS - S-CSCF way? Richard ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Do 01.06.2006 19:45 An: Lee, Yiu; Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Agreed, in this case the proxy associated with provB.net would be an intermediate device that would have to perform some sort of internal lookup in order to route the request to the next hop. > -----Original Message----- > From: Lee, Yiu > Sent: Thursday, June 01, 2006 13:34 > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > In this case, I guess when the originating proxy resolves the domain part > of the AOR (sip:+4319793321@provB.net), it will return the IP address of > the root domain "provB.net" which may be a redirect proxy. So "provB.net" > has two choices: > > (1) It accesses its local routing table and sends a 305 to the originating > proxy with "sbc4711.provB.net" in the contact header. > > (2) It replaces the domain part in the r-uri to more specific like=20 > "proxy.austria.provB.net" and forward the message to the next-hop. > > Either case, the assumption is provB.net will have a way to find out where > the home proxy of user +4319793321. > > This is only my guess. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 1:13 PM > To: Creighton, Tom; speermint@ietf.org > Cc: enum@ietf.org > Subject: [Speermint] Re: [Enum] How to correctly set up the request URI? > > I see, > > but how do you solve this problem if the users can also be reached by AoRs > direct? > > -sta > > ________________________________ > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 17:57 > An: Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > Maybe the service provider has some sort of segregated network (physically > or logically) and wants/needs to associate each its subscribers with a > particular network segment. If the provider went with the flat model of > provB.net, each of its proxies would have to accept requests destined to > all of its customers and would then have to route the request to the=20 > appropriate region or division of its network. > If the provider went with the hierarchical approach of sbc4711.provB.net, > all of the requests would already be routed to the appropriate ingress > point. This could very well save a service provider a lot of money in > route proxy equipment although might cost more on the provisioning side. > > That is my guess. > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 11:30 > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > Thank you, Tom > > > > just a minor additional question: > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > If I have to do this according to RFC3263 anyway, why put the=20 > > sbc4711.provB.net into ENUM in the first place? > > > > -sta > > > > > > > -----Original Message----- > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Sent: Thursday, June 01, 2006 4:36 PM > > > To: Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 09:06 > > > > To: speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > Folks, > > > > > > > > Question for clarification: > > > > > > > > In the discussions here on how to populate sip URI in > Infrastructure > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of > > > > thought exist: > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the > > > > address-of-record of the user: e.g. > sip:+4319793321@provB.net > > > > 2. the ingress point into the provider network: > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > The originating UAC has in this case set the To: field to > > > > tel:+4319793321 and the Request-URI to e.g. > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM = query at > > > > the proxy of provider A > > > > > > > > The question is how the proxy of provider A is now setting up the > > > > request URI in cases mentioned above? > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, or > > > > must the request URI set to the proper AoR as described in > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > [Tom Creighton wrote:] > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > identify an address that the UAS is willing to accept requests for, > it > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > As long as the UAS from provider B is "willing" to accept the > request, > > > either should work. Since provider B is populating Infrastructure > > ENUM, > > > one would hope that they would coordinate this data with the=20 > > > configuration of their proxies. > > > > > > Besides, how do you actually know that sbc4441.provB.net is actually > a > > > hostname and isn't a subdomain? > > > > > > In either case, after the provider A proxy performs an ENUM query > and > > > rewrites the request URI, it should behave as a UAC and follow the > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > address, > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > Regards > > > > > > > > -sta > > > > > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ 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 From enum-bounces@ietf.org Fri Jun 02 16:52:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGcj-0006vo-2s; Fri, 02 Jun 2006 16:52:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGch-0006vb-QH; Fri, 02 Jun 2006 16:51:59 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmGch-00053m-8D; Fri, 02 Jun 2006 16:51:59 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k52KpsJ11846; Fri, 2 Jun 2006 16:51:54 -0400 (EDT) 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: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 16:51:34 -0400 Message-ID: In-Reply-To: <4884CD6C1DF0A8429DD8DAD942BF9D96705448@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVA From: "James McEachern" To: "Creighton, Tom" , "Lee, Yiu" , "Stastny Richard" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: e06437eb72f6703f11713d345be8298a Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Ok, I think I see now. Presumably I can have a SIP URI that clearly = identifies me, but this is not the AOR that would be populated in = Infrastructure ENUM. That AOR would either be based on my E.164 number, = or on some other random string created by the carrier. Have I got it = right? James -----Original Message----- From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com]=20 Sent: Friday, June 02, 2006 3:49 PM To: McEachern, James [CAR:5N00:EXCH]; Lee, Yiu; Stastny Richard; = speermint@ietf.org; enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? I think we have two separate issues: 1. An issue of misunderstanding of the term AoR. Section 6 of RFC3261 defines an Address-of-Record as: "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the "public address" of the user." Based on that definition and the examples provided by Richard, a user's privacy would not be compromised because it doesn't directly reach or identify the customer. 2. There is confusion around what is or is not acceptable in the host portion of a SIP URI. As long as RFC3263 is followed, it shouldn't matter what is placed in the host portion of the SIP URI as long as it doesn't compromise a user's privacy. So in the examples Richard provided earlier, either are acceptable and would resolve in an identical manner. Tom > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Friday, June 02, 2006 15:12 > To: Lee, Yiu; Stastny Richard; Creighton, Tom; speermint@ietf.org; > enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > In the past it has been suggested that if Infrastructure ENUM is openly > accessible, then for data privacy reasons it would not be acceptable to > list the user AOR. Do we still believe this is the case, or do we now > think providing the user AOR would be acceptable? >=20 > James >=20 > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Sent: Thursday, June 01, 2006 2:22 PM > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > Actually, I think it is sufficient for the Enum to return the user AOR > because the routing decision should happen in the provB.net network. >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 2:18 PM > To: Lee, Yiu; Creighton, Tom; speermint@ietf.org > Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > Ok, so I am back to my original question: >=20 > if I implement both types of public user identities: > E.164 numbers and SIP AoRs, why doing the mapping to different hosting > proxies in two places (in this case ENUM and the HSS), if I can do it > only in one place? >=20 > -sta >=20 >=20 >=20 > ________________________________ >=20 > Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Gesendet: Do 01.06.2006 20:10 > An: Stastny Richard; Creighton, Tom; speermint@ietf.org > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 >=20 >=20 > Yes. IMS is using Option 2. Option 1 is also possible if the operator > decides to use just a redirect proxy. >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 2:07 PM > To: Creighton, Tom; Lee, Yiu; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > so basically the IMS I-CSCF - HSS - S-CSCF way? >=20 > Richard >=20 > ________________________________ >=20 > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 19:45 > An: Lee, Yiu; Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 >=20 >=20 > Agreed, in this case the proxy associated with provB.net would be an > intermediate device that would have to perform some sort of internal > lookup in order to route the request to the next hop. >=20 > > -----Original Message----- > > From: Lee, Yiu > > Sent: Thursday, June 01, 2006 13:34 > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > In this case, I guess when the originating proxy resolves the domain > part > > of the AOR (sip:+4319793321@provB.net), it will return the IP address > of > > the root domain "provB.net" which may be a redirect proxy. So > "provB.net" > > has two choices: > > > > (1) It accesses its local routing table and sends a 305 to the > originating > > proxy with "sbc4711.provB.net" in the contact header. > > > > (2) It replaces the domain part in the r-uri to more specific like > > "proxy.austria.provB.net" and forward the message to the next-hop. > > > > Either case, the assumption is provB.net will have a way to find out > where > > the home proxy of user +4319793321. > > > > This is only my guess. > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 1:13 PM > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > > > I see, > > > > but how do you solve this problem if the users can also be reached by > AoRs > > direct? > > > > -sta > > > > ________________________________ > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Gesendet: Do 01.06.2006 17:57 > > An: Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > > > > > Maybe the service provider has some sort of segregated network > (physically > > or logically) and wants/needs to associate each its subscribers with a >=20 > > particular network segment. If the provider went with the flat model > of > > provB.net, each of its proxies would have to accept requests destined > to > > all of its customers and would then have to route the request to the > > appropriate region or division of its network. > > If the provider went with the hierarchical approach of > sbc4711.provB.net, > > all of the requests would already be routed to the appropriate ingress >=20 > > point. This could very well save a service provider a lot of money in >=20 > > route proxy equipment although might cost more on the provisioning > side. > > > > That is my guess. > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 11:30 > > > To: Creighton, Tom; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > Thank you, Tom > > > > > > just a minor additional question: > > > > > > > In either case, after the provider A proxy performs an ENUM query > > and > > > > rewrites the request URI, it should behave as a UAC and follow the >=20 > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > address, > > > > port, and transport protocol for the provider B UAS. > > > > > > If I have to do this according to RFC3263 anyway, why put the > > > sbc4711.provB.net into ENUM in the first place? > > > > > > -sta > > > > > > > > > > -----Original Message----- > > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > > Sent: Thursday, June 01, 2006 4:36 PM > > > > To: Stastny Richard; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Thursday, June 01, 2006 09:06 > > > > > To: speermint@ietf.org > > > > > Cc: enum@ietf.org > > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > > > Folks, > > > > > > > > > > Question for clarification: > > > > > > > > > > In the discussions here on how to populate sip URI in > > Infrastructure > > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of >=20 > > > > > thought exist: > > > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the >=20 > > > > > address-of-record of the user: e.g. > > sip:+4319793321@provB.net > > > > > 2. the ingress point into the provider network: > > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > > > The originating UAC has in this case set the To: field to > > > > > tel:+4319793321 and the Request-URI to e.g. > > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM query > at > > > > > the proxy of provider A > > > > > > > > > > The question is how the proxy of provider A is now setting up > the > > > > > request URI in cases mentioned above? > > > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, > or > > > > > must the request URI set to the proper AoR as described in > > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > > > [Tom Creighton wrote:] > > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > > identify an address that the UAS is willing to accept requests > for, > > it > > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > > > As long as the UAS from provider B is "willing" to accept the > > request, > > > > either should work. Since provider B is populating Infrastructure > > > ENUM, > > > > one would hope that they would coordinate this data with the > > > > configuration of their proxies. > > > > > > > > Besides, how do you actually know that sbc4441.provB.net is > actually > > a > > > > hostname and isn't a subdomain? > > > > > > > > In either case, after the provider A proxy performs an ENUM query > > and > > > > rewrites the request URI, it should behave as a UAC and follow the >=20 > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > address, > > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > > > Regards > > > > > > > > > > -sta > > > > > > > > > > > > > > > _______________________________________________ > > > > > enum mailing list > > > > > enum@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ 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 From enum-bounces@ietf.org Fri Jun 02 16:55:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGgE-0002Ci-FA; Fri, 02 Jun 2006 16:55:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGgD-0002CP-01; Fri, 02 Jun 2006 16:55:37 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmGgC-0005NZ-Fh; Fri, 02 Jun 2006 16:55:36 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-14.tower-121.messagelabs.com!1149281735!7046634!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 30236 invoked from network); 2 Jun 2006 20:55:35 -0000 Received: from unknown (HELO ACCLUST02EVS1.ugd.att.com) (134.24.146.4) by server-14.tower-121.messagelabs.com with SMTP; 2 Jun 2006 20:55:35 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 16:55:34 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0CEFF8DE@ACCLUST02EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVAAABBo3A= From: "Pfautz, Penn L, GBLAM" To: "James McEachern" , "Creighton, Tom" , "Lee, Yiu" , "Stastny Richard" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 89ebdf268eceaeaf784b3acb625dc20e Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Yes. Again, there might be exceptions, for example a business might want a URI with their name to be used and some SPs might agree to that, but generally the point of infrastructure ENUM is to be invisible to the user=20 -----Original Message----- From: James McEachern [mailto:jmce@nortel.com]=20 Sent: Friday, June 02, 2006 4:52 PM To: Creighton, Tom; Lee, Yiu; Stastny Richard; speermint@ietf.org; enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Ok, I think I see now. Presumably I can have a SIP URI that clearly identifies me, but this is not the AOR that would be populated in Infrastructure ENUM. That AOR would either be based on my E.164 number, or on some other random string created by the carrier. Have I got it right? James -----Original Message----- From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com]=20 Sent: Friday, June 02, 2006 3:49 PM To: McEachern, James [CAR:5N00:EXCH]; Lee, Yiu; Stastny Richard; speermint@ietf.org; enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? I think we have two separate issues: 1. An issue of misunderstanding of the term AoR. Section 6 of RFC3261 defines an Address-of-Record as: "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the "public address" of the user." Based on that definition and the examples provided by Richard, a user's privacy would not be compromised because it doesn't directly reach or identify the customer. 2. There is confusion around what is or is not acceptable in the host portion of a SIP URI. As long as RFC3263 is followed, it shouldn't matter what is placed in the host portion of the SIP URI as long as it doesn't compromise a user's privacy. So in the examples Richard provided earlier, either are acceptable and would resolve in an identical manner. Tom > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Friday, June 02, 2006 15:12 > To: Lee, Yiu; Stastny Richard; Creighton, Tom; speermint@ietf.org; > enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > In the past it has been suggested that if Infrastructure ENUM is openly > accessible, then for data privacy reasons it would not be acceptable to > list the user AOR. Do we still believe this is the case, or do we now > think providing the user AOR would be acceptable? >=20 > James >=20 > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Sent: Thursday, June 01, 2006 2:22 PM > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > Actually, I think it is sufficient for the Enum to return the user AOR > because the routing decision should happen in the provB.net network. >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 2:18 PM > To: Lee, Yiu; Creighton, Tom; speermint@ietf.org > Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > Ok, so I am back to my original question: >=20 > if I implement both types of public user identities: > E.164 numbers and SIP AoRs, why doing the mapping to different hosting > proxies in two places (in this case ENUM and the HSS), if I can do it > only in one place? >=20 > -sta >=20 >=20 >=20 > ________________________________ >=20 > Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Gesendet: Do 01.06.2006 20:10 > An: Stastny Richard; Creighton, Tom; speermint@ietf.org > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 >=20 >=20 > Yes. IMS is using Option 2. Option 1 is also possible if the operator > decides to use just a redirect proxy. >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 2:07 PM > To: Creighton, Tom; Lee, Yiu; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > so basically the IMS I-CSCF - HSS - S-CSCF way? >=20 > Richard >=20 > ________________________________ >=20 > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 19:45 > An: Lee, Yiu; Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 >=20 >=20 > Agreed, in this case the proxy associated with provB.net would be an > intermediate device that would have to perform some sort of internal > lookup in order to route the request to the next hop. >=20 > > -----Original Message----- > > From: Lee, Yiu > > Sent: Thursday, June 01, 2006 13:34 > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > In this case, I guess when the originating proxy resolves the domain > part > > of the AOR (sip:+4319793321@provB.net), it will return the IP address > of > > the root domain "provB.net" which may be a redirect proxy. So > "provB.net" > > has two choices: > > > > (1) It accesses its local routing table and sends a 305 to the > originating > > proxy with "sbc4711.provB.net" in the contact header. > > > > (2) It replaces the domain part in the r-uri to more specific like > > "proxy.austria.provB.net" and forward the message to the next-hop. > > > > Either case, the assumption is provB.net will have a way to find out > where > > the home proxy of user +4319793321. > > > > This is only my guess. > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 1:13 PM > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > > > I see, > > > > but how do you solve this problem if the users can also be reached by > AoRs > > direct? > > > > -sta > > > > ________________________________ > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Gesendet: Do 01.06.2006 17:57 > > An: Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > > > > > Maybe the service provider has some sort of segregated network > (physically > > or logically) and wants/needs to associate each its subscribers with a >=20 > > particular network segment. If the provider went with the flat model > of > > provB.net, each of its proxies would have to accept requests destined > to > > all of its customers and would then have to route the request to the > > appropriate region or division of its network. > > If the provider went with the hierarchical approach of > sbc4711.provB.net, > > all of the requests would already be routed to the appropriate ingress >=20 > > point. This could very well save a service provider a lot of money in >=20 > > route proxy equipment although might cost more on the provisioning > side. > > > > That is my guess. > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 11:30 > > > To: Creighton, Tom; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > Thank you, Tom > > > > > > just a minor additional question: > > > > > > > In either case, after the provider A proxy performs an ENUM query > > and > > > > rewrites the request URI, it should behave as a UAC and follow the >=20 > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > address, > > > > port, and transport protocol for the provider B UAS. > > > > > > If I have to do this according to RFC3263 anyway, why put the > > > sbc4711.provB.net into ENUM in the first place? > > > > > > -sta > > > > > > > > > > -----Original Message----- > > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > > Sent: Thursday, June 01, 2006 4:36 PM > > > > To: Stastny Richard; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Thursday, June 01, 2006 09:06 > > > > > To: speermint@ietf.org > > > > > Cc: enum@ietf.org > > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > > > Folks, > > > > > > > > > > Question for clarification: > > > > > > > > > > In the discussions here on how to populate sip URI in > > Infrastructure > > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of >=20 > > > > > thought exist: > > > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the >=20 > > > > > address-of-record of the user: e.g. > > sip:+4319793321@provB.net > > > > > 2. the ingress point into the provider network: > > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > > > The originating UAC has in this case set the To: field to > > > > > tel:+4319793321 and the Request-URI to e.g. > > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM query > at > > > > > the proxy of provider A > > > > > > > > > > The question is how the proxy of provider A is now setting up > the > > > > > request URI in cases mentioned above? > > > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, > or > > > > > must the request URI set to the proper AoR as described in > > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > > > [Tom Creighton wrote:] > > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > > identify an address that the UAS is willing to accept requests > for, > > it > > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > > > As long as the UAS from provider B is "willing" to accept the > > request, > > > > either should work. Since provider B is populating Infrastructure > > > ENUM, > > > > one would hope that they would coordinate this data with the > > > > configuration of their proxies. > > > > > > > > Besides, how do you actually know that sbc4441.provB.net is > actually > > a > > > > hostname and isn't a subdomain? > > > > > > > > In either case, after the provider A proxy performs an ENUM query > > and > > > > rewrites the request URI, it should behave as a UAC and follow the >=20 > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > address, > > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > > > Regards > > > > > > > > > > -sta > > > > > > > > > > > > > > > _______________________________________________ > > > > > enum mailing list > > > > > enum@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jun 02 16:58:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGj2-0004lw-PJ; Fri, 02 Jun 2006 16:58:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGj1-0004lc-0u; Fri, 02 Jun 2006 16:58:31 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmGj0-0005lH-Fg; Fri, 02 Jun 2006 16:58:31 -0400 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: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 16:58:19 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D967054B5@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVAAAA6/FA= From: "Creighton, Tom" To: "James McEachern" , "Lee, Yiu" , "Stastny Richard" , , X-OriginalArrivalTime: 02 Jun 2006 20:58:19.0961 (UTC) FILETIME=[472F0A90:01C68687] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org That is correct. The SIP URI that clearly identifies you, as you described, would only be used within your provider's network. > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Friday, June 02, 2006 16:52 > To: Creighton, Tom; Lee, Yiu; Stastny Richard; speermint@ietf.org; > enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > Ok, I think I see now. Presumably I can have a SIP URI that clearly > identifies me, but this is not the AOR that would be populated in > Infrastructure ENUM. That AOR would either be based on my E.164 number, > or on some other random string created by the carrier. Have I got it > right? >=20 > James >=20 > -----Original Message----- > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Sent: Friday, June 02, 2006 3:49 PM > To: McEachern, James [CAR:5N00:EXCH]; Lee, Yiu; Stastny Richard; > speermint@ietf.org; enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 > I think we have two separate issues: >=20 > 1. An issue of misunderstanding of the term AoR. Section 6 of RFC3261 > defines an Address-of-Record as: >=20 > "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI > that points to a domain with a location service that can map > the URI to another URI where the user might be available. > Typically, the location service is populated through > registrations. An AOR is frequently thought of as the "public > address" of the user." >=20 > Based on that definition and the examples provided by Richard, a user's > privacy would not be compromised because it doesn't directly reach or > identify the customer. >=20 > 2. There is confusion around what is or is not acceptable in the host > portion of a SIP URI. As long as RFC3263 is followed, it shouldn't > matter what is placed in the host portion of the SIP URI as long as it > doesn't compromise a user's privacy. So in the examples Richard > provided earlier, either are acceptable and would resolve in an > identical manner. >=20 > Tom >=20 > > -----Original Message----- > > From: James McEachern [mailto:jmce@nortel.com] > > Sent: Friday, June 02, 2006 15:12 > > To: Lee, Yiu; Stastny Richard; Creighton, Tom; speermint@ietf.org; > > enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > In the past it has been suggested that if Infrastructure ENUM is > openly > > accessible, then for data privacy reasons it would not be acceptable > to > > list the user AOR. Do we still believe this is the case, or do we now > > think providing the user AOR would be acceptable? > > > > James > > > > -----Original Message----- > > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > > Sent: Thursday, June 01, 2006 2:22 PM > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > Actually, I think it is sufficient for the Enum to return the user AOR > > because the routing decision should happen in the provB.net network. > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 2:18 PM > > To: Lee, Yiu; Creighton, Tom; speermint@ietf.org > > Subject: Re: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > Ok, so I am back to my original question: > > > > if I implement both types of public user identities: > > E.164 numbers and SIP AoRs, why doing the mapping to different hosting > > proxies in two places (in this case ENUM and the HSS), if I can do it > > only in one place? > > > > -sta > > > > > > > > ________________________________ > > > > Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > > Gesendet: Do 01.06.2006 20:10 > > An: Stastny Richard; Creighton, Tom; speermint@ietf.org > > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > > > > > Yes. IMS is using Option 2. Option 1 is also possible if the operator > > decides to use just a redirect proxy. > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 2:07 PM > > To: Creighton, Tom; Lee, Yiu; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > so basically the IMS I-CSCF - HSS - S-CSCF way? > > > > Richard > > > > ________________________________ > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Gesendet: Do 01.06.2006 19:45 > > An: Lee, Yiu; Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > > > > > Agreed, in this case the proxy associated with provB.net would be an > > intermediate device that would have to perform some sort of internal > > lookup in order to route the request to the next hop. > > > > > -----Original Message----- > > > From: Lee, Yiu > > > Sent: Thursday, June 01, 2006 13:34 > > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > In this case, I guess when the originating proxy resolves the domain > > part > > > of the AOR (sip:+4319793321@provB.net), it will return the IP > address > > of > > > the root domain "provB.net" which may be a redirect proxy. So > > "provB.net" > > > has two choices: > > > > > > (1) It accesses its local routing table and sends a 305 to the > > originating > > > proxy with "sbc4711.provB.net" in the contact header. > > > > > > (2) It replaces the domain part in the r-uri to more specific like > > > "proxy.austria.provB.net" and forward the message to the next-hop. > > > > > > Either case, the assumption is provB.net will have a way to find out > > where > > > the home proxy of user +4319793321. > > > > > > This is only my guess. > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 1:13 PM > > > To: Creighton, Tom; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: [Speermint] Re: [Enum] How to correctly set up the request > > URI? > > > > > > I see, > > > > > > but how do you solve this problem if the users can also be reached > by > > AoRs > > > direct? > > > > > > -sta > > > > > > ________________________________ > > > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Gesendet: Do 01.06.2006 17:57 > > > An: Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > Maybe the service provider has some sort of segregated network > > (physically > > > or logically) and wants/needs to associate each its subscribers with > a > > > > > particular network segment. If the provider went with the flat > model > > of > > > provB.net, each of its proxies would have to accept requests > destined > > to > > > all of its customers and would then have to route the request to the > > > appropriate region or division of its network. > > > If the provider went with the hierarchical approach of > > sbc4711.provB.net, > > > all of the requests would already be routed to the appropriate > ingress > > > > > point. This could very well save a service provider a lot of money > in > > > > > route proxy equipment although might cost more on the provisioning > > side. > > > > > > That is my guess. > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 11:30 > > > > To: Creighton, Tom; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > Thank you, Tom > > > > > > > > just a minor additional question: > > > > > > > > > In either case, after the provider A proxy performs an ENUM > query > > > and > > > > > rewrites the request URI, it should behave as a UAC and follow > the > > > > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > > address, > > > > > port, and transport protocol for the provider B UAS. > > > > > > > > If I have to do this according to RFC3263 anyway, why put the > > > > sbc4711.provB.net into ENUM in the first place? > > > > > > > > -sta > > > > > > > > > > > > > -----Original Message----- > > > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > > > Sent: Thursday, June 01, 2006 4:36 PM > > > > > To: Stastny Richard; speermint@ietf.org > > > > > Cc: enum@ietf.org > > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > > Sent: Thursday, June 01, 2006 09:06 > > > > > > To: speermint@ietf.org > > > > > > Cc: enum@ietf.org > > > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > Folks, > > > > > > > > > > > > Question for clarification: > > > > > > > > > > > > In the discussions here on how to populate sip URI in > > > Infrastructure > > > > > > ENUM to derive the Call Routing data for SPEERMINT two lines > of > > > > > > > > thought exist: > > > > > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. > the > > > > > > > > address-of-record of the user: e.g. > > > sip:+4319793321@provB.net > > > > > > 2. the ingress point into the provider network: > > > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > > > > > The originating UAC has in this case set the To: field to > > > > > > tel:+4319793321 and the Request-URI to e.g. > > > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM > query > > at > > > > > > the proxy of provider A > > > > > > > > > > > > The question is how the proxy of provider A is now setting up > > the > > > > > > request URI in cases mentioned above? > > > > > > > > > > > > Does the UAS from provider B accept calls to > sbc7411.provB.net, > > or > > > > > > must the request URI set to the proper AoR as described in > > > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in > ENUM. > > > > > > > > > > [Tom Creighton wrote:] > > > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > > > identify an address that the UAS is willing to accept requests > > for, > > > it > > > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > > > > > As long as the UAS from provider B is "willing" to accept the > > > request, > > > > > either should work. Since provider B is populating > Infrastructure > > > > ENUM, > > > > > one would hope that they would coordinate this data with the > > > > > configuration of their proxies. > > > > > > > > > > Besides, how do you actually know that sbc4441.provB.net is > > actually > > > a > > > > > hostname and isn't a subdomain? > > > > > > > > > > In either case, after the provider A proxy performs an ENUM > query > > > and > > > > > rewrites the request URI, it should behave as a UAC and follow > the > > > > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > > address, > > > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > > > > > Regards > > > > > > > > > > > > -sta > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > enum mailing list > > > > > > enum@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 > _______________________________________________ > 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 From enum-bounces@ietf.org Fri Jun 02 16:59:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGjp-0005Xx-F4; Fri, 02 Jun 2006 16:59:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGjn-0005TW-8L; Fri, 02 Jun 2006 16:59:19 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmGjm-0005sc-6M; Fri, 02 Jun 2006 16:59:19 -0400 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: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 23:03:24 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AA9@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVAAABmHa4= From: "Stastny Richard" To: "James McEachern" , "Creighton, Tom" , "Lee, Yiu" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: abb8110dde048486ea2be9c769692569 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Exactly, =20 A service provider will never populate Infrastructure ENUM with a user = provided URI, (even if the user may have one), it will always be the alias used by the service provider. =20 We should not mix this up with the discussion in SPEERMINT on user = provided AoR such as sip:user@company.com. This will always be an alias in = addition to the AoR used by the provider. =20 Of couse the user may use this AoR in User ENUM. =20 -sta ________________________________ Von: James McEachern [mailto:jmce@nortel.com] Gesendet: Fr 02.06.2006 22:51 An: Creighton, Tom; Lee, Yiu; Stastny Richard; speermint@ietf.org; = enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? Ok, I think I see now. Presumably I can have a SIP URI that clearly = identifies me, but this is not the AOR that would be populated in = Infrastructure ENUM. That AOR would either be based on my E.164 number, = or on some other random string created by the carrier. Have I got it = right? James -----Original Message----- From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Sent: Friday, June 02, 2006 3:49 PM To: McEachern, James [CAR:5N00:EXCH]; Lee, Yiu; Stastny Richard; = speermint@ietf.org; enum@ietf.org Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? I think we have two separate issues: 1. An issue of misunderstanding of the term AoR. Section 6 of RFC3261 defines an Address-of-Record as: "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the "public address" of the user." Based on that definition and the examples provided by Richard, a user's privacy would not be compromised because it doesn't directly reach or identify the customer. 2. There is confusion around what is or is not acceptable in the host portion of a SIP URI. As long as RFC3263 is followed, it shouldn't matter what is placed in the host portion of the SIP URI as long as it doesn't compromise a user's privacy. So in the examples Richard provided earlier, either are acceptable and would resolve in an identical manner. Tom > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Friday, June 02, 2006 15:12 > To: Lee, Yiu; Stastny Richard; Creighton, Tom; speermint@ietf.org; > enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > In the past it has been suggested that if Infrastructure ENUM is openly > accessible, then for data privacy reasons it would not be acceptable to > list the user AOR. Do we still believe this is the case, or do we now > think providing the user AOR would be acceptable? > > James > > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Sent: Thursday, June 01, 2006 2:22 PM > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > Actually, I think it is sufficient for the Enum to return the user AOR > because the routing decision should happen in the provB.net network. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 2:18 PM > To: Lee, Yiu; Creighton, Tom; speermint@ietf.org > Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > Ok, so I am back to my original question: > > if I implement both types of public user identities: > E.164 numbers and SIP AoRs, why doing the mapping to different hosting > proxies in two places (in this case ENUM and the HSS), if I can do it > only in one place? > > -sta > > > > ________________________________ > > Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Gesendet: Do 01.06.2006 20:10 > An: Stastny Richard; Creighton, Tom; speermint@ietf.org > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > > > Yes. IMS is using Option 2. Option 1 is also possible if the operator > decides to use just a redirect proxy. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, June 01, 2006 2:07 PM > To: Creighton, Tom; Lee, Yiu; speermint@ietf.org > Cc: enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > so basically the IMS I-CSCF - HSS - S-CSCF way? > > Richard > > ________________________________ > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Do 01.06.2006 19:45 > An: Lee, Yiu; Stastny Richard; speermint@ietf.org > Cc: enum@ietf.org > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > > > Agreed, in this case the proxy associated with provB.net would be an > intermediate device that would have to perform some sort of internal > lookup in order to route the request to the next hop. > > > -----Original Message----- > > From: Lee, Yiu > > Sent: Thursday, June 01, 2006 13:34 > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > In this case, I guess when the originating proxy resolves the domain > part > > of the AOR (sip:+4319793321@provB.net), it will return the IP address > of > > the root domain "provB.net" which may be a redirect proxy. So > "provB.net" > > has two choices: > > > > (1) It accesses its local routing table and sends a 305 to the > originating > > proxy with "sbc4711.provB.net" in the contact header. > > > > (2) It replaces the domain part in the r-uri to more specific like > > "proxy.austria.provB.net" and forward the message to the next-hop. > > > > Either case, the assumption is provB.net will have a way to find out > where > > the home proxy of user +4319793321. > > > > This is only my guess. > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, June 01, 2006 1:13 PM > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > > > I see, > > > > but how do you solve this problem if the users can also be reached by > AoRs > > direct? > > > > -sta > > > > ________________________________ > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Gesendet: Do 01.06.2006 17:57 > > An: Stastny Richard; speermint@ietf.org > > Cc: enum@ietf.org > > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > > > > > Maybe the service provider has some sort of segregated network > (physically > > or logically) and wants/needs to associate each its subscribers with a > > > particular network segment. If the provider went with the flat model > of > > provB.net, each of its proxies would have to accept requests destined > to > > all of its customers and would then have to route the request to the > > appropriate region or division of its network. > > If the provider went with the hierarchical approach of > sbc4711.provB.net, > > all of the requests would already be routed to the appropriate ingress > > > point. This could very well save a service provider a lot of money in > > > route proxy equipment although might cost more on the provisioning > side. > > > > That is my guess. > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 11:30 > > > To: Creighton, Tom; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > Thank you, Tom > > > > > > just a minor additional question: > > > > > > > In either case, after the provider A proxy performs an ENUM query > > and > > > > rewrites the request URI, it should behave as a UAC and follow the > > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > address, > > > > port, and transport protocol for the provider B UAS. > > > > > > If I have to do this according to RFC3263 anyway, why put the > > > sbc4711.provB.net into ENUM in the first place? > > > > > > -sta > > > > > > > > > > -----Original Message----- > > > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > > Sent: Thursday, June 01, 2006 4:36 PM > > > > To: Stastny Richard; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Thursday, June 01, 2006 09:06 > > > > > To: speermint@ietf.org > > > > > Cc: enum@ietf.org > > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > > > Folks, > > > > > > > > > > Question for clarification: > > > > > > > > > > In the discussions here on how to populate sip URI in > > Infrastructure > > > > > ENUM to derive the Call Routing data for SPEERMINT two lines of > > > > > > thought exist: > > > > > > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1. the > > > > > > address-of-record of the user: e.g. > > sip:+4319793321@provB.net > > > > > 2. the ingress point into the provider network: > > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > > > The originating UAC has in this case set the To: field to > > > > > tel:+4319793321 and the Request-URI to e.g. > > > > > sip:+4319793321provA.net;user=3Dphone. This caused the ENUM query > at > > > > > the proxy of provider A > > > > > > > > > > The question is how the proxy of provider A is now setting up > the > > > > > request URI in cases mentioned above? > > > > > > > > > > Does the UAS from provider B accept calls to sbc7411.provB.net, > or > > > > > must the request URI set to the proper AoR as described in > > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in ENUM. > > > > > > > > [Tom Creighton wrote:] > > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does not > > > > identify an address that the UAS is willing to accept requests > for, > > it > > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > > > As long as the UAS from provider B is "willing" to accept the > > request, > > > > either should work. Since provider B is populating Infrastructure > > > ENUM, > > > > one would hope that they would coordinate this data with the > > > > configuration of their proxies. > > > > > > > > Besides, how do you actually know that sbc4441.provB.net is > actually > > a > > > > hostname and isn't a subdomain? > > > > > > > > In either case, after the provider A proxy performs an ENUM query > > and > > > > rewrites the request URI, it should behave as a UAC and follow the > > > > > procedures outlined in Section 4 of RFC3263 to determine the IP > > > address, > > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in ENUM. > > > > > > > > > > Regards > > > > > > > > > > -sta > > > > > > > > > > > > > > > _______________________________________________ > > > > > enum mailing list > > > > > enum@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ 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 From enum-bounces@ietf.org Fri Jun 02 16:59:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGjn-0005Tt-JM; Fri, 02 Jun 2006 16:59:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGjm-0005TJ-7U; Fri, 02 Jun 2006 16:59:18 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmGjk-0005sb-R6; Fri, 02 Jun 2006 16:59:18 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k52KxZJN030896; Fri, 2 Jun 2006 13:59:35 -0700 From: "Richard Shockey" To: "'Creighton, Tom'" , "'Stastny Richard'" , Subject: RE: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 16:59:09 -0400 Message-ID: <018201c68687$652ea320$40211f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAA1DG0wAArcX1AAAHkt4AACXAnA In-Reply-To: <4884CD6C1DF0A8429DD8DAD942BF9D9670545E@PACDCEXCMB03.cable.comcast.com> X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This discussion is best kept in SPEERMINT. IMHO. s/ your bewildered ENUM WG co-chair > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Friday, June 02, 2006 15:41 > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: Re: [Enum] How to correctly set up the request URI? > > > > Tom, > > > > being in favor of the usage of an AoR in Infrastructure ENUM, I have > no > > problems with your proposed words. There are only two issues: > > > > 1. There will be some people objecting, I assume. > > [Tom Creighton wrote:] > > I welcome any comments or recommendations that anyone has to help move > beyond this discussion. > > > 2. Where should this words go? > > -in the ENUM requirements or in the SPEERMINT requirements? > > [Tom Creighton wrote:] > > My initial reaction would be to keep it in SPEERMINT as this is a > peering architecture issue and not a specific ENUM protocol issue, but > as you said, advice from the 4 chairs would be appreciated. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jun 02 17:13:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGxf-0001eW-RQ; Fri, 02 Jun 2006 17:13:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGxe-0001eE-CP; Fri, 02 Jun 2006 17:13:38 -0400 Received: from peregrine.verisign.com ([216.168.239.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmGxd-00077L-5u; Fri, 02 Jun 2006 17:13:38 -0400 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id k52LPF80030496; Fri, 2 Jun 2006 17:25:15 -0400 Received: from trutkowski-desk.verisign.com ([10.169.64.230]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 17:13:27 -0400 Message-Id: <7.0.1.0.2.20060602165728.033db628@verisign.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 02 Jun 2006 17:13:33 -0400 To: "Pfautz, Penn L, GBLAM" , "James McEachern" , , From: Tony Rutkowski Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0CEFF8CE@ACCLUST02EVS1.ugd .att.com> References: <34DA635B184A644DA4588E260EC0A25A0CEFF8CE@ACCLUST02EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 02 Jun 2006 21:13:27.0626 (UTC) FILETIME=[6431BAA0:01C68689] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Penn, >I see no privacy issue with a carrier URI like the one you show below as >long as it points to a carrier network element rather than directly to >say, the user's terminal adapter. If the pointer is direct to CPE I'd >have some concerns, which is not to say a provider can be forbidden >(except by regulators) to do so. The concerns primarily relate to network integrity as well as support of law enforcement (CALEA/LI requirements) in determining authoritative bindings of user/provider information to identifiers. In Europe and many countries, this binding information is also subject to data retention directives. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jun 02 17:33:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmHGT-0005u9-OS; Fri, 02 Jun 2006 17:33:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmHGS-0005tn-GP; Fri, 02 Jun 2006 17:33:04 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmHGR-0000H8-2I; Fri, 02 Jun 2006 17:33:04 -0400 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: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 23:37:09 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AAB@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaGigRqepu1NVO+QBGwtTETRZuWxgAAalQs From: "Stastny Richard" To: "Tony Rutkowski" , "Pfautz, Penn L, GBLAM" , "James McEachern" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Tony, =20 I do not fully understand what the CALEA issue has to do with the = question which URI is put in ENUM. This may be a signalling requirement in SPEERMINT =20 I have complete different concerns regarding CALEA, in principle I do=20 not understand why the service providers are bothered with this at all, because the NSA is getting all data from Penn anyway ;-) =20 http://news.com.com/AT38T+leaks+sensitive+info+in+NSA+suit/2100-1028_3-60= 77353.html?tag=3Dnefd.lede =20 http://www.wired.com/news/technology/0,70944-0.html =20 -sta ________________________________ Von: Tony Rutkowski [mailto:trutkowski@verisign.com] Gesendet: Fr 02.06.2006 23:13 An: Pfautz, Penn L, GBLAM; James McEachern; speermint@ietf.org; = enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? Hi Penn, >I see no privacy issue with a carrier URI like the one you show below = as >long as it points to a carrier network element rather than directly to >say, the user's terminal adapter. If the pointer is direct to CPE I'd >have some concerns, which is not to say a provider can be forbidden >(except by regulators) to do so. The concerns primarily relate to network integrity as well as support of law enforcement (CALEA/LI requirements) in determining authoritative bindings of user/provider information to identifiers. In Europe and many countries, this binding information is also subject to data retention directives. --tony _______________________________________________ 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 From enum-bounces@ietf.org Fri Jun 02 17:49:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmHWK-0007l0-5L; Fri, 02 Jun 2006 17:49:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmHWI-0007fW-GH; Fri, 02 Jun 2006 17:49:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmGzR-0007Ap-Ih; Fri, 02 Jun 2006 17:15:29 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FmGor-00040o-Ep; Fri, 02 Jun 2006 17:04:34 -0400 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: [Enum] How to correctly set up the request URI? Date: Fri, 2 Jun 2006 23:05:53 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AAA@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAA1DG0wAArcX1AAAHkt4AACXAnAAABOEK8= From: "Stastny Richard" To: , "Creighton, Tom" , X-Spam-Score: -2.5 (--) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is also my preference, but it is basically what SPEERMINT expects to be the CRD output from Infrastructure ENUM (so it could also be a BCP what to put into Infrastucture ENUM ;-) =20 -sta ________________________________ Von: Richard Shockey [mailto:richard@shockey.us] Gesendet: Fr 02.06.2006 22:59 An: 'Creighton, Tom'; Stastny Richard; speermint@ietf.org Cc: enum@ietf.org Betreff: RE: [Enum] How to correctly set up the request URI? This discussion is best kept in SPEERMINT. IMHO. s/ your bewildered ENUM WG co-chair > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Friday, June 02, 2006 15:41 > > To: Creighton, Tom; speermint@ietf.org > > Cc: enum@ietf.org > > Subject: Re: [Enum] How to correctly set up the request URI? > > > > Tom, > > > > being in favor of the usage of an AoR in Infrastructure ENUM, I have > no > > problems with your proposed words. There are only two issues: > > > > 1. There will be some people objecting, I assume. > > [Tom Creighton wrote:] > > I welcome any comments or recommendations that anyone has to help move > beyond this discussion. > > > 2. Where should this words go? > > -in the ENUM requirements or in the SPEERMINT requirements? > > [Tom Creighton wrote:] > > My initial reaction would be to keep it in SPEERMINT as this is a > peering architecture issue and not a specific ENUM protocol issue, but > as you said, advice from the 4 chairs would be appreciated. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Jun 02 18:05:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmHmA-0000Dn-Cw; Fri, 02 Jun 2006 18:05:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmHm9-0000Df-2K; Fri, 02 Jun 2006 18:05:49 -0400 Received: from peregrine.verisign.com ([216.168.239.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmHm7-0002Sa-Sa; Fri, 02 Jun 2006 18:05:49 -0400 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id k52MHRjr032722; Fri, 2 Jun 2006 18:17:27 -0400 Received: from trutkowski-desk.verisign.com ([10.169.64.230]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 18:05:38 -0400 Message-Id: <7.0.1.0.2.20060602175232.033dc4e0@verisign.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 02 Jun 2006 18:05:44 -0400 To: "Stastny Richard" , "Pfautz, Penn L, GBLAM" , "James McEachern" , , From: Tony Rutkowski Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI? In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4AAB@oefeg-s04.oefeg.loc > References: <32755D354E6B65498C3BD9FD496C7D462C4AAB@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 02 Jun 2006 22:05:38.0760 (UTC) FILETIME=[AE7EDC80:01C68690] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Richard, >I do not fully understand what the CALEA issue has to do with the >question which >URI is put in ENUM. ENUM is little more than a more flexible routing table - a more dynamic LERG. Stable public infrastructures - for network integrity, law enforcement support, and a host of other requirements - require some ability to authenticate changes and maintain authoritative bindings to provider/user information. Austrian police cannot do lawful interceptions if they can't trust the E.164 to URI bindings and do queries to get authoritative information about providers and users. >I have complete different concerns regarding CALEA, in principle I do >not understand why the service providers are bothered with this at all, European authorities will be much better supported under the EU Data Retention Directive - which will require capturing and timestamping every signalling query. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Jun 03 09:11:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmVux-0000gt-5a; Sat, 03 Jun 2006 09:11:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmVuv-0000gl-Fc; Sat, 03 Jun 2006 09:11:49 -0400 Received: from omzesmtp02.mci.com ([199.249.17.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmVur-0000Ab-8M; Sat, 03 Jun 2006 09:11:49 -0400 Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0J0A00H4XCNKKZ@firewall.mci.com>; Sat, 03 Jun 2006 13:11:44 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([127.0.0.1]) by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0J0A00JECCNKSR@pmismtp04.mcilink.com>; Sat, 03 Jun 2006 13:11:44 +0000 (GMT) Received: from XS107V7775199 ([131.146.26.60]) by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0J0A00I6PCN56D@pmismtp04.mcilink.com>; Sat, 03 Jun 2006 13:11:44 +0000 (GMT) Date: Sat, 03 Jun 2006 08:11:24 -0500 From: Tim Dwight Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? In-reply-to: <4884CD6C1DF0A8429DD8DAD942BF9D967054B5@PACDCEXCMB03.cable.comcast.com> To: "'Creighton, Tom'" , 'James McEachern' , "'Lee, Yiu'" , 'Stastny Richard' , speermint@ietf.org, enum@ietf.org Message-id: <001c01c6870f$3e70b1f0$3c1a9283@mcilink.com> Organization: MCI MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVAAAA6/FAAIbZ38A== X-Spam-Score: 0.1 (/) X-Scan-Signature: 3643ee1fccf5d6cf2af25f27d28abb29 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: timothy.dwight@verizon.com List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org What good does this globally-visible public-user-ID to private-user-ID visible only within the serving network scheme do, if the means of translating globally-visible public user ID to private user ID is publicly accessible (public DNS)? Or, are we assuming that it's not publicly accessible, e.g., that the serving network has a split DNS and these "final translations" are only visible within that network? tim > -----Original Message----- > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Sent: Friday, June 02, 2006 3:58 PM > To: James McEachern; Lee, Yiu; Stastny Richard; > speermint@ietf.org; enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up > the request URI? > > That is correct. The SIP URI that clearly identifies you, as > you described, would only be used within your provider's network. > > > -----Original Message----- > > From: James McEachern [mailto:jmce@nortel.com] > > Sent: Friday, June 02, 2006 16:52 > > To: Creighton, Tom; Lee, Yiu; Stastny Richard; speermint@ietf.org; > > enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > Ok, I think I see now. Presumably I can have a SIP URI > that clearly > > identifies me, but this is not the AOR that would be populated in > > Infrastructure ENUM. That AOR would either be based on my E.164 > number, > > or on some other random string created by the carrier. > Have I got it > > right? > > > > James > > > > -----Original Message----- > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Sent: Friday, June 02, 2006 3:49 PM > > To: McEachern, James [CAR:5N00:EXCH]; Lee, Yiu; Stastny Richard; > > speermint@ietf.org; enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > I think we have two separate issues: > > > > 1. An issue of misunderstanding of the term AoR. Section 6 > of RFC3261 > > defines an Address-of-Record as: > > > > "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI > > that points to a domain with a location service > that can map > > the URI to another URI where the user might be available. > > Typically, the location service is populated through > > registrations. An AOR is frequently thought of as the > "public > > address" of the user." > > > > Based on that definition and the examples provided by Richard, a > user's > > privacy would not be compromised because it doesn't > directly reach or > > identify the customer. > > > > 2. There is confusion around what is or is not acceptable > in the host > > portion of a SIP URI. As long as RFC3263 is followed, it shouldn't > > matter what is placed in the host portion of the SIP URI as > long as it > > doesn't compromise a user's privacy. So in the examples Richard > > provided earlier, either are acceptable and would resolve in an > > identical manner. > > > > Tom > > > > > -----Original Message----- > > > From: James McEachern [mailto:jmce@nortel.com] > > > Sent: Friday, June 02, 2006 15:12 > > > To: Lee, Yiu; Stastny Richard; Creighton, Tom; > speermint@ietf.org; > > > enum@ietf.org > > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > In the past it has been suggested that if Infrastructure ENUM is > > openly > > > accessible, then for data privacy reasons it would not be > acceptable > > to > > > list the user AOR. Do we still believe this is the case, or do we > now > > > think providing the user AOR would be acceptable? > > > > > > James > > > > > > -----Original Message----- > > > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > > > Sent: Thursday, June 01, 2006 2:22 PM > > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > Actually, I think it is sufficient for the Enum to return the user > AOR > > > because the routing decision should happen in the > provB.net network. > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 2:18 PM > > > To: Lee, Yiu; Creighton, Tom; speermint@ietf.org > > > Subject: Re: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > Ok, so I am back to my original question: > > > > > > if I implement both types of public user identities: > > > E.164 numbers and SIP AoRs, why doing the mapping to different > hosting > > > proxies in two places (in this case ENUM and the HSS), if I can do > it > > > only in one place? > > > > > > -sta > > > > > > > > > > > > ________________________________ > > > > > > Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > > > Gesendet: Do 01.06.2006 20:10 > > > An: Stastny Richard; Creighton, Tom; speermint@ietf.org > > > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > > > > > > > Yes. IMS is using Option 2. Option 1 is also possible if the > operator > > > decides to use just a redirect proxy. > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 2:07 PM > > > To: Creighton, Tom; Lee, Yiu; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > so basically the IMS I-CSCF - HSS - S-CSCF way? > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Gesendet: Do 01.06.2006 19:45 > > > An: Lee, Yiu; Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > > > > > > > Agreed, in this case the proxy associated with provB.net > would be an > > > intermediate device that would have to perform some sort > of internal > > > lookup in order to route the request to the next hop. > > > > > > > -----Original Message----- > > > > From: Lee, Yiu > > > > Sent: Thursday, June 01, 2006 13:34 > > > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > > > request > > > > URI? > > > > > > > > In this case, I guess when the originating proxy resolves the > domain > > > part > > > > of the AOR (sip:+4319793321@provB.net), it will return the IP > > address > > > of > > > > the root domain "provB.net" which may be a redirect proxy. So > > > "provB.net" > > > > has two choices: > > > > > > > > (1) It accesses its local routing table and sends a 305 to the > > > originating > > > > proxy with "sbc4711.provB.net" in the contact header. > > > > > > > > (2) It replaces the domain part in the r-uri to more > specific like > > > > "proxy.austria.provB.net" and forward the message to > the next-hop. > > > > > > > > Either case, the assumption is provB.net will have a way to find > out > > > where > > > > the home proxy of user +4319793321. > > > > > > > > This is only my guess. > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 1:13 PM > > > > To: Creighton, Tom; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: [Speermint] Re: [Enum] How to correctly set up the > request > > > URI? > > > > > > > > I see, > > > > > > > > but how do you solve this problem if the users can also > be reached > > by > > > AoRs > > > > direct? > > > > > > > > -sta > > > > > > > > ________________________________ > > > > > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > > Gesendet: Do 01.06.2006 17:57 > > > > An: Stastny Richard; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > > > Maybe the service provider has some sort of segregated network > > > (physically > > > > or logically) and wants/needs to associate each its subscribers > with > > a > > > > > > > particular network segment. If the provider went with the flat > > model > > > of > > > > provB.net, each of its proxies would have to accept requests > > destined > > > to > > > > all of its customers and would then have to route the request to > the > > > > appropriate region or division of its network. > > > > If the provider went with the hierarchical approach of > > > sbc4711.provB.net, > > > > all of the requests would already be routed to the appropriate > > ingress > > > > > > > point. This could very well save a service provider a lot of > money > > in > > > > > > > route proxy equipment although might cost more on the > provisioning > > > side. > > > > > > > > That is my guess. > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Thursday, June 01, 2006 11:30 > > > > > To: Creighton, Tom; speermint@ietf.org > > > > > Cc: enum@ietf.org > > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > Thank you, Tom > > > > > > > > > > just a minor additional question: > > > > > > > > > > > In either case, after the provider A proxy performs an ENUM > > query > > > > and > > > > > > rewrites the request URI, it should behave as a UAC > and follow > > the > > > > > > > > > procedures outlined in Section 4 of RFC3263 to determine the > IP > > > > > address, > > > > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > If I have to do this according to RFC3263 anyway, why put the > > > > > sbc4711.provB.net into ENUM in the first place? > > > > > > > > > > -sta > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Creighton, Tom > [mailto:Tom_Creighton@cable.comcast.com] > > > > > > Sent: Thursday, June 01, 2006 4:36 PM > > > > > > To: Stastny Richard; speermint@ietf.org > > > > > > Cc: enum@ietf.org > > > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > > > Sent: Thursday, June 01, 2006 09:06 > > > > > > > To: speermint@ietf.org > > > > > > > Cc: enum@ietf.org > > > > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > Folks, > > > > > > > > > > > > > > Question for clarification: > > > > > > > > > > > > > > In the discussions here on how to populate sip URI in > > > > Infrastructure > > > > > > > ENUM to derive the Call Routing data for SPEERMINT two > lines > > of > > > > > > > > > > thought exist: > > > > > > > > > > > > > > The Enumservice SIP in Infrastructure ENUM should > contain 1. > > the > > > > > > > > > > address-of-record of the user: e.g. > > > > sip:+4319793321@provB.net > > > > > > > 2. the ingress point into the provider network: > > > > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > > > > > > > The originating UAC has in this case set the To: field to > > > > > > > tel:+4319793321 and the Request-URI to e.g. > > > > > > > sip:+4319793321provA.net;user=phone. This caused the ENUM > > query > > > at > > > > > > > the proxy of provider A > > > > > > > > > > > > > > The question is how the proxy of provider A is now setting > up > > > the > > > > > > > request URI in cases mentioned above? > > > > > > > > > > > > > > Does the UAS from provider B accept calls to > > sbc7411.provB.net, > > > or > > > > > > > must the request URI set to the proper AoR as described in > > > > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in > > ENUM. > > > > > > > > > > > > [Tom Creighton wrote:] > > > > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does > not > > > > > > identify an address that the UAS is willing to > accept requests > > > for, > > > > it > > > > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > > > > > > > As long as the UAS from provider B is "willing" to > accept the > > > > request, > > > > > > either should work. Since provider B is populating > > Infrastructure > > > > > ENUM, > > > > > > one would hope that they would coordinate this data > with the > > > > > > configuration of their proxies. > > > > > > > > > > > > Besides, how do you actually know that sbc4441.provB.net is > > > actually > > > > a > > > > > > hostname and isn't a subdomain? > > > > > > > > > > > > In either case, after the provider A proxy performs an ENUM > > query > > > > and > > > > > > rewrites the request URI, it should behave as a UAC > and follow > > the > > > > > > > > > procedures outlined in Section 4 of RFC3263 to determine the > IP > > > > > address, > > > > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in > ENUM. > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > -sta > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > enum mailing list > > > > > > > enum@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > > 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 > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Jun 03 10:17:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmWvr-00061q-Mq; Sat, 03 Jun 2006 10:16:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmWvp-0005zz-Ov; Sat, 03 Jun 2006 10:16:49 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmWvo-0006cn-FK; Sat, 03 Jun 2006 10:16:49 -0400 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: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Sat, 3 Jun 2006 16:20:54 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AAC@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVAAAA6/FAAIbZ38AAB+7kx From: "Stastny Richard" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 5df1f98f3253c63b673ea560243aa58f Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I think this discussion is getting a bit confused in terminology My I try to get this back in track from my knowledge: =20 The terms Public User ID and Private User ID are from 3GPP = specifications A Public User ID is defined as an ID somebody may put on his business = card: Examples are: a) tel:+4319793321 (a E.164 number) b) sip:+4319793321@provider.com (an E.164 number and an = address-of-record) c) sip:richard.stastny@provider.com (also an AoR) d) sip:richard@stastny.com =20 All of these could be aliases linked to one Private User Identity The private user identity is defined in 3GPP as a realm, used for = registration e.g. in the format richard.stastny @ provider.com To be compatible with existing 2G systems, it could also be derived from the IMSI with a predefined algorithm. Private User Identities are our of scope in Speermint (I think) a) cannot be user fro routing between SIP based networks, so it must be = translated to a SIP AoR. This can be done with ENUM. As we also stated here, not to = disclose and privacy, it should be in format b) This mapping is publicly visible in Infrastructure ENUM But this does not preclude me to put sip:richard.stastny@provider.com or sip:richard@stastny.com on my business card, so it will be used outside the providers network. The routing of sip:richard.stastny@provider.com is straightforward, for the mapping of the stastny.com part sip:richard@stastny.com to provider.com an entry (e.g. a NAPTR as Otmar described) is necessary in the stastny.com domain to get the call proverly routed to my network. The mapping of the user part "richard" to "richard.stastny" or +4319793321 takes place in the providers network and is not visible outside I hope this helps to clarify -sta ________________________________ Von: Tim Dwight [mailto:timothy.dwight@verizon.com] Gesendet: Sa 03.06.2006 15:11 An: 'Creighton, Tom'; 'James McEachern'; 'Lee, Yiu'; Stastny Richard; = speermint@ietf.org; enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? What good does this globally-visible public-user-ID to private-user-ID visible only within the serving network scheme do, if the means of translating globally-visible public user ID to private user ID is = publicly accessible (public DNS)? Or, are we assuming that it's not publicly accessible, e.g., that the serving network has a split DNS and these = "final translations" are only visible within that network? tim > -----Original Message----- > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Sent: Friday, June 02, 2006 3:58 PM > To: James McEachern; Lee, Yiu; Stastny Richard; > speermint@ietf.org; enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up > the request URI? > > That is correct. The SIP URI that clearly identifies you, as > you described, would only be used within your provider's network. > > > -----Original Message----- > > From: James McEachern [mailto:jmce@nortel.com] > > Sent: Friday, June 02, 2006 16:52 > > To: Creighton, Tom; Lee, Yiu; Stastny Richard; speermint@ietf.org; > > enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > Ok, I think I see now. Presumably I can have a SIP URI > that clearly > > identifies me, but this is not the AOR that would be populated in > > Infrastructure ENUM. That AOR would either be based on my E.164 > number, > > or on some other random string created by the carrier.=20 > Have I got it > > right? > > > > James > > > > -----Original Message----- > > From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > Sent: Friday, June 02, 2006 3:49 PM > > To: McEachern, James [CAR:5N00:EXCH]; Lee, Yiu; Stastny Richard; > > speermint@ietf.org; enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request > > URI? > > > > I think we have two separate issues: > > > > 1. An issue of misunderstanding of the term AoR. Section 6 > of RFC3261 > > defines an Address-of-Record as: > > > > "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI > > that points to a domain with a location service > that can map > > the URI to another URI where the user might be available. > > Typically, the location service is populated through > > registrations. An AOR is frequently thought of as the > "public > > address" of the user." > > > > Based on that definition and the examples provided by Richard, a > user's > > privacy would not be compromised because it doesn't > directly reach or > > identify the customer. > > > > 2. There is confusion around what is or is not acceptable > in the host > > portion of a SIP URI. As long as RFC3263 is followed, it shouldn't > > matter what is placed in the host portion of the SIP URI as > long as it > > doesn't compromise a user's privacy. So in the examples Richard > > provided earlier, either are acceptable and would resolve in an > > identical manner. > > > > Tom > > > > > -----Original Message----- > > > From: James McEachern [mailto:jmce@nortel.com] > > > Sent: Friday, June 02, 2006 15:12 > > > To: Lee, Yiu; Stastny Richard; Creighton, Tom; > speermint@ietf.org; > > > enum@ietf.org > > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > In the past it has been suggested that if Infrastructure ENUM is > > openly > > > accessible, then for data privacy reasons it would not be > acceptable > > to > > > list the user AOR. Do we still believe this is the case, or do we > now > > > think providing the user AOR would be acceptable? > > > > > > James > > > > > > -----Original Message----- > > > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > > > Sent: Thursday, June 01, 2006 2:22 PM > > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > Actually, I think it is sufficient for the Enum to return the user > AOR > > > because the routing decision should happen in the > provB.net network. > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 2:18 PM > > > To: Lee, Yiu; Creighton, Tom; speermint@ietf.org > > > Subject: Re: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > Ok, so I am back to my original question: > > > > > > if I implement both types of public user identities: > > > E.164 numbers and SIP AoRs, why doing the mapping to different > hosting > > > proxies in two places (in this case ENUM and the HSS), if I can do > it > > > only in one place? > > > > > > -sta > > > > > > > > > > > > ________________________________ > > > > > > Von: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > > > Gesendet: Do 01.06.2006 20:10 > > > An: Stastny Richard; Creighton, Tom; speermint@ietf.org > > > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > > > > > > > Yes. IMS is using Option 2. Option 1 is also possible if the > operator > > > decides to use just a redirect proxy. > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, June 01, 2006 2:07 PM > > > To: Creighton, Tom; Lee, Yiu; speermint@ietf.org > > > Cc: enum@ietf.org > > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > so basically the IMS I-CSCF - HSS - S-CSCF way? > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > Gesendet: Do 01.06.2006 19:45 > > > An: Lee, Yiu; Stastny Richard; speermint@ietf.org > > > Cc: enum@ietf.org > > > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the > > request > > > URI? > > > > > > > > > > > > Agreed, in this case the proxy associated with provB.net > would be an > > > intermediate device that would have to perform some sort > of internal > > > lookup in order to route the request to the next hop. > > > > > > > -----Original Message----- > > > > From: Lee, Yiu > > > > Sent: Thursday, June 01, 2006 13:34 > > > > To: Stastny Richard; Creighton, Tom; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > > > request > > > > URI? > > > > > > > > In this case, I guess when the originating proxy resolves the > domain > > > part > > > > of the AOR (sip:+4319793321@provB.net), it will return the IP > > address > > > of > > > > the root domain "provB.net" which may be a redirect proxy. So > > > "provB.net" > > > > has two choices: > > > > > > > > (1) It accesses its local routing table and sends a 305 to the > > > originating > > > > proxy with "sbc4711.provB.net" in the contact header. > > > > > > > > (2) It replaces the domain part in the r-uri to more > specific like > > > > "proxy.austria.provB.net" and forward the message to > the next-hop. > > > > > > > > Either case, the assumption is provB.net will have a way to find > out > > > where > > > > the home proxy of user +4319793321. > > > > > > > > This is only my guess. > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, June 01, 2006 1:13 PM > > > > To: Creighton, Tom; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Subject: [Speermint] Re: [Enum] How to correctly set up the > request > > > URI? > > > > > > > > I see, > > > > > > > > but how do you solve this problem if the users can also > be reached > > by > > > AoRs > > > > direct? > > > > > > > > -sta > > > > > > > > ________________________________ > > > > > > > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > > > > Gesendet: Do 01.06.2006 17:57 > > > > An: Stastny Richard; speermint@ietf.org > > > > Cc: enum@ietf.org > > > > Betreff: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > > > Maybe the service provider has some sort of segregated network > > > (physically > > > > or logically) and wants/needs to associate each its subscribers > with > > a > > > > > > > particular network segment. If the provider went with the flat > > model > > > of > > > > provB.net, each of its proxies would have to accept requests > > destined > > > to > > > > all of its customers and would then have to route the request to > the > > > > appropriate region or division of its network. > > > > If the provider went with the hierarchical approach of > > > sbc4711.provB.net, > > > > all of the requests would already be routed to the appropriate > > ingress > > > > > > > point. This could very well save a service provider a lot of > money > > in > > > > > > > route proxy equipment although might cost more on the > provisioning > > > side. > > > > > > > > That is my guess. > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Thursday, June 01, 2006 11:30 > > > > > To: Creighton, Tom; speermint@ietf.org > > > > > Cc: enum@ietf.org > > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > Thank you, Tom > > > > > > > > > > just a minor additional question: > > > > > > > > > > > In either case, after the provider A proxy performs an ENUM > > query > > > > and > > > > > > rewrites the request URI, it should behave as a UAC > and follow > > the > > > > > > > > > procedures outlined in Section 4 of RFC3263 to determine the > IP > > > > > address, > > > > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > If I have to do this according to RFC3263 anyway, why put the > > > > > sbc4711.provB.net into ENUM in the first place? > > > > > > > > > > -sta > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Creighton, Tom > [mailto:Tom_Creighton@cable.comcast.com] > > > > > > Sent: Thursday, June 01, 2006 4:36 PM > > > > > > To: Stastny Richard; speermint@ietf.org > > > > > > Cc: enum@ietf.org > > > > > > Subject: RE: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > > > Sent: Thursday, June 01, 2006 09:06 > > > > > > > To: speermint@ietf.org > > > > > > > Cc: enum@ietf.org > > > > > > > Subject: [Enum] How to correctly set up the request URI? > > > > > > > > > > > > > > Folks, > > > > > > > > > > > > > > Question for clarification: > > > > > > > > > > > > > > In the discussions here on how to populate sip URI in > > > > Infrastructure > > > > > > > ENUM to derive the Call Routing data for SPEERMINT two > lines > > of > > > > > > > > > > thought exist: > > > > > > > > > > > > > > The Enumservice SIP in Infrastructure ENUM should > contain 1. > > the > > > > > > > > > > address-of-record of the user: e.g. > > > > sip:+4319793321@provB.net > > > > > > > 2. the ingress point into the provider network: > > > > > > > e.g. sip:+4319793321@sbc4711.provB.net > > > > > > > > > > > > > > The originating UAC has in this case set the To: field to > > > > > > > tel:+4319793321 and the Request-URI to e.g. > > > > > > > sip:+4319793321provA.net;user=3Dphone. This caused the = ENUM > > query > > > at > > > > > > > the proxy of provider A > > > > > > > > > > > > > > The question is how the proxy of provider A is now setting > up > > > the > > > > > > > request URI in cases mentioned above? > > > > > > > > > > > > > > Does the UAS from provider B accept calls to > > sbc7411.provB.net, > > > or > > > > > > > must the request URI set to the proper AoR as described in > > > > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in > > ENUM. > > > > > > > > > > > > [Tom Creighton wrote:] > > > > > > From section 8.2.2.1 of RFC3261: "If the Request-URI does > not > > > > > > identify an address that the UAS is willing to > accept requests > > > for, > > > > it > > > > > > SHOULD reject the request with a 404 (Not Found) response." > > > > > > > > > > > > As long as the UAS from provider B is "willing" to > accept the > > > > request, > > > > > > either should work. Since provider B is populating > > Infrastructure > > > > > ENUM, > > > > > > one would hope that they would coordinate this data > with the > > > > > > configuration of their proxies. > > > > > > > > > > > > Besides, how do you actually know that sbc4441.provB.net is > > > actually > > > > a > > > > > > hostname and isn't a subdomain? > > > > > > > > > > > > In either case, after the provider A proxy performs an ENUM > > query > > > > and > > > > > > rewrites the request URI, it should behave as a UAC > and follow > > the > > > > > > > > > procedures outlined in Section 4 of RFC3263 to determine the > IP > > > > > address, > > > > > > port, and transport protocol for the provider B UAS. > > > > > > > > > > > > > > > > > > > > I would also like to draw the attention to section 3 of > > > > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in > ENUM. > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > -sta > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > enum mailing list > > > > > > > enum@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > > 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 > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Jun 03 10:42:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmXKn-0005sA-1t; Sat, 03 Jun 2006 10:42:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmXKl-0005rx-7W; Sat, 03 Jun 2006 10:42:35 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmXKj-0008Sa-Qi; Sat, 03 Jun 2006 10:42:35 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k53Eguib004110; Sat, 3 Jun 2006 07:42:56 -0700 From: "Richard Shockey" To: "'Tony Rutkowski'" , "'Stastny Richard'" , "'Pfautz, Penn L, GBLAM'" , "'James McEachern'" , , Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Sat, 3 Jun 2006 10:42:25 -0400 Message-ID: <011001c6871b$ef013ba0$23f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <7.0.1.0.2.20060602175232.033dc4e0@verisign.com> Thread-Index: AcaGkMhEXSK7WvlTRXSIW8VVxl/TawAigIiA X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Well Tony we continue to agree on some things after all .. You point is well taken. ENUM IS more than a flexible routing table. Its value is in the ability to authenticate and maintain authoritative bindings for E164 to URI bindings. How those bindings are used may or may not involve the use of DNS technology. Consequently the critical issue is the TRUST created by and maintained by the authoritative Registry of those bindings and that Registry MAY and in all likelihood MUST maintain some mechanism for the maintenance of information about providers and users. Which is why we did the work on IRIS in the ENUM WG. BTW Which EU directive you mention IYHO will require the maintenance of a pin trap of ENUM queries? > -----Original Message----- > From: Tony Rutkowski [mailto:trutkowski@verisign.com] > Sent: Friday, June 02, 2006 6:06 PM > To: Stastny Richard; Pfautz, Penn L, GBLAM; James McEachern; > speermint@ietf.org; enum@ietf.org > Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > Hi Richard, > > >I do not fully understand what the CALEA issue has to do with the > >question which > >URI is put in ENUM. > > ENUM is little more than a more flexible routing table > - a more dynamic LERG. Stable public infrastructures > - for network integrity, law enforcement support, and > a host of other requirements - require some ability > to authenticate changes and maintain authoritative > bindings to provider/user information. Austrian > police cannot do lawful interceptions if they can't > trust the E.164 to URI bindings and do queries to > get authoritative information about providers and > users. > > >I have complete different concerns regarding CALEA, in principle I do > >not understand why the service providers are bothered with this at all, > > European authorities will be much better supported > under the EU Data Retention Directive - which will > require capturing and timestamping every signalling > query. > > --tony > > > _______________________________________________ > 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 From enum-bounces@ietf.org Sat Jun 03 10:48:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmXPy-0006ty-6N; Sat, 03 Jun 2006 10:47:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmXPx-0006tf-0a; Sat, 03 Jun 2006 10:47:57 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmXPv-0000Da-Jn; Sat, 03 Jun 2006 10:47:56 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k53EmA45004889; Sat, 3 Jun 2006 07:48:11 -0700 From: "Richard Shockey" To: "'Pfautz, Penn L, GBLAM'" , "'James McEachern'" , "'Creighton, Tom'" , "'Lee, Yiu'" , "'Stastny Richard'" , , Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Sat, 3 Jun 2006 10:47:39 -0400 Message-ID: <011201c6871c$ab36fee0$23f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0CEFF8DE@ACCLUST02EVS1.ugd.att.com> Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVAAABBo3AAJXTKwA== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] > Sent: Friday, June 02, 2006 4:56 PM > To: James McEachern; Creighton, Tom; Lee, Yiu; Stastny Richard; > speermint@ietf.org; enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > Yes. Again, there might be exceptions, for example a business might want > a URI with their name to be used and some SPs might agree to that, but > generally the point of infrastructure ENUM is to be invisible to the > user > Now the 64B question is the "infrastructure" URI invisible to the global DNS? > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Jun 03 13:38:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fma54-00011l-Kq; Sat, 03 Jun 2006 13:38:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fma52-0000xD-A3 for enum@ietf.org; Sat, 03 Jun 2006 13:38:32 -0400 Received: from lb01nat06.inode.at ([62.99.145.6] helo=smartmx-06.inode.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmZqN-0007mb-0T for enum@ietf.org; Sat, 03 Jun 2006 13:23:26 -0400 Received: from [62.99.233.53] (port=4016 helo=mah92.inode.at) by smartmx-06.inode.at with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FmZqM-0006QA-1k; Sat, 03 Jun 2006 19:23:22 +0200 Message-Id: <7.0.1.0.2.20060603191204.01ffa208@inode.at> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 03 Jun 2006 19:23:15 +0200 To: Tony Rutkowski , "Stastny Richard" , "Pfautz, Penn L, GBLAM" , "James McEachern" , From: Michael Haberler Subject: Re: [Enum] How to correctly set up the request URI? In-Reply-To: <7.0.1.0.2.20060602175232.033dc4e0@verisign.com> References: <32755D354E6B65498C3BD9FD496C7D462C4AAB@oefeg-s04.oefeg.loc> <7.0.1.0.2.20060602175232.033dc4e0@verisign.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org At 00:05 03.06.2006, Tony Rutkowski wrote: >>I have complete different concerns regarding CALEA, in principle I do >>not understand why the service providers are bothered with this at all, > >European authorities will be much better supported >under the EU Data Retention Directive - which will >require capturing and timestamping every signalling >query. Tony - 1) you seem to assume that just because the data may be in a public tree it will be queried for call resolution my guess is the public tree will be a reference-of-last resort - most folks will query an internal copy - transferred by IXFR, AXFR, some kind of push - whatever I cant see how this is any different to some internal resolution mechanism today? 2) the Data Retention Directive is interpreted quite widely at times, but the signaling query recording requirement is new to me --- we had the nonsense of recording every (cc)TLD nameserver query pop up in the European discussion before, it seems we have laid it to rest for the time being, just like the the officials asking for national IP address allocation every other year or so - the RIR and TLD folks are getting quite good at curbing that kind of bull -Michael _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Jun 03 14:29:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmary-0003r0-Te; Sat, 03 Jun 2006 14:29:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmarx-0003qv-Fr for enum@ietf.org; Sat, 03 Jun 2006 14:29:05 -0400 Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fmarx-0005jx-6S for enum@ietf.org; Sat, 03 Jun 2006 14:29:05 -0400 Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id k53IVlih022270; Sat, 3 Jun 2006 14:31:48 -0400 Received: from trutkowski-desk.verisign.com ([10.169.64.230]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 3 Jun 2006 14:28:42 -0400 Message-Id: <7.0.1.0.2.20060603135555.033eee90@verisign.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 03 Jun 2006 14:28:47 -0400 To: Michael Haberler , "Stastny Richard" , "Pfautz, Penn L, GBLAM" , "James McEachern" , From: Tony Rutkowski Subject: Re: [Enum] How to correctly set up the request URI? In-Reply-To: <7.0.1.0.2.20060603191204.01ffa208@inode.at> References: <32755D354E6B65498C3BD9FD496C7D462C4AAB@oefeg-s04.oefeg.loc> <7.0.1.0.2.20060602175232.033dc4e0@verisign.com> <7.0.1.0.2.20060603191204.01ffa208@inode.at> Mime-Version: 1.0 X-OriginalArrivalTime: 03 Jun 2006 18:28:42.0123 (UTC) FILETIME=[8A636DB0:01C6873B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1188828483==" Errors-To: enum-bounces@ietf.org --===============1188828483== Content-Type: multipart/alternative; boundary="=====================_146408233==.ALT" --=====================_146408233==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Michael, >2) the Data Retention Directive is interpreted quite widely at >times, but the signaling query recording requirement is new to me Art. 5 requires providers to capture: (a) data necessary to trace and identify the source of a communication: ... (2) concerning Internet access, Internet e-mail and Internet telephony: (i) the user ID(s) allocated; (ii) the user ID and telephone number allocated to any communication entering the public telephone network; (iii) the name and address of the subscriber or registered user to whom an Internet Protocol (IP) address, user ID or telephone number was allocated at the time of the communication; (b) data necessary to trace and identify the destination of a communication: ... (2) concerning Internet e-mail and Internet telephony: (i) the user ID or telephone number of the intended recipient(s) of an Internet telephony call; (ii) the name(s) and address(es) of the subscriber(s) or registered user(s) and user ID of the intended recipient of the communication; (c) data necessary to identify the date, time and duration of a communication: ... (2) concerning Internet access, Internet e-mail and Internet telephony: (i) the date and time of the log-in and log-off of the Internet access service, based on a certain time zone, together with the IP address, whether dynamic or static, allocated by the Internet access service provider to a communication, and the user ID of the subscriber or registered user; (ii) the date and time of the log-in and log-off of the Internet e-mail service or Internet telephony service, based on a certain time zone; (d) data necessary to identify the type of communication: ... (2) concerning Internet e-mail and Internet telephony: the Internet service used; The extent to which signalling queries get captured will be determined by the degree the query information is necessary to comply with these Art. 5 requirements. It's worth noting also in the States that the recently enacted anti-cyberstalking provisions of the VAWA statute defines Internet software a telecommunications device for the purposes of making it a crime to use VoIP to harass someone without sufficiently identifying the calling party. VoIP providers will want to provide authoritative identification mechanisms to meet the requirements. --tony --=====================_146408233==.ALT Content-Type: text/html; charset="us-ascii" Hi Michael,

2) the Data Retention Directive is interpreted quite widely at times, but the signaling query recording requirement is new to me

Art. 5 requires providers to capture:

 (a) data necessary to trace and identify the source
     of a communication:
  ...
  (2) concerning Internet access, Internet e-mail and Internet
      telephony:
       (i) the user ID(s) allocated;
      (ii) the user ID and telephone number allocated to any
           communication entering the public telephone
           network;
     (iii) the name and address of the subscriber or registered
           user to whom an Internet Protocol (IP) address, user
           ID or telephone number was allocated at the time of
           the communication;

 (b) data necessary to trace and identify the destination
     of a communication:
  ...
  (2) concerning Internet e-mail and Internet telephony:
      (i) the user ID or telephone number of the intended
          recipient(s) of an Internet telephony call;
     (ii) the name(s) and address(es) of the subscriber(s)
          or registered user(s) and user ID of the intended
          recipient of the communication;

 (c) data necessary to identify the date, time and duration
     of a communication:
    ...
   (2) concerning Internet access, Internet e-mail and Internet
       telephony:
       (i) the date and time of the log-in and log-off of the
           Internet access service, based on a certain time
           zone, together with the IP address, whether dynamic
           or static, allocated by the Internet access service
           provider to a communication, and the user ID of the
           subscriber or registered user;
      (ii) the date and time of the log-in and log-off of the
           Internet e-mail service or Internet telephony service,
           based on a certain time zone;

 (d) data necessary to identify the type of communication:
     ...
     (2) concerning Internet e-mail and Internet telephony: the
         Internet service used;


The extent to which signalling queries get captured will be
determined by the degree the query information is necessary
to comply with these Art. 5 requirements.

It's worth noting also in the States that the recently enacted
anti-cyberstalking provisions of the VAWA statute defines
Internet software a telecommunications device for the purposes
of making it a crime to use VoIP to harass someone without
sufficiently identifying the calling party.  VoIP providers
will want to provide authoritative identification mechanisms
to meet the requirements.

--tony --=====================_146408233==.ALT-- --===============1188828483== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1188828483==-- From enum-bounces@ietf.org Sun Jun 04 16:04:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmyph-0004Cz-4D; Sun, 04 Jun 2006 16:04:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmypf-0004Co-9s for enum@ietf.org; Sun, 04 Jun 2006 16:04:19 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fmypd-0001XG-TB for enum@ietf.org; Sun, 04 Jun 2006 16:04:19 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k54K4cLi001860 for ; Sun, 4 Jun 2006 13:04:39 -0700 From: "Richard Shockey" To: Date: Sun, 4 Jun 2006 16:03:59 -0400 Message-ID: <000201c68812$04f96580$23f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcaIEgQX+5vQlSNTSoOa1TjjKJlQ/g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [Enum] Tasks before Montreal -Agenda Item Request X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Again I'd like to ask for agenda items for Montreal I have scheduled 2 1/2 hours so I don't think there is a problem here with time. That said there are several non controversial drafts that I think we can accelerate to WGLC ASAP if there is sufficient review and discussion before Montreal. The chairs have identified. http://www.ietf.org/internet-drafts/draft-ietf-enum-vcard-01.txt http://www.ietf.org/internet-drafts/draft-ietf-enum-im-service-00.txt http://www.ietf.org/internet-drafts/draft-ietf-enum-calendar-service-00.txt As being close to ready if the authors will complete any revisions they may have NOW (Alex) and ask the WG Secretary to NIT review their versions in advance. Shortly I will have ready. http://www.ietf.org/internet-drafts/draft-ietf-enum-cnam-02.txt Which will be sufficiently ready IMHO for WGLC as well. Comments are appreciated. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jun 05 11:15:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnGnk-000754-Ri; Mon, 05 Jun 2006 11:15:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnGnj-00074m-Iw; Mon, 05 Jun 2006 11:15:31 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnGni-0000dr-7Y; Mon, 05 Jun 2006 11:15:31 -0400 Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.20825811; Mon, 05 Jun 2006 11:15:15 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 11:15:15 -0400 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: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Mon, 5 Jun 2006 11:15:14 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D9670574F@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVAAABBo3AAJXTKwABkv/xg From: "Creighton, Tom" To: , "Pfautz, Penn L, GBLAM" , "James McEachern" , "Lee, Yiu" , "Stastny Richard" , , X-OriginalArrivalTime: 05 Jun 2006 15:15:15.0436 (UTC) FILETIME=[D9170AC0:01C688B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Who has the authority to make that decision? Is it the ITU, IETF, a combination of the two, or each country that opts to participate in Infrastructure ENUM? I think that is the 64B question. > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Saturday, June 03, 2006 10:48 > To: 'Pfautz, Penn L, GBLAM'; 'James McEachern'; Creighton, Tom; Lee, Yiu; > 'Stastny Richard'; speermint@ietf.org; enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? >=20 >=20 >=20 > > -----Original Message----- > > From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] > > Sent: Friday, June 02, 2006 4:56 PM > > To: James McEachern; Creighton, Tom; Lee, Yiu; Stastny Richard; > > speermint@ietf.org; enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > > URI? > > > > Yes. Again, there might be exceptions, for example a business might want > > a URI with their name to be used and some SPs might agree to that, but > > generally the point of infrastructure ENUM is to be invisible to the > > user > > >=20 >=20 > Now the 64B question is the "infrastructure" URI invisible to the global > DNS? >=20 >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jun 05 11:44:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHG2-00050K-IF; Mon, 05 Jun 2006 11:44:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHG1-0004zr-4h; Mon, 05 Jun 2006 11:44:45 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnHFz-0004q6-M2; Mon, 05 Jun 2006 11:44:45 -0400 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: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Mon, 5 Jun 2006 17:48:50 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AB4@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVAAABBo3AAJXTKwABkv/xgAAHQbNg= From: "Stastny Richard" To: "Creighton, Tom" , , "Pfautz, Penn L, GBLAM" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org >> > Yes. Again, there might be exceptions, for example a business might = want >> > a URI with their name to be used and some SPs might agree to that, = but >> > generally the point of infrastructure ENUM is to be invisible to = the >> > user >> > >> Now the 64B question is the "infrastructure" URI invisible to the = global >> DNS? >Who has the authority to make that decision? Is it the ITU, IETF, a >combination of the two, or each country that opts to participate in >Infrastructure ENUM? I think that is the 64B question ? I am confused Could anybody please explain to me what you are talking about I cannot parse this thread What is the "point of Infrastructure ENUM"? What is an "Infrastructure URI" and why should it be invisible? And what has this to do with an enterprise specific URI? -sta ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Mo 05.06.2006 17:15 An: richard@shockey.us; Pfautz, Penn L, GBLAM; James McEachern; Lee, = Yiu; Stastny Richard; speermint@ietf.org; enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request = URI? Who has the authority to make that decision? Is it the ITU, IETF, a combination of the two, or each country that opts to participate in Infrastructure ENUM? I think that is the 64B question. > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Saturday, June 03, 2006 10:48 > To: 'Pfautz, Penn L, GBLAM'; 'James McEachern'; Creighton, Tom; Lee, Yiu; > 'Stastny Richard'; speermint@ietf.org; enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > > > > -----Original Message----- > > From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] > > Sent: Friday, June 02, 2006 4:56 PM > > To: James McEachern; Creighton, Tom; Lee, Yiu; Stastny Richard; > > speermint@ietf.org; enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > > URI? > > > > Yes. Again, there might be exceptions, for example a business might want > > a URI with their name to be used and some SPs might agree to that, but > > generally the point of infrastructure ENUM is to be invisible to the > > user > > > > > Now the 64B question is the "infrastructure" URI invisible to the global > DNS? > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jun 05 11:57:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHSF-0001Ne-G1; Mon, 05 Jun 2006 11:57:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHSE-0001NR-Am; Mon, 05 Jun 2006 11:57:22 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnHSC-0005hr-WF; Mon, 05 Jun 2006 11:57:22 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-15.tower-121.messagelabs.com!1149522994!6609210!29 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 6114 invoked from network); 5 Jun 2006 15:57:20 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-15.tower-121.messagelabs.com with SMTP; 5 Jun 2006 15:57:20 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 44708FE9001FAB5A; Mon, 5 Jun 2006 11:57:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Mon, 5 Jun 2006 11:57:18 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0CF41506@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4AB4@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVAAABBo3AAJXTKwABkv/xgAAHQbNgAACAcMA== From: "Pfautz, Penn L, GBLAM" To: "Stastny Richard" , "Creighton, Tom" , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org My original statement about invisibility was that the end user doesn't need to specify/know the URI that the SP provides in infrastructure ENUM - or even that infrastructure ENUM even exists at all. The issue seems to have evolved to that of how much of the infrastructure ENUM tree and its products will be openly visible. This is a decision that many parties may have some level of input to. National regulators may well be able to veto public visibility if they so choose. Service providers may wish to control resolution to some degree although making the infrastructure ENUM Tier 1 inaccessible would not seem to be something the IETF would want to do other things being equal. Penn -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Monday, June 05, 2006 11:49 AM To: Creighton, Tom; richard@shockey.us; Pfautz, Penn L, GBLAM; speermint@ietf.org; enum@ietf.org Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI? >> > Yes. Again, there might be exceptions, for example a business might want >> > a URI with their name to be used and some SPs might agree to that, but >> > generally the point of infrastructure ENUM is to be invisible to the >> > user >> > >> Now the 64B question is the "infrastructure" URI invisible to the global >> DNS? >Who has the authority to make that decision? Is it the ITU, IETF, a >combination of the two, or each country that opts to participate in >Infrastructure ENUM? I think that is the 64B question ? I am confused Could anybody please explain to me what you are talking about I cannot parse this thread What is the "point of Infrastructure ENUM"? What is an "Infrastructure URI" and why should it be invisible? And what has this to do with an enterprise specific URI? -sta ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Mo 05.06.2006 17:15 An: richard@shockey.us; Pfautz, Penn L, GBLAM; James McEachern; Lee, Yiu; Stastny Richard; speermint@ietf.org; enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Who has the authority to make that decision? Is it the ITU, IETF, a combination of the two, or each country that opts to participate in Infrastructure ENUM? I think that is the 64B question. > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Saturday, June 03, 2006 10:48 > To: 'Pfautz, Penn L, GBLAM'; 'James McEachern'; Creighton, Tom; Lee, Yiu; > 'Stastny Richard'; speermint@ietf.org; enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > > > > -----Original Message----- > > From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] > > Sent: Friday, June 02, 2006 4:56 PM > > To: James McEachern; Creighton, Tom; Lee, Yiu; Stastny Richard; > > speermint@ietf.org; enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > > URI? > > > > Yes. Again, there might be exceptions, for example a business might want > > a URI with their name to be used and some SPs might agree to that, but > > generally the point of infrastructure ENUM is to be invisible to the > > user > > > > > Now the 64B question is the "infrastructure" URI invisible to the global > DNS? > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jun 05 12:13:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHhe-0001Dn-9p; Mon, 05 Jun 2006 12:13:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHhc-0001D8-4u; Mon, 05 Jun 2006 12:13:16 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnHhb-0007vA-Gd; Mon, 05 Jun 2006 12:13:16 -0400 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: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Mon, 5 Jun 2006 18:17:22 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AB5@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: [Enum] How to correctly set up the request URI? Thread-Index: AcaFfCUKMx50zyJCT9mhJO88vu1YDAACG1OAAALQARAAAEhP4AADaVbyAAAbobAAALkgMAABDqTDAAAGMDAAAFyItgAACowAADOBpmAAASpv0AACxYVAAABBo3AAJXTKwABkv/xgAAHQbNgAACAcMAAAxI86 From: "Stastny Richard" To: "Pfautz, Penn L, GBLAM" , "Creighton, Tom" , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org >My original statement about invisibility was that the end user doesn't >need to specify/know the URI that the SP provides in infrastructure = ENUM >- or even that infrastructure ENUM even exists at all. ok=20 >The issue seems to have evolved to that of how much of the >infrastructure ENUM tree and its products will be openly visible. This >is a decision that many parties may have some level of input to. >National regulators may well be able to veto public visibility if they >so choose.=20 I agree that national regulators may have some saying on what kind of URIs should be placed in Infastructure ENUM (e.g. none that jeopardizes the end-user privacy), but I do not see why the regulators do not want to have the Infrastructure ENUM data not public at all. =20 I already said that a security and privacy section is missing in draft-ietf-enum-infrastructure The Infrastructure ENUM data is basically providing a E.164 to SPID=20 mapping, and part of this is available on every regulators web-site (the block assignment). What is not is the numbers ported out of this blocks and this seems more to be a concern of the providers and not of the regulators. The problem here is that this information hiding is more to other providers and not to the public. But then a non public Infrastructure ENUM does not help either ;-) =20 -sta =20 >Service providers may wish to control resolution to some >degree although making the infrastructure ENUM Tier 1 inaccessible = would >not seem to be something the IETF would want to do other things being >equal. Penn -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Monday, June 05, 2006 11:49 AM To: Creighton, Tom; richard@shockey.us; Pfautz, Penn L, GBLAM; speermint@ietf.org; enum@ietf.org Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI? >> > Yes. Again, there might be exceptions, for example a business might want >> > a URI with their name to be used and some SPs might agree to that, but >> > generally the point of infrastructure ENUM is to be invisible to the >> > user >> > >> Now the 64B question is the "infrastructure" URI invisible to the global >> DNS? >Who has the authority to make that decision? Is it the ITU, IETF, a >combination of the two, or each country that opts to participate in >Infrastructure ENUM? I think that is the 64B question ? I am confused Could anybody please explain to me what you are talking about I cannot parse this thread What is the "point of Infrastructure ENUM"? What is an "Infrastructure URI" and why should it be invisible? And what has this to do with an enterprise specific URI? -sta ________________________________ Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] Gesendet: Mo 05.06.2006 17:15 An: richard@shockey.us; Pfautz, Penn L, GBLAM; James McEachern; Lee, Yiu; Stastny Richard; speermint@ietf.org; enum@ietf.org Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the request URI? Who has the authority to make that decision? Is it the ITU, IETF, a combination of the two, or each country that opts to participate in Infrastructure ENUM? I think that is the 64B question. > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Saturday, June 03, 2006 10:48 > To: 'Pfautz, Penn L, GBLAM'; 'James McEachern'; Creighton, Tom; Lee, Yiu; > 'Stastny Richard'; speermint@ietf.org; enum@ietf.org > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > URI? > > > > > -----Original Message----- > > From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] > > Sent: Friday, June 02, 2006 4:56 PM > > To: James McEachern; Creighton, Tom; Lee, Yiu; Stastny Richard; > > speermint@ietf.org; enum@ietf.org > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request > > URI? > > > > Yes. Again, there might be exceptions, for example a business might want > > a URI with their name to be used and some SPs might agree to that, but > > generally the point of infrastructure ENUM is to be invisible to the > > user > > > > > Now the 64B question is the "infrastructure" URI invisible to the global > DNS? > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jun 05 12:41:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnI8d-0006v4-Ne; Mon, 05 Jun 2006 12:41:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnI8d-0006uz-93 for enum@ietf.org; Mon, 05 Jun 2006 12:41:11 -0400 Received: from norman.insensate.co.uk ([213.152.49.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnI8c-0001TD-I3 for enum@ietf.org; Mon, 05 Jun 2006 12:41:11 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id D786D8AE9B; Mon, 5 Jun 2006 17:40:59 +0100 (BST) In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0CF41506@ACCLUST02EVS1.ugd.att.com> References: <34DA635B184A644DA4588E260EC0A25A0CF41506@ACCLUST02EVS1.ugd.att.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <70BE5912-216E-4B0E-97C1-6F9DD4662F24@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Speermint] Re: [Enum] How to correctly set up the request URI? Date: Mon, 5 Jun 2006 17:40:57 +0100 To: "Pfautz, Penn L, GBLAM" X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: enum@ietf.org, Richard Stastny , "Creighton, Tom" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Penn, ENUM folks, Regulators can veto pretty much anything. However, so far the concerns I have seen in ENUM have been *exclusively* focussed on publication of PII by a SP without the explicit and informed consent of the data subject (its customer). Some definitions of PII have included the domainpart of a SIP URI, but if one has to hide the identity of a SP from prying eyes, that just stops the day getting boring. (Speaking of I.ENUM being used for the authoritative SP -> number binding, or not). Having a private scheme is fine and requires no involvement of the IETF (or anyone else, AFAICT, qua anti-cartel laws). However, for the IETF and infrastructure ENUM, any private scheme would seem to conflict fundamentally with the IAB's architecture. In short - you want to play in the privacy of your own home - fine. If you want to use the street, then here's the place to agree the protocol. Remember that this is NOT peering arrangement - it's just the ENUM lookup to help to find the rendezvous. What you do from that point onwards is your business (and/or speermint). all the best, Lawrence On 5 Jun 2006, at 16:57, Pfautz, Penn L, GBLAM wrote: > My original statement about invisibility was that the end user > doesn't > need to specify/know the URI that the SP provides in infrastructure > ENUM > - or even that infrastructure ENUM even exists at all. > > The issue seems to have evolved to that of how much of the > infrastructure ENUM tree and its products will be openly visible. This > is a decision that many parties may have some level of input to. > National regulators may well be able to veto public visibility if they > so choose. Service providers may wish to control resolution to some > degree although making the infrastructure ENUM Tier 1 inaccessible > would > not seem to be something the IETF would want to do other things being > equal. > > Penn > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Monday, June 05, 2006 11:49 AM > To: Creighton, Tom; richard@shockey.us; Pfautz, Penn L, GBLAM; > speermint@ietf.org; enum@ietf.org > Subject: Re: [Speermint] Re: [Enum] How to correctly set up the > request > URI? > >>>> Yes. Again, there might be exceptions, for example a business might > want >>>> a URI with their name to be used and some SPs might agree to that, > but >>>> generally the point of infrastructure ENUM is to be invisible to > the >>>> user >>>> >>> Now the 64B question is the "infrastructure" URI invisible to the > global >>> DNS? >> Who has the authority to make that decision? Is it the ITU, IETF, a >> combination of the two, or each country that opts to participate in >> Infrastructure ENUM? I think that is the 64B question > > ? > I am confused > Could anybody please explain to me what you are talking about > I cannot parse this thread > > What is the "point of Infrastructure ENUM"? > What is an "Infrastructure URI" and why should it be invisible? > And what has this to do with an enterprise specific URI? > > -sta > > > > ________________________________ > > Von: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com] > Gesendet: Mo 05.06.2006 17:15 > An: richard@shockey.us; Pfautz, Penn L, GBLAM; James McEachern; Lee, > Yiu; Stastny Richard; speermint@ietf.org; enum@ietf.org > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the > request > URI? > > > > Who has the authority to make that decision? Is it the ITU, IETF, a > combination of the two, or each country that opts to participate in > Infrastructure ENUM? I think that is the 64B question. > >> -----Original Message----- >> From: Richard Shockey [mailto:richard@shockey.us] >> Sent: Saturday, June 03, 2006 10:48 >> To: 'Pfautz, Penn L, GBLAM'; 'James McEachern'; Creighton, Tom; Lee, > Yiu; >> 'Stastny Richard'; speermint@ietf.org; enum@ietf.org >> Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request >> URI? >> >> >> >>> -----Original Message----- >>> From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] >>> Sent: Friday, June 02, 2006 4:56 PM >>> To: James McEachern; Creighton, Tom; Lee, Yiu; Stastny Richard; >>> speermint@ietf.org; enum@ietf.org >>> Subject: RE: [Speermint] Re: [Enum] How to correctly set up the > request >>> URI? >>> >>> Yes. Again, there might be exceptions, for example a business might > want >>> a URI with their name to be used and some SPs might agree to that, > but >>> generally the point of infrastructure ENUM is to be invisible to the >>> user >>> >> >> >> Now the 64B question is the "infrastructure" URI invisible to the > global >> DNS? >> >> >>> _______________________________________________ >>> Speermint mailing list >>> Speermint@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speermint > > > > > _______________________________________________ > 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 From enum-bounces@ietf.org Mon Jun 05 18:23:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnNU5-0005Kp-9n; Mon, 05 Jun 2006 18:23:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnNU3-0005Kb-Sf for enum@ietf.org; Mon, 05 Jun 2006 18:23:39 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnNU2-0001H9-Jx for enum@ietf.org; Mon, 05 Jun 2006 18:23:39 -0400 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k55MNbWQ027409 for ; Mon, 5 Jun 2006 22:23:38 GMT From: "Richard Shockey" To: Date: Mon, 5 Jun 2006 18:23:37 -0400 Organization: NeuStar, Inc, Message-ID: <02e701c688ee$b13b10f0$57a623c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_02E8_01C688CD.2A2970F0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaI2WYqNRPy0SgJR/6D5on2G5Ow4wAFT1OQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Subject: [Enum] FW: I-D ACTION:draft-stastny-enum-ern-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rich.shockey@NeuStar.biz List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_02E8_01C688CD.2A2970F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, June 05, 2006 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-stastny-enum-ern-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : IANA Registration for an Enumservice to Hint to E.164 > Resolution Namespaces (ERN) > Author(s) : R. Stastny > Filename : draft-stastny-enum-ern-00.txt > Pages : 11 > Date : 2006-6-5 > > This document registers the Enumservice type "ern" and subtype "http" > using the URI scheme 'http', as well as the subtype "urn" using the > URI scheme 'urn' as per the IANA registration process defined in the > ENUM specification RFC 3761. This Enumservice is used to provide a > hint in ENUM to an E.164 Resolution Namespace a service provider > chooses to populate with E.164 numbers to be shared within a limited > group of other service providers. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-stastny-enum-ern-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-stastny-enum-ern-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-stastny-enum-ern-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------=_NextPart_000_02E8_01C688CD.2A2970F0 Content-Type: Message/External-body; name="draft-stastny-enum-ern-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-stastny-enum-ern-00.txt" Content-Type: text/plain Content-ID: <2006-6-5141853.I-D@ietf.org> ------=_NextPart_000_02E8_01C688CD.2A2970F0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ------=_NextPart_000_02E8_01C688CD.2A2970F0-- From enum-bounces@ietf.org Tue Jun 06 15:02:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fngob-0007Lx-3A; Tue, 06 Jun 2006 15:02:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FngoZ-0007Lr-Qb for enum@ietf.org; Tue, 06 Jun 2006 15:02:07 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FngoY-0007YH-In for enum@ietf.org; Tue, 06 Jun 2006 15:02:07 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Tue, 06 Jun 2006 15:02:33 -0400 id 0158C114.4485D149.000033AD Message-ID: <4485D125.7070902@hxr.us> Date: Tue, 06 Jun 2006 15:01:57 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Enum] move ENUM testbeds to e164-thirtysecondtimeout.arpa X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I think it is time the IETF asked the IAB to move ENUM test beds to a separate tree, since some countries are now trying to use it for real... meaning people have e164.arpa lookups going in their production soft switches and PBXs. Over the weekend, I noticed that lookups to every single Irish number (CC 353) were failing. None of the nameservers in the 3.5.3.e164.arpa delegation respond to anything. (BTW: not an Afilias problem, they have nothing to do with it any more). It's not like this is the first time something like this has happened. See: http://www.ripe.net/ripe/maillists/archives/enum-wg/2006/msg00047.html So perhaps it would be best for all the countries that consider ENUM to be in a production state to have all the test beds moved to e164-test.arpa or something. -andy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jun 06 15:29:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnhEp-0004gs-7Q; Tue, 06 Jun 2006 15:29:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnhEo-0004gn-Sx for enum@ietf.org; Tue, 06 Jun 2006 15:29:14 -0400 Received: from lb01nat01.inode.at ([62.99.145.1] helo=mx.inode.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnhEn-0002Ul-GW for enum@ietf.org; Tue, 06 Jun 2006 15:29:14 -0400 Received: from [81.223.16.194] (port=11165 helo=mah22.inode.at) by smartmx-01.inode.at with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FnhEm-0001EK-My; Tue, 06 Jun 2006 21:29:12 +0200 Message-Id: <7.0.1.0.2.20060606211327.03d1b338@inode.at> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 06 Jun 2006 21:29:10 +0200 To: Andrew Newton ,enum@ietf.org From: Michael Haberler Subject: Re: [Enum] move ENUM testbeds to e164-thirtysecondtimeout.arpa In-Reply-To: <4485D125.7070902@hxr.us> References: <4485D125.7070902@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org At 21:01 06.06.2006, Andrew Newton wrote: >I think it is time the IETF asked the IAB to move ENUM test beds to >a separate tree, since some countries are now trying to use it for >real... meaning people have e164.arpa lookups going in their >production soft switches and PBXs. yes - I fully concur - our registrars are having problem as well >Over the weekend, I noticed that lookups to every single Irish >number (CC 353) were failing. None of the nameservers in the >3.5.3.e164.arpa delegation respond to anything. > >(BTW: not an Afilias problem, they have nothing to do with it any more). the new kids in town dont have either.. not yet. operation of the trial hasnt been handed over to a production service yet - in fact those who won the bid are still negotiating.. we are about three months away I'll investigate -Michael >It's not like this is the first time something like this has >happened. See: >http://www.ripe.net/ripe/maillists/archives/enum-wg/2006/msg00047.html > >So perhaps it would be best for all the countries that consider ENUM >to be in a production state to have all the test beds moved to >e164-test.arpa or something. > >-andy > > > >_______________________________________________ >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 From enum-bounces@ietf.org Wed Jun 07 12:36:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo11L-00054X-9C; Wed, 07 Jun 2006 12:36:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo11K-00054S-PP for enum@ietf.org; Wed, 07 Jun 2006 12:36:38 -0400 Received: from dakota.ucd.ie ([193.1.169.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo11J-0007Kg-2j for enum@ietf.org; Wed, 07 Jun 2006 12:36:38 -0400 Received: from conversion-daemon.dakota.ucd.ie by dakota.ucd.ie (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) id <0J0I00B010K6LE00@dakota.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for enum@ietf.org; Wed, 07 Jun 2006 17:36:35 +0100 (IST) Received: from [10.0.1.189] ([83.141.81.52]) by dakota.ucd.ie (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTPSA id <0J0I00JX20SYCY30@dakota.ucd.ie>; Wed, 07 Jun 2006 17:36:35 +0100 (IST) Date: Wed, 07 Jun 2006 17:36:25 +0100 From: Niall O'Reilly Subject: Re: [Enum] move ENUM testbeds to e164-thirtysecondtimeout.arpa In-reply-to: <4485D125.7070902@hxr.us> To: Andrew Newton Message-id: <13C7D6F8-8715-4800-9836-B709388FA330@ucd.ie> MIME-version: 1.0 X-Mailer: Apple Mail (2.750) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT X-Pgp-Agent: GPGMail 1.1.1 (Tiger) References: <4485D125.7070902@hxr.us> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: enum@ietf.org, Irish ENUM Operations Mailing list , Niall O'Reilly X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6 Jun 2006, at 20:01, Andrew Newton wrote: > Over the weekend, I noticed that lookups to every single Irish > number (CC 353) were failing. None of the nameservers in the > 3.5.3.e164.arpa delegation respond to anything. (BTW: not an > Afilias problem, they have nothing to do with it any more). Andy, Thanks for highlighting this, and apologies for the confusion here. I think you'll find that +353 is working again, although we still have to dissolve some bad glue in the parent zone. Best regards, Niall O'Reilly Chair, ENUM +353 Policy Advisory Board -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEhwCOeYfkja6ZXtkRAnW0AJ9BJ/E/mPyQEznxpo9ZJ4b11xnkzACfcx4K cVkrxedt51a2jOwdLNXjG1c= =k6dE -----END PGP SIGNATURE----- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jun 07 14:54:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo3At-0000qk-JA; Wed, 07 Jun 2006 14:54:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo3As-0000qe-EE for enum@ietf.org; Wed, 07 Jun 2006 14:54:38 -0400 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fo3Aq-0008G8-11 for enum@ietf.org; Wed, 07 Jun 2006 14:54:38 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-9.tower-126.messagelabs.com!1149706436!9472968!8 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 15359 invoked from network); 7 Jun 2006 18:54:34 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-9.tower-126.messagelabs.com with SMTP; 7 Jun 2006 18:54:34 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 44708FE90026453A for enum@ietf.org; Wed, 7 Jun 2006 14:54:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] FW: I-D ACTION:draft-stastny-enum-ern-00.txt Date: Wed, 7 Jun 2006 14:54:33 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0CFA38B3@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <02e701c688ee$b13b10f0$57a623c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] FW: I-D ACTION:draft-stastny-enum-ern-00.txt Thread-Index: AcaI2WYqNRPy0SgJR/6D5on2G5Ow4wAFT1OQAFzahXA= From: "Pfautz, Penn L, GBLAM" To: X-Spam-Score: 0.5 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Richard: I appreciate the problem you're trying to solve here but have some concerns: 1. I don't think a carrier can effectively hide it's "ownership" of a number through this technique. Even if the ERN doesn't directly reveal the carrier, I'm guessing it won't be hard to figure out. 2.If you don't know the secret handshake knowing the ERN won't be much use; if you do, you probably already know where to go for resolution. 3. I think this encourages fragmentation of the namespace for E.164.=20 Penn -----Original Message----- From: Richard Shockey [mailto:Rich.Shockey@NeuStar.biz]=20 Sent: Monday, June 05, 2006 6:24 PM To: enum@ietf.org Subject: [Enum] FW: I-D ACTION:draft-stastny-enum-ern-00.txt > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, June 05, 2006 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-stastny-enum-ern-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : IANA Registration for an Enumservice to Hint to E.164 > Resolution Namespaces (ERN) > Author(s) : R. Stastny > Filename : draft-stastny-enum-ern-00.txt > Pages : 11 > Date : 2006-6-5 >=20 > This document registers the Enumservice type "ern" and subtype "http" > using the URI scheme 'http', as well as the subtype "urn" using the > URI scheme 'urn' as per the IANA registration process defined in the > ENUM specification RFC 3761. This Enumservice is used to provide a > hint in ENUM to an E.164 Resolution Namespace a service provider > chooses to populate with E.164 numbers to be shared within a limited > group of other service providers. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-stastny-enum-ern-00.txt >=20 > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-stastny-enum-ern-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-stastny-enum-ern-00.txt". >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jun 07 16:03:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4F6-0007K2-S5; Wed, 07 Jun 2006 16:03:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4F5-0007IZ-Q9 for enum@ietf.org; Wed, 07 Jun 2006 16:03:03 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fo4F4-0003JK-8g for enum@ietf.org; Wed, 07 Jun 2006 16:03:03 -0400 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: [Enum] FW: I-D ACTION:draft-stastny-enum-ern-00.txt Date: Wed, 7 Jun 2006 22:07:09 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AC7@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] FW: I-D ACTION:draft-stastny-enum-ern-00.txt Thread-Index: AcaI2WYqNRPy0SgJR/6D5on2G5Ow4wAFT1OQAFzahXAAAsvabw== From: "Stastny Richard" To: "Pfautz, Penn L, GBLAM" , X-Spam-Score: 0.5 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org =20 >I appreciate the problem you're trying to solve here but have some >concerns: >1. I don't think a carrier can effectively hide it's "ownership" of a >number through this technique. Even if the ERN doesn't directly reveal >the carrier, I'm guessing it won't be hard to figure out. How? If the ERN is pointing to e164enum.net and it is an Austrian number, you would know it is an Austran mobile operator. I could have told you also from looking at the number anyway >2.If you don't know the secret handshake knowing the ERN won't be much >use; if you do, you probably already know where to go for resolution. Yes, the ERN is only optional. It just saves you the time trying out all possible options. >3. I think this encourages fragmentation of the namespace for E.164. The fragmentation is already happening. With this we could at least try to keep a common anchor or umbrella. Richard >Penn -----Original Message----- From: Richard Shockey [mailto:Rich.Shockey@NeuStar.biz] Sent: Monday, June 05, 2006 6:24 PM To: enum@ietf.org Subject: [Enum] FW: I-D ACTION:draft-stastny-enum-ern-00.txt > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, June 05, 2006 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-stastny-enum-ern-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : IANA Registration for an Enumservice to Hint to E.164 > Resolution Namespaces (ERN) > Author(s) : R. Stastny > Filename : draft-stastny-enum-ern-00.txt > Pages : 11 > Date : 2006-6-5 > > This document registers the Enumservice type "ern" and subtype "http" > using the URI scheme 'http', as well as the subtype "urn" using the > URI scheme 'urn' as per the IANA registration process defined in the > ENUM specification RFC 3761. This Enumservice is used to provide a > hint in ENUM to an E.164 Resolution Namespace a service provider > chooses to populate with E.164 numbers to be shared within a limited > group of other service providers. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-stastny-enum-ern-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-stastny-enum-ern-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-stastny-enum-ern-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ 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 From enum-bounces@ietf.org Thu Jun 08 16:23:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoR1k-00059A-Vx; Thu, 08 Jun 2006 16:22:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoR1j-000595-Kf for enum@ietf.org; Thu, 08 Jun 2006 16:22:47 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoR1i-0005cv-8F for enum@ietf.org; Thu, 08 Jun 2006 16:22:47 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k58KNAg6000680 for ; Thu, 8 Jun 2006 13:23:10 -0700 From: "Richard Shockey" To: Date: Thu, 8 Jun 2006 16:22:36 -0400 Message-ID: <00f501c68b39$48a2bfa0$72201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaLE561dn+2V16hR06i62h7wz4ObQAJaTUg X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [Enum] FW: IETF 67 Location Announcement X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: IETF Administrative Director [mailto:iad@ietf.org] > Sent: Thursday, June 08, 2006 11:52 AM > To: IETF Announcement list > Subject: IETF 67 Location Announcement > > The IETF is pleased to announce its selection of San Diego, California, > USA and > the Sheraton San Diego Hotel & Marina as the site of IETF 67 being held > November > 5 - 10, 2006. > > As we celebrate IETF's 20th year we return to the city where IETF 01 (with > 21 > attendees) was held, as well as IETFs' 9, 23, 49, and 60. The Sheraton has > added > another 18,000 sq ft of meeting space for us to use this year. > > Note Well: There are other conferences being held in San Diego so we > encourage > you to reserve your hotel rooms right away. > > We have arrangements on Harbor Island with: > > Sheraton San Diego Hotel & Marina for 770 rooms and 50 rooms at the Hilton > San > Diego Airport/Marina, both properties with free Internet in the rooms. > More > information can be found at: http://www.ietf.org/meetings/hotels_67.html > > Registration for San Diego will open July 12th. > > We are looking forward to San Diego in November, but until then we will > see you > in Montreal in 31 days! > > And speaking of Montreal, Early Bird registration with its $550 > registration > fee expires at 1600 GMT on 30 June! If you have not registered yet, delay > no > longer! http://www.ietf.org/meetings/IETF-66.html > > Ray Pelletier > IETF Administrative Director > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Jun 11 21:16:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpb1w-0003qB-FA; Sun, 11 Jun 2006 21:15:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpb1v-0003q6-HZ for enum@ietf.org; Sun, 11 Jun 2006 21:15:47 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpb1u-0004MR-5g for enum@ietf.org; Sun, 11 Jun 2006 21:15:47 -0400 Received: from RSHOCKEYLTXP (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k5C1G9Me004108 for ; Sun, 11 Jun 2006 18:16:09 -0700 From: "Richard Shockey" To: Date: Sun, 11 Jun 2006 21:15:40 -0400 Message-ID: <011d01c68dbd$b896e530$23f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaNvbfA47EWIQb6TkK6jp7XjDIFyg== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Enum] ENUM WG Meeting information for those of you travel planning. X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org As we suspected we are early in the week. NOTE this is tentative. The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the information of sessions that you have requested. ENUM Session 1 (2.5 hours) Monday, Morning Session I 0900-1130 Room Name: Room 520ABC ---------------------------------------------- Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jun 13 19:33:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqINn-00005S-0B; Tue, 13 Jun 2006 19:33:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqINl-0008WO-HA; Tue, 13 Jun 2006 19:33:13 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqHxn-0005cW-2u; Tue, 13 Jun 2006 19:06:23 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqHiv-0005Zy-VZ; Tue, 13 Jun 2006 18:51:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5DMo1mU014132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Jun 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FqHhx-0006dH-IO; Tue, 13 Jun 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 13 Jun 2006 18:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-vcard-02.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : IANA Registration for vCard Enumservice Author(s) : A. Mayrhofer Filename : draft-ietf-enum-vcard-02.txt Pages : 9 Date : 2006-6-13 This memo registers the Enumservice "vCard" with the subtypes "plain", "xml" and "rdf" using the URI schemes "http" and "https" according to the IANA Enumservice registration process described in RFC 3671. This Enumservice is to be used to refer from an ENUM domain name to a vCard instance describing the user of the respective E.164 number. Information gathered from those vCards could be used before, during or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-vcard-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-vcard-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-vcard-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-13154159.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-vcard-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-vcard-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-13154159.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Wed Jun 14 02:51:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqPDn-0006D9-C7; Wed, 14 Jun 2006 02:51:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqPDm-0006D1-GN for enum@ietf.org; Wed, 14 Jun 2006 02:51:22 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FqPDk-0003Zx-WE for enum@ietf.org; Wed, 14 Jun 2006 02:51:22 -0400 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: [Enum] Tasks before Montreal -Agenda Item Request Date: Wed, 14 Jun 2006 08:55:28 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4AD4@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] Tasks before Montreal -Agenda Item Request Thread-Index: AcaIEgQX+5vQlSNTSoOa1TjjKJlQ/gHbMT2H From: "Stastny Richard" To: , X-Spam-Score: 0.5 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Dear co-chairs, =20 please add 10' for draft-stastny-enumservice-ern-00.txt =20 In addition we request 10' for draft-haberler-carrier-enum-03.txt (to be = submitted) =20 We should also consider how to proceed with draft-lendl-enum-branch-location-record-00 =20 Richard ________________________________ Von: Richard Shockey [mailto:richard@shockey.us] Gesendet: So 04.06.2006 22:03 An: enum@ietf.org Betreff: [Enum] Tasks before Montreal -Agenda Item Request Again I'd like to ask for agenda items for Montreal I have scheduled 2 = 1/2 hours so I don't think there is a problem here with time. That said there are several non controversial drafts that I think we can accelerate to WGLC ASAP if there is sufficient review and discussion = before Montreal. The chairs have identified. http://www.ietf.org/internet-drafts/draft-ietf-enum-vcard-01.txt=20 http://www.ietf.org/internet-drafts/draft-ietf-enum-im-service-00.txt http://www.ietf.org/internet-drafts/draft-ietf-enum-calendar-service-00.t= xt As being close to ready if the authors will complete any revisions they = may have NOW (Alex) and ask the WG Secretary to NIT review their versions in advance. Shortly I will have ready. http://www.ietf.org/internet-drafts/draft-ietf-enum-cnam-02.txt Which will be sufficiently ready IMHO for WGLC as well. Comments are appreciated. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ 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 From enum-bounces@ietf.org Wed Jun 14 03:31:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqPqY-0007t2-U4; Wed, 14 Jun 2006 03:31:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqPqX-0007so-B6 for enum@ietf.org; Wed, 14 Jun 2006 03:31:25 -0400 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqPqW-00074W-1n for enum@ietf.org; Wed, 14 Jun 2006 03:31:25 -0400 Received: from [192.168.1.206] (85-124-83-205.dynamic.xdsl-line.inode.at [::ffff:85.124.83.205]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 14 Jun 2006 09:31:21 +0200 id 0007C020.448FBB49.000024E7 Message-ID: <448FBB36.5040501@enum.at> Date: Wed, 14 Jun 2006 09:31:02 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: enum@ietf.org Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-vcard-02.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Internet-Drafts@ietf.org wrote: > Title : IANA Registration for vCard Enumservice > Author(s) : A. Mayrhofer > Filename : draft-ietf-enum-vcard-02.txt > Pages : 9 > Date : 2006-6-13 [..] > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-vcard-02.txt Can somebody please volunteer to NITS-review this? Since i'm the author, i can't review it by myself - the chairs have indicated that this is pretty much ready for WGLC soon, so reviews are definitely appreciated ... thanks, Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jun 14 12:00:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXnN-0001Ak-FN; Wed, 14 Jun 2006 12:00:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXnI-00010r-DG for enum@ietf.org; Wed, 14 Jun 2006 12:00:36 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXiL-0006du-Kt for enum@ietf.org; Wed, 14 Jun 2006 11:55:30 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k5EFtjMF003950; Wed, 14 Jun 2006 08:55:46 -0700 From: "Richard Shockey" To: "'Stastny Richard'" , Subject: RE: [Enum] Tasks before Montreal -Agenda Item Request Date: Wed, 14 Jun 2006 11:55:06 -0400 Message-ID: <012101c68fca$e8d1b0e0$6e201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0122_01C68FA9.61C010E0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4AD4@oefeg-s04.oefeg.loc> X-MS-TNEF-Correlator: 00000000D782A326514E234E9AEF378ABB1DFA3DA4895F00 Thread-Index: AcaIEgQX+5vQlSNTSoOa1TjjKJlQ/gHbMT2HABMDCQA= X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0122_01C68FA9.61C010E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit OK ... no problem _____ From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Wednesday, June 14, 2006 2:55 AM To: richard@shockey.us; enum@ietf.org Subject: Re: [Enum] Tasks before Montreal -Agenda Item Request Dear co-chairs, please add 10' for draft-stastny-enumservice-ern-00.txt In addition we request 10' for draft-haberler-carrier-enum-03.txt (to be submitted) We should also consider how to proceed with draft-lendl-enum-branch-location-record-00 Richard Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 ------=_NextPart_000_0122_01C68FA9.61C010E0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IgcPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQOQBgCYFQAAJAAAAAsAAgABAAAAAwAmAAAAAAALACsAAAAAAAMA LgAAAAAAHgBwAAEAAAAyAAAAW0VudW1dIFRhc2tzIGJlZm9yZSBNb250cmVhbCAtQWdlbmRhIEl0 ZW0gUmVxdWVzdAAAAAIBcQABAAAAIAAAAAHGiBIEF/ub0JUjU0qDmtU44yiZUP4B2zE9hwATAwkA CwABDgAAAAACAQoOAQAAABgAAAAAAAAA14KjJlFOI06a7zeKux36PcKAAAADABQOAQAAAB4AKA4B AAAAMgAAADAwMDAwMDAxAXJpY2hhcmRAc2hvY2tleS51cwFSU2hvY2tleSBNYWlsIEFjY291bnQA AAAeACkOAQAAADIAAAAwMDAwMDAwMQFyaWNoYXJkQHNob2NrZXkudXMBUlNob2NrZXkgTWFpbCBB Y2NvdW50AAAAAwDeP59OAAADAAJZAAAWAAMACVkCAAAACwABgAggBgAAAAAAwAAAAAAAAEYAAAAA A4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAsADYAIIAYAAAAAAMAAAAAA AABGAAAAAIKFAAAAAAAACwA6gAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAD2ACCAGAAAA AADAAAAAAAAARgAAAAAYhQAAAAAAAAsAUoAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwBT gAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAABAAFWACCAGAAAAAADAAAAAAAAARgAAAABghQAA AAjW6CkAAAALAB8OAQAAAAIB+A8BAAAAEAAAANeCoyZRTiNOmu83irsd+j0CAfoPAQAAABAAAADX gqMmUU4jTprvN4q7Hfo9AwD+DwUAAAACAQkQAQAAAOMRAADfEQAA9kwAAExaRnXRHu6CAwAKAHJj cGcxMjWCMgNDaHRtbDEDMP8BAwH3CoACpAPkBxMCgBAD/wBQBFYIVQeyETUOUQMBAgCEY2gKwHNl dDIGANsGwxE1MwRGE8cwEj8CAK40A8UV2RDqNRe/IAdtxRE1NgPGVGFoA3ECgLcRQwjvCfc7Hg8O MDUfL3plDiA4IH8fARFBDGBjZwBQCwkBZDM2FmALpTRyIBACKlwOsgGQDhA5ZCA8DrIgeA7QAIA6 SHY9IghwbjoE8GhiZQDAcy1tDeADYHNqbwGALQWgbScQDtAiXSa1byc/KEkocGYN4GV7K2UpJncp vyrPLLAFsGTxKSZzdDEs3y3vMEAAwDsAICYBcyklL/AOsHRwEDovL3czsC53MwIuBbBnL1RSL1II RUMtDrI0MCI+PxFDJacUUAqjNV82b2cz4yVAJmBlYWQ1TQ7xN79rOj8l5DYO8DwHgAGQIGRuYQeA PUcJ8ASQYV50BbEFoAIwCfB0L/BNSSgmIFcvESAxDvAoLyuQJfAEkAmAIAeAZGm4dW0pNT47nzdD ND0BECEtLVsGkCAhbSkoYF0+CqM8L8B5bIJlRJR2XFw6KgMwSHtiZRPwdmkFsDqRCHBsKCMBAWF1 JfCgI1ZNTCkhwH0Ko+5vRc9G30fld0hvSX9H5eQucxPwcGVLT0xfRMI2L0UJQ8BbCfBA4GZdT0Pg QU9CXyYRNzcmUHQMaXRFMUKvIFtFbuVBAF0coXNrBCBOIAIQHyHgBdACISHgB0AgLUFWZ1FBPWBJ PqBtB/BlznEKUC/AUd04NVAxVF9jUo9DGm86UzIyHLBn7FR5TdE9gnMKsCuwCHGfL/8xDzIZCqM9 dCJQC2DlK7BOPZEiL1p/W49cn/9dr16/X89g32HpZiJi32Pv/2T/Zg9nH2gvaT9hxyhQAZD+bAhQ AQBrX2xvbX9uj2+f93Cvcb9hxlMBkD6gc+90/792D3cfeC95P3pPYcZDWjD+eXwvfT9+T39fgG+B f4KP/2HGC1EsIYRvhX+Gj4efiK/fib+Kz2HWBJAoYG5in41v/0MPRB9FJy/BSwJOD08VCJDybwhg aSkDME/vUP+Vj3+Wnz0BRQSff58Ul8JqBC/lSzBGAiEgRAEQC4BaMFOakAYxKi9qBEACEi1/TyAr sAqkAZFN8aTlKBBsXHk6HLWleAqwbihQZZgtMToUUD/xNiAlQLwzIFngJUAlQBRQNEfWH6MCe9BF IaOPYaJwLk0NKGBOBbAAwGwsIGx2aaxKQOB2rEilejIxZ7kLgDowC4CnWa90LQbg0wJAKMEuMLGw MQUwp1n7pOMAkHorwA4gsaCx/6Z2SiIHbSJH1mE6rQBu1mus4JBxbqxCSI/xTsB3tvGleh2DOgoy p1k+oHj/KJAFgz4gpAFOoJ2gt/O5oe+2ZpqAAJA+oGS3L7cAo0D6bB2gdwmAuF+5b7p/u40+cK67 KGAoALDUPjBwLbkHQHQ6TzA+MLAfLQUQ/mcOsK/ew7ixNMSPsJhFMH8BgK/dss+z37Tvtfu9I0X/ AMADEKqTWcDC7kUDxECP8V46t+GUsQdAxiBlC1B5v8xvppQQ5KV4v3Q9gHbS8d1H9EAKsFfABlFj o/IjY+OltsuzOC41C4A/4bGg76//r7HY8z/gLg4w2pPaiP9H1q3i1v9N8daij1DcxUfW/53xny+X YiZBnKWeL9+P4j97JeOXki85Hzdv5g8lmDVlFmA8BuBkeazwAHBnYD1FTi1VBfC24j3/CjJFoOpH 5XAlswAhAzDpkvgxMDOpIOumFmAlaySx1+fv7j8l4zmo4Dyt4T5g+wtgBBA93LbriQAA7O/vT+vz 7yVrNjjhcPFVrFfyT/PzXw4QNDgmUAISmaDLwXY9FFAdgz3V0stQkJE97wcT+GsL4gMwYxNQAzEl QHv5LyXUODjhvSKZoUUhPb4ny2iis+yAzCPTvzvVeCYn+G/+809L/z8mI9g4MjMi4euoJ1nQ/qj9 PXBvp/AOgB3gkYChHTjh/Y9AcOV+DkCcgQqf8NAL0q+9IuuJ65f5rjXw8S+k4v8Nzw7T66aisg54 IxHrt77B+xNY8403C9IKvvXPFu/2n//3rwSf+c/63/vv/P/+D/8f/wAvAT8CTwNfGz/zfgpPBkjM bmKQcAc7YTAnvwtf/wxvDX8sDw+fL58RvxLPE9//FO8V/xhfOI8ZLxo/Jy8cX/8dbx5/H48gnz3v Ir8jzyTf/yXvPN9DbykfKi8rP0m/LV//Lm8vf04PMZ9RnzO/NM8133827zf/Ol9aj/CMRRXIIHL/ u4HVwN6QwABeNMoklLCtAGxkIOqT2PA1zEG+wGTXnbDsYMpyIGFGNMwiSK//WC9b32Q/XK9ib2N/ Zd9pj49cvzvttrCtAGduPYxw36NglJBFBsDDbfM6blRiXHxxY0MJOttnv2jPPw0z36KzQMPN30Fu QvFmqUBzf/9EL0U9zARiX3k/5MFrP355f1Q/VUlR6lirB0dWOmuvaMuZkT+0d1/gdGiQ8OyAeDAl Im3svxHbALuAeD49qGBBbN0gcSBxEGpcxZtgZKXxfiBfivKKsf/sMLvBVfNXz2qvjO/mvz8Sr1D1 j39TtuLMMEsBL2d8/1H/jo+VfzqfO688v5TvejX+YpobpfGa73SfP8N2M6b0/0FvQsGo4J2Peg97 HkaEdeT/zSmgVEbUvoDGQ8ggioB8b/2iVEYJELGAT+9Q/6IfUx//q0+sX6qjnIquv56PP6R16L+g X6Fvsb+jj6Sepe9hqB8nCGXQAG0QdG5AoFJpdGNoV6Bkfy+AO7YZWzvPwsRQOrzF3KC8VEBvgcpA ZWcuYXRdse3yMa2BYnLri4uRjB9+L/+bj5yfxG+3X0VWp2+7L9ywfz9wqc+q37FPr8/PHwiwVwRl ZF7Ac2RheSzYIEp1XsDY0DTTYEJQHDA2xO++T8/FMjo1+XjQQU3B78L/xA/Uj8Yvv8c/2b/JX8pv y3/duFRPkH/QP86P3b/Qr+R/Sg/fQXSYMTpQbpBfsG5OR0D1YEB3X6B0dnBesHeBR7AJvONAc7SA Y2tleXgudXNOb+PB6VuQ4DsP2l/Vb+UVbmB1bUBp6mW+4C5IMGfXX9hv2X//7n/bn9yv9A/ez9/f 4O/MieB1YmplY81f47/kz7fl3/7/CKFSpQC/sEXw4dPBwLpgc2t20GJfcEgw52BA6C/pM0NpXdBG I+o5uwRP6TNwbQB2UOoqTT9h/wQQb4DsD+0UCEMGzuznBaJhBsAgLUFnzTDTMCB6SW6AbfSv71// tQLAcf9gMF3AAC/+f/+PrQ8SzxPf/0rvTt9Vf1aPV59Yr1m/9Z//Hu+TDxWvlS8gbyQ/mF+Zb/+a f7IPdTl2L3c/eE8pf/l//0WdfB8pDxdPS49Mn02vGK//T88STyLfFG8Vf1UfGo8bn3873x2/JX9D n2u/bMFf4D0xX+BPV0ECwAhAeVTBb0EzMTc1NzIvQa//RV9Kf2avSK9Jv0wfT88mj28nn04vKb+f O2NfwF8APetgECugayuEQergU921lPxjZitwidD1cVTPL38wj+sxkblPOlhDO1cz+yBXorsyH1qE RAmgdhBXMC284fpp6aAsOV86b1pPPI9jv/9kzzRfOE8+7z//QQ9CH0Mv/1F/b98hT2afTw9xX3Uv TP//YC90b3bPen9ST1NfeN9Vf/8q7yv/LQ8uH1sfXC8xT36//4UPNe82/2gPaR84v2K/c0//f79l 7z4Pav9sD20fbi97L/9675pfcm+UD5rPm9+fr3e//4i/oD+f/6T/fQ9+H6NfgD//Vr9Xz1jfWe+F P4ZPXR9eLy9fP6kvCEAJoHPTsGFk+mSycSeBsAQADl8Pb69VsGRyYWaxwbxULfDSKbZwcna80GW6 sHJu8i3UIC50SCCPj5Cfry//kr+9n76vjW+Of5Ufli+XP/+YT5lfpl/Jv5yPwH+j78s//88Pod+1 D85P0K/UX6cvqD//0r+qX4Efgi+DP4RPr/+xD/+Hf9if3u+Kr4u/we/C/47v/7yfzS/Zn7/PlD/E 38Xvxv//yA/VD9TP9D/MT+3v9K/1v//5j9Gf4p/6H/nf/t/W79f///0/2h+rlqzfrequ/99P4F++ OrKF4XOy/+IvCDRJCdDxtqFpdGmrYOOf5K/lusJ3toByZXF13DDbELe25bnVYeBiuxDgkHJhwN/x ILPAE8G6wruwM7vvuC9hB+kodG8gE4DbIHWCYrNgdHRlZCnpb//qfwf/7J8aPxtP50/oX+7///AP 8R/yL/M/AD8mX/ZvHR///c8n3yuv+78NHyrvLU8w//8BDwIfL18EP9r/3A/dH94v/wjPCd/hXzU/ O48P7+WfHo//H5/ozxk/Kc82Pxxv7h8hf/8ijyOfJK8xrzFvUN8o70qP/1FPUl9WLy4/Pz9Wv1Z/ W3//M480n1nfNr8FfwaPB587v188zwrPC99fX2TjVxgBaHhvdWy2wF8wXtCsAW51seBkuxAgayA5 IBfBcLxybzhgGJARwA6gaEYP/0cfZJ9JP28PcB9D70T/S5//TK9Nv07PT99c33svUw9x7/9ab3yv gH9YX2m/f7+CH4XP/12vXr+EL2DfYe9i/2QPZR8/Zi9nP2hPaV+5bD0wbmSKbBRkYrnwbmNolbA1 bPBhDrItEgCsEHJk/7uxbZ9ur48fcM+Zf5qPc///dQ92H3cveD95T3pfh1+ln/99j5xfhO+nH6rv gt+UP6ov/6yPsD+IL4k/rp+LXzefOK//Ob86z4/vkP89/7R/us9BL/9CP53Pnt9Fb5h/qQ+1f5uv /0q/oL+hz6Lfo++w77Cv0B//qC/Jz9CP0Z/Vb61/vn/V///Vv9q/ss+z39kftf+Mn42vf46/uv+8 D5Hvkv/en+QjUvZplrDNAGTFT8Zf49/If//sD+0fwy/EP8rfy+/M/84P/88f3B/4L9JP7u/Zr/mv /X//+n/7j/yf/v8Cz9eP6O8CDx8Ebwgf3Nvl1d5gcmdp+ZdQYm8YcLiQ5tC9vwbP/+Bf4Wq33+J/ uf/kn+WgvVPf5d/m5Az/E08AITHuQZZw6RGpXGwL8GX1b/B2ueETCcPqJSBTayBja2UeeRgvGT8a TxtffURpA5dxbKByLCBNZW26Ymwxb8FQbXBq8FSXgDxobuow3nAc4AlgZmavHW8efx+PIJ99EQB1 I9Gf9VEkTyVfJm8bfjQ2l+DD8A/lUnQxOlDdsBBgyFR5cGrwdzoVQBCA6+EgEZFDliB0bDDxn+uR by7K8XAtjy6ZTugAL3tP/GFrMK8xuTSC8X0b9sDnnxL/Mz8vDxGRO8F6YTW/2TG/IC06XztkcDvS L4rrP787c0NtYHm9Uy+KI9D7bDAq4Wc9bz50Q4LxcCIwn0IvO3Mj0TBwL4pWQUVfbz50SKMyrztH bxVA3nBD3m9sIEPP42ApwDZJ3z51/0038X8+VkETUT0pvyrPK99jCcO9AHA6cmsRHSIozZcQKVeQ MHBsLt5ARUxPVA9VH1YvVzc1Nw8wMUBAZndkLnBrQHb1bDAua9BtWR9aL1s/XE/BPQBTVE4gTyQA 6jARavArMSBdoS40M+Q0Lu4wNTFe71//YQ9/Yh9jJEvPQzdBb2nfQR9N/G9i6CBnEVF/Uo9vH0bE Hjpj4WfvOO9ndTcwM4VkkDl1UDI2ODNk739l/2cPct8IvMBC8LDAyTyjeF/k6GEgaJdwZhCAf95g 6CAMUFew6jRYQlfVLlR1cxGdaViwZPBCZgeBMAvwFUB7SFlQRcBSTElOSyB+X39rPH19uZGBMFfA 8LBcY/hmMVxeUDm5gs9/eQD/t8qpAX/q62FwfcBCZ3tq/j6KD3Zvd3+OH3mfeq97v/d8z33f6jQu V9mQoIAAKLH6Lm5weoAvgT+CT5ePmJr/hJ+Fr5w/mF2Jb4k/lQ+LX/+Mb41/jo+Pn5Cvkb9TL6nP /6rfq++s/64Prx+wLwSv63//pB/tn+6vuA/wz/Hf8u/z///1D/Yf9y8Jj8Mf/78Az8Dv/8SfyG/F b8Z/x4/J782/yr9fy8/M388/0w/UGjUPUS99DCBkRvG7TNTv13+7pjdX0PGy0rydM9kFfdxQAAMA DTT9PwMAAwAPNP0/AwACARQ0AQAAABAAAABOSVRB+b+4AQCqADfZbgAAAgF/AAEAAAAxAAAAMDAw MDAwMDBENzgyQTMyNjUxNEUyMzRFOUFFRjM3OEFCQjFERkEzREE0ODk1RjAwAAAAAAMABhBr9pzE AwAHEIICAAADABAQAAAAAAMAERABAAAAHgAIEAEAAABlAAAAT0tOT1BST0JMRU1GUk9NOlNUQVNU TllSSUNIQVJETUFJTFRPOlJJQ0hBUkRTVEFTVE5ZQE9FRkVHQVRTRU5UOldFRE5FU0RBWSxKVU5F MTQsMjAwNjI6NTVBTVRPOlJJQ0hBUgAAAAB8/w== ------=_NextPart_000_0122_01C68FA9.61C010E0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ------=_NextPart_000_0122_01C68FA9.61C010E0-- From enum-bounces@ietf.org Wed Jun 14 12:01:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXnf-0001pv-Us; Wed, 14 Jun 2006 12:00:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXnI-0000ug-OP for enum@ietf.org; Wed, 14 Jun 2006 12:00:36 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXhf-0006cw-Lv for enum@ietf.org; Wed, 14 Jun 2006 11:54:49 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k5EFt5Vp003800 for ; Wed, 14 Jun 2006 08:55:06 -0700 From: "Richard Shockey" To: Date: Wed, 14 Jun 2006 11:54:26 -0400 Message-ID: <012001c68fca$d09613e0$6e201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaPys/SFmRQtIMVRNuRckxYpF8Nyw== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Enum] IETF Montreal ENUM WG Agenda X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org http://www.ietf.org/internet-drafts/draft-ietf-enum-vcard-02.txt http://www.ietf.org/internet-drafts/draft-ietf-enum-im-service-00.txt http://www.ietf.org/internet-drafts/draft-ietf-enum-calendar-service-00.txt http://www.ietf.org/internet-drafts/draft-ietf-enum-cnam-02.txt 10' for draft-stastny-enumservice-ern-00.txt In addition we request 10' for draft-haberler-carrier-enum-03.txt We should also consider how to proceed with draft-lendl-enum-branch-location-record-00 10 Min. Infrastructure ENUM root. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jun 14 19:31:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqepu-0007vT-Bg; Wed, 14 Jun 2006 19:31:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqeps-0007vL-Uw for enum@ietf.org; Wed, 14 Jun 2006 19:31:44 -0400 Received: from charles.frobbit.se ([85.30.129.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqepp-0002yj-EI for enum@ietf.org; Wed, 14 Jun 2006 19:31:44 -0400 Received: from charles.frobbit.se (localhost [127.0.0.1]) by charles.frobbit.se (8.13.4/8.13.4) with ESMTP id k5ENUOq1045488; Thu, 15 Jun 2006 01:30:24 +0200 (CEST) (envelope-from www@charles.frobbit.se) Received: (from www@localhost) by charles.frobbit.se (8.13.4/8.12.10/Submit) id k5ENUOZO045487; Thu, 15 Jun 2006 01:30:24 +0200 (CEST) (envelope-from www) Date: Thu, 15 Jun 2006 01:30:24 +0200 (CEST) From: "YOU HAVE WON via RT" <3761bis@frobbit.se> In-Reply-To: <5C59075D.17342BA@lottery.com> References: <5C59075D.17342BA@lottery.com> Message-ID: Precedence: bulk X-RT-Loop-Prevention: ticket.frobbit.se RT-Ticket: ticket.frobbit.se #1498 Managed-by: RT 3.4.4 (http://www.bestpractical.com/rt/) RT-Originator: lottery111@lottery.com Cc: enum@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RT-Original-Encoding: utf-8 X-Spam-Score: 1.7 (+) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [Enum] [ticket.frobbit.se #1498] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Reply-To: 3761bis@frobbit.se List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Thu Jun 15 01:30:23 2006: Request 1498 was acted upon. Transaction: Ticket created by lottery111@lottery.com Queue: 3761bis Subject: (No subject given) Owner: Nobody Requestors: lottery111@lottery.com Status: new Ticket www.lotto.nl Suite 120 1007 South/Zuld, 1NL Meppo Holland (Customer Services) Ref: NL/8161/99 Batch: NL/BE12-11 Government Accredited Licensed lottery promoters. International Promotions/Prize Award Department Login to Website: www.lotto.nl We are please to announce you as one of the 10 lucky winners in the national lottery held on the 7th June, 2006. All 10 winning addresses wererandomly selected from a batch of 50,000,000 international emails. Your email address emerged alongside 9 others as a category 2 winner in this yearLotto. NL game drawConsequently, you have therefore been approved for a total pay out of 1,000,000 (one million Euros) only. In order to avoid unnecessary delays and complications please remember to quote your reference number and batch numbers: 1, Batch 9484-9006-0076 2, Ref: 637409467-Nll 3, lucky numbers 1-0960-31-444 Please note that your lucky winning number falls within our European booklet representative office in Europe as indicated in your play coupon. Inview of this, your 1,000,000 (One Million Euros) would be released to you by any of our payment offices in Europe. To file for your claim, please contact Advocate Steven cox Tel: +31 -630 143 359 Fax: +31-84-722-8603 Email:bejesbejescom@netscape.net law & Associates This will enable the office of law & asscociates to send the claims application form (A4) to you the Beneficiary.you can confirm your winningswhen you Login to Website: www.lotto.nl For security reasons, you are advised to keep your winning information confidential till your claims is processed and your money remitted to you in whatever manner you deem fit to claim your prize. This is part of our precautionary measure to avoid double claiming and unwarranted abuse of this program. Please be warned. Remember, all winnings must be claim not later than June 20th, 2006, after this date, unclaimed funds willbe returned to the Lotto. NL CONGRATULATIONS! CALL NOW TO CLAIM YOUR WINNING PRIZE Advocate Steven cox Tel: +31 -630 143 359 Fax: +31-84-722-8603 Email:bejesbejescom@netscape.net law & Associates Note:Send all your reply to bejesbejescom@netscape.net Yours faithfully, Mrs Maria Van Boer Online coordinator Sweepstakes International Program. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jun 19 08:36:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsIyl-0006co-7K; Mon, 19 Jun 2006 08:35:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsIyk-0006cj-Q8 for enum@ietf.org; Mon, 19 Jun 2006 08:35:42 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsIyi-00034W-GI for enum@ietf.org; Mon, 19 Jun 2006 08:35:42 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 19 Jun 2006 05:35:40 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5JCZd31004142 for ; Mon, 19 Jun 2006 05:35:39 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5JCZd9s006272 for ; Mon, 19 Jun 2006 05:35:39 -0700 (PDT) Received: from [127.0.0.1] (ssh-ams-1.cisco.com [144.254.226.40]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k5JCUsva010253 for ; Mon, 19 Jun 2006 05:31:08 -0700 Mime-Version: 1.0 (Apple Message framework v750) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <67506C47-7F8E-44B4-AC7C-C1D289CAA0E0@cisco.com> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Mon, 19 Jun 2006 05:35:36 -0700 To: IETF ENUM WG X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-3.cisco.com; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=543; t=1150720539; x=1151584539; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20 |Subject:FYI=3A=20draft-mahy-speermint-direct-peering; X=v=3Dcisco.com=3B=20h=3D5hl1kqJFoj8eSgYVBriTyyo03LI=3D; b=HHCE8VYXkNSllUt3uNwadM5FtZNp0EQcGIAtVYoV0TXrk1KuoliHho3oSD61u1PkJ1GjlisP VTk2ZyTFLO0eMx1X8AHbd6Y3YATwVMJsa36hQ9pTGAJ4a2JULU319XLS; X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Enum] FYI: draft-mahy-speermint-direct-peering X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Begin forwarded message: >> Hi Folks, >> >> I just submitted a draft with a minimalist approach to peering. I >> thought this might be a useful way to have a productive discussion >> on requirements. >> >> Until it appears in the archive, you can get it here: >> >> http://scm.sipfoundry.org/rep/ietf-drafts/rohan/direct-peering/ >> draft-mahy-speermint-direct-peering-00.html >> http://scm.sipfoundry.org/rep/ietf-drafts/rohan/direct-peering/ >> draft-mahy-speermint-direct-peering-00.txt >> >> thanks, >> -rohan _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jun 22 20:09:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtZEM-0003Tm-Mc; Thu, 22 Jun 2006 20:09:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtZEL-0003Q6-9p; Thu, 22 Jun 2006 20:09:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtYV2-00007c-0k; Thu, 22 Jun 2006 19:22:12 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtY0s-0006m6-LO; Thu, 22 Jun 2006 18:51:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5MMo2mU022647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtXzu-0007tL-3i; Thu, 22 Jun 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 22 Jun 2006 18:50:02 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-im-service-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services Author(s) : R. Mahy Filename : draft-ietf-enum-im-service-01.txt Pages : 5 Date : 2006-6-22 This document registers a Telephone Number Mapping (ENUM) service for Instant Messaging (IM). Specifically, this document focuses on provisioning 'im:' URIs in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-im-service-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-im-service-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-im-service-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-22155217.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-im-service-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-im-service-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-22155217.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Thu Jun 22 20:20:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtZP3-0006a1-6d; Thu, 22 Jun 2006 20:20:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtZP0-0006Yk-5H; Thu, 22 Jun 2006 20:20:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtYV2-00008i-02; Thu, 22 Jun 2006 19:22:12 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtY0s-0006m3-6j; Thu, 22 Jun 2006 18:51:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5MMo1mU022637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtXzt-0007sN-NK; Thu, 22 Jun 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 22 Jun 2006 18:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-validation-arch-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Validation Architecture Author(s) : A. Mayrhofer, B. Hoeneisen Filename : draft-ietf-enum-validation-arch-03.txt Pages : 18 Date : 2006-6-22 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes validation requirements and a high level architecture for an ENUM validation infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-arch-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-validation-arch-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-validation-arch-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-22151356.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-validation-arch-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-validation-arch-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-22151356.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Mon Jun 26 09:00:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuqhT-0000eS-1I; Mon, 26 Jun 2006 09:00:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuqhR-0000cu-Kd for enum@ietf.org; Mon, 26 Jun 2006 09:00:21 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuqhP-0006LM-6H for enum@ietf.org; Mon, 26 Jun 2006 09:00:21 -0400 Received: from g8ibr.kiel01.telekom.de by tcmail31.dmz.telekom.de with ESMTP for enum@ietf.org; Mon, 26 Jun 2006 15:00:17 +0200 Received: by G8IBR.kiel01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Jun 2006 15:00:17 +0200 Message-Id: <665519695E86E64190E6B57727F60912028A3F88@S4DE9JSAAHX.nord.t-com.de> From: "Schiefner, Carsten" To: enum@ietf.org Subject: RE: [Enum] move ENUM testbeds to e164-thirtysecondtimeout.arpa Date: Mon, 26 Jun 2006 15:00:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Andy, all - ensuring DNS quality of the ENUM is an issue that has already been = raised with the RIPE NCC, the ENUM Tier 0 registry; some first drafts = for initial and ongoing delegation checks are currently being = discussed. Unfortunately the problem seems to be more persistent than thought: = although Ireland's ENUM delegation (3.5.3.e164.arpa) eventually = reappeared on the net, there is currently another one being offline = since 5 June. All formal and informal points of contact have been triggered already. Best, -C. --=20 Carsten Schiefner | p: +49 441 = 234-4571 Deutsche Telekom AG | f: +49 431 = 7163-3972 T-Com Zentrale TK44 | m: +49 151 = 14525458 Ammerl=E4nder Heerstr. 138 | = mailto:Carsten.Schiefner@t-com.net D-26129 Oldenburg | = http://www.t-com.de/kundendienst > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Tuesday, June 06, 2006 9:02 PM > To: enum@ietf.org > Subject: [Enum] move ENUM testbeds to e164-thirtysecondtimeout.arpa >=20 >=20 > I think it is time the IETF asked the IAB to move ENUM test beds to a = > separate tree, since some countries are now trying to use it=20 > for real...=20 > meaning people have e164.arpa lookups going in their production soft=20 > switches and PBXs. >=20 > Over the weekend, I noticed that lookups to every single Irish number = > (CC 353) were failing. None of the nameservers in the=20 > 3.5.3.e164.arpa=20 > delegation respond to anything. (BTW: not an Afilias problem,=20 > they have=20 > nothing to do with it any more). >=20 > It's not like this is the first time something like this has=20 > happened.=20 > See:=20 > = http://www.ripe.net/ripe/maillists/archives/enum-wg/2006/msg00047.html >=20 > So perhaps it would be best for all the countries that=20 > consider ENUM to=20 > be in a production state to have all the test beds moved to=20 > e164-test.arpa or something. >=20 > -andy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jun 26 10:29:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fus61-00065I-Du; Mon, 26 Jun 2006 10:29:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fus5z-000655-Rj for enum@ietf.org; Mon, 26 Jun 2006 10:29:47 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fus5y-0004iZ-Dw for enum@ietf.org; Mon, 26 Jun 2006 10:29:47 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k5QETvNh029391 for ; Mon, 26 Jun 2006 07:29:57 -0700 From: "Richard Shockey" To: Date: Mon, 26 Jun 2006 10:29:28 -0400 Message-ID: <00e801c6992c$ee9b8c60$4d201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00E9_01C6990B.6789EC60" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaXH07kWokZUzoQRoyjUjAkC5aAiwCDZoGA X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Subject: [Enum] FW: I-D ACTION:draft-haberler-carrier-enum-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_00E9_01C6990B.6789EC60 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Friday, June 23, 2006 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-haberler-carrier-enum-03.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Combined User and Infrastructure ENUM in the e164.arpa > tree > Author(s) : M. Haberler, R. Stastny > Filename : draft-haberler-carrier-enum-03.txt > Pages : 11 > Date : 2006-6-23 > > This memo defines an interim solution for Infrastructure ENUM to > allow a combined User and Infrastructure ENUM implementation in > e164.arpa as a national choice until the long-term solution is > approved. This interim solution will be deprecated after deployment > of the long-term solution. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-haberler-carrier-enum-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-haberler-carrier-enum-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------=_NextPart_000_00E9_01C6990B.6789EC60 Content-Type: Message/External-body; name="ATT00594.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00594.dat" Content-Type: text/plain Content-ID: <2006-6-23140420.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-haberler-carrier-enum-03.txt ------=_NextPart_000_00E9_01C6990B.6789EC60 Content-Type: Message/External-body; name="draft-haberler-carrier-enum-03.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-haberler-carrier-enum-03.txt" Content-Type: text/plain Content-ID: <2006-6-23140420.I-D@ietf.org> ------=_NextPart_000_00E9_01C6990B.6789EC60 Content-Type: text/plain; name="ATT00597.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00597.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_00E9_01C6990B.6789EC60 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ------=_NextPart_000_00E9_01C6990B.6789EC60-- From enum-bounces@ietf.org Mon Jun 26 10:52:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FusSH-0006R5-1D; Mon, 26 Jun 2006 10:52:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FusSF-0006Q1-KS for enum@ietf.org; Mon, 26 Jun 2006 10:52:47 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FusSE-0007ri-6W for enum@ietf.org; Mon, 26 Jun 2006 10:52:47 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k5QEr5jw032734 for ; Mon, 26 Jun 2006 07:53:05 -0700 From: "Richard Shockey" To: Date: Mon, 26 Jun 2006 10:52:36 -0400 Message-ID: <00fb01c69930$29f6d500$4d201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00FC_01C6990E.A2E53500" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaUotJFDbUOnys5R4WRPJjorWyRkwEjVObg X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Subject: [Enum] FW: I-D ACTION:draft-daigle-unaptr-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_00FC_01C6990E.A2E53500 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, June 20, 2006 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-daigle-unaptr-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Domain-based Application Service Location Using URIs > and the Dynamic Delegation Discovery Service (DDDS) > Author(s) : L. Daigle > Filename : draft-daigle-unaptr-00.txt > Pages : 9 > Date : 2006-6-20 > > The purpose of this memo is to provide a small extension to the > "Straightforward NAPTR" (S-NAPTR) Dynamic Delegation Discovery System > (DDDS) Application so that URIs can be offered as the target of the > DDDS resolution. > > It is not yet clear (in this -00 draft) whether that is best > achievedby extending the S-NAPTR specification, or by providing a new > DDDS Application. This version of the draft focuses on describing > the extension and pros/cons of either approach. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-daigle-unaptr-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-daigle-unaptr-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-daigle-unaptr-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------=_NextPart_000_00FC_01C6990E.A2E53500 Content-Type: Message/External-body; name="ATT01201.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT01201.dat" Content-Type: text/plain Content-ID: <2006-6-20104950.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-daigle-unaptr-00.txt ------=_NextPart_000_00FC_01C6990E.A2E53500 Content-Type: Message/External-body; name="draft-daigle-unaptr-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-daigle-unaptr-00.txt" Content-Type: text/plain Content-ID: <2006-6-20104950.I-D@ietf.org> ------=_NextPart_000_00FC_01C6990E.A2E53500 Content-Type: text/plain; name="ATT01204.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT01204.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_00FC_01C6990E.A2E53500 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ------=_NextPart_000_00FC_01C6990E.A2E53500-- From enum-bounces@ietf.org Mon Jun 26 11:10:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FusjW-0005KF-VV; Mon, 26 Jun 2006 11:10:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FusjV-0005K7-9u for enum@ietf.org; Mon, 26 Jun 2006 11:10:37 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FusjU-0000uK-Qv for enum@ietf.org; Mon, 26 Jun 2006 11:10:37 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k5QFAxjS003604 for ; Mon, 26 Jun 2006 08:10:59 -0700 From: "Richard Shockey" To: Date: Mon, 26 Jun 2006 11:10:30 -0400 Message-ID: <010a01c69932$aa289a40$4d201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaZMqmRcgh9D1VASxKrN0fhE7GpOA== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Subject: [Enum] Preliminary ENUM aganda IETF Montreal X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is what I have so far. Please Comment ASAP REMINDER : People wanting to make presentations should send them to Alexander Mayrhofer [alexander.mayrhofer@enum.at] and the chairs so we can post them in the meeting manager. https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66 Agenda of the 66th IETF Meeting July 9-14, 2006 MONDAY, July 10, 2006 0800-1800 IETF Registration - Foyer 500D 0800-0900 Continental Breakfast - Foyer 500D 0900-1130 Morning Session I Room 520ABC RAI enum Telephone Number Mapping WG Status of Drafts in Queue? Title : ENUM Validation Architecture Author(s) : A. Mayrhofer, B. Hoeneisen Filename : draft-ietf-enum-validation-arch-03.txt Pages : 18 Date : 2006-6-22 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes validation requirements and a high level architecture for an ENUM validation infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-arch-03.txt ENUM PSTN ************************************ 10 M EDNS 0 issues in ENUM 5M Experiences Draft Final Final issues? 5M General Agreement to Go to Last Call on .... Title : IANA Registration for vCard Enumservice Author(s) : A. Mayrhofer Filename : draft-ietf-enum-vcard-02.txt Pages : 9 Date : 2006-6-13 This memo registers the Enumservice "vCard" with the subtypes "plain", "xml" and "rdf" using the URI schemes "http" and "https" according to the IANA Enumservice registration process described in RFC 3671. This Enumservice is to be used to refer from an ENUM domain name to a vCard instance describing the user of the respective E.164 number. Information gathered from those vCards could be used before, during or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-vcard-02.txt Title : A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services Author(s) : R. Mahy Filename : draft-ietf-enum-im-service-01.txt Pages : 5 Date : 2006-6-22 This document registers a Telephone Number Mapping (ENUM) service for Instant Messaging (IM). Specifically, this document focuses on provisioning 'im:' URIs in ENUM. http://www.ietf.org/internet-drafts/draft-ietf-enum-calendar-service-00.txt http://www.ietf.org/internet-drafts/draft-ietf-enum-cnam-02.txt *********************************** 10 M Title : IANA Registration for an Enumservice to Hint to E.164 esolution Namespaces (ERN) Author(s) : R. Stastny Filename : draft-stastny-enum-ern-00.txt Pages : 11 Date : 2006-6-5 This document registers the Enumservice type "ern" and subtype "http" using the URI scheme 'http', as well as the subtype "urn" using the URI scheme 'urn' as per the IANA registration process defined in the ENUM specification RFC 3761. This Enumservice is used to provide a hint in ENUM to an E.164 Resolution Namespace a service provider chooses to populate with E.164 numbers to be shared within a limited group of other service providers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stastny-enum-ern-00.txt 10M Title : Combined User and Infrastructure ENUM in the e164.arpa tree Author(s) : M. Haberler, R. Stastny Filename : draft-haberler-carrier-enum-03.txt Pages : 11 Date : 2006-6-23 This memo defines an interim solution for Infrastructure ENUM to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice until the long-term solution is approved. This interim solution will be deprecated after deployment of the long-term solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-03.txt 15 Min We should also consider how to proceed with draft-lendl-enum-branch-location-record-00 15Min Infrastructure ENUM root? Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Jun 26 11:11:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuskn-0005di-IJ; Mon, 26 Jun 2006 11:11:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuskm-0005dd-1V for enum@ietf.org; Mon, 26 Jun 2006 11:11:56 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuskk-0000xN-KV for enum@ietf.org; Mon, 26 Jun 2006 11:11:56 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k5QFCBK7003855 for ; Mon, 26 Jun 2006 08:12:11 -0700 From: "Richard Shockey" To: Date: Mon, 26 Jun 2006 11:11:41 -0400 Message-ID: <010b01c69932$d4b6c480$4d201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_010C_01C69911.4DA52480" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaUy7TYyn7rWT2GRTi7mXgwLgyO3AEZxjnw X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Subject: [Enum] FW: I-D ACTION:draft-mahy-speermint-direct-peering-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_010C_01C69911.4DA52480 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit FYI > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, June 20, 2006 6:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-mahy-speermint-direct-peering-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : A Minimalist Approach to Direct Peering > Author(s) : R. Mahy > Filename : draft-mahy-speermint-direct-peering-00.txt > Pages : 11 > Date : 2006-6-20 > > This document describes a concrete example of a peering convention > for domains and federations of domain which use SIP for > communications, especially in conjunction with E.164 addresses > (telephone numbers). The author hopes this example mechanism will > promote and facilitate discussion within the speermint working group. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mahy-speermint-direct-peering- > 00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-mahy-speermint-direct-peering-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-mahy-speermint-direct-peering-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------=_NextPart_000_010C_01C69911.4DA52480 Content-Type: Message/External-body; name="ATT01753.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT01753.dat" Content-Type: text/plain Content-ID: <2006-6-20155639.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mahy-speermint-direct-peering-00.txt ------=_NextPart_000_010C_01C69911.4DA52480 Content-Type: Message/External-body; name="draft-mahy-speermint-direct-peering-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-mahy-speermint-direct-peering-00.txt" Content-Type: text/plain Content-ID: <2006-6-20155639.I-D@ietf.org> ------=_NextPart_000_010C_01C69911.4DA52480 Content-Type: text/plain; name="ATT01756.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT01756.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_010C_01C69911.4DA52480 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ------=_NextPart_000_010C_01C69911.4DA52480-- From enum-bounces@ietf.org Tue Jun 27 02:21:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv6xC-00085T-Ue; Tue, 27 Jun 2006 02:21:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv6xC-00085N-8g for enum@ietf.org; Tue, 27 Jun 2006 02:21:42 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv6x7-0007Eg-Tl for enum@ietf.org; Tue, 27 Jun 2006 02:21:42 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 62E8B1A372; Tue, 27 Jun 2006 08:21:35 +0200 (CEST) Date: Tue, 27 Jun 2006 08:21:35 +0200 From: Otmar Lendl To: enum@ietf.org Subject: Re: [Enum] FW: I-D ACTION:draft-haberler-carrier-enum-03.txt Message-ID: <20060627062135.GA21965@nic.at> References: <00e801c6992c$ee9b8c60$4d201f0a@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00e801c6992c$ee9b8c60$4d201f0a@cis.neustar.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 2006/06/26 16:06, Richard Shockey wrote: > > > Title : Combined User and Infrastructure ENUM in the e164.arpa tree > > Author(s) : M. Haberler, R. Stastny > > Filename : draft-haberler-carrier-enum-03.txt > > Pages : 11 > > Date : 2006-6-23 > > > > This memo defines an interim solution for Infrastructure ENUM to > > allow a combined User and Infrastructure ENUM implementation in > > e164.arpa as a national choice until the long-term solution is > > approved. This interim solution will be deprecated after deployment > > of the long-term solution. The current version of the sister document which contains the specification of the EBL DNS RR has hit the archives as well: ==================== A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The ENUM Branch Location Record Author(s) : O. Lendl Filename : draft-lendl-enum-branch-location-record-02.txt Pages : 7 Date : 2006-6-26 This documents defines the ENUM Branch Location record which is used to indicate where the ENUM tree for special ENUM application is located. The primary application for the EBL is to enable a temporary solution for the infrastructure ENUM tree. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lendl-enum-branch-location-record-02.txt ==================== /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jun 27 02:24:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv6zs-0001wV-TB; Tue, 27 Jun 2006 02:24:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv6zs-0001wP-1C for enum@ietf.org; Tue, 27 Jun 2006 02:24:28 -0400 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv6zq-0007Tk-NA for enum@ietf.org; Tue, 27 Jun 2006 02:24:28 -0400 Received: from [192.168.1.206] (85-124-83-166.dynamic.xdsl-line.inode.at [::ffff:85.124.83.166]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Tue, 27 Jun 2006 08:24:24 +0200 id 0007C046.44A0CF18.00000CBA Message-ID: <44A0CF08.4080703@enum.at> Date: Tue, 27 Jun 2006 08:24:08 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: multipart/mixed; boundary="------------040408030400010205080909" X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Subject: [Enum] [Fwd: I-D ACTION:draft-lendl-enum-branch-location-record-02.txt] X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --------------040408030400010205080909 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI. --------------040408030400010205080909 Content-Type: message/rfc822; name*0="I-D ACTION:draft-lendl-enum-branch-location-record-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="I-D ACTION:draft-lendl-enum-branch-location-record-02.txt" Received: from megatron.ietf.org (odin.ietf.org [::ffff:156.154.16.145]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Tue, 27 Jun 2006 01:23:17 +0200 id 0007C049.44A06C65.00006184 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuzu9-0004Qf-J7; Mon, 26 Jun 2006 18:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuzu6-0004O8-83 for i-d-announce@ietf.org; Mon, 26 Jun 2006 18:50:02 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuzu5-0007eB-Qe for i-d-announce@ietf.org; Mon, 26 Jun 2006 18:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5QMo1WR010132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Jun 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fuzu5-0007z0-Hx for i-d-announce@ietf.org; Mon, 26 Jun 2006 18:50:01 -0400 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_pahula-24964-1151364197-0001-2" To: i-d-announce@ietf.org Cc: From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 26 Jun 2006 18:50:01 -0400 X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Subject: I-D ACTION:draft-lendl-enum-branch-location-record-02.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on pahula X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.3 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_pahula-24964-1151364197-0001-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The ENUM Branch Location Record Author(s) : O. Lendl Filename : draft-lendl-enum-branch-location-record-02.txt Pages : 7 Date : 2006-6-26 This documents defines the ENUM Branch Location record which is used to indicate where the ENUM tree for special ENUM application is located. The primary application for the EBL is to enable a temporary solution for the infrastructure ENUM tree. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lendl-enum-branch-location-record-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lendl-enum-branch-location-record-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lendl-enum-branch-location-record-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --=_pahula-24964-1151364197-0001-2 Content-Type: multipart/alternative; boundary="=_pahula-24964-1151364197-0001-3" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_pahula-24964-1151364197-0001-3 Content-Type: message/external-body; access-type=mail-server; server="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2006-6-26155151.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lendl-enum-branch-location-record-02.txt --=_pahula-24964-1151364197-0001-3 Content-Type: message/external-body; name="draft-lendl-enum-branch-location-record-02.txt"; site="ftp.ietf.org"; access-type=anon-ftp; directory=internet-drafts Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2006-6-26155151.I-D@ietf.org> --=_pahula-24964-1151364197-0001-3-- --=_pahula-24964-1151364197-0001-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --=_pahula-24964-1151364197-0001-2-- --------------040408030400010205080909 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------040408030400010205080909-- From enum-bounces@ietf.org Tue Jun 27 03:53:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv8NV-0008RZ-DA; Tue, 27 Jun 2006 03:52:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv8NT-0008RT-9L for enum@ietf.org; Tue, 27 Jun 2006 03:52:55 -0400 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv8NS-0005Ka-0F for enum@ietf.org; Tue, 27 Jun 2006 03:52:55 -0400 Received: from [10.10.0.107] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Tue, 27 Jun 2006 09:52:51 +0200 id 0007C04A.44A0E3D3.000019DB Message-ID: <44A0E3C2.1000509@enum.at> Date: Tue, 27 Jun 2006 09:52:34 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: richard@shockey.us, enum@ietf.org Subject: Re: [Enum] Preliminary ENUM aganda IETF Montreal References: <010a01c69932$aa289a40$4d201f0a@cis.neustar.com> In-Reply-To: <010a01c69932$aa289a40$4d201f0a@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Richard Shockey wrote: > Status of Drafts in Queue? I'll try to gather the status of all documents and post a report about the docs rsn, so that we can quickly go through this agenda item, and just decide about potential action items. Other stuff: I'd like to add a 5min slot for draft-ietf-enum-validation-token - this has been around for a long time, and is part of the "validation" group of drafts, from which the two others (draft-ietf-enum-validation-arch and draft-ietf-enum-validation-epp) are already in the IESG queue. And, we need a slot (15min, including discussions?) for the enumservices guide draft - we need to move this forward, because it would ease work on upcoming Enumservice registrations. cheers alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jun 27 04:56:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv9Mm-0006PD-Uf; Tue, 27 Jun 2006 04:56:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv9Ml-0006Kl-FR for enum@ietf.org; Tue, 27 Jun 2006 04:56:15 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv9Mk-0007YM-6g for enum@ietf.org; Tue, 27 Jun 2006 04:56:15 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id E414E1A372; Tue, 27 Jun 2006 10:56:12 +0200 (CEST) Date: Tue, 27 Jun 2006 10:56:12 +0200 From: Otmar Lendl To: enum@ietf.org Subject: Re: [Enum] FW: I-D ACTION:draft-haberler-carrier-enum-03.txt Message-ID: <20060627085612.GB21965@nic.at> References: <00e801c6992c$ee9b8c60$4d201f0a@cis.neustar.com> <20060627062135.GA21965@nic.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060627062135.GA21965@nic.at> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 2006/06/27 08:06, Otmar Lendl wrote: > > The current version of the sister document which contains the > specification of the EBL DNS RR has hit the archives as well: > Addendum: I still haven't ironed out all errors in the examples: infrastructure.9.4.e164.arpa. IN EBL 0 "" e164i.arpa. doesn't lead to +49 891234567 7.6.5.4.3.2.1.9.8.e164i.arpa but +49 891234567 7.6.5.4.3.2.1.9.8.9.4.e164i.arpa instead. Mea culpa. /ol (thanks to Rolf Schwander for spotting this) -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jun 27 10:40:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvEjS-0006o8-Og; Tue, 27 Jun 2006 10:40:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvEjS-0006jM-0a for enum@ietf.org; Tue, 27 Jun 2006 10:40:02 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvEj4-0002MX-82 for enum@ietf.org; Tue, 27 Jun 2006 10:39:40 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k5REdtUE022475; Tue, 27 Jun 2006 07:39:55 -0700 From: "Richard Shockey" To: "'Otmar Lendl'" , Subject: RE: [Enum] FW: I-D ACTION:draft-haberler-carrier-enum-03.txt Date: Tue, 27 Jun 2006 10:39:51 -0400 Message-ID: <002401c699f7$8c749420$4d201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20060627085612.GB21965@nic.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaZx57lY1oWwZNkRqqFEVIvX35zFQAL9bBQ X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I think we all agreed that the infrastructure apex would be ie164.arpa. > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Tuesday, June 27, 2006 4:56 AM > To: enum@ietf.org > Subject: Re: [Enum] FW: I-D ACTION:draft-haberler-carrier-enum-03.txt > > On 2006/06/27 08:06, Otmar Lendl wrote: > > > > The current version of the sister document which contains the > > specification of the EBL DNS RR has hit the archives as well: > > > > Addendum: > > I still haven't ironed out all errors in the examples: > > infrastructure.9.4.e164.arpa. IN EBL 0 "" e164i.arpa. > > doesn't lead to > > +49 891234567 7.6.5.4.3.2.1.9.8.e164i.arpa > > but > > +49 891234567 7.6.5.4.3.2.1.9.8.9.4.e164i.arpa > > instead. > > Mea culpa. > > /ol (thanks to Rolf Schwander for spotting this) > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > _______________________________________________ > 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 From enum-bounces@ietf.org Tue Jun 27 11:05:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvF84-0006YE-OF; Tue, 27 Jun 2006 11:05:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvF82-0006XW-SA for enum@ietf.org; Tue, 27 Jun 2006 11:05:26 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvF80-0004Lp-HQ for enum@ietf.org; Tue, 27 Jun 2006 11:05:26 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 570391A372; Tue, 27 Jun 2006 17:05:23 +0200 (CEST) Date: Tue, 27 Jun 2006 17:05:23 +0200 From: Otmar Lendl To: Richard Shockey Subject: Re: [Enum] FW: I-D ACTION:draft-haberler-carrier-enum-03.txt Message-ID: <20060627150522.GX2086@nic.at> References: <20060627085612.GB21965@nic.at> <002401c699f7$8c749420$4d201f0a@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002401c699f7$8c749420$4d201f0a@cis.neustar.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 2006/06/27 16:06, Richard Shockey wrote: > > I think we all agreed that the infrastructure apex would be ie164.arpa. > Mea culpa, I should have used "example.org". /ol > > -----Original Message----- > > From: Otmar Lendl [mailto:lendl@nic.at] > > Sent: Tuesday, June 27, 2006 4:56 AM > > To: enum@ietf.org > > Subject: Re: [Enum] FW: I-D ACTION:draft-haberler-carrier-enum-03.txt > > > > On 2006/06/27 08:06, Otmar Lendl wrote: > > > > > > The current version of the sister document which contains the > > > specification of the EBL DNS RR has hit the archives as well: > > > > > > > Addendum: > > > > I still haven't ironed out all errors in the examples: > > > > infrastructure.9.4.e164.arpa. IN EBL 0 "" e164i.arpa. > > > > doesn't lead to > > > > +49 891234567 7.6.5.4.3.2.1.9.8.e164i.arpa > > > > but > > > > +49 891234567 7.6.5.4.3.2.1.9.8.9.4.e164i.arpa > > > > instead. > > > > Mea culpa. > > > > /ol (thanks to Rolf Schwander for spotting this) > > -- > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Jun 27 11:23:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvFPK-00047C-So; Tue, 27 Jun 2006 11:23:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvFPJ-00044W-W0 for enum@ietf.org; Tue, 27 Jun 2006 11:23:17 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvFPI-0006EE-I6 for enum@ietf.org; Tue, 27 Jun 2006 11:23:17 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k5RFNKDp031443; Tue, 27 Jun 2006 08:23:21 -0700 From: "Richard Shockey" To: "'Alexander Mayrhofer'" , Subject: RE: [Enum] Preliminary ENUM aganda IETF Montreal Date: Tue, 27 Jun 2006 11:22:51 -0400 Message-ID: <003501c699fd$8ec07130$4d201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44A0E3C2.1000509@enum.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaZvsXrzpVcJFZhRieUYk6a5uYmOwAOMzlw X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] > Sent: Tuesday, June 27, 2006 3:53 AM > To: richard@shockey.us; enum@ietf.org > Subject: Re: [Enum] Preliminary ENUM aganda IETF Montreal > > Richard Shockey wrote: > > Status of Drafts in Queue? > > I'll try to gather the status of all documents and post a report about > the docs rsn, so that we can quickly go through this agenda item, and just > decide about potential action items. This IMHO is a good idea. We'll start off the meeting with your report. > > Other stuff: > > I'd like to add a 5min slot for > draft-ietf-enum-validation-token - this has been around for a long time, > and > is part of the "validation" group of drafts, from which the two others > (draft-ietf-enum-validation-arch and draft-ietf-enum-validation-epp) are > already in the IESG queue. IMHO there is nothing more to discuss here. The Validation Token draft should simply go to WGLC along with the rest of the ones I've outlined. > > And, we need a slot (15min, including discussions?) for the enumservices > guide draft - we need to move this forward, because it would ease work on > upcoming Enumservice registrations. Yes of course and what do we do with the existing registrations and the drafts that we'd like to go to WGLC on ASAP. > > cheers > > alex > > > _______________________________________________ > 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 From enum-bounces@ietf.org Tue Jun 27 18:50:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvMNl-0006lM-Tr; Tue, 27 Jun 2006 18:50:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvMNf-0006ke-SP; Tue, 27 Jun 2006 18:50:03 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvMNe-0005A7-Ku; Tue, 27 Jun 2006 18:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5RMo19F020788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvMNd-0005rq-NX; Tue, 27 Jun 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Jun 2006 18:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-enumservices-guide-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : Guide and Template for IANA Registrations of Enumervices Author(s) : J. Livingood, et al. Filename : draft-ietf-enum-enumservices-guide-01.txt Pages : 15 Date : 2006-6-27 This document provides a guide to and template for the creation of new IANA registration of ENUM services. It is also to be used for updates of existing IANA registrations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-enumservices-guide-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-enumservices-guide-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-27154647.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-enumservices-guide-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-enumservices-guide-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27154647.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Wed Jun 28 10:10:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvakc-0004a0-IT; Wed, 28 Jun 2006 10:10:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvaka-0004QD-6U for enum@ietf.org; Wed, 28 Jun 2006 10:10:40 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvaiy-0003UX-Qy for enum@ietf.org; Wed, 28 Jun 2006 10:09:02 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 047511A37F; Wed, 28 Jun 2006 16:08:58 +0200 (CEST) Date: Wed, 28 Jun 2006 16:08:58 +0200 From: Otmar Lendl To: enum@ietf.org, "Hollenbeck, Scott" Message-ID: <20060628140858.GA6897@nic.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [Enum] Erratum in RFC 4114: vs. X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org FYI, The XML element name for the NAPTR "Replacement" field is not consistent throughout the document. The text describes the element name (in 3.1.2., 3.2.1., and 3.2.5.) always as - An OPTIONAL element that contains a NAPTR replacement value. The XML schema contains the following definition: There is thus a conflict whether or is the correct element name. The examples in the RFC do not use this optional element. --- Before I send this to the RFC errata page: What is more normative? The text or the schema? The Austrian Infrastructure ENUM Registry has used the schema as basis for the implementation. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Jun 28 10:52:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvbOu-0006gb-0M; Wed, 28 Jun 2006 10:52:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvbOt-0006fc-3Q for enum@ietf.org; Wed, 28 Jun 2006 10:52:19 -0400 Received: from peregrine.verisign.com ([216.168.239.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvbOr-0007zo-RV for enum@ietf.org; Wed, 28 Jun 2006 10:52:19 -0400 Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id k5SErni0002504; Wed, 28 Jun 2006 10:53:49 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 10:52:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Jun 2006 10:52:23 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07015E4089@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Erratum in RFC 4114: vs. Thread-Index: AcaavGUdGEzvKCs+RIC8ITL/ByHVmQABev6g From: "Hollenbeck, Scott" To: "Otmar Lendl" , X-OriginalArrivalTime: 28 Jun 2006 14:52:17.0316 (UTC) FILETIME=[732ADE40:01C69AC2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Subject: [Enum] RE: Erratum in RFC 4114: vs. X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Otmar, The schema is what counts. The text will need to be corrected at an opportune time. -Scott- > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at]=20 > Sent: Wednesday, June 28, 2006 10:09 AM > To: enum@ietf.org; Hollenbeck, Scott > Subject: Erratum in RFC 4114: vs. >=20 >=20 > FYI, >=20 > The XML element name for the NAPTR "Replacement" field is not > consistent throughout the document. The text describes > the element name (in 3.1.2., 3.2.1., and 3.2.5.) always as=20 >=20 > - An OPTIONAL element that contains a NAPTR > replacement value. >=20 > The XML schema contains the following definition: >=20 > > > > > minOccurs=3D"0"/> > > minOccurs=3D"0"/> > minOccurs=3D"0"/> > > >=20 > There is thus a conflict whether or > is the correct element name. >=20 > The examples in the RFC do not use this optional element. >=20 > --- >=20 > Before I send this to the RFC errata page: What is more > normative? The text or the schema?=20 >=20 > The Austrian Infrastructure ENUM Registry has used the > schema as basis for the implementation. >=20 > /ol > --=20 > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jun 29 15:51:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw2Xg-0007Al-29; Thu, 29 Jun 2006 15:51:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw2WZ-0004kd-PU; Thu, 29 Jun 2006 15:50:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw2WY-0001YD-BS; Thu, 29 Jun 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5TJo1UA025374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fw2WX-0003Rg-LW; Thu, 29 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 29 Jun 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-experiences-05.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-05.txt Pages : 36 Date : 2006-6-29 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is advisory, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-experiences-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-experiences-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-29103634.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-experiences-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-experiences-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-29103634.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Thu Jun 29 16:37:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw3GT-0005g9-DR; Thu, 29 Jun 2006 16:37:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw3GS-0005fz-1V for enum@ietf.org; Thu, 29 Jun 2006 16:37:28 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw3GQ-0007ME-Jg for enum@ietf.org; Thu, 29 Jun 2006 16:37:28 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k5TKbVKT024781 for ; Thu, 29 Jun 2006 13:37:32 -0700 From: "Richard Shockey" To: Date: Thu, 29 Jun 2006 16:37:02 -0400 Message-ID: <015d01c69bbb$c71d8cb0$4d201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_015E_01C69B9A.400BECB0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcabttEIzovmBfyqRfet1dEZXu1bugABO4Ig X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Subject: [Enum] FW: I-D ACTION:draft-conroy-enum-edns0-02.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_015E_01C69B9A.400BECB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Thursday, June 29, 2006 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-conroy-enum-edns0-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : ENUM Requirement for EDNS0 Support > Author(s) : L. Conroy, J. Reid > Filename : draft-conroy-enum-edns0-02.txt > Pages : 16 > Date : 2006-6-29 > > Support for EDNS0 (Extension Mechanisms for DNS) is mandated in this > document for DNS entities querying for or serving NAPTR records. In > general those entities will be supporting ENUM resolution. This > requirement is needed because DNS responses to ENUM-related queries > generally return large RRSets. Without EDNS0 support these lookups > would result in truncated responses and repeated queries over TCP > transport. That has a severe impact on DNS server load and on the > latency of those queries. > > This document updates RFC3761 only in adding this requirement. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-conroy-enum-edns0-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-conroy-enum-edns0-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-conroy-enum-edns0-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------=_NextPart_000_015E_01C69B9A.400BECB0 Content-Type: Message/External-body; name="ATT00226.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00226.dat" Content-Type: text/plain Content-ID: <2006-6-29141010.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-conroy-enum-edns0-02.txt ------=_NextPart_000_015E_01C69B9A.400BECB0 Content-Type: Message/External-body; name="draft-conroy-enum-edns0-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-conroy-enum-edns0-02.txt" Content-Type: text/plain Content-ID: <2006-6-29141010.I-D@ietf.org> ------=_NextPart_000_015E_01C69B9A.400BECB0 Content-Type: text/plain; name="ATT00229.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00229.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_015E_01C69B9A.400BECB0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ------=_NextPart_000_015E_01C69B9A.400BECB0-- From enum-bounces@ietf.org Thu Jun 29 16:41:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw3Js-0006Zd-89; Thu, 29 Jun 2006 16:41:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw3Jq-0006Yo-Oq for enum@ietf.org; Thu, 29 Jun 2006 16:40:58 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw3Jq-0000Ub-63 for enum@ietf.org; Thu, 29 Jun 2006 16:40:58 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k5TKf76e026221 for ; Thu, 29 Jun 2006 13:41:07 -0700 From: "Richard Shockey" To: Date: Thu, 29 Jun 2006 16:40:37 -0400 Message-ID: <016c01c69bbc$47418130$4d201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcabvEawyggBh7zaSlWCNApQ7W+/fQ== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Subject: [Enum] ENUM WG Agenda IETF Montreal V02 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Agenda of the 66th IETF Meeting July 9-14, 2006 IETF 66 Telephone Number Mapping (ENUM) WG Agenda Preliminary V2 Chair(s): Patrik Faltstrom Richard Shockey WG Secretary: Alexander Mayrhofer RAI Director(s): Jon Peterson jon.peterson@neustar.biz Cullen Jennings fluffy@cisco.com RAI Area Advisor: Jon Peterson MONDAY, July 10, 2006 0800-1800 IETF Registration - Foyer 500D 0800-0900 Continental Breakfast - Foyer 500D 0900-1130 Morning Session I Room 520ABC RAI enum Telephone Number Mapping WG ********************************** Review of Agenda Status of Drafts and in Drafts the Queue Overview - Alexander Mayhofer WG Secretary ENUM Validation Architecture ENUM PSTN ENUM VOID Etal. ************************************ 10 M Title : ENUM Requirement for EDNS0 Support Author(s) : L. Conroy, J. Reid Filename : draft-conroy-enum-edns0-02.txt Pages : 16 Date : 2006-6-29 Support for EDNS0 (Extension Mechanisms for DNS) is mandated in this document for DNS entities querying for or serving NAPTR records. In general those entities will be supporting ENUM resolution. This requirement is needed because DNS responses to ENUM-related queries generally return large RRSets. Without EDNS0 support these lookups would result in truncated responses and repeated queries over TCP transport. That has a severe impact on DNS server load and on the latency of those queries. This document updates RFC3761 only in adding this requirement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-conroy-enum-edns0-02.txt 5M Experiences Draft Final Final issues? Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-05.txt Pages : 36 Date : 2006-6-29 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is advisory, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-05.txt ************************************* 10M General Agreement to Go to Last Call on .... Title : IANA Registration for vCard Enumservice Author(s) : A. Mayrhofer Filename : draft-ietf-enum-vcard-02.txt Pages : 9 Date : 2006-6-13 This memo registers the Enumservice "vCard" with the subtypes "plain", "xml" and "rdf" using the URI schemes "http" and "https" according to the IANA Enumservice registration process described in RFC 3671. This Enumservice is to be used to refer from an ENUM domain name to a vCard instance describing the user of the respective E.164 number. Information gathered from those vCards could be used before, during or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-vcard-02.txt Title : A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services Author(s) : R. Mahy Filename : draft-ietf-enum-im-service-01.txt Pages : 5 Date : 2006-6-22 This document registers a Telephone Number Mapping (ENUM) service for Instant Messaging (IM). Specifically, this document focuses on provisioning 'im:' URIs in ENUM. http://www.ietf.org/internet-drafts/draft-ietf-enum-calendar-service-01.txt Title : ENUM Validation Token Format Definition Author(s) : O. Lendl Filename : draft-ietf-enum-validation-token-01.txt Pages : 16 Date : 2006-2-13 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes an signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-token-01.txt http://www.ietf.org/internet-drafts/draft-ietf-enum-cnam-0?.txt When submitted ****************************************************************** 10 Min Title : Guide and Template for IANA Registrations of Enumervices Author(s) : J. Livingood, et al. Filename : draft-ietf-enum-enumservices-guide-01.txt Pages : 15 Date : 2006-6-27 This document provides a guide to and template for the creation of new IANA registration of ENUM services. It is also to be used for updates of existing IANA registrations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-01.tx t ******************************************************************** New Business 10 Min Title : IANA Registration for an Enumservice to Hint to E.164 Resolution Namespaces (ERN) Author(s) : R. Stastny Filename : draft-stastny-enum-ern-00.txt Pages : 11 Date : 2006-6-5 This document registers the Enumservice type "ern" and subtype "http" using the URI scheme 'http', as well as the subtype "urn" using the URI scheme 'urn' as per the IANA registration process defined in the ENUM specification RFC 3761. This Enumservice is used to provide a hint in ENUM to an E.164 Resolution Namespace a service provider chooses to populate with E.164 numbers to be shared within a limited group of other service providers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stastny-enum-ern-00.txt Old Business. 10M Title : Combined User and Infrastructure ENUM in the e164.arpa tree Author(s) : M. Haberler, R. Stastny Filename : draft-haberler-carrier-enum-03.txt Pages : 11 Date : 2006-6-23 This memo defines an interim solution for Infrastructure ENUM to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice until the long-term solution is approved. This interim solution will be deprecated after deployment of the long-term solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-03.txt 15 Min Title : The ENUM Branch Location Record Author(s) : O. Lendl Filename : draft-lendl-enum-branch-location-record-02.txt Pages : 7 Date : 2006-6-26 This documents defines the ENUM Branch Location record which is used to indicate where the ENUM tree for special ENUM application is located. The primary application for the EBL is to enable a temporary solution for the infrastructure ENUM tree. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lendl-enum-branch-location-record- 02.txt 15Min Infrastructure ENUM root? http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-00.txt Open Session .. ********************************************************************** Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Jun 29 17:46:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw4Ko-0005y7-EI; Thu, 29 Jun 2006 17:46:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw4Km-0005vq-9r for enum@ietf.org; Thu, 29 Jun 2006 17:46:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw3Ee-0007CF-HD for enum@ietf.org; Thu, 29 Jun 2006 16:35:36 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fw3EQ-0004nu-7f for enum@ietf.org; Thu, 29 Jun 2006 16:35:24 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k5TKZbp6024575 for ; Thu, 29 Jun 2006 13:35:37 -0700 From: "Richard Shockey" To: Date: Thu, 29 Jun 2006 16:35:07 -0400 Message-ID: <015901c69bbb$83059a90$4d201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_015A_01C69B99.FBF58130" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acabt1ofA+9+4PMHT9afx8axlJw4ugABB7ng X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: -0.9 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Subject: [Enum] FW: I-D ACTION:draft-ietf-iptel-tel-enumdi-05.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_015A_01C69B99.FBF58130 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit FYI > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Thursday, June 29, 2006 3:50 PM > To: i-d-announce@ietf.org > Cc: iptel@ietf.org > Subject: I-D ACTION:draft-ietf-iptel-tel-enumdi-05.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Telephony Working Group of the IETF. > > Title : The ENUM Dip Indicator parameter for the "tel" URI > Author(s) : R. Stastny, et al. > Filename : draft-ietf-iptel-tel-enumdi-05.txt > Pages : 9 > Date : 2006-6-29 > > This document defines a new parameter "enumdi" for the "tel" Uniform > Resource Identifier (URI) to support the handling of ENUM queries in > VoIP (Voice over Internet Protocol) network elements. A VoIP network > element may receive an URI containing an E.164 number, where that URI > contains an "enumdi" parameter. The presence of the "enumdi" > parameter indicates that an ENUM query has already been performed on > the E.164 number by a previous VoIP network element. Equally, if a > VoIP network element sends such an URI, it asserts that an ENUM query > has been carried out on this number. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-enumdi-05.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-iptel-tel-enumdi-05.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-iptel-tel-enumdi-05.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------=_NextPart_000_015A_01C69B99.FBF58130 Content-Type: Message/External-body; name="ATT00280.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00280.dat" Content-Type: text/plain Content-ID: <2006-6-29121001.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-tel-enumdi-05.txt ------=_NextPart_000_015A_01C69B99.FBF58130 Content-Type: Message/External-body; name="draft-ietf-iptel-tel-enumdi-05.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-iptel-tel-enumdi-05.txt" Content-Type: text/plain Content-ID: <2006-6-29121001.I-D@ietf.org> ------=_NextPart_000_015A_01C69B99.FBF58130 Content-Type: text/plain; name="ATT00283.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00283.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_015A_01C69B99.FBF58130 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ------=_NextPart_000_015A_01C69B99.FBF58130-- From enum-bounces@ietf.org Fri Jun 30 08:28:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwI6Y-0003MU-5t; Fri, 30 Jun 2006 08:28:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwI6X-0003MP-DL for enum@ietf.org; Fri, 30 Jun 2006 08:28:13 -0400 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwI6V-0008R1-VH for enum@ietf.org; Fri, 30 Jun 2006 08:28:13 -0400 Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Fri, 30 Jun 2006 14:23:07 +0200 id 0007C027.44A517AC.000045E6 Message-ID: <44A51799.7010308@enum.at> Date: Fri, 30 Jun 2006 14:22:49 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_pahula-17894-1151670188-0001-2" To: "'enum@ietf.org'" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Subject: [Enum] document inventory & status X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_pahula-17894-1151670188-0001-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hi, please find a short ENUM document status inventory attached, including those docs for which we have already requested publication. enjoy. Alex --=_pahula-17894-1151670188-0001-2 Content-Type: text/plain; name="doc-status-enum66.txt"; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="doc-status-enum66.txt" Published since IETF65 ====================== - no publications WG items in publication process =============================== - draft-ietf-enum-void: IESG Evaluation :: Revised ID Needed One remaining "discuss"-Position, to be clarified between Authors / ADs. - draft-ietf-enum-pstn: IESG Evaluation :: AD Followup Two "discuss" positions, comments from Gen-ART plus on IANA section. Small id-nits. - draft-ietf-enum-validation-arch: AD Evaluation :: AD Followup New version addresses comment from initial AD Evaluation. - draft-ietf-enum-validation-epp: AD Evaluation recently added, no comments yet. - draft-ietf-enum-infrastructure-reqs: AD Evaluation added after Dallas, no comments yet. Other WG items ============== - draft-ietf-enum-calendar-services: new version addresses ID-NITS from initial version. - draft-ietf-enum-cnam: -02 will show up in archives after IETF66 - draft-ietf-enum-enumservices-guide: new version, work in progress. comments appreciated. - draft-ietf-enum-experiences: update addresses comments from group, DNS stuff split out into draft-conroy-enum-edns0. - draft-ietf-enum-iax: no new version - waiting for "iax2" URI scheme? - draft-ietf-enum-im-services: new version addresses comments from NITS-review - draft-ietf-enum-infrastructure: first version of infrastructure ENUM according to "Dallas Treaty" - draft-ietf-enum-validation-token: no new version - ready for last call? - draft-ietf-enum-vcard: new version extending security considerations and addressing comments. Related non-WG items (and items in other WGs) ============================================= - draft-haberler-carrier-enum: new revision of interim infrastructure ENUM according to "Dallas Treaty" - draft-lendl-enum-branch-location-record: new document for interim infrastructure ENUM - draft-stastny-enum-ern: new Enumservice for indicating resolution context for E.164 numbers - draft-conroy-enum-edns0: mandates EDNS0 support from entities involved in ENUM resolution. "spinoff" of experiences draft. - draft-reichinger-enum-foaf: no update - draft-mayrhofer-enum-domainkeys: no update - draft-ietf-iptel-tel-enumdi: in publication process (IESG Evaluation :: AD Followup). ENUM dip indicator for the tel:-URI. New version addresses comments from IESG review. --=_pahula-17894-1151670188-0001-2 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --=_pahula-17894-1151670188-0001-2--