From enum-bounces@ietf.org Tue Nov 01 09:15:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWwv9-0006Gi-NN; Tue, 01 Nov 2005 09:15:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWwv7-0006GJ-Vs for enum@megatron.ietf.org; Tue, 01 Nov 2005 09:15:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23009 for ; Tue, 1 Nov 2005 09:15:06 -0500 (EST) Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWx9U-0007FN-Tp for enum@ietf.org; Tue, 01 Nov 2005 09:30:19 -0500 Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id jA1EWnun004788; Tue, 1 Nov 2005 09:32:49 -0500 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Nov 2005 09:15:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] There are preliinary plans for another ENUM Summit in the US. Date: Tue, 1 Nov 2005 09:15:05 -0500 Message-ID: Thread-Topic: [Enum] There are preliinary plans for another ENUM Summit in the US. Thread-Index: AcXeagcMbOSJJCyOQLqfXoRRTNlwcAAhFV9g From: "Cartwright, Kenneth" To: "Richard Shockey" , , "Kerri Hughes" X-OriginalArrivalTime: 01 Nov 2005 14:15:06.0500 (UTC) FILETIME=[A8C51C40:01C5DEEE] X-Spam-Score: 0.8 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org For those of us not involved in the previous summit can you provide a link discussing the purpose of the summit? Thank You -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Monday, October 31, 2005 5:23 PM To: 'enum@ietf.org'; Kerri Hughes Subject: [Enum] There are preliinary plans for another ENUM Summit in the US. Many of you know there was a "ENUM Summit" Conference earlier this year=20 in Miami that was rather successful. The Conference organizers have=20 contacted me again to indicate they are planning on the 2nd Annual ENUM=20 Summit with yours truly once again as Conference Chair. Timing as of this date looks like early to mid April so no conflicts=20 with IETF or VON. Venue TBD but I'm pressing for either JFK/LGA, ORD, SFO or possibly BOS. Folks interested in the conference or have speaking proposals should=20 contact. Kerri Hughes IQPC (International Quality & Productivity Center) 535 5th Ave, 8th Floor New York, NY 10017 P: 212-885-2760 * F: 212-885-2762 kerri.hughes@iqpc.com www.iqpc.com --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ 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 Nov 01 18:14:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX5L9-0006yw-M5; Tue, 01 Nov 2005 18:14:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX5L8-0006xO-Hu for enum@megatron.ietf.org; Tue, 01 Nov 2005 18:14:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23121 for ; Tue, 1 Nov 2005 18:14:29 -0500 (EST) Received: from pne-smtpout1-sn1.fre.skanova.net ([81.228.11.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX5Zb-0008L1-8Q for enum@ietf.org; Tue, 01 Nov 2005 18:29:47 -0500 Received: from MISAN (213.64.230.47) by pne-smtpout1-sn1.fre.skanova.net (7.2.060.1) id 436614220007E6EF for enum@ietf.org; Wed, 2 Nov 2005 00:14:39 +0100 From: "Gunnar Hellstrom" To: Date: Wed, 2 Nov 2005 00:14:33 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.5 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Subject: [Enum] Comment on draft-ietf-enum-voice-01.txt about calls needing text capability 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="===============1452461681==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============1452461681== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0FEF_01C5DF42.6698E960" This is a multi-part message in MIME format. ------=_NextPart_000_0FEF_01C5DF42.6698E960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: Quoted-Printable I have a question related to draft-ietf-enum-voice-01.txt ( http://www.ietf.org/internet-drafts/draft-ietf-enum-voice-01.txt ) In PSTN, we have a service called text telephony. You can use real time t= ext and voice alternating if you use text telephony. You can also on the same number use text in some calls and voice in others. You usually combine a terminal by a telephone and a text telephone. The text telephone makes us= e of some modem transmission for the text, but is made silent when there is= a wish to talk instead. On the IP side you may have real time transmission of text and voice simultaneously in a terminal including a voice codec and a text codec. Te= xt is text coded and packetized. ( RFC 4103 is the currently only defined transport for real time text with IP terminals ). It is also popular to combine with video. Now, too many gateways have been deployed without support for translating between PSTN text and IP text. So, for calling between these environments= , you need a way to route the call to the right gateway, with text capabili= ty. But note, it shall only have text capability. In most cases it should sta= rt silent, just monitoring the two sides for text activity, and then activat= e text functionality towards PSTN. Sadly, PSTN users have the habit to bring their text telephones and plug them into the telephone connection without setting up any NAPTR records f= or an occasional visit. So, I have some urgent questions if enum can contrib= ute to finding the right gateway supported path for the calls that might cont= ain text. When reading draft-ietf-enum-voice-01.txt , I get the impression that we would need something similar for the "text and voice" service. For now, l= et us call it the "rtext" enumservice. ( or do you want to se it called "votex"? ). I have prepared a draft, based on one of the other enumservic= e registration documents, and am prepared to submit it if you find it motivated. But first some questions: 1. Do you find it feasible to register an enumservice "rtext" for real ti= me text possibly combined with voice in the same call? 2. Will the "voice" enumservice imply something for the possibility to us= e other media in the same call? Regards -------------------------------------------------------------------------= --- - Gunnar Hellstr=F6m, Omnitor gunnar.hellstrom@omnitor.se Mob: +46 708 204 288 Phone: +46 8 556 002 03 www.omnitor.se ------=_NextPart_000_0FEF_01C5DF42.6698E960 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: Quoted-Printable

I have a = question=20 related to draft-ietf-enum-voice-01.txt  

(=20 http://www.ietf.org/internet-drafts/draft-ietf-enum-voice-0= 1.txt  = )

In PSTN,=20 we have a service called text telephony. You can use real time text and = voice=20 alternating if you use text telephony. You can also on the same number = use text=20 in some calls and voice in others. You usually combine a terminal by a = telephone=20 and a text telephone. The text telephone makes use of some modem=20 transmission for the text, but is made silent when there is a = wish to=20 talk instead. 

On the=20 IP side you may have real time transmission of text and voice=20 simultaneously in a terminal including a voice codec and a text = codec. Text=20 is text coded and packetized. ( RFC 4103 is the currently only defined = transport=20 for real time text with IP terminals ). It=20 is also popular to combine with video.

Now, too=20 many gateways have been deployed without support for translating between = PSTN=20 text and IP text. So, for calling between these environments, you need a = way to=20 route the call to the right gateway, with text capability. But note, it = shall=20 only have text capability. In most cases it should start silent, just = monitoring=20 the two sides for text activity, and then activate text functionality = towards=20 PSTN.

Sadly, PSTN users have the habit to bring their = text=20 telephones and plug them into the telephone connection without setting = up any=20 NAPTR records for an occasional visit. So, I have some urgent questions = if enum=20 can contribute to finding the right gateway supported path for the = calls=20 that might contain text. 

When=20 reading draft-ietf-enum-voice-01.txt , I get the impression that = we would=20 need something similar for the "text and voice" service. For now, let us = call it=20 the "rtext" enumservice. ( or do you want to se it called "votex"? ). I = have=20 prepared a draft, based on one of the other enumservice registration = documents,=20 and am prepared to submit it if you find it motivated.

But=20 first some questions:

1. Do=20 you find it feasible to register an enumservice "rtext" for real time = text=20 possibly combined with voice in the same call?

2. Will=20 the "voice" enumservice imply something for the possibility to use other = media=20 in the same call?

 

Regards

----------------------------------------------------------------= -------------
Gunnar Hellstr=F6m, = Omnitor
gunnar.hellstrom@omnitor.se
Mob: +46 708 204 288
Phone: +46 8 556 002 03
www.omnitor.se
 
------=_NextPart_000_0FEF_01C5DF42.6698E960-- --===============1452461681== 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 --===============1452461681==-- From enum-bounces@ietf.org Tue Nov 01 19:35:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX6bG-0008BS-5v; Tue, 01 Nov 2005 19:35:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX6bD-0008A3-Vu for enum@megatron.ietf.org; Tue, 01 Nov 2005 19:35:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26725 for ; Tue, 1 Nov 2005 19:35:10 -0500 (EST) Received: from 213-152-49-123.dsl.eclipse.net.uk ([213.152.49.123] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX6ph-0002YS-P4 for enum@ietf.org; Tue, 01 Nov 2005 19:50:30 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 268347377C; Wed, 2 Nov 2005 00:34:55 +0000 (GMT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) X-Priority: 3 (Normal) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: lconroy Subject: Re: [Enum] Comment on draft-ietf-enum-voice-01.txt about calls needing text capability Date: Wed, 2 Nov 2005 00:34:54 +0000 To: Gunnar Hellstrom X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Content-Transfer-Encoding: quoted-printable 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Gunnar, folks, Background: Almost all of these PSTN Enumservices are tricky. They don't define a means to make the connection, as that could be =20 direct or indirect. They don't care how the ENUM Client's terminal does it - the =20 Enumservice spec just tells him or her what to expect if this contact is used (i.e. it's =20 something like a teleservice identifier tagged along with a tel: URI) So... If a NAPTR has voice:tel as its Enumservice (with a tel: URI in =20= the REGEXP field) then this says that a voice call cal be made to this telephone =20= number. If a NAPTR has an sms:tel Enumservice, then it says that the =20 destination reached by this telephone number can handle SMS messages. Most mobile phones can do both, so it is perfectly valid to have a =20 single NAPTR with both Enumservices in it - something like: $ORIGIN 0.0.0.0.6.9.4.1.4.1.4.4.e164.arpa. . IN NAPTR 100 10 "u" "E2U+voice:tel+sms:tel" "!^.*$!tel:=20 +447700900000!" . In effect, this compound NAPTR says that you can make a voice call or =20= send an SMS to this number. Now... if you are suggesting that the ugly audio+text abominations =20 that still exist do multiplexed voice AND text at the same time, then this seems =20= to me to be a different teleservice from "pure" voice. If this is true, then I'd suggest that it needs a different =20 Enumservice specification - the recipient of the NAPTR will not expect to be able to plug in an =20= old-style text phone if they see E2U+voice:tel. However, if this telephone number =20 also handles normal voice calls as well (as I guess it will), then showing both =20 Enumservices in a single NAPTR would be perfectly valid. Hence an appropriate example would be: $ORIGIN 1.0.0.0.9.6.4.7.0.2.4.4.e164.arpa. . IN NAPTR 100 10 "u" "E2U+voice:tel+vortex:tel" "!^.*$!tel:=20 +442079460001!" . Quick question: If there are broken old gateways that can't handle conversion from =20 old-style PSTN text phone signals to 4103 style IP real time text, then how =20 does one use these boxes to bridge between a conversational text device on the =20= Internet to some text phone connected to the PSTN? PSTN->IP looks like a nightmare, whilst IP->PSTN is still a =20 challenge, if the gateway doesn't do conversion to and from 4103. In that case, I would have thought it was easier to have a PC with a =20 4103-capable program running rather than use a PSTN-connected text phone - just =20 use the Internet and forget the old gateways and the PSTN altogether. What am =20= I missing? ---- Of course, if you were doing something sensible like using 4103, then =20= be aware that you are vanishingly unlikely to get an Enumservice approved that =20= indicates that your SIP AoR is associated with a permanently registered device =20 that can handle 4103-style text conversations. To do so would be wrong, and =20 such heresy will not be anointed with an RFC. It's a funny world, isn't it. all the best and good luck, Lawrence On 1 Nov 2005, at 23:14, Gunnar Hellstrom wrote: > I have a question related to draft-ietf-enum-voice-01.txt > > ( http://www.ietf.org/internet-drafts/draft-ietf-enum-voice-01.txt ) > > In PSTN, we have a service called text telephony. You can use real =20 > time text > and voice alternating if you use text telephony. You can also on =20 > the same > number use text in some calls and voice in others. You usually =20 > combine a > terminal by a telephone and a text telephone. The text telephone =20 > makes use > of some modem transmission for the text, but is made silent when =20 > there is a > wish to talk instead. > > On the IP side you may have real time transmission of text and voice > simultaneously in a terminal including a voice codec and a text =20 > codec. Text > is text coded and packetized. ( RFC 4103 is the currently only defined > transport for real time text with IP terminals ). It is also =20 > popular to > combine with video. > > Now, too many gateways have been deployed without support for =20 > translating > between PSTN text and IP text. So, for calling between these =20 > environments, > you need a way to route the call to the right gateway, with text =20 > capability. > But note, it shall only have text capability. In most cases it =20 > should start > silent, just monitoring the two sides for text activity, and then =20 > activate > text functionality towards PSTN. > > Sadly, PSTN users have the habit to bring their text telephones and =20= > plug > them into the telephone connection without setting up any NAPTR =20 > records for > an occasional visit. So, I have some urgent questions if enum can =20 > contribute > to finding the right gateway supported path for the calls that =20 > might contain > text. > > When reading draft-ietf-enum-voice-01.txt , I get the impression =20 > that we > would need something similar for the "text and voice" service. For =20 > now, let > us call it the "rtext" enumservice. ( or do you want to se it called > "votex"? ). I have prepared a draft, based on one of the other =20 > enumservice > registration documents, and am prepared to submit it if you find it > motivated. > > But first some questions: > > 1. Do you find it feasible to register an enumservice "rtext" for =20 > real time > text possibly combined with voice in the same call? > > 2. Will the "voice" enumservice imply something for the possibility =20= > to use > other media in the same call? > > > > Regards > > ----------------------------------------------------------------------=20= > ------ > - > Gunnar Hellstr=F6m, Omnitor > gunnar.hellstrom@omnitor.se > Mob: +46 708 204 288 > Phone: +46 8 556 002 03 > www.omnitor.se > _______________________________________________ > 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 Nov 02 02:38:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXDCY-0005mK-IT; Wed, 02 Nov 2005 02:38:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXDCW-0005kf-SN for enum@megatron.ietf.org; Wed, 02 Nov 2005 02:38:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17563 for ; Wed, 2 Nov 2005 02:38:06 -0500 (EST) Received: from pne-smtpout1-sn1.fre.skanova.net ([81.228.11.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXDR4-0003Iz-6Y for enum@ietf.org; Wed, 02 Nov 2005 02:53:31 -0500 Received: from MISAN (213.64.230.47) by pne-smtpout1-sn1.fre.skanova.net (7.2.060.1) id 43661422000898FA; Wed, 2 Nov 2005 08:38:10 +0100 From: "Gunnar Hellstrom" To: "lconroy" Subject: RE: [Enum] Comment on draft-ietf-enum-voice-01.txt about calls needing text capability Date: Wed, 2 Nov 2005 08:37:34 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Transfer-Encoding: Quoted-Printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Content-Transfer-Encoding: Quoted-Printable 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Lawrence and all, Thanks for good explanations, hints and leads to further discussions. And thanks for the name proposal "vortex" for the combined voice and text service ;- We have a pile of situations to solve in order to guide calls between PST= N text telephones and text capable IP terminals. Proper use of enum seems t= o be one good piece in the puzzle. We also have a need for smart invocation of translation services where en= um also could play a role. The need --------- Humans need to communicate in conversational mode with at least voice, te= xt and video. They should not need to bother much about what kind of network the other party is connected to. But the tools and transmission technolog= y varies between the networks. For voice there is reasonable coverage in interoperable networks. But for the text medium, the development has not been that forceful. We have RFC 4103 that is used to carry text in IP calls, and you can do it in a full multimedia fashion, with simultaneous voice and text. But there are too f= ew gateways between PSTN calls containing text and IP calls with text. So, one need is to have a means to route calls PSTN -> IP and IP -> PSTN through the right kind of text enabled gateway. The gateway may very wel= l also be able to handle pure voice. It may also be a series connection of = a voice gateway and an IP located transcoder between audio and IP text. IP -> PSTN ---------- Let us start with IP -> PSTN . Assigning an enumservice name for the text+voice service in PSTN would make it possible to show to the IP calle= r that this PSTN terminal can handle text AND that it can be reached throug= h a suitable gateway. But enum itself would not give the hint on how to find that gateway, only that it can be requested. That is at least halfway. Now, assume that the PSTN textphone user is in a hotel room with PSTN connection. He cannot influence the NAPTR record but want to get an incom= ing text call. The calling IP endpoint would not get assured that it is possi= ble to call by text, so what does he do to make the call . Should it take tha= t as an indicator that there is a need to invoke a separate transcoding service between RFC 4103 and audio coded text? ( there must be a similar situation for FAX, how have you solved that ? ) Also assume in a bright future, all gateways will be capable of doing bot voice gatewaying and voice+text gatewaying. Then all enum lookups for the= se services could look for either "voice" or "voicetext" with the same good result. How can we at that time reduce complexity in our NAPTR records an= d return to one simple specification of just one of them? Name "rtxt" "text" "voicetext" vortex" "txp" "votext" ? ------------------------------------------------------- Please help to assign a name for the service! In an offline discussion we were close to assigning "rtxt" or "text" to it when we hesitated because = it may be good to show its voice capabilities as well in the name. As soon as we have a proposed name, I can submit a draft proposing registering it as an enumservice for the scheme "tel". Regards Gunnar -------------------------------------------------------------------------= --- - Gunnar Hellstr=F6m, Omnitor gunnar.hellstrom@omnitor.se Mob: +46 708 204 288 Phone: +46 8 556 002 03 www.omnitor.se Subject: Re: [Enum] Comment on draft-ietf-enum-voice-01.txt about callsneeding text capability Hi Gunnar, folks, Background: Almost all of these PSTN Enumservices are tricky. They don't define a means to make the connection, as that could be direct or indirect. They don't care how the ENUM Client's terminal does it - the Enumservice spec just tells him or her what to expect if this contact is used (i.e. it's something like a teleservice identifier tagged along with a tel: URI) So... If a NAPTR has voice:tel as its Enumservice (with a tel: URI in the REGEXP field) then this says that a voice call cal be made to this telephone number. If a NAPTR has an sms:tel Enumservice, then it says that the destination reached by this telephone number can handle SMS messages. Most mobile phones can do both, so it is perfectly valid to have a single NAPTR with both Enumservices in it - something like: $ORIGIN 0.0.0.0.6.9.4.1.4.1.4.4.e164.arpa. . IN NAPTR 100 10 "u" "E2U+voice:tel+sms:tel" "!^.*$!tel: +447700900000!" . In effect, this compound NAPTR says that you can make a voice call or send an SMS to this number. Now... if you are suggesting that the ugly audio+text abominations that still exist do multiplexed voice AND text at the same time, then this seems to me to be a different teleservice from "pure" voice. If this is true, then I'd suggest that it needs a different Enumservice specification - the recipient of the NAPTR will not expect to be able to plug in an old-style text phone if they see E2U+voice:tel. However, if this telephone number also handles normal voice calls as well (as I guess it will), then showing both Enumservices in a single NAPTR would be perfectly valid. Hence an appropriate example would be: $ORIGIN 1.0.0.0.9.6.4.7.0.2.4.4.e164.arpa. . IN NAPTR 100 10 "u" "E2U+voice:tel+vortex:tel" "!^.*$!tel: +442079460001!" . Quick question: If there are broken old gateways that can't handle conversion from old-style PSTN text phone signals to 4103 style IP real time text, then how does one use these boxes to bridge between a conversational text device on the Internet to some text phone connected to the PSTN? PSTN->IP looks like a nightmare, whilst IP->PSTN is still a challenge, if the gateway doesn't do conversion to and from 4103. In that case, I would have thought it was easier to have a PC with a 4103-capable program running rather than use a PSTN-connected text phone - just use the Internet and forget the old gateways and the PSTN altogether. What am I missing? ---- Of course, if you were doing something sensible like using 4103, then be aware that you are vanishingly unlikely to get an Enumservice approved that indicates that your SIP AoR is associated with a permanently registered device that can handle 4103-style text conversations. To do so would be wrong, and such heresy will not be anointed with an RFC. It's a funny world, isn't it. all the best and good luck, Lawrence On 1 Nov 2005, at 23:14, Gunnar Hellstrom wrote: > I have a question related to draft-ietf-enum-voice-01.txt > > ( http://www.ietf.org/internet-drafts/draft-ietf-enum-voice-01.txt ) > > In PSTN, we have a service called text telephony. You can use real > time text > and voice alternating if you use text telephony. You can also on > the same > number use text in some calls and voice in others. You usually > combine a > terminal by a telephone and a text telephone. The text telephone > makes use > of some modem transmission for the text, but is made silent when > there is a > wish to talk instead. > > On the IP side you may have real time transmission of text and voice > simultaneously in a terminal including a voice codec and a text > codec. Text > is text coded and packetized. ( RFC 4103 is the currently only defined > transport for real time text with IP terminals ). It is also > popular to > combine with video. > > Now, too many gateways have been deployed without support for > translating > between PSTN text and IP text. So, for calling between these > environments, > you need a way to route the call to the right gateway, with text > capability. > But note, it shall only have text capability. In most cases it > should start > silent, just monitoring the two sides for text activity, and then > activate > text functionality towards PSTN. > > Sadly, PSTN users have the habit to bring their text telephones and > plug > them into the telephone connection without setting up any NAPTR > records for > an occasional visit. So, I have some urgent questions if enum can > contribute > to finding the right gateway supported path for the calls that > might contain > text. > > When reading draft-ietf-enum-voice-01.txt , I get the impression > that we > would need something similar for the "text and voice" service. For > now, let > us call it the "rtext" enumservice. ( or do you want to se it called > "votex"? ). I have prepared a draft, based on one of the other > enumservice > registration documents, and am prepared to submit it if you find it > motivated. > > But first some questions: > > 1. Do you find it feasible to register an enumservice "rtext" for > real time > text possibly combined with voice in the same call? > > 2. Will the "voice" enumservice imply something for the possibility > to use > other media in the same call? > > > > Regards > > ---------------------------------------------------------------------- > ------ > - > Gunnar Hellstr=F6m, Omnitor > gunnar.hellstrom@omnitor.se > Mob: +46 708 204 288 > Phone: +46 8 556 002 03 > www.omnitor.se > _______________________________________________ > 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 Wed Nov 02 12:33:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMUA-0007f6-1u; Wed, 02 Nov 2005 12:33:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMU8-0007eb-BQ for enum@megatron.ietf.org; Wed, 02 Nov 2005 12:33:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23795 for ; Wed, 2 Nov 2005 12:32:54 -0500 (EST) Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXMij-0005QT-OY for enum@ietf.org; Wed, 02 Nov 2005 12:48:23 -0500 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by atlrel8.hp.com (Postfix) with ESMTP id 7644D48A6; Wed, 2 Nov 2005 12:33:11 -0500 (EST) Received: from anoop ([16.150.200.11]) by iconsrv6.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id WAA21429; Wed, 2 Nov 2005 22:58:03 +0530 (IST) Message-Id: <200511021728.WAA21429@iconsrv6.india.hp.com> From: "sajitha" To: "'Jim Reid'" , "'Otmar Lendl'" Subject: RE: [Enum] [Fwd: I-D ACTION:draft-sajitha-enum-api-00.txt] Date: Wed, 2 Nov 2005 23:02:44 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcXbAP9Se1fK5mcCRaCl83V3EkRbagEq3KMg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org The timeout value can be made configurable for this API. I will revise the draft with this information. The asynchronous operation can be implemented for this API, which will allow parallel lookups. In that case res_*() calls cannot be used & the API has to implement send/receive by its own. Does this sound okay? -sajitha -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Jim Reid Sent: Thursday, October 27, 2005 7:50 PM To: Otmar Lendl Cc: enum@ietf.org Subject: Re: [Enum] [Fwd: I-D ACTION:draft-sajitha-enum-api-00.txt] On Oct 27, 2005, at 11:26, Otmar Lendl wrote: > The timeout requirements regarding ENUM may be different than for > other > DNS lookups. Agreed. Someone needs to capture those requirements: ie how long will it be after someone picks up an ENUM handset before they get a ring signal? > I don't like your reference to res_*(). These calls are not defined > in your API. > You're implying that any implementation of your API will be based on > libresolv and not some other DNS library like adns or firedns. True enough, but libresolv (for all its many faults) is ubiquitous. The DNS is badly in need of a decent API. And not just for ENUM. So far nobody has shown much interest in working on this or funding it. So until that changes, we're pretty much stuck with an API that's almost 20 years old. > Furthermore, I don't think that the timeout configuration in libresolv > is all that helpful as you can only set RES_RETRANS and RES_RETRY for > individual servers and not an overall timeout. These parameters only affect the stub resolver. So they're not much help if the recursive server that gets these queries is playing by different rules. > IMHO a feature-complete ENUM API should also contain functions to: > > * query more than one tree in parallel > * asynchronous operation > > As I'm doing some programming on the Asterisk ENUM code again I would > really appreciate a decent API for ENUM lookups to rely on. Indeed. But who can develop this API and steer it through the likes of X/Open or IEEE? _______________________________________________ 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 Nov 02 12:36:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMXB-0002GU-Kr; Wed, 02 Nov 2005 12:36:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMX9-0002FP-Kb for enum@megatron.ietf.org; Wed, 02 Nov 2005 12:36:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24028 for ; Wed, 2 Nov 2005 12:36:01 -0500 (EST) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXMll-0005aT-Aq for enum@ietf.org; Wed, 02 Nov 2005 12:51:30 -0500 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by palrel11.hp.com (Postfix) with ESMTP id 95A5371C0; Wed, 2 Nov 2005 09:33:01 -0800 (PST) Received: from anoop ([16.150.200.11]) by iconsrv6.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id WAA21419; Wed, 2 Nov 2005 22:57:55 +0530 (IST) Message-Id: <200511021727.WAA21419@iconsrv6.india.hp.com> From: "sajitha" To: "'Richard Shockey'" , "'Jim Reid'" Subject: RE: [Enum] [Fwd: I-D ACTION:draft-sajitha-enum-api-00.txt] Date: Wed, 2 Nov 2005 23:02:44 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcXb3PdnmXN40fu9Q3SjzMkR0sC3XQDzmRUg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <4362531F.8030106@shockey.us> X-Spam-Score: 0.8 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, 'Otmar Lendl' 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I can point out one example where API's are worked upon in IETF. The Basic Socket Interface Extensions for IPv6, RFC 3493. These APIs have later undergone the X/Open standardization and is now part of Unix200x specification. -Sajitha -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Friday, October 28, 2005 10:05 PM To: Jim Reid Cc: enum@ietf.org; Otmar Lendl Subject: Re: [Enum] [Fwd: I-D ACTION:draft-sajitha-enum-api-00.txt] > > These parameters only affect the stub resolver. So they're not much > help if the recursive server that gets these queries is playing by > different rules. > >> IMHO a feature-complete ENUM API should also contain functions to: >> >> * query more than one tree in parallel >> * asynchronous operation >> >> As I'm doing some programming on the Asterisk ENUM code again I would >> really appreciate a decent API for ENUM lookups to rely on. > > > Indeed. But who can develop this API and steer it through the likes of > X/Open or IEEE? This is the question I have for this document. Are API's an appropriate standardization task for the IETF? IMHO no. but I'd like some one to convince me otherwise or show me other examples of API's in the IETF along with the underlying justification and problem statement as to why the work should be done here. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ 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 Nov 02 17:21:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXQyc-0000VZ-KN; Wed, 02 Nov 2005 17:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXQyb-0000VR-ML for enum@megatron.ietf.org; Wed, 02 Nov 2005 17:21:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11375 for ; Wed, 2 Nov 2005 17:20:40 -0500 (EST) Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXRDG-0001HL-AI for enum@ietf.org; Wed, 02 Nov 2005 17:36:11 -0500 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Wed, 2 Nov 2005 17:20:15 -0500 Received: from mclmx.mail.saic.com ([149.8.64.10]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005110217201504619 ; Wed, 02 Nov 2005 17:20:15 -0500 Received: from bh-exchangefe.saic-abingdon.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com with ESMTP; Wed, 2 Nov 2005 17:20:15 -0500 Received: from bh-exchange02.saic-abingdon.com ([10.42.81.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Nov 2005 17:24:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Enum] Comment on draft-ietf-enum-voice-01.txt about callsneeding text capability Date: Wed, 2 Nov 2005 17:24:02 -0500 Message-Id: <2FE23D25B7292B489A217D1965CDA866726531@bh-exchange02.saic-abingdon.com> Thread-Topic: [Enum] Comment on draft-ietf-enum-voice-01.txt about callsneeding text capability Thread-Index: AcXfgX3Cgo4CBr+yQ5WtOFjnJk7NgQAQ6tTg From: "Roy, Radhika \(AEAD\)" To: "Gunnar Hellstrom" , "lconroy" X-OriginalArrivalTime: 02 Nov 2005 22:24:10.0421 (UTC) FILETIME=[2585DE50:01C5DFFC] X-Spam-Score: 0.5 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 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: , Content-Type: multipart/mixed; boundary="===============2116989767==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============2116989767== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DFFC.20BF1AF8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DFFC.20BF1AF8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Let me break silence over naming ... Inline [RRR] Name "rtxt" "text" "voicetext" vortex" "txp" "votext" ? ------------------------------------------------------- Please help to assign a name for the service! In an offline discussion = we were close to assigning "rtxt" or "text" to it when we hesitated because = it may be good to show its voice capabilities as well in the name. [RRR] Let us use the term "rtxt." [RRR] We cannot use the term "Text." "Text" as an application can be = non-real-time - also, SIP or RTP does NOT recognize "text" as a = real-time application. If needed, we may also contact SIP, SIPPING, = MMUSIC, and AVT WG. Any real-time media that needs to be sent over RTP = is the right one to standardize it. [RRR] I have seen that TEXT as a media is sent over TCP (not over = RTP/UDP). If AVT WG recognizes that TEXT is also sent over TCP, and it = is not a real-time application, the naming of this as TEXT will be = confusing among the standards. So, if ENUM decides to name it as "text," = it is then needs to take approval from AVT and other WGs of IETF. [RRR] Even if we decide "rtxt" or other (excluding TEXT) name, we still = need to inform AVT and other WGs about our naming decision. In this way, = it will be confirmed as standard across the whole IETF. As soon as we have a proposed name, I can submit a draft proposing registering it as an enumservice for the scheme "tel". Regards Gunnar ------_=_NextPart_001_01C5DFFC.20BF1AF8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= RE: [Enum] Comment on draft-ietf-enum-voice-01.txt about = callsneeding text capability=0A= =0A= =0A= =0A= =0A=

Let me break silence over =0A= naming ...

=0A=

Inline =0A= [RRR]

=0A= =0A=

Name "rtxt" "text" "voicetext" vortex" "txp" "votext" = ?

=0A= =0A=

-------------------------------------------------------

=0A= =0A=

Please help to assign a name for the service! In an offline = discussion we

=0A= =0A=

were close to assigning "rtxt" or "text" to it when we hesitated = because it

=0A= =0A=

may be good to show its voice capabilities as well in the = name.

=0A= =0A=

[RRR] Let us use the term = “rtxt.”

=0A= =0A=

[RRR] We cannot use the = term = “Text.”  “Text” as an application can be non-real-time = – also, SIP or RTP does NOT recognize “text” as a = real-time application. =0A= =0A= =0A= =0A= If needed, we may also contact SIP, SIPPING, MMUSIC, =0A= and AVT WG. Any real-time media that needs to be sent over RTP is = the right one to standardize it.

=0A=

[RRR] I have seen that TEXT as a media is sent over TCP (not = over =0A= RTP/UDP). If AVT WG recognizes that TEXT is also sent over TCP, and it = is not a =0A= real-time application, the naming of this as TEXT will be confusing = among the =0A= standards. So, if ENUM decides to name it as "text," it is then = needs to =0A= take approval from AVT and other WGs of IETF.

=0A= =0A=

[RRR] Even if we decide "rtxt" or other (excluding TEXT) name, = we still need to =0A= inform AVT and other WGs about our naming decision. In this way, it will = be =0A= confirmed as standard across the whole IETF.

=0A= =0A=

As soon as we have a proposed name, I can submit a draft = proposing

=0A= =0A=

registering it as an enumservice for the scheme = "tel".

=0A= =0A=

Regards

=0A= =0A=

Gunnar

=0A= =0A= =0A= ------_=_NextPart_001_01C5DFFC.20BF1AF8-- --===============2116989767== 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 --===============2116989767==-- From enum-bounces@ietf.org Wed Nov 02 17:34:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXRBL-0006gy-Ow; Wed, 02 Nov 2005 17:34:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXRBK-0006g4-FR for enum@megatron.ietf.org; Wed, 02 Nov 2005 17:34:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12334 for ; Wed, 2 Nov 2005 17:33:48 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EXRPy-0001xg-HC for enum@ietf.org; Wed, 02 Nov 2005 17:49:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Nov 2005 23:34:24 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C464D@oefeg-s04.oefeg.loc> Thread-Topic: ENUM Delegations this week Thread-Index: AcXfgX3Cgo4CBr+yQ5WtOFjnJk7NgQAQ6tTgAA4aqfY= From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Subject: [Enum] ENUM Delegations this week 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Folks, =20 The ITU TSB approved today the request for ENUM delegation of CC +39 = (Italy) by Consorzio Voipex and the Italian = Ministry of Communications . On Monday the ITU TSB approved the request for ENUM delegation of CC = +350 (Gibraltar) by Sapphire Networks (coming = soon ;-). Here also Afilias seems to be = involved. Yesterday also a seemingly serious request was received from Japan for = CC +81 submitted from the Ministry of Internal Affairs and = Communications (MIC), = providing JPNIC as tech contact. The request has not been approved yet by ITU TSB, but this seems only be = a matter of days. Welcome all to the world of ENUM, especially to Hiro, Yoshiro and = Ohashi.=20 =20 Ok, the latter are not so new ;-) =20 Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 03 02:57:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXZyl-0006en-Ip; Thu, 03 Nov 2005 02:57:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXZyg-0006d7-Qr for enum@megatron.ietf.org; Thu, 03 Nov 2005 02:57:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13154 for ; Thu, 3 Nov 2005 02:57:20 -0500 (EST) Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXaDP-0003QA-FP for enum@ietf.org; Thu, 03 Nov 2005 03:12:57 -0500 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id jA37vcai015882Thu, 3 Nov 2005 07:57:38 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1EXZyb-000Puy-00; Thu, 03 Nov 2005 07:57:37 +0000 Date: Thu, 3 Nov 2005 07:57:37 +0000 From: "Clive D.W. Feather" To: sajitha Subject: Re: [Enum] [Fwd: I-D ACTION:draft-sajitha-enum-api-00.txt] Message-ID: <20051103075737.GG94334@finch-staff-1.thus.net> References: <4362531F.8030106@shockey.us> <200511021727.WAA21419@iconsrv6.india.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200511021727.WAA21419@iconsrv6.india.hp.com> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: enum@ietf.org, 'Jim Reid' , 'Otmar Lendl' , 'Richard Shockey' 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org sajitha said: > I can point out one example where API's are worked upon in IETF. The Basic > Socket Interface Extensions for IPv6, RFC 3493. That's the ones. Unfortunately they were written by someone who didn't properly understand the C Standard. > These APIs have later > undergone the X/Open standardization and is now part of Unix200x > specification. And caused problems in doing so. [I don't have time to work through the details; it'll be in the X/Open archives somewhere.] -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 03 09:01:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXff5-0001tJ-JR; Thu, 03 Nov 2005 09:01:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXff4-0001sy-Cs for enum@megatron.ietf.org; Thu, 03 Nov 2005 09:01:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02242 for ; Thu, 3 Nov 2005 09:01:27 -0500 (EST) Received: from shaun.rfc1035.com ([195.54.233.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXftr-0003JN-6I for enum@ietf.org; Thu, 03 Nov 2005 09:17:08 -0500 Received: from [195.54.233.69] (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id jA3E1Sd3003083; Thu, 3 Nov 2005 14:01:29 GMT In-Reply-To: <200511021728.WAA21429@iconsrv6.india.hp.com> References: <200511021728.WAA21429@iconsrv6.india.hp.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <06860DE2-B696-457D-9A68-25ABA55C2187@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] [Fwd: I-D ACTION:draft-sajitha-enum-api-00.txt] Date: Thu, 3 Nov 2005 14:01:23 +0000 To: sajitha X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, 'Otmar Lendl' 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Nov 2, 2005, at 17:32, sajitha wrote: > The timeout value can be made configurable for this API. I will > revise the > draft with this information. The asynchronous operation can be > implemented > for this API, which will allow parallel lookups. In that case res_* > () calls > cannot be used & the API has to implement send/receive by its own. > Does this > sound okay? I'm not sure: probably not. It might be a good starting point for a discussion about an API though. A lot of work would need to be done on a requirements document before an API could be worked on. And there's still the unresolved question of where that API standarisation work would be done. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 03 10:30:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXh32-0006mC-Fu; Thu, 03 Nov 2005 10:30:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXh30-0006ir-2d for enum@megatron.ietf.org; Thu, 03 Nov 2005 10:30:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06662 for ; Thu, 3 Nov 2005 10:30:14 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXhHn-0006bA-NR for enum@ietf.org; Thu, 03 Nov 2005 10:45:57 -0500 Received: from [10.31.13.172] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jA3FV0Kb029501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Nov 2005 07:31:01 -0800 Message-ID: <436A2D08.6070800@shockey.us> Date: Thu, 03 Nov 2005 10:30:16 -0500 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Reid Subject: Re: [Enum] [Fwd: I-D ACTION:draft-sajitha-enum-api-00.txt] References: <200511021728.WAA21429@iconsrv6.india.hp.com> <06860DE2-B696-457D-9A68-25ABA55C2187@rfc1035.com> In-Reply-To: <06860DE2-B696-457D-9A68-25ABA55C2187@rfc1035.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, 'Otmar Lendl' 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Jim Reid wrote: > On Nov 2, 2005, at 17:32, sajitha wrote: > >> The timeout value can be made configurable for this API. I will >> revise the >> draft with this information. The asynchronous operation can be >> implemented >> for this API, which will allow parallel lookups. In that case res_* () >> calls >> cannot be used & the API has to implement send/receive by its own. >> Does this >> sound okay? > > > I'm not sure: probably not. It might be a good starting point for a > discussion about an API though. A lot of work would need to be done on > a requirements document before an API could be worked on. And there's > still the unresolved question of where that API standarisation work > would be done. Where is right. We can discuss this in Vancouver ( quickly ) but frankly I do not see this document as being relevant to our revised charter. Speaking as co-chair IMHO this document is out of scope. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 03 11:02:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXhYI-0007br-TC; Thu, 03 Nov 2005 11:02:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXhYF-0007b3-HB; Thu, 03 Nov 2005 11:02:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08417; Thu, 3 Nov 2005 11:02:34 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXhn4-0008U4-MI; Thu, 03 Nov 2005 11:18:14 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EXhYC-00072T-Ce; Thu, 03 Nov 2005 11:02:52 -0500 Content-Type: text/plain Mime-Version: 1.0 To: IETF-Announce@ietf.org From: The IESG Message-Id: Date: Thu, 03 Nov 2005 11:02:52 -0500 X-Spam-Score: 0.8 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: enum@ietf.org, Patrik Faltstrom , Richard Shockey Subject: [Enum] WG Review: Recharter of Telephone Number Mapping (enum) X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org A modified charter has been submitted for the Telephone Number Mapping (enum) working group in the Transport Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by November 9th. +++ Telephone Number Mapping (enum) ================================ Current Status: Active Working Group Chair(s): Patrik Faltstrom Richard Shockey Transport Area Director(s): Allison Mankin Jon Peterson Transport Area Advisor: Allison Mankin Secretary(ies): Alex Mayrhofer Mailing Lists: General Discussion: enum@ietf.org To Subscribe: enum-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/enum/index.html The ENUM working group has defined a DNS-based architecture and protocol [RFC 3761] by which an E.164 number, as defined in ITU Recommendation E.164, can be expressed as a Fully Qualified Domain Name in a specific Internet Infrastructure domain defined for this purpose (e164.arpa). Background: E.164 numbers are globally unique, language independent identifiers for resources on Public Telecommunication Networks that can support many different services and protocols. There is an emerging desire for network operators to utilize aspects of RFC 3761 to discover points of interconnection necessary to terminate communications sessions identified by a E164 number,in addition to identifying end point protocols and services. Working Group Revised Goals and Scope: 1. The working group will update RFC 3761 and advance to Draft Standard. 2. The working group will examine and document the use of RFC 3761 to facilitate network interconnection for services using E.164 addressing. The working group will coordinate its activities with other IETF working groups, existing or to be chartered, that are investigating elements of peering and or interconnection for VoIP or other services that typically use E.164 addressing. 3. The working group will continue examine and document various aspects of ENUM administrative and /or operational procedures irrespective of whether e164.arpa domain is used. 4. The working group will also examine the use of RFC 3761 technology for storing and delivering other information about services addressed by E.164 numbers, for example PSTN call routing and signaling data. 5. The Working Group will continue to maintain appropriate contact and liaison with other standards bodies and groups, specifically ITU-T SG2, to provide technical or educational information and address, as needed, issues related to the use of the E.164 numbering plan for services on IP networks. In addition the Working Group will continue to encourage the exchange of technical information within the emerging global ENUM community as well as documentation on practical experiences with implementations, alternate technology uses and the administration and provisioning of RFC 3761. 6. As described in RFC 3761, the IETF documents and registers the Enumservices. While extant, it is the ENUM working group that performs the technical review and development of the Enumservices for the Internet community. The working group determines whether to advance them and how to progress them technically. Coordination with other WGs will be taken into account on these. Other than Enumservices, all proposed deliverables of the working group will be discussed with and approved by the Area Directors, who may require wider review due to the broad impact of the subject. Goals and Milestones March 06 Enumservice Registration for Local Number Portability and Related Data as a Proposed Standard April 06 Requirements for Carrier Interconnection using ENUM as an Informational June 06 Carrier Interconnection using ENUM as a Proposed Standard July 06 ENUM Privacy and Security Considerations as an Informational August 06 Advancement of RFC 3761 to Draft Standard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 03 12:32:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXixE-00046A-4K; Thu, 03 Nov 2005 12:32:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXixC-000462-SS for enum@megatron.ietf.org; Thu, 03 Nov 2005 12:32:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16270 for ; Thu, 3 Nov 2005 12:32:24 -0500 (EST) Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXjC2-0005KB-KD for enum@ietf.org; Thu, 03 Nov 2005 12:48:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] [Fwd: RFC 4238 on Voice Message Routing Service] Date: Thu, 3 Nov 2005 12:32:05 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7301FBCAAA@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] [Fwd: RFC 4238 on Voice Message Routing Service] Thread-Index: AcXei6PPtLMWx5fgSieWb+e3dtJGXACC0uxQ From: "Creighton, Tom" To: "Richard Shockey" , X-OriginalArrivalTime: 03 Nov 2005 17:32:06.0484 (UTC) FILETIME=[82DB0940:01C5E09C] X-Spam-Score: 0.8 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: quoted-printable 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org >From section 2.2 of RFC 4238: > Example: > > Query: 2.1.2.1.5.5.5.3.1.6.1.e164.arpa > Responses: > IN NAPTR 10 10 "U" "E2U+VPIM:LDAP" \ > "!^.*$!ldap://vdir1.Zcorp.com/telephoneNumber=3D\1!" . > > IN NAPTR 10 20 "U" " E2U+VPIM:LDAP" \ > "!^.*$!ldap://vdir2.Zcorp.com/telephoneNumber=3D\1!" . It appears that a backref expression is being used in the repl portion of the substitution expression. Since the ERE section of the substituion expression is not enclosed by '(' and ')', it doesn't appear to be a properly formatted substituion expression. =20 If the desired result is to have the '\1' replaced by original telephone number used in the query, then the regular expression would have to look like one of the following: IN NAPTR 10 10 "U" "E2U+VPIM:LDAP" \ "!(^.*$)!ldap://vdir1.Zcorp.com/telephoneNumber=3D\1!" . Which would result in: ldap://vdir1.Zcorp.com/telephoneNumber=3D+16135551212 Or: IN NAPTR 10 10 "U" "E2U+VPIM:LDAP" \ "!^+(.*)$!ldap://vdir1.Zcorp.com/telephoneNumber=3D\1!" . Which would result in: ldap://vdir1.Zcorp.com/telephoneNumber=3D16135551212 Regards, Tom -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Monday, October 31, 2005 9:22 PM To: 'enum@ietf.org' Subject: [Enum] [Fwd: RFC 4238 on Voice Message Routing Service] FYI -------- Original Message -------- Subject: RFC 4238 on Voice Message Routing Service Date: Mon, 31 Oct 2005 16:56:33 -0800 From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org CC: vpim@ietf.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 4238 Title: Voice Message Routing Service Author(s): G. Vaudreuil Status: Standards Track Date: October 2005 Mailbox: GregV@ieee.org Pages: 10 Characters: 18902 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-vpim-routing-10.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4238.txt Voice messaging is traditionally addressed using telephone number addressing. This document describes two techniques for routing voice messages based on a telephone number. The complete service uses the Voice Profile for Internet Mail (VPIM) Directory service to lookup a VPIM email address with a telephone number and confirm that the address is both valid and associated with the intended recipient. However, this service will take time to become widely deployed in the near term. This document also describes a basic send-and-pray service that routes and delivers messages using only the ENUM telephone number resolution service and the existing DNS mail routing facilities. This document is a product of the Voice Profile for Internet Mail Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 03 14:46:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXl2e-0006tY-VV; Thu, 03 Nov 2005 14:46:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXl2d-0006qT-Ow for enum@megatron.ietf.org; Thu, 03 Nov 2005 14:46:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22287 for ; Thu, 3 Nov 2005 14:46:09 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXlHS-00022E-No for enum@ietf.org; Thu, 03 Nov 2005 15:01:53 -0500 Received: from [10.31.13.172] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jA3JkujE025263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 Nov 2005 11:46:58 -0800 Message-ID: <436A6904.4020209@shockey.us> Date: Thu, 03 Nov 2005 14:46:12 -0500 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Subject: [Enum] ENUM WG Chairs have determined that draft-sajitha-enum-api-00.txt is Out of Scope 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org The chairs have determined that this draft is out of scope of our revised charter and as such will not be discussed in Vancouver. Title : An ENUM Library API discussion ) Author(s) : T. Sajitha Filename : draft-sajitha-enum-api-00.txt Pages : 7 Date : 2005-10-21 This draft defines a library API for ENUM. The API takes telephone number as input and returns the URI associated with that telephone number. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sajitha-enum-api-00.txt -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Nov 04 00:55:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXuYA-0004IR-Ov; Fri, 04 Nov 2005 00:55:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXuY3-0004Hx-AI for enum@megatron.ietf.org; Fri, 04 Nov 2005 00:55:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24443 for ; Fri, 4 Nov 2005 00:55:12 -0500 (EST) Received: from pne-smtpout2-sn2.hy.skanova.net ([81.228.8.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXumm-0001ws-Dj for enum@ietf.org; Fri, 04 Nov 2005 01:11:01 -0500 Received: from MISAN (213.64.230.47) by pne-smtpout2-sn2.hy.skanova.net (7.2.060.1) id 4365DD8D00139074; Fri, 4 Nov 2005 06:55:04 +0100 From: "Gunnar Hellstrom" To: "Roy, Radhika \(AEAD\)" , "lconroy" Subject: RE: [Enum] Comment on draft-ietf-enum-voice-01.txt about calls needingtext capability Date: Fri, 4 Nov 2005 06:55:00 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <2FE23D25B7292B489A217D1965CDA866726531@bh-exchange02.saic-abingdon.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 0.9 (/) X-Scan-Signature: 75ac86d24bd0a3cd8a26e327ae61143e 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: , Content-Type: multipart/mixed; boundary="===============1277628671==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============1277628671== Content-Type: multipart/alternative; boundary="----=_NextPart_000_012F_01C5E10C.ACBE58A0" This is a multi-part message in MIME format. ------=_NextPart_000_012F_01C5E10C.ACBE58A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: Quoted-Printable RE: [Enum] Comment on draft-ietf-enum-voice-01.txt about callsneeding tex= t capabilityRadhika, After some consideration, I am back to proposing that we book the enumservice name "text" to mean real time conversational text with option= al voice. =46rom the discussion here in the enum group I realized that we can speci= fy voice+text to indicate capability for both, like this. $ORIGIN 0.0.0.0.6.9.4.1.4.1.4.4.e164.arpa. . IN NAPTR 100 10 "u" "E2U+voice:tel+text:tel" "!^.*$!tel: +447700900000!" . Thereby my fear that people would not understand that the "text" service also can carry voice was reduced. It also can show that the same terminal can be used for both services. So if you want to call a plain voice call, you may find "voice" in the record, use it and do not need to understand alternatives. I have also understood that a readable and understandable name is to be strongly preferred. I also saw that various message-wise text services have booked their name= s already ( email, fax, sms, ems, mms ), so I realized that there should be very little confusion. ( I have not seen any booking for IM based text messaging though, it would be interesting to know if they intend to book = a name. ) The multimedia framework service specification F.700 describes the "text" medium. It gives characteristics for various forms of text, with real tim= e ones and non-real time ones. So that standard definition of the text medi= um at least includes real time and is not as non-real-timish as you want to = see text. Another example: In the MIME media type specification, there is a media t= ype called "text". It contains various subtypes that can be used for real tim= e and non-real-time. In real life, there are all time relations conected to text as well as vo= ice and video. I can buy a video cassette. I can buy a voice recording on casette. I can watch TV with real time subtitled text. We do not need to go into transport protocol discussion on use of RTP or TCP. It is the human experience of real time that we want to achieve. We need to meet the user requirement of not more than one second from charac= ter entry to display for good quality of service. Two seconds for usable leve= l. We have standardised to use RTP, and agree on it for use in IP. But it is possible to use TCP for similar user experience. We hope to maintain the implemented base harmonized. However, most of the terminals specified by = the enumservice "text" will be PSTN terminals using modem transport outside = the gateway. For SIP terminals we are not supposed to use the detailed specifications on the enum level. So, that was why I want a readable name and see "text" as the currently b= est alternative very well matching "voice" and "video" for use in real time calls. Gunnar -------------------------------------------------------------------------= --- - Gunnar Hellstr=F6m, Omnitor gunnar.hellstrom@omnitor.se Mob: +46 708 204 288 Phone: +46 8 556 002 03 www.omnitor.se -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org]On Behalf Of Roy, Radhika (AEAD) Sent: Wednesday, November 02, 2005 11:24 PM To: Gunnar Hellstrom; lconroy Cc: enum@ietf.org Subject: RE: [Enum] Comment on draft-ietf-enum-voice-01.txt about callsneedingtext capability Let me break silence over naming ... Inline [RRR] Name "rtxt" "text" "voicetext" vortex" "txp" "votext" ? ------------------------------------------------------- Please help to assign a name for the service! In an offline discussion = we were close to assigning "rtxt" or "text" to it when we hesitated becaus= e it may be good to show its voice capabilities as well in the name. [RRR] Let us use the term =93rtxt.=94 [RRR] We cannot use the term =93Text.=94 =93Text=94 as an application = can be non-real-time =96 also, SIP or RTP does NOT recognize =93text=94 as a rea= l-time application. If needed, we may also contact SIP, SIPPING, MMUSIC, and AVT WG. Any real-time media that needs to be sent over RTP is the right one t= o standardize it. [RRR] I have seen that TEXT as a media is sent over TCP (not over RTP/UDP). If AVT WG recognizes that TEXT is also sent over TCP, and it is not a real-time application, the naming of this as TEXT will be confusing among the standards. So, if ENUM decides to name it as "text," it is then needs to take approval from AVT and other WGs of IETF. [RRR] Even if we decide "rtxt" or other (excluding TEXT) name, we still need to inform AVT and other WGs about our naming decision. In this way, = it will be confirmed as standard across the whole IETF. As soon as we have a proposed name, I can submit a draft proposing registering it as an enumservice for the scheme "tel". Regards Gunnar ------=_NextPart_000_012F_01C5E10C.ACBE58A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: Quoted-Printable RE: [Enum] Comment on draft-ietf-enum-voice-01.txt = about callsneeding text capability
Radhika,
After=20 some consideration, I am back to proposing that we book the enumservice = name=20 "text" to mean real time conversational text with optional voice.=20
 
From the = discussion here in the enum group I = realized that we=20 can specify voice+text to indicate capability for both, like this.=20
 
$ORIGIN=20 0.0.0.0.6.9.4.1.4.1.4.4.e164.arpa.

. IN NAPTR 100 10 "u" "E2U+voice:tel+text:tel" "!^.*$!tel:

+447700900000!" .

 
Thereby my fear that people would not understand that the = "text" service=20 also can carry voice was reduced. It also=20 can show that the same terminal can be used for both services. So if you = want to=20 call a plain voice call, you may find "voice" in the record, use it and = do not=20 need to understand = alternatives.
 
I have also = understood that a=20 readable and understandable name is to be strongly preferred.
 
I also=20 saw that various message-wise text services have booked their = names=20 already ( email, fax, sms, ems, mms = ), so=20 I realized that there should be very little confusion. ( I have not = seen=20 any booking for IM based text messaging though, it would be interesting = to know=20 if they intend to book a name. )
 
The=20 multimedia framework service = specification F.700 describes the "text" medium. It = gives=20 characteristics for various forms of text, with real time ones = and=20 non-real time ones. So that standard definition of the text = medium at least=20 includes real time and is not as non-real-timish as you want to=20 see text.
 
Another example: In the MIME media type specification, there is = a media=20 type called "text". It contains various subtypes that can be used for = real time=20 and non-real-time. 
 
In=20 real life, there are all time relations conected to text as well as = voice and=20 video. I can buy a video cassette. I can buy a voice recording on = casette. I can=20 watch TV with real time subtitled text.
 
We do not need to go into transport protocol discussion on use = of RTP or=20 TCP. It is the human experience of real time that we want to achieve. We = need to=20 meet the user requirement of not more than one second from character = entry to=20 display for good quality of service. Two seconds for usable level. =  We have=20 standardised to use RTP, = and agree on=20 it for use in IP. But it is possible to use TCP for similar user=20 experience. We hope to maintain the implemented base harmonized. However, most of the terminals specified by = the=20 enumservice  "text" will be PSTN terminals using modem transport = outside=20 the gateway. For SIP terminals we are not supposed to use the detailed=20 specifications on the enum level. =
 
So, that was why I = want a=20 readable name and see "text" as the currently best alternative very well = matching "voice" and "video" for use in = real time=20 calls.
 
 
Gunnar
 
----------------------------------------------------------------= -------------
Gunnar Hellstr=F6m, = Omnitor
gunnar.hellstrom@omnitor.se
Mob: +46 708 204 288
Phone: +46 8 556 002 03
www.omnitor.se
-----Original Message-----
From: = enum-bounces@ietf.org=20 [mailto:enum-bounces@ietf.org]On Behalf Of Roy, Radhika=20 (AEAD)
Sent: Wednesday, November 02, 2005 11:24 = PM
To:=20 Gunnar Hellstrom; lconroy
Cc: = enum@ietf.org
Subject: RE:=20 [Enum] Comment on draft-ietf-enum-voice-01.txt about callsneedingtext=20 capability

Let me=20 break silence over naming ...

Inline=20 [RRR]

Name "rtxt"=20 "text" "voicetext" vortex" "txp" "votext" ?

-------------------------------------------------------

Please help=20 to assign a name for the service! In an offline discussion=20 we

were close=20 to assigning "rtxt" or "text" to it when we hesitated because=20 it

may be good=20 to show its voice capabilities as well in the name.

[RRR] Let us use the term =93rtxt.=94

[RRR] We cannot use the=20 term =93Text.=94  =93Text=94 as an = application can be=20 non-real-time =96 also, SIP or RTP does NOT recognize =93text=94 as a = real-time=20 application. If needed, we may = also contact=20 SIP, SIPPING, MMUSIC, and AVT WG. Any real-time media that needs = to be=20 sent over RTP is the right one to standardize it.

[RRR] I have seen that TEXT as a media is sent over TCP (not = over=20 RTP/UDP). If AVT WG recognizes that TEXT is also sent over TCP, and it = is not=20 a real-time application, the naming of this as TEXT will be confusing = among=20 the standards. So, if ENUM decides to name it as "text," it = is then needs=20 to take approval from AVT and other WGs of IETF.

[RRR] Even if we = decide "rtxt" or=20 other (excluding TEXT) name, we still need to inform AVT and other WGs = about=20 our naming decision. In this way, it will be confirmed as standard = across the=20 whole IETF.

As soon as=20 we have a proposed name, I can submit a draft = proposing

registering=20 it as an enumservice for the scheme "tel".

Regards

Gunnar

------=_NextPart_000_012F_01C5E10C.ACBE58A0-- --===============1277628671== 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 --===============1277628671==-- From enum-bounces@ietf.org Sat Nov 05 18:07:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYX8O-0004yn-BV; Sat, 05 Nov 2005 18:07:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYX8M-0004vi-4i for enum@megatron.ietf.org; Sat, 05 Nov 2005 18:07:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25090 for ; Sat, 5 Nov 2005 18:07:13 -0500 (EST) Received: from mail15c.boca15-verio.com ([131.103.218.142]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EYXNd-00068f-4I for enum@ietf.org; Sat, 05 Nov 2005 18:23:26 -0500 Received: from mx14.bcrtfl01.us.mxservers.net (131.103.218.101) by mail15c.boca15-verio.com (RS ver 1.0.95vs) with SMTP id 0-0383462055; Sat, 5 Nov 2005 18:07:36 -0500 (EST) Received: from mmm1507.boca15-verio.com [207.201.145.105] (EHLO mmm1507.boca15-verio.com) by mx14.bcrtfl01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id 73b3d634.18365.217.mx14.bcrtfl01.us.mxservers.net; Sat, 05 Nov 2005 18:07:35 -0500 (EST) Received: (from webapps@localhost) by mmm1507.boca15-verio.com (8.12.11/8.12.9/Submit) id jA5N7YSu092422; Sat, 5 Nov 2005 18:07:34 -0500 (EST) (envelope-from david@rubicom.com) Message-Id: <200511052307.jA5N7YSu092422@mmm1507.boca15-verio.com> X-Authentication-Warning: mmm1507.boca15-verio.com: webapps set sender to david@rubicom.com using -f Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" MIME-Version: 1.0 From: "David" To: KCartwright@verisign.com, KCartwright@verisign.com, richard@shockey.us, enum@ietf.org, Kerri.Hughes@IQPC.com Subject: =?US-ASCII?B?dW5zdWJzY3JpYmUgdW5zdWJzY3JpYmUgUkU6IFJFOiBbRW51bV0gVGhlcmUgYXJlIHByZWxpaW5hcnkgcGxhbnMgZm9yIGFub3RoZXIgRU5VTSBTdW1taXQgaW4gdGhlIFVTLg==?= Date: Sat, 5 Nov 2005 23:07:34 +0000 X-Mailer: AutoBahn Webmail X-Spam: [F=0.0100000000; heur=0.500(-400); stat=0.010; spamtraq-heur=0.500(2005110408)] X-MAIL-FROM: X-SOURCE-IP: [207.201.145.105] X-Loop-Detect: 1 X-DistLoop-Detect: 1 X-Spam-Score: 0.8 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org >----- ------- Original Message ------- ----- >From: KCartwright@verisign.com >To: richard@shockey.us, enum@ietf.org, >Kerri.Hughes@IQPC.com >Sent: Tue, 1 Nov 2005 09:15:05 > >For those of us not involved in the previous summit >can you provide a >link discussing the purpose of the summit? > >Thank You > >-----Original Message----- >From: enum-bounces@ietf.org >[mailto:enum-bounces@ietf.org] On Behalf Of >Richard Shockey >Sent: Monday, October 31, 2005 5:23 PM >To: 'enum@ietf.org'; Kerri Hughes >Subject: [Enum] There are preliinary plans for >another ENUM Summit in >the US. > > >Many of you know there was a "ENUM Summit" >Conference earlier this year >in Miami that was rather successful. The Conference >organizers have >contacted me again to indicate they are planning on >the 2nd Annual ENUM >Summit with yours truly once again as Conference >Chair. > >Timing as of this date looks like early to mid >April so no conflicts >with IETF or VON. > >Venue TBD but I'm pressing for either JFK/LGA, ORD, >SFO or possibly BOS. > >Folks interested in the conference or have speaking >proposals should >contact. > > >Kerri Hughes >IQPC (International Quality & Productivity Center) >535 5th Ave, 8th Floor >New York, NY 10017 >P: 212-885-2760 * F: 212-885-2762 >kerri.hughes@iqpc.com >www.iqpc.com > > > >-- > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> >Richard Shockey, Director - Member of Technical >Staff >NeuStar Inc. >46000 Center Oak Plaza - Sterling, VA 20166 >sip:rshockey(at)iptel.org >sip:57141(at)fwd.pulver.com >ENUM +87810-13313-31331 >PSTN Office +1 571.434.5651 PSTN Mobile +1 >703.593.2683 >Fax: +1 815.333.1237 > or > > ; ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ><< > >_______________________________________________ >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 Sat Nov 05 19:05:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYY2N-0006qa-1X; Sat, 05 Nov 2005 19:05:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYY2L-0006qV-97 for enum@megatron.ietf.org; Sat, 05 Nov 2005 19:05:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28052 for ; Sat, 5 Nov 2005 19:05:04 -0500 (EST) Received: from 213-152-49-123.dsl.eclipse.net.uk ([213.152.49.123] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYYHc-0007YS-Jx for enum@ietf.org; Sat, 05 Nov 2005 19:21:18 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 35D9773C7E; Sun, 6 Nov 2005 00:04:43 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v746.2) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <348EEE1C-8DF1-438F-8DAF-A08E406A31D0@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Date: Sun, 6 Nov 2005 00:04:42 +0000 To: "'enum@ietf.org' ENUM" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: Stastny Richard , Rudolf Brandner Subject: [Enum] FYI: Last Call: 'Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail' to Proposed Standard 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Folks, FYI - this is the re-tread of the document reference to which is holding up the MSG draft in the RFC-ED queue, so things MAY be moving - praise the Lord. all the best, Lawrence Begin forwarded message: > From: The IESG > Date: 5 November 2005 23:42:55 GMT > To: IETF-Announce > Cc: lemonade@ietf.org > Subject: Last Call: 'Mapping Between the Multimedia Messaging > Service (MMS) and Internet Mail' to Proposed Standard > Reply-To: iesg@ietf.org > > A previous version of this document was approved by the IESG. > After an > appeal by John Klensin, the document was returned to the working > group. > The working group has made significant changes in response to the > appeal > and in relation to the follow-on discussion. This version > incorporates those > changes, and the Enhancements to Internet email to support diverse > service environments WG has requested the IESG to consider the > following > document: > > - 'Mapping Between the Multimedia Messaging Service (MMS) and > Internet Mail ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2005-11-25. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-lemonade-mms- > mapping-06.txt > > > _______________________________________________ > 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 Sat Nov 05 19:24:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYYKX-00029n-U3; Sat, 05 Nov 2005 19:24:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYYKW-00029f-9L for enum@megatron.ietf.org; Sat, 05 Nov 2005 19:24:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28668 for ; Sat, 5 Nov 2005 19:23:51 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYYZn-0007v3-TT for enum@ietf.org; Sat, 05 Nov 2005 19:40:05 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 05 Nov 2005 16:24:06 -0800 X-IronPort-AV: i="3.97,295,1125903600"; d="scan'208"; a="227620066:sNHT26399950" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA60O3Nl000345; Sat, 5 Nov 2005 16:24:03 -0800 (PST) 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 jA60XKao003239; Sat, 5 Nov 2005 16:33:21 -0800 In-Reply-To: <5247FEA3-3AA3-45DF-B169-F872AAC47A8B@rfc1035.com> References: <20051026182142.GU16044@denics7.denic.de> <5247FEA3-3AA3-45DF-B169-F872AAC47A8B@rfc1035.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] Re: I-D ACTION:draft-conroy-enum-edns0-01.txt Date: Sat, 5 Nov 2005 16:23:57 -0800 To: Jim Reid X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=820; t=1131237203; x=1131669403; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=paf@cisco.com; z=Subject:Re=3A=20[Enum]=20Re=3A=20I-D=20ACTION=3Adraft-conroy-enum-edns0-01.txt| From:=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20| Date:Sat,=205=20Nov=202005=2016=3A23=3A57=20-0800| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=gTnaLyXhPlJu/jEnAbia3xcwVWpD5UU/9ntm2HbpgPO/29dDrENxD1wQwW3oEH8xuizhbkSr YrMmRESZ5t/vovlwQMokMzcJfhoIgXflnPUpHO80Z87ILSmv9fn88PBTX5m/r0OyZ5Y+vQLaTTa 1jrVUuXNwSlUD/+/zlbZhcUE= Authentication-Results: imail.cisco.com; header.From=paf@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: IETF ENUM WG , Peter Koch 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 27 okt 2005, at 07.07, Jim Reid wrote: > Well if it's not done in that way through some sort of standards- > track RFC, what other approach would you suggest? IMO without such > a document, implementors have nothing to go on. If there's nothing > that says "you've got to support EDNS0" (and explains why), there's > a good chance EDNS0 support won't make it into ENUM-aware handsets. > Making EDNS0 support mandatory should mean it doesn't get dropped > from the feature set in the OS for these types of embedded devices. > ie Unless someone/something tells those developers to put in EDNS0, > they won't. My view is that EDNS0 is a requirement for *DNS* operation for a while, so I think anyone running DNS should support EDNS0, and because of that, I would like to see an RFC talking about "requirements for running DNS in the year 2005". Then other important things can be added as well. Such as an explanation for the "unknown RR types", support for DNSSEC etc. Not specifically for ENUM. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Nov 06 05:21:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYhen-0007YT-Od; Sun, 06 Nov 2005 05:21:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYhem-0007WX-Gh for enum@megatron.ietf.org; Sun, 06 Nov 2005 05:21:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18429 for ; Sun, 6 Nov 2005 05:21:23 -0500 (EST) Received: from shaun.rfc1035.com ([195.54.233.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYhu9-0006e4-0F for enum@ietf.org; Sun, 06 Nov 2005 05:37:42 -0500 Received: from [195.54.233.69] (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id jA6ALNd3007953; Sun, 6 Nov 2005 10:21:24 GMT In-Reply-To: References: <20051026182142.GU16044@denics7.denic.de> <5247FEA3-3AA3-45DF-B169-F872AAC47A8B@rfc1035.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <11449F70-8DA9-4A04-AF97-251B0FF4E016@rfc1035.com> Content-Transfer-Encoding: quoted-printable From: Jim Reid Subject: Re: [Enum] Re: I-D ACTION:draft-conroy-enum-edns0-01.txt Date: Sun, 6 Nov 2005 10:21:18 +0000 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: IETF ENUM WG , Peter Koch 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Nov 6, 2005, at 00:23, Patrik F=E4ltstr=F6m wrote: > On 27 okt 2005, at 07.07, Jim Reid wrote: > >> Well if it's not done in that way through some sort of standards-=20 >> track RFC, what other approach would you suggest? IMO without such =20= >> a document, implementors have nothing to go on. If there's nothing =20= >> that says "you've got to support EDNS0" (and explains why), =20 >> there's a good chance EDNS0 support won't make it into ENUM-aware =20 >> handsets. Making EDNS0 support mandatory should mean it doesn't =20 >> get dropped from the feature set in the OS for these types of =20 >> embedded devices. ie Unless someone/something tells those =20 >> developers to put in EDNS0, they won't. > > My view is that EDNS0 is a requirement for *DNS* operation for a =20 > while, so I think anyone running DNS should support EDNS0, and =20 > because of that, I would like to see an RFC talking about =20 > "requirements for running DNS in the year 2005". Then other =20 > important things can be added as well. Such as an explanation for =20 > the "unknown RR types", support for DNSSEC etc. I agree this is needed. However it can wait IMO. Manufacturers are =20 now gearing up to ship ENUM-aware handsets. Unless the IETF produces =20 a "use EDNS0" RFC very soon, these devices won't have EDNS0 support. =20 It would be better to fix that immediate concern now and then have =20 dnsop work on the longer-term problems. The all-singing, all-dancing =20 RFC you/we want will take at least a year to produce, probably more. =20 Assuming dnsop chooses to accept that work item. That'll be too long =20 because the ENUM-in-handsets train will have left the station by then. The draft is principally an exercise in damage limitation. We all =20 agree I hope that EDNS0 for ENUM is a Very Good Thing. So it should =20 be non-controversial for the WG to push out an RFC which requires EDNS0. I'm surprised and a little disappointed at the push-back the draft =20 has received. The choice here is stark: let the draft through (warts =20 and all) or else deal with the DNS consequences of millions of ENUM-=20 aware devices causing billions of truncated responses and TCP =20 retries. Which of these options does the WG want to take?= _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Nov 06 08:16:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYkOJ-0003qK-Gq; Sun, 06 Nov 2005 08:16:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYkOI-0003qF-IW for enum@megatron.ietf.org; Sun, 06 Nov 2005 08:16:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25979 for ; Sun, 6 Nov 2005 08:16:32 -0500 (EST) Received: from 213-152-49-123.dsl.eclipse.net.uk ([213.152.49.123] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYkdh-0001zj-Me for enum@ietf.org; Sun, 06 Nov 2005 08:32:54 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id EFB6273D24; Sun, 6 Nov 2005 13:16:47 +0000 (GMT) In-Reply-To: <11449F70-8DA9-4A04-AF97-251B0FF4E016@rfc1035.com> References: <20051026182142.GU16044@denics7.denic.de> <5247FEA3-3AA3-45DF-B169-F872AAC47A8B@rfc1035.com> <11449F70-8DA9-4A04-AF97-251B0FF4E016@rfc1035.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <9109610F-F06B-4CBB-9185-52E24B377886@insensate.co.uk> Content-Transfer-Encoding: quoted-printable From: lconroy Subject: Re: [Enum] Re: I-D ACTION:draft-conroy-enum-edns0-01.txt Date: Sun, 6 Nov 2005 13:16:46 +0000 To: Jim Reid X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Cc: IETF ENUM WG , Peter Koch , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Patrik, Jim, Peter, Folks, This is curious - we're wildly agreeing. Perhaps the draft should have a preface stating - "You need to understand DNS in order to do ENUM. These are some of the important items you MUST have in order for this to work well". AFAICT, ENUM differs from "traditional" uses of DNS only in the size of the responses it will elicit being larger than the average. Thus it would be VERY good if there was a generic DNSOPS document to spell out to everyone that: "there are already tools to deal with this, these are what they are, and you MUST use them if you don't want to break things" However, this is a general issue and will/should take time. For now, we have a specific issue with a cohort of DNS traffic that is distinctly different from traditional messages, and for which these items need to be raised. I will be VERY happy if this proposed RFC is obsoleted by a DNSOPS one (as soon as you can), in the same way that RFC3226 was, in effect, obsoleted by inclusion in later specifications. However, for now, please can we do exactly what was done for DNSSEC/IPV6 and produce an "RFC3226-like" RFC so that folk know to "do what is needed". It's not like we have a shortage of RFC numbers and we need to be careful about giving people too much to read - they only read the examples, anyway. Thus, if this is not wrong/broken (and I don't think it is), please can we progress it now to give DNSOPS a chance to do their job? all the best, Lawrence On 6 Nov 2005, at 10:21, Jim Reid wrote: > On Nov 6, 2005, at 00:23, Patrik F=E4ltstr=F6m wrote: >> On 27 okt 2005, at 07.07, Jim Reid wrote: >>> Well if it's not done in that way through some sort of standards-=20 >>> track RFC, what other approach would you suggest? IMO without =20 >>> such a document, implementors have nothing to go on. If there's =20 >>> nothing that says "you've got to support EDNS0" (and explains =20 >>> why), there's a good chance EDNS0 support won't make it into ENUM-=20= >>> aware handsets. Making EDNS0 support mandatory should mean it =20 >>> doesn't get dropped from the feature set in the OS for these =20 >>> types of embedded devices. ie Unless someone/something tells =20 >>> those developers to put in EDNS0, they won't. >> >> My view is that EDNS0 is a requirement for *DNS* operation for a =20 >> while, so I think anyone running DNS should support EDNS0, and =20 >> because of that, I would like to see an RFC talking about =20 >> "requirements for running DNS in the year 2005". Then other =20 >> important things can be added as well. Such as an explanation for =20 >> the "unknown RR types", support for DNSSEC etc. > > I agree this is needed. However it can wait IMO. Manufacturers are =20 > now gearing up to ship ENUM-aware handsets. Unless the IETF =20 > produces a "use EDNS0" RFC very soon, these devices won't have =20 > EDNS0 support. It would be better to fix that immediate concern now =20= > and then have dnsop work on the longer-term problems. The all-=20 > singing, all-dancing RFC you/we want will take at least a year to =20 > produce, probably more. Assuming dnsop chooses to accept that work =20 > item. That'll be too long because the ENUM-in-handsets train will =20 > have left the station by then. > > The draft is principally an exercise in damage limitation. We all =20 > agree I hope that EDNS0 for ENUM is a Very Good Thing. So it should =20= > be non-controversial for the WG to push out an RFC which requires =20 > EDNS0. > I'm surprised and a little disappointed at the push-back the draft =20 > has received. The choice here is stark: let the draft through =20 > (warts and all) or else deal with the DNS consequences of millions =20 > of ENUM-aware devices causing billions of truncated responses and =20 > TCP retries. Which of these options does the WG want to take? > _______________________________________________ > 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 Sun Nov 06 12:49:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYoeE-0000ee-EQ; Sun, 06 Nov 2005 12:49:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYoeC-0000eY-UT for enum@megatron.ietf.org; Sun, 06 Nov 2005 12:49:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11100 for ; Sun, 6 Nov 2005 12:49:15 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYotd-0000GP-Nj for enum@ietf.org; Sun, 06 Nov 2005 13:05:39 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 06 Nov 2005 09:49:31 -0800 X-IronPort-AV: i="3.97,298,1125903600"; d="scan'208"; a="227685608:sNHT26759952" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jA6HnO62019731; Sun, 6 Nov 2005 09:49:25 -0800 (PST) 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 jA6HwgVi009826; Sun, 6 Nov 2005 09:58:43 -0800 In-Reply-To: <11449F70-8DA9-4A04-AF97-251B0FF4E016@rfc1035.com> References: <20051026182142.GU16044@denics7.denic.de> <5247FEA3-3AA3-45DF-B169-F872AAC47A8B@rfc1035.com> <11449F70-8DA9-4A04-AF97-251B0FF4E016@rfc1035.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] Re: I-D ACTION:draft-conroy-enum-edns0-01.txt Date: Sun, 6 Nov 2005 09:49:22 -0800 To: Jim Reid X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=572; t=1131299925; x=1131732125; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=paf@cisco.com; z=Subject:Re=3A=20[Enum]=20Re=3A=20I-D=20ACTION=3Adraft-conroy-enum-edns0-01.txt| From:=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20| Date:Sun,=206=20Nov=202005=2009=3A49=3A22=20-0800| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=G//TyUKZlFXL5ofx7XQQqtIWW7JxeNCkpmfAR5cDjnaFC8eiD1ZxbqpxtHkAwkkZY94Mauy6 PEYgGOwf95Jvt5Nrv+JsJkzY98W2QkOaBTPpz9RtYKnnbDLtnD0wsnk05VwqLSu0vEqyADmjemF 9R+tFUyWiaPSejmlW9CpD6hY= Authentication-Results: imail.cisco.com; header.From=paf@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: IETF ENUM WG , Peter Koch 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 6 nov 2005, at 02.21, Jim Reid wrote: > The choice here is stark: let the draft through (warts and all) or > else deal with the DNS consequences of millions of ENUM-aware > devices causing billions of truncated responses and TCP retries. > Which of these options does the WG want to take? I want the DNS wg's in the IETF make the decision, because I see a risk there will be a BCP on how to run DNS and one on how to run DNS "and you happen to deal with ENUM queries". You point at handsets. What about the resolver the handset is using? Should we force all DNS operators in the world also read the ENUM DNS- operational RFC? I am only saying "go to the dnsop wg and have a document on how to run DNS *NOW*". paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Nov 06 12:50:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYof1-0000tm-B6; Sun, 06 Nov 2005 12:50:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYoez-0000rO-Es for enum@megatron.ietf.org; Sun, 06 Nov 2005 12:50:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11122 for ; Sun, 6 Nov 2005 12:50:04 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYouQ-0000H1-AF for enum@ietf.org; Sun, 06 Nov 2005 13:06:27 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 06 Nov 2005 09:50:20 -0800 X-IronPort-AV: i="3.97,298,1125903600"; d="scan'208"; a="227685653:sNHT25567128" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jA6HoD62019859; Sun, 6 Nov 2005 09:50:13 -0800 (PST) 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 jA6HwgVj009826; Sun, 6 Nov 2005 09:59:32 -0800 In-Reply-To: <9109610F-F06B-4CBB-9185-52E24B377886@insensate.co.uk> References: <20051026182142.GU16044@denics7.denic.de> <5247FEA3-3AA3-45DF-B169-F872AAC47A8B@rfc1035.com> <11449F70-8DA9-4A04-AF97-251B0FF4E016@rfc1035.com> <9109610F-F06B-4CBB-9185-52E24B377886@insensate.co.uk> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] Re: I-D ACTION:draft-conroy-enum-edns0-01.txt Date: Sun, 6 Nov 2005 09:50:11 -0800 To: lconroy X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=288; t=1131299973; x=1131732173; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=paf@cisco.com; z=Subject:Re=3A=20[Enum]=20Re=3A=20I-D=20ACTION=3Adraft-conroy-enum-edns0-01.txt| From:=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20| Date:Sun,=206=20Nov=202005=2009=3A50=3A11=20-0800| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=k2+yRoaKqxDBQ4P5vagGsteuDihtyHyqdtq1pk0ITFOWugyiP3biKXaOexd1VBEq61cUbGeB gRxzUTu3UTohfa8Rx1ARlFNDcB4Bot/qYujQoAzPoGsYE71677N6hnkd52eGYCEiKwO0K3HkRq8 C2clqr6rFxPpVpOf8OsgSmmI= Authentication-Results: imail.cisco.com; header.From=paf@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: IETF ENUM WG , Jim Reid , Peter Koch 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 6 nov 2005, at 05.16, lconroy wrote: > Perhaps the draft should have a preface stating > - "You need to understand DNS in order to do ENUM. > These are some of the important items you MUST > have in order for this to work well". And the effective way of doing this is to point at a "BCP for how to run DNS in 2005". Let me talk with the DNSOP wg chairs asap. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 07 13:29:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZBk0-0008Eo-C1; Mon, 07 Nov 2005 13:29:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZBjy-0008Ej-UB for enum@megatron.ietf.org; Mon, 07 Nov 2005 13:29:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27548 for ; Mon, 7 Nov 2005 13:28:44 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZBzc-0003q4-Kw for enum@ietf.org; Mon, 07 Nov 2005 13:45:22 -0500 Received: from [209.52.111.147] (pp111-147.bctel.ca [209.52.111.147]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jA7ITEnJ003023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 7 Nov 2005 10:29:26 -0800 Message-ID: <436F9CCD.4040802@shockey.us> Date: Mon, 07 Nov 2005 13:28:29 -0500 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.9 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [Enum] Reminder ... get your slides in ASAP 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org They will be promptly posted to the agenda site as soon as I receive them. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 08 13:51:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYYj-0004PA-8Q; Tue, 08 Nov 2005 13:51:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYYg-0004OI-TP for enum@megatron.ietf.org; Tue, 08 Nov 2005 13:51:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25384 for ; Tue, 8 Nov 2005 13:50:36 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZYoY-0004d0-C8 for enum@ietf.org; Tue, 08 Nov 2005 14:07:26 -0500 Received: from [209.52.111.147] (pp111-147.bctel.ca [209.52.111.147]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jA8IpDcL016909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Nov 2005 10:51:15 -0800 Message-ID: <4370F375.2060406@shockey.us> Date: Tue, 08 Nov 2005 13:50:29 -0500 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: multipart/mixed; boundary="------------010500030903020001030607" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.9 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Subject: [Enum] [Fwd: I-D ACTION:draft-jennings-iptel-tel-reg-00.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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --------------010500030903020001030607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI -------- Original Message -------- Subject: I-D ACTION:draft-jennings-iptel-tel-reg-00.txt Date: Mon, 07 Nov 2005 18:50:01 -0500 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry Author(s) : C. Jennings Filename : draft-jennings-iptel-tel-reg-00.txt Pages : 7 Date : 2005-11-7 This document creates an Internet Assigned Number Authority (IANA) registry for the tel Uniform Resource Identifier (URI) parameters, and their values. It also lists the already existing parameters to be used as initial values for that registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jennings-iptel-tel-reg-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-jennings-iptel-tel-reg-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-jennings-iptel-tel-reg-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. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< --------------010500030903020001030607 Content-Type: Message/External-body; name="draft-jennings-iptel-tel-reg-00.txt" Content-Disposition: inline; filename="draft-jennings-iptel-tel-reg-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-11-7163923.I-D@ietf.org> --------------010500030903020001030607 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------010500030903020001030607 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 --------------010500030903020001030607-- From enum-bounces@ietf.org Tue Nov 08 18:07:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZcZG-000267-2F; Tue, 08 Nov 2005 18:07:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZcZF-00025x-A5 for enum@megatron.ietf.org; Tue, 08 Nov 2005 18:07:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12359 for ; Tue, 8 Nov 2005 18:07:27 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZcp7-00041f-U1 for enum@ietf.org; Tue, 08 Nov 2005 18:24:19 -0500 Received: from [209.52.111.147] (pp111-147.bctel.ca [209.52.111.147]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jA8N7uJZ010665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Nov 2005 15:07:56 -0800 Message-ID: <43712F9F.8060102@shockey.us> Date: Tue, 08 Nov 2005 18:07:11 -0500 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.9 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: [Enum] Location for the ENUM WG Slides and agenda for the meeting 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org https://onsite.ietf.org/public/meeting_materials.cgi?meeting_num=64 -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 09 12:39:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZtuZ-0005G8-Qd; Wed, 09 Nov 2005 12:39:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZtuY-0005Fb-CP for enum@megatron.ietf.org; Wed, 09 Nov 2005 12:39:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24794 for ; Wed, 9 Nov 2005 12:38:35 -0500 (EST) Received: from [193.80.224.123] (helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZuAU-0003OM-OG for enum@ietf.org; Wed, 09 Nov 2005 12:55:38 -0500 Received: from [209.52.106.201] (pp106-201.bctel.ca [::ffff:209.52.106.201]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Wed, 09 Nov 2005 18:38:17 +0100 id 000680A4.4372340B.00004A2F Message-ID: <437233F6.6020902@enum.at> Date: Wed, 09 Nov 2005 18:37:58 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.4.1 (Windows/20051006) 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: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [Enum] please post issues from yesterdays session 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org All, i'd like to ask you to post any issue which you brought up during yesterday's WG session on the list. that would make tracking those issues much more easier. thanks, alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 09 14:09:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvJr-00060l-Or; Wed, 09 Nov 2005 14:09:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvJq-00060g-3t for enum@megatron.ietf.org; Wed, 09 Nov 2005 14:09:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01298 for ; Wed, 9 Nov 2005 14:08:46 -0500 (EST) 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 1EZvZt-0006M9-Cs for enum@ietf.org; Wed, 09 Nov 2005 14:25:50 -0500 Received: from ([10.20.9.172]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.14882773; Wed, 09 Nov 2005 14:08:31 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Nov 2005 14:08:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] please post issues from yesterdays session Date: Wed, 9 Nov 2005 14:08:11 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A398F9@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcXlVOESHAaUx3AgTgq+rXFIqZVGVwABoDgA From: "Livingood, Jason" To: "Alexander Mayrhofer" , X-OriginalArrivalTime: 09 Nov 2005 19:08:15.0016 (UTC) FILETIME=[EFA5AA80:01C5E560] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I noted that during my presentation on "draft-ietf-enum-pstn-00" the following issues were discussed and decided upon: 1. Minor nits with the draft will be resolved and I will re-submit to up-rev to -01. 2. Must revisit the section on Distribution of Data to note that it may or may not be done on a private basis. This will be primarily determined based on regulatory requirements in a particular country. I have not determined the exact wording of this yet. 3. After fixing the nits and word-smithing #2 above (resulting in -01), we will work on -02 with new suggested data types. These include CNAM and 800 number data, per feedback from Kevin McCandless. (This would not include Global Title Translation - which was a question raised by the co-chair.) The co-authors are open to any other suggestions. Separately, the need was again confirmed for a guide to creating an enumservice I-D. This work will be undertaken by members of the WG in the near future. Regards Jason Livingood > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of Alexander Mayrhofer > Sent: Wednesday, November 09, 2005 12:38 PM > To: enum@ietf.org > Subject: [Enum] please post issues from yesterdays session >=20 > All, >=20 > i'd like to ask you to post any issue which you brought up=20 > during yesterday's WG session on the list. >=20 > that would make tracking those issues much more easier. >=20 > thanks, >=20 > alex >=20 >=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 From enum-bounces@ietf.org Wed Nov 09 15:04:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZwBO-0003vy-AR; Wed, 09 Nov 2005 15:04:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZwBM-0003vt-J6 for enum@megatron.ietf.org; Wed, 09 Nov 2005 15:04:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05119 for ; Wed, 9 Nov 2005 15:04:05 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EZwRQ-00088M-9k for enum@ietf.org; Wed, 09 Nov 2005 15:21:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] please post issues from yesterdays session Date: Wed, 9 Nov 2005 21:08:06 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C466E@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcXlVWH1YbBDJ8aATsmGUb+Sbt+h6wAEXAYv From: "Stastny Richard" To: "Alexander Mayrhofer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org One issue raised during the discussion on Ed Guys IAX was to finally clarify the rules for subtyping of ENUMservices. =20 1. should there be subtypes or not 2. what should be used at subtypes (e.g. the URI) =20 This discussion is not new, some years? ago it was discussed if you need subtypes indication the URI on the right side at all, because you just have to look at the right side of the NAPTR to see it =20 So basically the registration template is indicating which URI are valid to be used with this ENUMsevice type =20 This was rejected because then a client is required to evalute ALL NAPTRs for this ENUMservice type (including regexp) to find out the URI and then decide which ob to take =20 As stated by co.chair Patrik this must not be the case, it must be possible by the client to select the NAPTR only by the information in the ENUMservice field, taking stupid clients into account. =20 Therefore the praxis was established to use subtypes indication the URI on the right side, and also to use the the URI name itself, to avoid confusion, although this is not necessary. If only one URI is possible, no subtype is used (e.g. ENUMservice sip or H323). =20 The only problem here exists when an ENUMservice is defined which contains at the moment only one URI, but MAY be expanded later with an additional URI. =20 We (e.g. Lawrence, Rudi and I) prefer in this also to use a subtype (the URI), even if it seems not necessary, just to be on the save side for future extensions. =20 My proposal is that in future all new ENUMservice registration SHOULD contain the URI as subtype =20 regards Richard =20 =20 ________________________________ Von: enum-bounces@ietf.org im Auftrag von Alexander Mayrhofer Gesendet: Mi 09.11.2005 18:37 An: enum@ietf.org Betreff: [Enum] please post issues from yesterdays session All, i'd like to ask you to post any issue which you brought up during yesterday's WG session on the list. that would make tracking those issues much more easier. thanks, 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 Wed Nov 09 16:40:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZxg9-0006PP-WA; Wed, 09 Nov 2005 16:40:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZxg8-0006PK-6k for enum@megatron.ietf.org; Wed, 09 Nov 2005 16:40:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12091 for ; Wed, 9 Nov 2005 16:39:56 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EZxwC-000367-N5 for enum@ietf.org; Wed, 09 Nov 2005 16:57:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] please post issues from yesterdays session Date: Wed, 9 Nov 2005 22:43:52 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4672@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcXlVWH1YbBDJ8aATsmGUb+Sbt+h6wAH6kHX From: "Stastny Richard" To: "Alexander Mayrhofer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This was not brought up by me, but concerns=20 our draft: =20 The definitions and terminolgy used in=20 draft-haberler-carrier-enum-01 should be moved over and aligned with the definitions and terminology in draft-lind-infrastructure-enum-reqs-01 =20 Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Alexander Mayrhofer Gesendet: Mi 09.11.2005 18:37 An: enum@ietf.org Betreff: [Enum] please post issues from yesterdays session All, i'd like to ask you to post any issue which you brought up during yesterday's WG session on the list. that would make tracking those issues much more easier. thanks, 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 Wed Nov 09 16:42:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZxhp-0007B2-4O; Wed, 09 Nov 2005 16:42:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZxhn-0007Au-Ky for enum@megatron.ietf.org; Wed, 09 Nov 2005 16:42:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12252 for ; Wed, 9 Nov 2005 16:41:39 -0500 (EST) Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZxxs-0003Ad-5Q for enum@ietf.org; Wed, 09 Nov 2005 16:58:45 -0500 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.1/8.13.4) with ESMTP id jA9Lg1ST013885; Wed, 9 Nov 2005 13:42:01 -0800 Received: from OVE1WNEXCB02.vcorp.ad.vrsn.com ([10.60.13.34]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 9 Nov 2005 13:42:01 -0800 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] please post issues from yesterdays session Date: Wed, 9 Nov 2005 15:41:57 -0600 Message-ID: <122A5731B827474C99ED552C6BFE23ED1338F5@OVE1WNEXCB02.vcorp.ad.vrsn.com> Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcXlVOESHAaUx3AgTgq+rXFIqZVGVwABoDgAAAaxdJA= From: "McCandless, Kevin" To: "Livingood, Jason" , "Alexander Mayrhofer" , X-OriginalArrivalTime: 09 Nov 2005 21:42:01.0077 (UTC) FILETIME=[6ACEDA50:01C5E576] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I would also add to the list that if you perform a PSTN URI query and no record exists that you consider a value to return. One that comes to mind is 'Void'. There was a draft discussed in this working group for the use of value. Thoughts? -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Livingood, Jason Sent: Wednesday, November 09, 2005 1:08 PM To: Alexander Mayrhofer; enum@ietf.org Subject: RE: [Enum] please post issues from yesterdays session I noted that during my presentation on "draft-ietf-enum-pstn-00" the following issues were discussed and decided upon: 1. Minor nits with the draft will be resolved and I will re-submit to up-rev to -01. 2. Must revisit the section on Distribution of Data to note that it may or may not be done on a private basis. This will be primarily determined based on regulatory requirements in a particular country. I have not determined the exact wording of this yet. 3. After fixing the nits and word-smithing #2 above (resulting in -01), we will work on -02 with new suggested data types. These include CNAM and 800 number data, per feedback from Kevin McCandless. (This would not include Global Title Translation - which was a question raised by the co-chair.) The co-authors are open to any other suggestions. Separately, the need was again confirmed for a guide to creating an enumservice I-D. This work will be undertaken by members of the WG in the near future. Regards Jason Livingood > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of Alexander Mayrhofer > Sent: Wednesday, November 09, 2005 12:38 PM > To: enum@ietf.org > Subject: [Enum] please post issues from yesterdays session >=20 > All, >=20 > i'd like to ask you to post any issue which you brought up=20 > during yesterday's WG session on the list. >=20 > that would make tracking those issues much more easier. >=20 > thanks, >=20 > alex >=20 >=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 Wed Nov 09 19:49:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea0dH-0003o0-Q3; Wed, 09 Nov 2005 19:49:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea0dF-0003nc-VT for enum@megatron.ietf.org; Wed, 09 Nov 2005 19:49:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22614 for ; Wed, 9 Nov 2005 19:49:10 -0500 (EST) Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea0tM-00081Y-UA for enum@ietf.org; Wed, 09 Nov 2005 20:06:17 -0500 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id jAA191Up021591; Wed, 9 Nov 2005 20:09:02 -0500 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Nov 2005 19:49:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Enum] please post issues from yesterdays session Date: Wed, 9 Nov 2005 19:49:20 -0500 Message-ID: Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcXlVWH1YbBDJ8aATsmGUb+Sbt+h6wAEXAYvAAlAZ1o= From: "Cartwright, Kenneth" To: "Stastny Richard" , "Alexander Mayrhofer" , X-OriginalArrivalTime: 10 Nov 2005 00:49:21.0394 (UTC) FILETIME=[968F1D20:01C5E590] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 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="===============1132868126==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============1132868126== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E590.960E1632" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E590.960E1632 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your reasoning and conclusion are the same ones I'd arrived at. And I = think your use of the word SHOULD rather than MUST is important to allow = for the cases where it may not be best to use the URI Scheme as the = sub-type. =20 Last I checked, about 12 of the roughly 15 registered ENUM services do = define required sub types, with SIP and pres being the most notable = exceptions. And of the 12 or so that do require sub types almost all of = them simply echo the URI Scheme. =20 Furthermore, in trying to make the ill-fated counter argument that the = Service/SubService Field should *not* be used to infer anything about = the URI in the regexp replacement substring (including the URI's Scheme) = you would end up having to say that the following NAPTR is a good one, = which of course it's not: IN NAPTR 100 50 "u" "E2U+sms:mailto" "!^.*$!tel:joesbox@example.com!" . It's not a good NAPTR because the obvious intention of the ENUM service = registration doc for sms is that when the service field is = "E2U+sms:mailto" then the URI Scheme in the URI should be mailto, not = tel. And when it's E2U+sms:tel the the URI Scheme in the regexp should = be tel, not mailto. Jason's plan to precisely address this matter in an ID is important. Ken ________________________________ From: enum-bounces@ietf.org on behalf of Stastny Richard Sent: Wed 11/9/2005 3:08 PM To: Alexander Mayrhofer; enum@ietf.org Subject: Re: [Enum] please post issues from yesterdays session One issue raised during the discussion on Ed Guys IAX was to finally clarify the rules for subtyping of ENUMservices. 1. should there be subtypes or not 2. what should be used at subtypes (e.g. the URI) This discussion is not new, some years? ago it was discussed if you need subtypes indication the URI on the right side at all, because you just have to look at the right side of the NAPTR to see it So basically the registration template is indicating which URI are valid to be used with this ENUMsevice type This was rejected because then a client is required to evalute ALL NAPTRs for this ENUMservice type (including regexp) to find out the URI and then decide which ob to take As stated by co.chair Patrik this must not be the case, it must be possible by the client to select the NAPTR only by the information in the ENUMservice field, taking stupid clients into account. Therefore the praxis was established to use subtypes indication the URI on the right side, and also to use the the URI name itself, to avoid confusion, although this is not necessary. If only one URI is possible, no subtype is used (e.g. ENUMservice sip or H323). The only problem here exists when an ENUMservice is defined which contains at the moment only one URI, but MAY be expanded later with an additional URI. We (e.g. Lawrence, Rudi and I) prefer in this also to use a subtype (the URI), even if it seems not necessary, just to be on the save side for future extensions. My proposal is that in future all new ENUMservice registration SHOULD contain the URI as subtype regards Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Alexander Mayrhofer Gesendet: Mi 09.11.2005 18:37 An: enum@ietf.org Betreff: [Enum] please post issues from yesterdays session All, i'd like to ask you to post any issue which you brought up during yesterday's WG session on the list. that would make tracking those issues much more easier. thanks, 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 ------_=_NextPart_001_01C5E590.960E1632 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [Enum] please post issues from yesterdays session=0A= =0A= =0A=
=0A=
Your = reasoning and conclusion =0A= are the same ones I'd arrived at. And I think your use of the word = SHOULD =0A= rather than MUST is important to allow for the cases where it may not be = best to =0A= use the URI Scheme as the sub-type.
=0A=
 
=0A=
Last I = checked, about 12 of =0A= the roughly 15 registered ENUM services do define required sub = types, with =0A= SIP and pres being the most notable exceptions.  And of the 12 or = so that =0A= do require sub types almost all of them simply echo the URI = Scheme.
=0A=
 
=0A=
Furthermore, in trying to = make the =0A= ill-fated counter argument that the Service/SubService Field should = *not* be =0A= used to infer anything about the URI in the regexp replacement = substring =0A= (including the URI's Scheme) you would end up having to say that the = following =0A= NAPTR is a good one, which of course it's not:
=0A=
=0A=

IN NAPTR 100 50 "u" "E2U+sms:mailto" "!^.*$!tel:joesbox@example.com!" = .

=0A=

It's not a good NAPTR because the obvious intention of the ENUM = service =0A= registration doc for sms is that when the service field is = "E2U+sms:mailto" then =0A= the URI Scheme in the URI should be mailto, not tel.  And when it's =0A= E2U+sms:tel the the URI Scheme in the regexp should be tel, not = mailto.

=0A=

Jason's plan to precisely address this matter in an ID is = important.

=0A=

Ken

=0A=

=0A=

=0A=

=0A=

From: enum-bounces@ietf.org on = behalf of =0A= Stastny Richard
Sent: Wed 11/9/2005 3:08 PM
To: = Alexander =0A= Mayrhofer; enum@ietf.org
Subject: Re: [Enum] please post = issues from =0A= yesterdays session

=0A=
=0A=

One issue raised during the discussion on Ed Guys IAX = was to =0A= finally
clarify the rules for subtyping of ENUMservices.

1. = should =0A= there be subtypes or not
2. what should be used at subtypes (e.g. the =0A= URI)

This discussion is not new, some years? ago it was = discussed
if =0A= you need subtypes indication the URI on the right side at = all,
because you =0A= just have to look at the right side of the NAPTR to see it

So = basically =0A= the registration template is indicating which URI are
valid to be = used with =0A= this ENUMsevice type

This was rejected because then a client is = required =0A= to evalute
ALL NAPTRs for this ENUMservice type (including regexp) to =0A= find
out the URI and then decide which ob to take

As stated by =0A= co.chair Patrik this must not be the case, it must
be possible by the = client =0A= to select the NAPTR only by the information
in the ENUMservice field, = taking =0A= stupid clients into account.

Therefore the praxis was established = to use =0A= subtypes indication the
URI on the right side, and also to use the = the URI =0A= name itself, to avoid
confusion, although this is not necessary. If = only one =0A= URI is possible,
no subtype is used (e.g. ENUMservice sip or =0A= H323).

The only problem here exists when an ENUMservice is = defined =0A= which
contains at the moment only one URI, but MAY be expanded = later
with =0A= an additional URI.

We (e.g. Lawrence, Rudi and I) prefer in this = also to =0A= use a subtype
(the URI), even if it seems not necessary, just to be = on the =0A= save side
for future extensions.

My proposal is that in future = all new =0A= ENUMservice registration SHOULD
contain the URI as =0A= subtype

regards
Richard



________________________= ________

Von: =0A= enum-bounces@ietf.org im Auftrag von Alexander Mayrhofer
Gesendet: Mi =0A= 09.11.2005 18:37
An: enum@ietf.org
Betreff: [Enum] please post = issues from =0A= yesterdays session



All,

i'd like to ask you to = post any =0A= issue which you brought up during
yesterday's WG session on the =0A= list.

that would make tracking those issues much more =0A= easier.

thanks,

alex


___________________________= ____________________
enum =0A= mailing list
enum@ietf.org
https://www1.ietf.or= g/mailman/listinfo/enum



______________________________= _________________
enum =0A= mailing list
enum@ietf.org
https://www1.ietf.or= g/mailman/listinfo/enum

=0A= =0A= =0A= ------_=_NextPart_001_01C5E590.960E1632-- --===============1132868126== 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 --===============1132868126==-- From enum-bounces@ietf.org Wed Nov 09 20:03:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea0r3-0002pq-9x; Wed, 09 Nov 2005 20:03:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea0r1-0002p8-Ro for enum@megatron.ietf.org; Wed, 09 Nov 2005 20:03:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23434 for ; Wed, 9 Nov 2005 20:03:24 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ea179-0008QU-4j for enum@ietf.org; Wed, 09 Nov 2005 20:20:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] please post issues from yesterdays session Date: Thu, 10 Nov 2005 02:03:20 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4675@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcXlVWH1YbBDJ8aATsmGUb+Sbt+h6wAEXAYvAAlAZ1oAAa3Tmg== From: "Stastny Richard" To: "Cartwright, Kenneth" , "Alexander Mayrhofer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Kenneth wrote: >Your reasoning and conclusion are the same ones I'd arrived at. And I = think your use of the word SHOULD rather than MUST is important to allow = >for the cases where it may not be best to use the URI Scheme as the = sub-type. =20 correct, I already had written MUST and then changed it to SHOULD = exactly for this reason =20 >Last I checked, about 12 of the roughly 15 registered ENUM services do = define required sub types, with SIP and pres being the most notable = >exceptions. And of the 12 or so that do require sub types almost all = of them simply echo the URI Scheme. quod licet jovi, not licet bovi ;-) =20 . >Jason's plan to precisely address this matter in an ID is important. agree Richard >Ken ________________________________ From: enum-bounces@ietf.org on behalf of Stastny Richard Sent: Wed 11/9/2005 3:08 PM To: Alexander Mayrhofer; enum@ietf.org Subject: Re: [Enum] please post issues from yesterdays session One issue raised during the discussion on Ed Guys IAX was to finally clarify the rules for subtyping of ENUMservices. 1. should there be subtypes or not 2. what should be used at subtypes (e.g. the URI) This discussion is not new, some years? ago it was discussed if you need subtypes indication the URI on the right side at all, because you just have to look at the right side of the NAPTR to see it So basically the registration template is indicating which URI are valid to be used with this ENUMsevice type This was rejected because then a client is required to evalute ALL NAPTRs for this ENUMservice type (including regexp) to find out the URI and then decide which ob to take As stated by co.chair Patrik this must not be the case, it must be possible by the client to select the NAPTR only by the information in the ENUMservice field, taking stupid clients into account. Therefore the praxis was established to use subtypes indication the URI on the right side, and also to use the the URI name itself, to avoid confusion, although this is not necessary. If only one URI is possible, no subtype is used (e.g. ENUMservice sip or H323). The only problem here exists when an ENUMservice is defined which contains at the moment only one URI, but MAY be expanded later with an additional URI. We (e.g. Lawrence, Rudi and I) prefer in this also to use a subtype (the URI), even if it seems not necessary, just to be on the save side for future extensions. My proposal is that in future all new ENUMservice registration SHOULD contain the URI as subtype regards Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Alexander Mayrhofer Gesendet: Mi 09.11.2005 18:37 An: enum@ietf.org Betreff: [Enum] please post issues from yesterdays session All, i'd like to ask you to post any issue which you brought up during yesterday's WG session on the list. that would make tracking those issues much more easier. thanks, 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From sigtran-bounces@ietf.org Wed Nov 09 20:19:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea15q-0006q6-Ae; Wed, 09 Nov 2005 20:19:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea15n-0006pl-Jg for sigtran@megatron.ietf.org; Wed, 09 Nov 2005 20:19:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24094 for ; Wed, 9 Nov 2005 20:18:40 -0500 (EST) Received: from gw.openss7.com ([142.179.199.224] ident=[BMp6lDBvfDJfl/3qthycmBWoZ3YJS8dz]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea1Lu-0000LU-1y for sigtran@ietf.org; Wed, 09 Nov 2005 20:35:47 -0500 Received: from ns.pigworks.openss7.net (IDENT:JozaQOhyqHzVnqLU2UonTw0SDWHhidFi@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id jAA1Itc00642; Wed, 9 Nov 2005 18:18:55 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id jAA1It520494; Wed, 9 Nov 2005 18:18:55 -0700 Date: Wed, 9 Nov 2005 18:18:55 -0700 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] SE-IPSP definition Message-ID: <20051109181855.A20305@openss7.org> Mail-Followup-To: Tolga Asveren , sigtran@ietf.org References: <20051109120817.C17443@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from asveren@ulticom.com on Wed, Nov 09, 2005 at 02:29:04PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sigtran-bounces@ietf.org Errors-To: sigtran-bounces@ietf.org Tolga, I think that you are talking about something completely different than RFC 3332. Might I suggest a new IPSP draft that has things the way that you want them? --brian Tolga Asveren wrote: (Wed, 09 Nov 2005 14:29:04) > Brian, > > > -I will try to consolidate my replies as much as I can- > > -----Original Message----- > > From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On > > Behalf Of Brian F. G. Bidulock > > Sent: Wednesday, November 09, 2005 2:08 PM > > To: Tolga Asveren > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] SE-IPSP definition > > > > > > Tolga, > > > > I an not talking about SNMM used to indicate the status of remote point > > codes, etc. I am talking about SNMM used to indciate the status of local > > point codes, etc. for the sending IPSP. > [TOLGA]ASPTM should be enough for that purpose. If one wants to be notified > about remote user part status for IPSP case, one should have RKs defined in > User Part granularity. For availability/unavailability there is ASPAC/ASPIA. > We only miss the congestion message in ASPTM, which hopefully should be > ready soon. > > > > Also, it might not be necessary (in all cases), it might not even be very > > useful (in some cases), but it is currently not prohibited. > a)I am not speaking of SG-SG at all, what I am saying has nothing to do with > it. You also know that actually it is SG-SG, which is SSNM based -and which > makes sense considering the services it needs to provide-, but this is not > hte topic right now. > > b)Your answer in "M3UA User Part's Management" thread was about IPSP > communication, if you want, you can check the original question in that > thread. ;-) > > c)The section you mention in "4.6 MTP3 Restart" is really really wrong and > needs an update IMHO. An IPSP does not have MTP3 layer. One obviously can > build a box which provides both SGP and IPSP services but IPSP functionality > itself has nothing to do with MTP3. IPSP will host only local application > logic which communicates directly with another application hosted byt a peer > IPSP. Remote endpoint in traditional SS7 domain will be responsibility of > SGP and MTP3 restart is applicable only for SGP, not for IPSP. > > For the sake of making progress here is what I think: > a)People are confused about use of SSNM for IPSP (I think we agree about > this) > b)SSNM is not necessary for IPSP case -except for SCON, which needs further > study, i.e. ASPCONG-. If there is a situation where we *really* need it, > let's try to figure out whether it can be handled with ASPTM. (This is my > position. AFAICS, you also think that it is probably not a good idea to use > SSNM either but you think that the document does not disallow this.) > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From enum-bounces@ietf.org Wed Nov 09 20:19:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea15v-0006rD-Bc; Wed, 09 Nov 2005 20:19:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea15u-0006qg-5d for enum@megatron.ietf.org; Wed, 09 Nov 2005 20:19:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24103 for ; Wed, 9 Nov 2005 20:18:46 -0500 (EST) Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea1M0-0000LX-Mw for enum@ietf.org; Wed, 09 Nov 2005 20:35:54 -0500 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id jAA1cZPv022409; Wed, 9 Nov 2005 20:38:35 -0500 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Nov 2005 20:18:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Enum] please post issues from yesterdays session Date: Wed, 9 Nov 2005 20:18:53 -0500 Message-ID: Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcXlVWH1YbBDJ8aATsmGUb+Sbt+h6wAH6kHXAAe9YWg= From: "Cartwright, Kenneth" To: "Stastny Richard" , "Alexander Mayrhofer" , X-OriginalArrivalTime: 10 Nov 2005 01:18:54.0424 (UTC) FILETIME=[B75E0580:01C5E594] X-Spam-Score: 0.5 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f 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="===============2114497427==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============2114497427== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E594.B6F88890" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E594.B6F88890 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Right, I feel that the Requirements section (section 3) in the haberler = document further clarifies the carrier er. infrastructure ENUM problem, = and is mostly complementary with what's already in the lind document. = ...but it's a small point. =20 Ken ________________________________ From: enum-bounces@ietf.org on behalf of Stastny Richard Sent: Wed 11/9/2005 4:43 PM To: Alexander Mayrhofer; enum@ietf.org Subject: Re: [Enum] please post issues from yesterdays session This was not brought up by me, but concerns our draft: The definitions and terminolgy used in draft-haberler-carrier-enum-01 should be moved over and aligned with the definitions and terminology in draft-lind-infrastructure-enum-reqs-01 Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Alexander Mayrhofer Gesendet: Mi 09.11.2005 18:37 An: enum@ietf.org Betreff: [Enum] please post issues from yesterdays session All, i'd like to ask you to post any issue which you brought up during yesterday's WG session on the list. that would make tracking those issues much more easier. thanks, 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 ------_=_NextPart_001_01C5E594.B6F88890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [Enum] please post issues from yesterdays session=0A= =0A= =0A=
=0A=
Right, I feel = that the =0A= Requirements section (section 3) in the haberler document further = clarifies the =0A= carrier er. infrastructure ENUM problem, and is mostly = complementary with =0A= what's already in the lind document.  ...but it's a small =0A= point.
=0A=
 
=0A=
Ken
=0A=

=0A=
=0A= From: enum-bounces@ietf.org on = behalf of Stastny =0A= Richard
Sent: Wed 11/9/2005 4:43 PM
To: Alexander = Mayrhofer; =0A= enum@ietf.org
Subject: Re: [Enum] please post issues from = yesterdays =0A= session

=0A=
=0A=

This was not brought up by me, but concerns
our =0A= draft:

The definitions and terminolgy used =0A= in
draft-haberler-carrier-enum-01 should be moved over and = aligned
with =0A= the definitions and terminology =0A= in
draft-lind-infrastructure-enum-reqs-01

Richard

______= __________________________

Von: =0A= enum-bounces@ietf.org im Auftrag von Alexander Mayrhofer
Gesendet: Mi =0A= 09.11.2005 18:37
An: enum@ietf.org
Betreff: [Enum] please post = issues from =0A= yesterdays session



All,

i'd like to ask you to = post any =0A= issue which you brought up during
yesterday's WG session on the =0A= list.

that would make tracking those issues much more =0A= easier.

thanks,

alex


___________________________= ____________________
enum =0A= mailing list
enum@ietf.org
https://www1.ietf.or= g/mailman/listinfo/enum



______________________________= _________________
enum =0A= mailing list
enum@ietf.org
https://www1.ietf.or= g/mailman/listinfo/enum

=0A= =0A= =0A= ------_=_NextPart_001_01C5E594.B6F88890-- --===============2114497427== 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 --===============2114497427==-- From enum-bounces@ietf.org Wed Nov 09 20:41:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea1RQ-0007ap-MC; Wed, 09 Nov 2005 20:41:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea1RO-0007ah-Lc for enum@megatron.ietf.org; Wed, 09 Nov 2005 20:41:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25229 for ; Wed, 9 Nov 2005 20:40:57 -0500 (EST) Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea1hU-0000tw-6r for enum@ietf.org; Wed, 09 Nov 2005 20:58:04 -0500 Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id jAA20qBq023028 for ; Wed, 9 Nov 2005 21:00:52 -0500 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Nov 2005 20:41:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Enum] please post issues from yesterdays session Date: Wed, 9 Nov 2005 20:41:10 -0500 Message-ID: Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcXlVWH1YbBDJ8aATsmGUb+Sbt+h6wAH6kHXAAgGIQY= From: "Cartwright, Kenneth" To: X-OriginalArrivalTime: 10 Nov 2005 01:41:11.0033 (UTC) FILETIME=[D40C5E90:01C5E597] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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="===============1016581025==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============1016581025== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E597.D3BED6E7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E597.D3BED6E7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think it's a vital point that Patrik and Richard schooled me on: The = fact that the IETF will make *no* judgments or statements about the = appropriateness, precedence, or "conflict" resolution of NAPTRs in the = User ENUM tree and the Carrier ENUM tree for the same TN. The Carrier = ENUM tree may very well have NAPTRs for any ENUM service type for a = given TN, while NAPTRs for the same TN and the same ENUM service types, = but with perhaps different URIs, may also reside in the User ENUM tree = at the same time. The decision on which tree to query, and perhaps in = what order to query them, and perhaps how to resolve "conflicts" (I = don't use the term "conflict" in a negative sense) is entirely up to the = ENUM client application. I had not heard this said before or seen it = written, but it certainly simplifies the problem of having two trees. =20 Ken. ________________________________ From: enum-bounces@ietf.org on behalf of Stastny Richard Sent: Wed 11/9/2005 4:43 PM To: Alexander Mayrhofer; enum@ietf.org Subject: Re: [Enum] please post issues from yesterdays session This was not brought up by me, but concerns our draft: The definitions and terminolgy used in draft-haberler-carrier-enum-01 should be moved over and aligned with the definitions and terminology in draft-lind-infrastructure-enum-reqs-01 Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Alexander Mayrhofer Gesendet: Mi 09.11.2005 18:37 An: enum@ietf.org Betreff: [Enum] please post issues from yesterdays session All, i'd like to ask you to post any issue which you brought up during yesterday's WG session on the list. that would make tracking those issues much more easier. thanks, 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 ------_=_NextPart_001_01C5E597.D3BED6E7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [Enum] please post issues from yesterdays session=0A= =0A= =0A=
=0A=
I think it's = a vital point =0A= that Patrik and Richard schooled me on:  The fact that the IETF = will make =0A= *no* judgments or statements about the appropriateness, precedence, or =0A= "conflict" resolution of NAPTRs in the User ENUM tree and the = Carrier ENUM =0A= tree for the same TN.  The Carrier ENUM tree may very well = have NAPTRs =0A= for any ENUM service type for a given TN, while NAPTRs for the same TN = and the =0A= same ENUM service types, but with perhaps different URIs, may also = reside in the =0A= User ENUM tree at the same time.  The decision on which tree to = query, and =0A= perhaps in what order to query them, and perhaps how to resolve = "conflicts" (I =0A= don't use the term "conflict" in a negative sense) is entirely up = to the =0A= ENUM client application.   I had not heard this said before or = seen it =0A= written, but it certainly simplifies the problem of having two =0A= trees.
=0A=
 
=0A=
Ken.
=0A=

=0A=
=0A= From: enum-bounces@ietf.org on = behalf of Stastny =0A= Richard
Sent: Wed 11/9/2005 4:43 PM
To: Alexander = Mayrhofer; =0A= enum@ietf.org
Subject: Re: [Enum] please post issues from = yesterdays =0A= session

=0A=
=0A=

This was not brought up by me, but concerns
our =0A= draft:

The definitions and terminolgy used =0A= in
draft-haberler-carrier-enum-01 should be moved over and = aligned
with =0A= the definitions and terminology =0A= in
draft-lind-infrastructure-enum-reqs-01

Richard

______= __________________________

Von: =0A= enum-bounces@ietf.org im Auftrag von Alexander Mayrhofer
Gesendet: Mi =0A= 09.11.2005 18:37
An: enum@ietf.org
Betreff: [Enum] please post = issues from =0A= yesterdays session



All,

i'd like to ask you to = post any =0A= issue which you brought up during
yesterday's WG session on the =0A= list.

that would make tracking those issues much more =0A= easier.

thanks,

alex


___________________________= ____________________
enum =0A= mailing list
enum@ietf.org
https://www1.ietf.or= g/mailman/listinfo/enum



______________________________= _________________
enum =0A= mailing list
enum@ietf.org
https://www1.ietf.or= g/mailman/listinfo/enum

=0A= =0A= =0A= ------_=_NextPart_001_01C5E597.D3BED6E7-- --===============1016581025== 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 --===============1016581025==-- From enum-bounces@ietf.org Thu Nov 10 00:27:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea4yX-0005tX-6L; Thu, 10 Nov 2005 00:27:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea4yV-0005rX-Ix for enum@megatron.ietf.org; Thu, 10 Nov 2005 00:27:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08545 for ; Thu, 10 Nov 2005 00:27:22 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ea5Ee-0006aH-M8 for enum@ietf.org; Thu, 10 Nov 2005 00:44:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Enum] please post issues from yesterdays session Date: Thu, 10 Nov 2005 06:31:24 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4678@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcXlVWH1YbBDJ8aATsmGUb+Sbt+h6wAH6kHXAAgGIQYAB0PIOA== From: "Stastny Richard" To: "Cartwright, Kenneth" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org HI Ken, =20 I think it is a good idea to state this clearly somewhere. I am not sure = if this is a "requirement" but it may be useful to make this clarifcation there. =20 The intersting issue about this is that this "non-conflict" was always = intrinsically there in User ENUM. If you made an entry in User ENUM for lets say a geographic number, = there was always the intrinsic asumption made that you still had a DIFFERENT terminatiion on the PSTN. = User ENUM is an additional service for the end-user. Nobody sees a "conflict" here. =20 Infrastructure ENUM is now dealingwith the termination mentioned above. = An entry in Infrastucture ENUM is pointing to a border element of a "carrier" = hosting the number in question, regardless if this end-user is on IP or on the PSTN. =20 So nothing has changed here. Before Infrastructure ENUM, a carrier could = choose to route the call conventionally on the PSTN or query User ENUM in addition (as = some VoIP providers do) =20 Now the Carrier could chose again to route the call by querying = Infrastructure ENUM or to query User ENUM in addition. =20 Looking up User ENUM is always a subscriber feature and opt-in. So the = user may either query User ENUM by himself, or the provider is querying User = ENUM ON BEHALF of the User.=20 =20 Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Cartwright, Kenneth Gesendet: Do 10.11.2005 02:41 An: enum@ietf.org Betreff: RE: [Enum] please post issues from yesterdays session I think it's a vital point that Patrik and Richard schooled me on: The = fact that the IETF will make *no* judgments or statements about the = appropriateness, precedence, or "conflict" resolution of NAPTRs in the = User ENUM tree and the Carrier ENUM tree for the same TN. The Carrier = ENUM tree may very well have NAPTRs for any ENUM service type for a = given TN, while NAPTRs for the same TN and the same ENUM service types, = but with perhaps different URIs, may also reside in the User ENUM tree = at the same time. The decision on which tree to query, and perhaps in = what order to query them, and perhaps how to resolve "conflicts" (I = don't use the term "conflict" in a negative sense) is entirely up to the = ENUM client application. I had not heard this said before or seen it = written, but it certainly simplifies the problem of having two trees. =20 Ken. ________________________________ From: enum-bounces@ietf.org on behalf of Stastny Richard Sent: Wed 11/9/2005 4:43 PM To: Alexander Mayrhofer; enum@ietf.org Subject: Re: [Enum] please post issues from yesterdays session This was not brought up by me, but concerns our draft: The definitions and terminolgy used in draft-haberler-carrier-enum-01 should be moved over and aligned with the definitions and terminology in draft-lind-infrastructure-enum-reqs-01 Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Alexander Mayrhofer Gesendet: Mi 09.11.2005 18:37 An: enum@ietf.org Betreff: [Enum] please post issues from yesterdays session All, i'd like to ask you to post any issue which you brought up during yesterday's WG session on the list. that would make tracking those issues much more easier. thanks, 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 10 11:31:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaFL2-0004id-7o; Thu, 10 Nov 2005 11:31:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaFKz-0004iX-HP for enum@megatron.ietf.org; Thu, 10 Nov 2005 11:31:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14763 for ; Thu, 10 Nov 2005 11:31:16 -0500 (EST) Received: from peregrine.verisign.com ([216.168.239.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaFbE-0007Jw-M4 for enum@ietf.org; Thu, 10 Nov 2005 11:48:33 -0500 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.1/8.12.11) with ESMTP id jAAGmJpY004002; Thu, 10 Nov 2005 11:48:20 -0500 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Nov 2005 11:31:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Enum] please post issues from yesterdays session Date: Thu, 10 Nov 2005 11:31:28 -0500 Message-ID: Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcXlVWH1YbBDJ8aATsmGUb+Sbt+h6wAH6kHXAAgGIQYAB0PIOAAYHaP+ From: "Cartwright, Kenneth" To: "Stastny Richard" , X-OriginalArrivalTime: 10 Nov 2005 16:31:29.0229 (UTC) FILETIME=[33C637D0:01C5E614] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b 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="===============0908211587==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============0908211587== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E614.337CE454" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E614.337CE454 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Right. And furthermore, based on yesterday's explanation, the carrier = (COR) could legitimately choose to enter an "E2U+email:mailto" NAPRT or = an "E2U+web:http" NAPTR, etc, etc in the carrier ENUM tree for any of = their TNs. =20 Ken ________________________________ From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thu 11/10/2005 12:31 AM To: Cartwright, Kenneth; enum@ietf.org Subject: AW: [Enum] please post issues from yesterdays session HI Ken, I think it is a good idea to state this clearly somewhere. I am not sure = if this is a "requirement" but it may be useful to make this clarifcation there. The intersting issue about this is that this "non-conflict" was always = intrinsically there in User ENUM. If you made an entry in User ENUM for lets say a geographic number, = there was always the intrinsic asumption made that you still had a DIFFERENT terminatiion on the PSTN. = User ENUM is an additional service for the end-user. Nobody sees a "conflict" here. Infrastructure ENUM is now dealingwith the termination mentioned above. = An entry in Infrastucture ENUM is pointing to a border element of a "carrier" = hosting the number in question, regardless if this end-user is on IP or on the PSTN. So nothing has changed here. Before Infrastructure ENUM, a carrier could = choose to route the call conventionally on the PSTN or query User ENUM in addition (as = some VoIP providers do) Now the Carrier could chose again to route the call by querying = Infrastructure ENUM or to query User ENUM in addition. Looking up User ENUM is always a subscriber feature and opt-in. So the = user may either query User ENUM by himself, or the provider is querying User = ENUM ON BEHALF of the User. Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Cartwright, Kenneth Gesendet: Do 10.11.2005 02:41 An: enum@ietf.org Betreff: RE: [Enum] please post issues from yesterdays session I think it's a vital point that Patrik and Richard schooled me on: The = fact that the IETF will make *no* judgments or statements about the = appropriateness, precedence, or "conflict" resolution of NAPTRs in the = User ENUM tree and the Carrier ENUM tree for the same TN. The Carrier = ENUM tree may very well have NAPTRs for any ENUM service type for a = given TN, while NAPTRs for the same TN and the same ENUM service types, = but with perhaps different URIs, may also reside in the User ENUM tree = at the same time. The decision on which tree to query, and perhaps in = what order to query them, and perhaps how to resolve "conflicts" (I = don't use the term "conflict" in a negative sense) is entirely up to the = ENUM client application. I had not heard this said before or seen it = written, but it certainly simplifies the problem of having two trees. Ken. ________________________________ From: enum-bounces@ietf.org on behalf of Stastny Richard Sent: Wed 11/9/2005 4:43 PM To: Alexander Mayrhofer; enum@ietf.org Subject: Re: [Enum] please post issues from yesterdays session This was not brought up by me, but concerns our draft: The definitions and terminolgy used in draft-haberler-carrier-enum-01 should be moved over and aligned with the definitions and terminology in draft-lind-infrastructure-enum-reqs-01 Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Alexander Mayrhofer Gesendet: Mi 09.11.2005 18:37 An: enum@ietf.org Betreff: [Enum] please post issues from yesterdays session All, i'd like to ask you to post any issue which you brought up during yesterday's WG session on the list. that would make tracking those issues much more easier. thanks, 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 ------_=_NextPart_001_01C5E614.337CE454 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= AW: [Enum] please post issues from yesterdays session=0A= =0A= =0A=
=0A=
Right.  = And furthermore, =0A= based on yesterday's explanation, the carrier (COR) could legitimately = choose to =0A= enter an "E2U+email:mailto" NAPRT or an "E2U+web:http" NAPTR, etc, etc = in the =0A= carrier ENUM tree for any of their TNs.
=0A=
 
=0A=
Ken
=0A=

=0A=
=0A= From: Stastny Richard =0A= [mailto:Richard.Stastny@oefeg.at]
Sent: Thu 11/10/2005 12:31 =0A= AM
To: Cartwright, Kenneth; enum@ietf.org
Subject: = AW: =0A= [Enum] please post issues from yesterdays session

=0A=
=0A=

HI Ken,

I think it is a good idea to state this = clearly =0A= somewhere. I am not sure if this is a "requirement"
but it may be = useful to =0A= make this clarifcation there.

The intersting issue about this is = that =0A= this "non-conflict" was always intrinsically there in User ENUM.
If = you made =0A= an entry in User ENUM for lets say a geographic number, there was always = the =0A= intrinsic
asumption made that you still had a DIFFERENT terminatiion = on the =0A= PSTN. User ENUM is an additional
service for the end-user. Nobody = sees a =0A= "conflict" here.

Infrastructure ENUM is now dealingwith  the =0A= termination mentioned above. An entry
in Infrastucture ENUM is = pointing to a =0A= border element of a "carrier" hosting the number in
question, = regardless if =0A= this end-user is on IP or on the PSTN.

So nothing has changed = here. =0A= Before Infrastructure ENUM, a carrier could choose to route
the call =0A= conventionally on the PSTN or query User ENUM in addition (as some VoIP =0A= providers do)

Now the Carrier could chose again to route the call = by =0A= querying Infrastructure ENUM or to
query User ENUM in =0A= addition.

Looking up User ENUM is always a subscriber feature and = opt-in. =0A= So the user
may either query User ENUM by himself, or the provider is =0A= querying User ENUM
ON BEHALF of the =0A= User.

Richard

________________________________

Von: =0A= enum-bounces@ietf.org im Auftrag von Cartwright, Kenneth
Gesendet: Do =0A= 10.11.2005 02:41
An: enum@ietf.org
Betreff: RE: [Enum] please post = issues =0A= from yesterdays session


I think it's a vital point that = Patrik and =0A= Richard schooled me on:  The fact that the IETF will make *no* = judgments or =0A= statements about the appropriateness, precedence, or "conflict" = resolution of =0A= NAPTRs in the User ENUM tree and the Carrier ENUM tree for the same = TN.  =0A= The Carrier ENUM tree may very well have NAPTRs for any ENUM service = type for a =0A= given TN, while NAPTRs for the same TN and the same ENUM service types, = but with =0A= perhaps different URIs, may also reside in the User ENUM tree at the = same =0A= time.  The decision on which tree to query, and perhaps in what = order to =0A= query them, and perhaps how to resolve "conflicts" (I don't use the term =0A= "conflict" in a negative sense) is entirely up to the ENUM client =0A= application.   I had not heard this said before or seen it = written, =0A= but it certainly simplifies the problem of having two =0A= trees.

Ken.

________________________________

From: =0A= enum-bounces@ietf.org on behalf of Stastny Richard
Sent: Wed = 11/9/2005 4:43 =0A= PM
To: Alexander Mayrhofer; enum@ietf.org
Subject: Re: [Enum] = please post =0A= issues from yesterdays session



This was not brought up by = me, but =0A= concerns
our draft:

The definitions and terminolgy used =0A= in
draft-haberler-carrier-enum-01 should be moved over and = aligned
with =0A= the definitions and terminology =0A= in
draft-lind-infrastructure-enum-reqs-01

Richard

______= __________________________

Von: =0A= enum-bounces@ietf.org im Auftrag von Alexander Mayrhofer
Gesendet: Mi =0A= 09.11.2005 18:37
An: enum@ietf.org
Betreff: [Enum] please post = issues from =0A= yesterdays session



All,

i'd like to ask you to = post any =0A= issue which you brought up during
yesterday's WG session on the =0A= list.

that would make tracking those issues much more =0A= easier.

thanks,

alex


___________________________= ____________________
enum =0A= mailing list
enum@ietf.org
https://www1.ietf.or= g/mailman/listinfo/enum



______________________________= _________________
enum =0A= mailing list
enum@ietf.org
https://www1.ietf.or= g/mailman/listinfo/enum




=0A= =0A= =0A= ------_=_NextPart_001_01C5E614.337CE454-- --===============0908211587== 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 --===============0908211587==-- From enum-bounces@ietf.org Thu Nov 10 14:33:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaIB0-0008At-2B; Thu, 10 Nov 2005 14:33:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaIAv-00088t-Vn for enum@megatron.ietf.org; Thu, 10 Nov 2005 14:33:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28326 for ; Thu, 10 Nov 2005 14:33:04 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EaIJf-00059B-RP for enum@ietf.org; Thu, 10 Nov 2005 14:42:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] please post issues from yesterdays session Date: Thu, 10 Nov 2005 20:29:16 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C467B@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcXlVWH1YbBDJ8aATsmGUb+Sbt+h6wAH6kHXAAgGIQYAB0PIOAAYHaP+AAQOt5A= From: "Stastny Richard" To: "Cartwright, Kenneth" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: quoted-printable 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Yes. provided they do not disclose any privacy information of the end-user without asking him: =20 Additional question: they could, but why should they? =20 Richard ________________________________ Von: Cartwright, Kenneth [mailto:KCartwright@verisign.com] Gesendet: Do 10.11.2005 17:31 An: Stastny Richard; enum@ietf.org Betreff: RE: [Enum] please post issues from yesterdays session Right. And furthermore, based on yesterday's explanation, the carrier = (COR) could legitimately choose to enter an "E2U+email:mailto" NAPRT or = an "E2U+web:http" NAPTR, etc, etc in the carrier ENUM tree for any of = their TNs. =20 Ken ________________________________ From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thu 11/10/2005 12:31 AM To: Cartwright, Kenneth; enum@ietf.org Subject: AW: [Enum] please post issues from yesterdays session HI Ken, I think it is a good idea to state this clearly somewhere. I am not sure = if this is a "requirement" but it may be useful to make this clarifcation there. The intersting issue about this is that this "non-conflict" was always = intrinsically there in User ENUM. If you made an entry in User ENUM for lets say a geographic number, = there was always the intrinsic asumption made that you still had a DIFFERENT terminatiion on the PSTN. = User ENUM is an additional service for the end-user. Nobody sees a "conflict" here. Infrastructure ENUM is now dealingwith the termination mentioned above. = An entry in Infrastucture ENUM is pointing to a border element of a "carrier" = hosting the number in question, regardless if this end-user is on IP or on the PSTN. So nothing has changed here. Before Infrastructure ENUM, a carrier could = choose to route the call conventionally on the PSTN or query User ENUM in addition (as = some VoIP providers do) Now the Carrier could chose again to route the call by querying = Infrastructure ENUM or to query User ENUM in addition. Looking up User ENUM is always a subscriber feature and opt-in. So the = user may either query User ENUM by himself, or the provider is querying User = ENUM ON BEHALF of the User. Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Cartwright, Kenneth Gesendet: Do 10.11.2005 02:41 An: enum@ietf.org Betreff: RE: [Enum] please post issues from yesterdays session I think it's a vital point that Patrik and Richard schooled me on: The = fact that the IETF will make *no* judgments or statements about the = appropriateness, precedence, or "conflict" resolution of NAPTRs in the = User ENUM tree and the Carrier ENUM tree for the same TN. The Carrier = ENUM tree may very well have NAPTRs for any ENUM service type for a = given TN, while NAPTRs for the same TN and the same ENUM service types, = but with perhaps different URIs, may also reside in the User ENUM tree = at the same time. The decision on which tree to query, and perhaps in = what order to query them, and perhaps how to resolve "conflicts" (I = don't use the term "conflict" in a negative sense) is entirely up to the = ENUM client application. I had not heard this said before or seen it = written, but it certainly simplifies the problem of having two trees. Ken. ________________________________ From: enum-bounces@ietf.org on behalf of Stastny Richard Sent: Wed 11/9/2005 4:43 PM To: Alexander Mayrhofer; enum@ietf.org Subject: Re: [Enum] please post issues from yesterdays session This was not brought up by me, but concerns our draft: The definitions and terminolgy used in draft-haberler-carrier-enum-01 should be moved over and aligned with the definitions and terminology in draft-lind-infrastructure-enum-reqs-01 Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Alexander Mayrhofer Gesendet: Mi 09.11.2005 18:37 An: enum@ietf.org Betreff: [Enum] please post issues from yesterdays session All, i'd like to ask you to post any issue which you brought up during yesterday's WG session on the list. that would make tracking those issues much more easier. thanks, 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Nov 11 12:29:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eacid-0003T8-6U; Fri, 11 Nov 2005 12:29:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eacib-0003Sn-H6 for enum@megatron.ietf.org; Fri, 11 Nov 2005 12:29:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22002 for ; Fri, 11 Nov 2005 12:29:11 -0500 (EST) Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eacz3-0005fo-Ve for enum@ietf.org; Fri, 11 Nov 2005 12:46:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] please post issues from yesterdays session Date: Fri, 11 Nov 2005 12:28:56 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C730EEC8C@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcXlVOESHAaUx3AgTgq+rXFIqZVGVwABoDgAAAaxdJAAWvp9JQ== From: "Creighton, Tom" To: "McCandless, Kevin" , "Livingood, Jason" , "Alexander Mayrhofer" , X-OriginalArrivalTime: 11 Nov 2005 17:28:57.0788 (UTC) FILETIME=[65B04FC0:01C5E6E5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org What happens if the number you are performing a PSTN URI query on isn't = ported? Wouldn't you want to receive an NXDOMAIN and fall back to the = PSTN anyway? =20 Also, having to add any type of response record for every number that = isn't ported, would result in an enormous database on day 1. ________________________________ From: enum-bounces@ietf.org on behalf of McCandless, Kevin Sent: Wed 11/9/2005 4:41 PM To: Livingood, Jason; Alexander Mayrhofer; enum@ietf.org Subject: RE: [Enum] please post issues from yesterdays session I would also add to the list that if you perform a PSTN URI query and no record exists that you consider a value to return. One that comes to mind is 'Void'. There was a draft discussed in this working group for the use of value. Thoughts? -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Livingood, Jason Sent: Wednesday, November 09, 2005 1:08 PM To: Alexander Mayrhofer; enum@ietf.org Subject: RE: [Enum] please post issues from yesterdays session I noted that during my presentation on "draft-ietf-enum-pstn-00" the following issues were discussed and decided upon: 1. Minor nits with the draft will be resolved and I will re-submit to up-rev to -01. 2. Must revisit the section on Distribution of Data to note that it may or may not be done on a private basis. This will be primarily determined based on regulatory requirements in a particular country. I have not determined the exact wording of this yet. 3. After fixing the nits and word-smithing #2 above (resulting in -01), we will work on -02 with new suggested data types. These include CNAM and 800 number data, per feedback from Kevin McCandless. (This would not include Global Title Translation - which was a question raised by the co-chair.) The co-authors are open to any other suggestions. Separately, the need was again confirmed for a guide to creating an enumservice I-D. This work will be undertaken by members of the WG in the near future. Regards Jason Livingood > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On > Behalf Of Alexander Mayrhofer > Sent: Wednesday, November 09, 2005 12:38 PM > To: enum@ietf.org > Subject: [Enum] please post issues from yesterdays session > > All, > > i'd like to ask you to post any issue which you brought up > during yesterday's WG session on the list. > > that would make tracking those issues much more easier. > > thanks, > > 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 _______________________________________________ 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 Nov 11 13:33:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eadim-0007jc-TI; Fri, 11 Nov 2005 13:33:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eadik-0007jB-Fp for enum@megatron.ietf.org; Fri, 11 Nov 2005 13:33:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26155 for ; Fri, 11 Nov 2005 13:33:24 -0500 (EST) Received: from shaun.rfc1035.com ([195.54.233.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EadzC-0008NK-GE for enum@ietf.org; Fri, 11 Nov 2005 13:50:56 -0500 Received: from [195.54.233.69] (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id jABIXOd3016659; Fri, 11 Nov 2005 18:33:24 GMT In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C730EEC8C@PACDCEXCMB01.cable.comcast.com> References: <6EEEACD9D7F52940BEE26F5467C02C730EEC8C@PACDCEXCMB01.cable.comcast.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5846968A-9591-497B-B8F1-202C583B8AF3@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] please post issues from yesterdays session Date: Fri, 11 Nov 2005 18:33:18 +0000 To: "Creighton, Tom" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, "Livingood, Jason" , "McCandless, Kevin" , Alexander Mayrhofer 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On Nov 11, 2005, at 17:28, Creighton, Tom wrote: > What happens if the number you are performing a PSTN URI query on > isn't ported? Wouldn't you want to receive an NXDOMAIN and fall > back to the PSTN anyway? Nope. That only works if the number is reachable over the PSTN. If the number is VoIP only, it may be impossible to terminate calls to that number on the PSTN. This was one of the motivations behind the void NAPTR draft. That allows ENUM clients (such as SIP) gateways to make a distinction between numbers that are not entered into ENUM and numbers which don't have service or can't be reached from the PSTN. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Nov 11 14:19:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaeQf-0007SI-7B; Fri, 11 Nov 2005 14:19:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaeQd-0007SA-L7 for enum@megatron.ietf.org; Fri, 11 Nov 2005 14:19:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29137 for ; Fri, 11 Nov 2005 14:18:45 -0500 (EST) 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 1Eaeh3-0001vZ-Vy for enum@ietf.org; Fri, 11 Nov 2005 14:36:17 -0500 Received: from ([10.20.62.12]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.14944959; Fri, 11 Nov 2005 14:18:43 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCRLY02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 11 Nov 2005 14:18:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] please post issues from yesterdays session Date: Fri, 11 Nov 2005 14:18:42 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C730EEC90@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcXm7nXP2qzoZwA2T0uw5GIotrXTVgAA4uEY From: "Creighton, Tom" To: "Jim Reid" X-OriginalArrivalTime: 11 Nov 2005 19:18:43.0191 (UTC) FILETIME=[BAE51070:01C5E6F4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, "Livingood, Jason" , "McCandless, Kevin" , Alexander Mayrhofer 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org What would be the purpose of querying for PSTN routing data (LNP data in = the case of North America) as described in Jason's proposal if you = aren't destined for the PSTN? I envision querying for E2U+pstn records = in a private tree only after all other VoIP options are exhausted. That = being the case, if I were to receive an NXDOMAIN from this tree, it = would indicate that the number is not ported and that the call still = needs to be routed to the PSTN. =20 If the number were VoIP only, it would either have a NAPTR or void = record in e164.arpa that would route or terminate the call prior to = reaching the step mentioned above. ________________________________ From: Jim Reid [mailto:jim@rfc1035.com] Sent: Fri 11/11/2005 1:33 PM To: Creighton, Tom Cc: McCandless, Kevin; Livingood, Jason; Alexander Mayrhofer; = enum@ietf.org Subject: Re: [Enum] please post issues from yesterdays session On Nov 11, 2005, at 17:28, Creighton, Tom wrote: > What happens if the number you are performing a PSTN URI query on=20 > isn't ported? Wouldn't you want to receive an NXDOMAIN and fall=20 > back to the PSTN anyway? Nope. That only works if the number is reachable over the PSTN. If=20 the number is VoIP only, it may be impossible to terminate calls to=20 that number on the PSTN. This was one of the motivations behind the=20 void NAPTR draft. That allows ENUM clients (such as SIP) gateways to=20 make a distinction between numbers that are not entered into ENUM and=20 numbers which don't have service or can't be reached from the PSTN. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 14 10:05:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebfu0-0000q3-FZ; Mon, 14 Nov 2005 10:05:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebfty-0000pY-Rc for enum@megatron.ietf.org; Mon, 14 Nov 2005 10:05:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27749 for ; Mon, 14 Nov 2005 10:05:14 -0500 (EST) Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbgB1-0007oP-VV for enum@ietf.org; Mon, 14 Nov 2005 10:23:24 -0500 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id jAEFQD0p026934 for ; Mon, 14 Nov 2005 10:26:13 -0500 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Nov 2005 10:05:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] please post issues from yesterdays session Date: Mon, 14 Nov 2005 10:05:29 -0500 Message-ID: Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcXlVWH1YbBDJ8aATsmGUb+Sbt+h6wAH6kHXAAgGIQYAB0PIOAAYHaP+AAQOt5AAwlq/UA== From: "Cartwright, Kenneth" To: X-OriginalArrivalTime: 14 Nov 2005 15:05:29.0485 (UTC) FILETIME=[D9FAC3D0:01C5E92C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: quoted-printable 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I don't know why it would happen or if it would happen. Ken -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Thursday, November 10, 2005 2:29 PM To: Cartwright, Kenneth; enum@ietf.org Subject: Re: [Enum] please post issues from yesterdays session Yes. provided they do not disclose any privacy information of the end-user without asking him: =20 Additional question: they could, but why should they? =20 Richard ________________________________ Von: Cartwright, Kenneth [mailto:KCartwright@verisign.com] Gesendet: Do 10.11.2005 17:31 An: Stastny Richard; enum@ietf.org Betreff: RE: [Enum] please post issues from yesterdays session Right. And furthermore, based on yesterday's explanation, the carrier (COR) could legitimately choose to enter an "E2U+email:mailto" NAPRT or an "E2U+web:http" NAPTR, etc, etc in the carrier ENUM tree for any of their TNs. =20 Ken ________________________________ From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thu 11/10/2005 12:31 AM To: Cartwright, Kenneth; enum@ietf.org Subject: AW: [Enum] please post issues from yesterdays session HI Ken, I think it is a good idea to state this clearly somewhere. I am not sure if this is a "requirement" but it may be useful to make this clarifcation there. The intersting issue about this is that this "non-conflict" was always intrinsically there in User ENUM. If you made an entry in User ENUM for lets say a geographic number, there was always the intrinsic asumption made that you still had a DIFFERENT terminatiion on the PSTN. User ENUM is an additional service for the end-user. Nobody sees a "conflict" here. Infrastructure ENUM is now dealingwith the termination mentioned above. An entry in Infrastucture ENUM is pointing to a border element of a "carrier" hosting the number in question, regardless if this end-user is on IP or on the PSTN. So nothing has changed here. Before Infrastructure ENUM, a carrier could choose to route the call conventionally on the PSTN or query User ENUM in addition (as some VoIP providers do) Now the Carrier could chose again to route the call by querying Infrastructure ENUM or to query User ENUM in addition. Looking up User ENUM is always a subscriber feature and opt-in. So the user may either query User ENUM by himself, or the provider is querying User ENUM ON BEHALF of the User. Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Cartwright, Kenneth Gesendet: Do 10.11.2005 02:41 An: enum@ietf.org Betreff: RE: [Enum] please post issues from yesterdays session I think it's a vital point that Patrik and Richard schooled me on: The fact that the IETF will make *no* judgments or statements about the appropriateness, precedence, or "conflict" resolution of NAPTRs in the User ENUM tree and the Carrier ENUM tree for the same TN. The Carrier ENUM tree may very well have NAPTRs for any ENUM service type for a given TN, while NAPTRs for the same TN and the same ENUM service types, but with perhaps different URIs, may also reside in the User ENUM tree at the same time. The decision on which tree to query, and perhaps in what order to query them, and perhaps how to resolve "conflicts" (I don't use the term "conflict" in a negative sense) is entirely up to the ENUM client application. I had not heard this said before or seen it written, but it certainly simplifies the problem of having two trees. Ken. ________________________________ From: enum-bounces@ietf.org on behalf of Stastny Richard Sent: Wed 11/9/2005 4:43 PM To: Alexander Mayrhofer; enum@ietf.org Subject: Re: [Enum] please post issues from yesterdays session This was not brought up by me, but concerns our draft: The definitions and terminolgy used in draft-haberler-carrier-enum-01 should be moved over and aligned with the definitions and terminology in draft-lind-infrastructure-enum-reqs-01 Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Alexander Mayrhofer Gesendet: Mi 09.11.2005 18:37 An: enum@ietf.org Betreff: [Enum] please post issues from yesterdays session All, i'd like to ask you to post any issue which you brought up during yesterday's WG session on the list. that would make tracking those issues much more easier. thanks, 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 14 10:42:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbgT4-0000ZA-6r; Mon, 14 Nov 2005 10:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbgT2-0000Yo-BY for enum@megatron.ietf.org; Mon, 14 Nov 2005 10:42:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29908 for ; Mon, 14 Nov 2005 10:41:27 -0500 (EST) Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebgk4-0000af-Jw for enum@ietf.org; Mon, 14 Nov 2005 10:59:38 -0500 Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id jAEG2U1R028643 for ; Mon, 14 Nov 2005 11:02:30 -0500 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Nov 2005 10:41:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Nov 2005 10:41:45 -0500 Message-ID: Thread-Topic: draft-haberler-carrier-enum-01 Thread-Index: AcXpMesc9KB+XG6tQpOmc9xx4zdJqg== From: "Cartwright, Kenneth" To: X-OriginalArrivalTime: 14 Nov 2005 15:41:46.0071 (UTC) FILETIME=[EB536E70:01C5E931] X-Spam-Score: 0.4 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Subject: [Enum] draft-haberler-carrier-enum-01 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="===============0493942173==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============0493942173== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E931.EB15FF04" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E931.EB15FF04 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable A couple follow up questions on this doc: =20 1) Has a decision been made on whether Carrier/Infra ENUM will be specificed as a new DDDS Application or an extension to the existing ENUM DDDS Application defined by 3761, or something else entirely? The BLR mechanism in draft-haberler-carrier-enum-01 necessitates either a change to the existing First Well Known Rule defined in 3761 (to account for the BLR algorithm), or the creation of a separate DDDS app with its own First Well Known Rule. The First Well Known Rule in a DDDS application is supposed to specify the algorithm by which the first Database Key to look up (a domain name in ENUM's case) is constructed. =20 I think a couple operative drivers here are: a) If Infra ENUM is added into 3761 there may be, depending on how the new spec is worded, ramifications on what can accurately be called an ENUM resolver or an ENUM application. b) If a separate DDDS application is created then the "ENUM Services" specifications may need to be re-visited or re-categorized as applying to both DDDS applications. =20 2) It this sentence in the third paragraph of part 4 speaking to the first "Case" or the second "Case"? =20 "This approach, putting aside significant process and timing concerns, appears to be an easier to manage long-term approach to tree naming." =20 Thanks. =20 --=20 | Ken Cartwright | Work: kcartwright@verisign.com | Tel: +1 703 948 4339 | | Home: ken@thecartwrights.net | Fax: +1 703 948 4331 | | | Mobile: +1 703 307 6172 =20 ------_=_NextPart_001_01C5E931.EB15FF04 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

A couple follow up questions on this = doc:

 

1) Has a decision been made on whether Carrier/Infra = ENUM will be specificed as a new DDDS Application or an extension to the = existing ENUM DDDS Application defined by 3761, or something else entirely?  = The BLR mechanism in draft-haberler-carrier-enum-01 necessitates either a = change to the existing First Well Known Rule defined in 3761 (to account for the = BLR algorithm), or the creation of a separate DDDS app with its own First = Well Known Rule.  The First Well Known Rule in a DDDS application is = supposed to specify the algorithm by which the first Database Key to look up (a = domain name in ENUM’s case) is constructed.

 

I think a couple operative drivers here = are:

a) If Infra ENUM is added into 3761 there may be, = depending on how the new spec is worded, ramifications on what can accurately be = called an ENUM resolver or an ENUM application.

b) If a separate DDDS application is created then the = “ENUM Services” specifications may need to be re-visited or = re-categorized as applying to both DDDS applications.

 

2) It this sentence in the third paragraph of part 4 = speaking to the first “Case” or the second = “Case”?

 

“This approach, putting aside significant = process and timing concerns, appears to be an easier to manage long-term approach to = tree naming.”

 

Thanks.

 

--

| Ken Cartwright | Work: kcartwright@verisign.com | = Tel: +1 703 948 4339

| =             &= nbsp;         | Home: ken@thecartwrights.net &n= bsp;  | Fax: +1 703 948 4331

|    &nb= sp;           &nbs= p;      | =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;| Mobile: +1 703 307 6172

 

=00 ------_=_NextPart_001_01C5E931.EB15FF04-- --===============0493942173== 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 --===============0493942173==-- From enum-bounces@ietf.org Mon Nov 14 10:48:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbgZO-00023m-2G; Mon, 14 Nov 2005 10:48:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbgZM-00023X-6O for enum@megatron.ietf.org; Mon, 14 Nov 2005 10:48:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00418 for ; Mon, 14 Nov 2005 10:47:59 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbgqO-0000ri-9w for enum@ietf.org; Mon, 14 Nov 2005 11:06:08 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id jAEFm8sk012405; Mon, 14 Nov 2005 08:48:08 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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] Re: I-D ACTION:draft-conroy-enum-edns0-01.txt Date: Mon, 14 Nov 2005 08:48:08 -0700 Message-ID: Thread-Topic: [Enum] Re: I-D ACTION:draft-conroy-enum-edns0-01.txt Thread-Index: AcXi+vbVJYk6h+ytSvC/n6inenFWbACW2vxw From: "Jean-Francois Mule" To: "lconroy" , "Jim Reid" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: IETF ENUM WG , Olafur Gudmundsson 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Here are a couple of comments on the enum-edns0 draft to follow up on = the question I raised at the mike last week.=20 --- 1. Update to RFC3761 and MUST requirements To recap the mike interaction, I asked a question on the level of = requirements for the client and server side. Olafur Gudmundsson then = stated that EDNS0 must be implemented. EDNS0 does seem a necessary addition to ENUM clients and servers but = before doing so by updating 3761 and adding normative MUST requirements, = I would recommend we get more info & experience on its implementation by = ENUM clients and DNS server folks. The question of 'backward compatibility' between ENUM DNS entities that = do not support EDNS0 (those implementations compliant with both the = obsoleted RFC2976 and 3761) and the ones that do support EDNS0 (this ID = or the 3761-update) should also be expanded in the draft. My original comment was motivated by the following posting on EDNS0 = interop testing on dnsext: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00842.html I did ping both co-authors and there has been no update on this EDNS0 = testing draft. This is where I think we need more implementation = feedback. --- 2. 'backward compatibility' with ENUM DNS entities Olafur and I did chat after the ENUM wg meeting, especially around the = question of backward compatibility. Here is what transpired: - consider adding some text in the draft to recommend how long enum = DNS clients supporting eDNS0 should cache the server's maximum payload = size (see RFC2671, 4.5.4), - consider adding some informative text around anycast DNS server = clouds (all enum servers belonging to an anycast group should support = eDNS0 or none; after playing the scenarios, having a mix of both will = likely result in some client confusion). I copy Olafur so he can add anything I've missed. Hope this helps. --- 3. Additional notes I wonder what the impact of supporting EDNS0 is on enum server = performance in the case where clients use max payload sizes without any = good guidance, especially since servers should not cache the client's = maximum payload size (this may be another reason for recommending a = reasonable max payload size for clients to support and advertise). Finally, you should consider adding some simple examples of enum RRsets = that cause the DNS response to be truncated. Jean-Fran=E7ois jfm@cablelabs.com > -----Original Message----- > From: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] > Sent: Sunday, November 06, 2005 10:50 AM > To: lconroy > Cc: IETF ENUM WG; Jim Reid; Peter Koch > Subject: Re: [Enum] Re: I-D ACTION:draft-conroy-enum-edns0-01.txt >=20 > On 6 nov 2005, at 05.16, lconroy wrote: >=20 > > Perhaps the draft should have a preface stating > > - "You need to understand DNS in order to do ENUM. > > These are some of the important items you MUST > > have in order for this to work well". >=20 > And the effective way of doing this is to point at a "BCP for how to > run DNS in 2005". >=20 > Let me talk with the DNSOP wg chairs asap. >=20 > paf >=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 Mon Nov 14 12:06:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebhmf-0001bw-Hz; Mon, 14 Nov 2005 12:06:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebhmd-0001br-Ct for enum@megatron.ietf.org; Mon, 14 Nov 2005 12:06:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04933 for ; Mon, 14 Nov 2005 12:05:46 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebi3g-0003Kn-KA for enum@ietf.org; Mon, 14 Nov 2005 12:23:57 -0500 Received: from [10.75.119.254] (wsip-24-120-60-190.lv.lv.cox.net [24.120.60.190]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jAEH6hj9019878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Nov 2005 09:06:43 -0800 Message-ID: <4378C3AC.7050600@shockey.us> Date: Mon, 14 Nov 2005 12:04:44 -0500 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Cartwright, Kenneth" Subject: Re: [Enum] draft-haberler-carrier-enum-01 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 1.0 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Cartwright, Kenneth wrote: > A couple follow up questions on this doc: > > > > 1) Has a decision been made on whether Carrier/Infra ENUM will be > specificed as a new DDDS Application or an extension to the existing > ENUM DDDS Application defined by 3761, or something else entirely? No decision has been made. There needs to be a requirements document first. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 14 12:48:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbiRL-0006uY-Sb; Mon, 14 Nov 2005 12:48:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbiRI-0006tu-Sa for enum@megatron.ietf.org; Mon, 14 Nov 2005 12:48:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08425 for ; Mon, 14 Nov 2005 12:47:49 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbiiI-0004zh-5i for enum@ietf.org; Mon, 14 Nov 2005 13:05:56 -0500 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id jAEHm4vG005023; Mon, 14 Nov 2005 09:48:05 -0800 Received: from OVE1WNEXCB02.vcorp.ad.vrsn.com ([10.60.13.34]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Nov 2005 09:48:04 -0800 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] please post issues from yesterdays session Date: Mon, 14 Nov 2005 11:48:04 -0600 Message-ID: <122A5731B827474C99ED552C6BFE23ED133A78@OVE1WNEXCB02.vcorp.ad.vrsn.com> Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcXm7nXP2qzoZwA2T0uw5GIotrXTVgAA4uEYAJRVj7A= From: "McCandless, Kevin" To: "Creighton, Tom" , "Jim Reid" X-OriginalArrivalTime: 14 Nov 2005 17:48:04.0858 (UTC) FILETIME=[90A28DA0:01C5E943] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, Alexander Mayrhofer , "Livingood, Jason" 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I still think that using VOID is cleaner the NXDOMAIN. You could have VOID for two reasons. Record does not exist for VoIP and there is no LNP data available. -----Original Message----- From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com]=20 Sent: Friday, November 11, 2005 1:19 PM To: Jim Reid Cc: McCandless, Kevin; Livingood, Jason; Alexander Mayrhofer; enum@ietf.org Subject: RE: [Enum] please post issues from yesterdays session What would be the purpose of querying for PSTN routing data (LNP data in the case of North America) as described in Jason's proposal if you aren't destined for the PSTN? I envision querying for E2U+pstn records in a private tree only after all other VoIP options are exhausted. That being the case, if I were to receive an NXDOMAIN from this tree, it would indicate that the number is not ported and that the call still needs to be routed to the PSTN. =20 If the number were VoIP only, it would either have a NAPTR or void record in e164.arpa that would route or terminate the call prior to reaching the step mentioned above. ________________________________ From: Jim Reid [mailto:jim@rfc1035.com] Sent: Fri 11/11/2005 1:33 PM To: Creighton, Tom Cc: McCandless, Kevin; Livingood, Jason; Alexander Mayrhofer; enum@ietf.org Subject: Re: [Enum] please post issues from yesterdays session On Nov 11, 2005, at 17:28, Creighton, Tom wrote: > What happens if the number you are performing a PSTN URI query on=20 > isn't ported? Wouldn't you want to receive an NXDOMAIN and fall=20 > back to the PSTN anyway? Nope. That only works if the number is reachable over the PSTN. If=20 the number is VoIP only, it may be impossible to terminate calls to=20 that number on the PSTN. This was one of the motivations behind the=20 void NAPTR draft. That allows ENUM clients (such as SIP) gateways to=20 make a distinction between numbers that are not entered into ENUM and=20 numbers which don't have service or can't be reached from the PSTN. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 14 14:42:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbkDK-0002xJ-Ap; Mon, 14 Nov 2005 14:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbkDJ-0002x9-2l for enum@megatron.ietf.org; Mon, 14 Nov 2005 14:42:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17209 for ; Mon, 14 Nov 2005 14:41:29 -0500 (EST) Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbkUM-0000y1-OU for enum@ietf.org; Mon, 14 Nov 2005 14:59:41 -0500 Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id jAEK2SIe006027; Mon, 14 Nov 2005 15:02:28 -0500 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Nov 2005 14:41:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] draft-haberler-carrier-enum-01 Date: Mon, 14 Nov 2005 14:41:41 -0500 Message-ID: Thread-Topic: [Enum] draft-haberler-carrier-enum-01 Thread-Index: AcXpPbxRoIYOYD2xQfaF2pQAf7FAzgAEht3A From: "Cartwright, Kenneth" To: "Richard Shockey" X-OriginalArrivalTime: 14 Nov 2005 19:41:41.0489 (UTC) FILETIME=[6FA9E610:01C5E953] X-Spam-Score: 1.0 (+) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Ok, point taken. But I think you'd agree that the referenced document goes well beyond requirements. It's proposing a technical solution to infrastructure ENUM that could be made part of the existing ENUM specification or created as a separate specification. And the answer to this question is, imho, really a key aspect of the proposal. Is it proposing an expansion to the definition of what it means to be "ENUM compliant" or is it proposing something separable? Just a question, not a judgment call. Thanks. Ken. -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us]=20 Sent: Monday, November 14, 2005 12:05 PM To: Cartwright, Kenneth Cc: enum@ietf.org Subject: Re: [Enum] draft-haberler-carrier-enum-01 Cartwright, Kenneth wrote: > A couple follow up questions on this doc: >=20 > =20 >=20 > 1) Has a decision been made on whether Carrier/Infra ENUM will be=20 > specificed as a new DDDS Application or an extension to the existing=20 > ENUM DDDS Application defined by 3761, or something else entirely?=20 No decision has been made. There needs to be a requirements document first. --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 16 14:16:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcSmB-0004J3-11; Wed, 16 Nov 2005 14:16:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcSmA-0004Iu-1S for enum@megatron.ietf.org; Wed, 16 Nov 2005 14:16:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18276 for ; Wed, 16 Nov 2005 14:16:23 -0500 (EST) Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcT3d-00059E-OM for enum@ietf.org; Wed, 16 Nov 2005 14:35:02 -0500 Received: from ([10.20.9.172]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.14958102; Wed, 16 Nov 2005 14:16:21 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 14:16:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] please post issues from yesterdays session Date: Wed, 16 Nov 2005 14:16:20 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A39977@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcXm7nXP2qzoZwA2T0uw5GIotrXTVgAA4uEYAJRVj7AACIw+oA== From: "Livingood, Jason" To: "McCandless, Kevin" , X-OriginalArrivalTime: 16 Nov 2005 19:16:21.0565 (UTC) FILETIME=[3A8B66D0:01C5EAE2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Kevin McCandless wrote: > I still think that using VOID is cleaner the NXDOMAIN. You=20 > could have VOID for two reasons. Record does not exist for=20 > VoIP and there is no LNP data available. I have been thinking more about this discussion since the IETF meeting. A VOID is intended to be used to tag a number as not in service, as compared with NXDOMAIN being for no record found. =20 In the call routing process, VOID should trigger a switch/proxy/user agent to play an announcement to the effect that a number is not in service. This typically stops any further call routing or call progression. =20 A query response of NXDOMAIN will result in a switch/proxy/user agent in progressing to the next step in the call lookup process. After failing all of the lookups, this may mean there is a default PSTN route of last resort which is used, or that a route to an IXC is used, or whatever. A primary purpose of using E2U+PSTN is to consolidate "on-net" and "off-net" call queries into a single DNS lookup (rather than say a DNS lookup, followed by an LNP dip, followed by a lookup in a LERG table, etc.). A service provider would typically create VOID records just for their numbers that were inactive so that takes care of that use case. And if there is no LNP data, there may still be an E2U+PSTN record; keep in mind that these records could very well include ported, pooled, and block numbers. =20 In any case, I think you want a return of NXDOMAIN if no record is found so that the call lookup process continues. Thus, I don't see a need for VOID records specific to E2U+PSTN as the existing VOID Enumservice type can be used by a service provider to indicate which of their numbers is not in service. Jason =20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 16 14:26:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcSuz-0007NZ-OI; Wed, 16 Nov 2005 14:26:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcSux-0007Mt-SQ for enum@megatron.ietf.org; Wed, 16 Nov 2005 14:26:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18843 for ; Wed, 16 Nov 2005 14:25:29 -0500 (EST) 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 1EcTCR-0005UQ-F3 for enum@ietf.org; Wed, 16 Nov 2005 14:44:08 -0500 Received: from ([10.20.62.12]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.15052460; Wed, 16 Nov 2005 14:25:11 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCRLY02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 14:25:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] please post issues from yesterdays session (re CNAM in E2U+PSTN) Date: Wed, 16 Nov 2005 14:25:26 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A39978@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] please post issues from yesterdays session (re CNAM in E2U+PSTN) Thread-Index: AcXlVOESHAaUx3AgTgq+rXFIqZVGVwABoDgAAWG44AA= From: "Livingood, Jason" To: X-OriginalArrivalTime: 16 Nov 2005 19:25:27.0099 (UTC) FILETIME=[7FB548B0:01C5EAE3] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Coming to this last point of the discussion (see below). Folks voiced a desire to put CNAM (Calling Name) into the draft somehow, so I would like to seek out use cases. When performing SIP peering between service providers, the calling name and number should be transmitted just fine using SIP, so for on-net calls using SIP it should not be necessary. Other use cases I can come up with where it may be necessary: * Web apps (like maybe a call log viewer or address book) that queries for CNAM based on a TN that is displayed or inputted by a user. * Aggregating CNAM data for exchange with other PSTN-centric providers or other 3rd parties. * ?? So if anyone wishes to suggest other use cases to help Rich and I understand better how to solve this, I'd appreciate it. Also, if there are any suggestions as to what type of URI to put this in, I am all ears. Thanks! Jason Livingood=20 > -----Original Message----- > From: Livingood, Jason=20 > Sent: Wednesday, November 09, 2005 1:36 PM > To: Alexander Mayrhofer; enum@ietf.org > Subject: RE: [Enum] please post issues from yesterdays session >=20 > I noted that during my presentation on=20 > "draft-ietf-enum-pstn-00" the following issues were discussed=20 > and decided upon: > <<<>>> >=20 > 3. After fixing the nits and word-smithing #2 above=20 > (resulting in -01), we will work on -02 with new suggested=20 > data types. These include CNAM and 800 number data, per=20 > feedback from Kevin McCandless. (This would not include=20 > Global Title Translation - which was a question raised by the=20 > co-chair.) The co-authors are open to any other suggestions. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 16 16:01:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcUPQ-0007W0-8b; Wed, 16 Nov 2005 16:01:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcUPO-0007Ur-85 for enum@megatron.ietf.org; Wed, 16 Nov 2005 16:01:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25758 for ; Wed, 16 Nov 2005 16:00:58 -0500 (EST) Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcUgq-00012S-Ds for enum@ietf.org; Wed, 16 Nov 2005 16:19:37 -0500 Received: from rrc-dte-ieg01.cc.telcordia.com (rrc-dte-ieg01.cc.telcordia.com [128.96.20.22]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id jAGL1KB21443; Wed, 16 Nov 2005 16:01:20 -0500 (EST) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2005111616012100071 ; Wed, 16 Nov 2005 16:01:21 -0500 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 16 Nov 2005 16:01:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] please post issues from yesterdays session (re CNAM inE2U+PSTN) Date: Wed, 16 Nov 2005 16:01:20 -0500 Message-ID: Thread-Topic: [Enum] please post issues from yesterdays session (re CNAM inE2U+PSTN) Thread-Index: AcXlVOESHAaUx3AgTgq+rXFIqZVGVwABoDgAAWG44AAAAvVxkA== From: "Mowafy, Hala" To: "Livingood, Jason" , X-OriginalArrivalTime: 16 Nov 2005 21:01:21.0251 (UTC) FILETIME=[E5733330:01C5EAF0] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Jason, To add to your list below, there are validation applications in which the CNAM stored in a database, such as LIDB, is retrieved for comparison to data given by the party being validated. This is different from a web address book that may be publicly available. Having said that, and since you are describing information about PSTN services, I suggest one of your subtypes under 'tel: ' could be LIDB. It is a major source of a wide range of data that both PSTN and VoIP providers use (even beyond CNAM). Hala -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Livingood, Jason Sent: Wednesday, November 16, 2005 2:25 PM To: enum@ietf.org Subject: RE: [Enum] please post issues from yesterdays session (re CNAM inE2U+PSTN) Coming to this last point of the discussion (see below). Folks voiced a desire to put CNAM (Calling Name) into the draft somehow, so I would like to seek out use cases. When performing SIP peering between service providers, the calling name and number should be transmitted just fine using SIP, so for on-net calls using SIP it should not be necessary. Other use cases I can come up with where it may be necessary: * Web apps (like maybe a call log viewer or address book) that queries for CNAM based on a TN that is displayed or inputted by a user. * Aggregating CNAM data for exchange with other PSTN-centric providers or other 3rd parties. * ?? So if anyone wishes to suggest other use cases to help Rich and I understand better how to solve this, I'd appreciate it. Also, if there are any suggestions as to what type of URI to put this in, I am all ears. Thanks! Jason Livingood=20 > -----Original Message----- > From: Livingood, Jason > Sent: Wednesday, November 09, 2005 1:36 PM > To: Alexander Mayrhofer; enum@ietf.org > Subject: RE: [Enum] please post issues from yesterdays session >=20 > I noted that during my presentation on > "draft-ietf-enum-pstn-00" the following issues were discussed=20 > and decided upon: > <<<>>> >=20 > 3. After fixing the nits and word-smithing #2 above > (resulting in -01), we will work on -02 with new suggested=20 > data types. These include CNAM and 800 number data, per=20 > feedback from Kevin McCandless. (This would not include=20 > Global Title Translation - which was a question raised by the=20 > co-chair.) The co-authors are open to any other suggestions. _______________________________________________ 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 Nov 16 16:28:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcUp2-0007Fu-8S; Wed, 16 Nov 2005 16:28:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcUoz-0007Fp-Ui for enum@megatron.ietf.org; Wed, 16 Nov 2005 16:28:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01049 for ; Wed, 16 Nov 2005 16:27:28 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcV6V-0003FL-M4 for enum@ietf.org; Wed, 16 Nov 2005 16:46:08 -0500 Received: from [10.75.119.254] (wsip-24-120-60-190.lv.lv.cox.net [24.120.60.190]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jAGLSIjk030321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Nov 2005 13:28:19 -0800 Message-ID: <437BA448.2020307@shockey.us> Date: Wed, 16 Nov 2005 16:27:36 -0500 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Mowafy, Hala" Subject: Re: [Enum] please post issues from yesterdays session (re CNAM inE2U+PSTN) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, "Livingood, Jason" 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Mowafy, Hala wrote: > Jason, > To add to your list below, there are validation applications in which > the CNAM stored in a database, such as LIDB, is retrieved for comparison > to data given by the party being validated. This is different from a > web address book that may be publicly available. > Having said that, and since you are describing information about PSTN > services, I suggest one of your subtypes under 'tel: ' could be LIDB. > It is a major source of a wide range of data that both PSTN and VoIP > providers use (even beyond CNAM). Nice idea but how would you translate LIDB data into a IP format and what would be the URI necessary to query for the data requested? > > Hala > > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of > Livingood, Jason > Sent: Wednesday, November 16, 2005 2:25 PM > To: enum@ietf.org > Subject: RE: [Enum] please post issues from yesterdays session (re CNAM > inE2U+PSTN) > > > Coming to this last point of the discussion (see below). Folks voiced a > desire to put CNAM (Calling Name) into the draft somehow, so I would > like to seek out use cases. When performing SIP peering between service > providers, the calling name and number should be transmitted just fine > using SIP, so for on-net calls using SIP it should not be necessary. > > Other use cases I can come up with where it may be necessary: > * Web apps (like maybe a call log viewer or address book) that queries > for CNAM based on a TN that is displayed or inputted by a user. > > * Aggregating CNAM data for exchange with other PSTN-centric providers > or other 3rd parties. > > * ?? > > So if anyone wishes to suggest other use cases to help Rich and I > understand better how to solve this, I'd appreciate it. Also, if there > are any suggestions as to what type of URI to put this in, I am all > ears. > > Thanks! > Jason Livingood > > >>-----Original Message----- >>From: Livingood, Jason >>Sent: Wednesday, November 09, 2005 1:36 PM >>To: Alexander Mayrhofer; enum@ietf.org >>Subject: RE: [Enum] please post issues from yesterdays session >> >>I noted that during my presentation on >>"draft-ietf-enum-pstn-00" the following issues were discussed >>and decided upon: >> > > <<<>>> > >>3. After fixing the nits and word-smithing #2 above >>(resulting in -01), we will work on -02 with new suggested >>data types. These include CNAM and 800 number data, per >>feedback from Kevin McCandless. (This would not include >>Global Title Translation - which was a question raised by the >>co-chair.) The co-authors are open to any other suggestions. > > > _______________________________________________ > 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 > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 16 17:15:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcVZM-0003SB-Jt; Wed, 16 Nov 2005 17:15:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcVZK-0003Rb-H0 for enum@megatron.ietf.org; Wed, 16 Nov 2005 17:15:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03512 for ; Wed, 16 Nov 2005 17:15:17 -0500 (EST) Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcVql-0004jS-Ie for enum@ietf.org; Wed, 16 Nov 2005 17:33:57 -0500 Received: from pya-dte-ieg01.cc.telcordia.com (pya-dte-ieg01.cc.telcordia.com [128.96.20.21]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id jAGMFcB11701; Wed, 16 Nov 2005 17:15:38 -0500 (EST) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by pya-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2005111617153903398 ; Wed, 16 Nov 2005 17:15:39 -0500 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 16 Nov 2005 17:15:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] please post issues from yesterdays session (re CNAM inE2U+PSTN) Date: Wed, 16 Nov 2005 17:15:38 -0500 Message-ID: Thread-Topic: [Enum] please post issues from yesterdays session (re CNAM inE2U+PSTN) Thread-Index: AcXq9Ki1hiQ+qAVlQcWr90QeA5p7SAABeqrQ From: "Mowafy, Hala" To: X-OriginalArrivalTime: 16 Nov 2005 22:15:39.0355 (UTC) FILETIME=[46AFE2B0:01C5EAFB] X-Spam-Score: 0.8 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, "Livingood, Jason" 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard, LIDBs can have hub points of access that are members of the IP network. The URI would be the IP address of that hub, which in turn takes care of the routing. =20 As for the data from LIDB, the data could be encapsulated in a SIP message as payload or could be modified by the hub before it is returned. Hala -----Original Message----- From: richard@shockey.us [mailto:richard@shockey.us]=20 Sent: Wednesday, November 16, 2005 4:28 PM To: Mowafy, Hala Cc: Livingood, Jason; enum@ietf.org Subject: Re: [Enum] please post issues from yesterdays session (re CNAM inE2U+PSTN) Mowafy, Hala wrote: > Jason, > To add to your list below, there are validation applications in which=20 > the CNAM stored in a database, such as LIDB, is retrieved for=20 > comparison to data given by the party being validated. This is=20 > different from a web address book that may be publicly available.=20 > Having said that, and since you are describing information about PSTN=20 > services, I suggest one of your subtypes under 'tel: ' could be LIDB.=20 > It is a major source of a wide range of data that both PSTN and VoIP=20 > providers use (even beyond CNAM). Nice idea but how would you translate LIDB data into a IP format and=20 what would be the URI necessary to query for the data requested? >=20 > Hala >=20 > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf=20 > Of Livingood, Jason > Sent: Wednesday, November 16, 2005 2:25 PM > To: enum@ietf.org > Subject: RE: [Enum] please post issues from yesterdays session (re=20 > CNAM > inE2U+PSTN) >=20 >=20 > Coming to this last point of the discussion (see below). Folks voiced > a desire to put CNAM (Calling Name) into the draft somehow, so I would > like to seek out use cases. When performing SIP peering between=20 > service providers, the calling name and number should be transmitted=20 > just fine using SIP, so for on-net calls using SIP it should not be=20 > necessary. >=20 > Other use cases I can come up with where it may be necessary: > * Web apps (like maybe a call log viewer or address book) that queries > for CNAM based on a TN that is displayed or inputted by a user. >=20 > * Aggregating CNAM data for exchange with other PSTN-centric providers > or other 3rd parties. >=20 > * ?? >=20 > So if anyone wishes to suggest other use cases to help Rich and I=20 > understand better how to solve this, I'd appreciate it. Also, if=20 > there are any suggestions as to what type of URI to put this in, I am=20 > all ears. >=20 > Thanks! > Jason Livingood >=20 >=20 >>-----Original Message----- >>From: Livingood, Jason >>Sent: Wednesday, November 09, 2005 1:36 PM >>To: Alexander Mayrhofer; enum@ietf.org >>Subject: RE: [Enum] please post issues from yesterdays session >> >>I noted that during my presentation on "draft-ietf-enum-pstn-00" the=20 >>following issues were discussed and decided upon: >> >=20 > <<<>>> >=20 >>3. After fixing the nits and word-smithing #2 above (resulting in=20 >>-01), we will work on -02 with new suggested data types. These=20 >>include CNAM and 800 number data, per feedback from Kevin McCandless. >>(This would not include Global Title Translation - which was a=20 >>question raised by the >>co-chair.) The co-authors are open to any other suggestions. >=20 >=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 >=20 --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Nov 17 03:39:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcfIc-0007rm-0i; Thu, 17 Nov 2005 03:39:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcfIZ-0007rc-TP for enum@megatron.ietf.org; Thu, 17 Nov 2005 03:39:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07397 for ; Thu, 17 Nov 2005 03:38:42 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EcfaB-0008Ut-Cd for enum@ietf.org; Thu, 17 Nov 2005 03:57:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Enum] please post issues from yesterdays session Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Nov 2005 09:42:42 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B222C@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcXm7nXP2qzoZwA2T0uw5GIotrXTVgAA4uEYAJRVj7AACIw+oAB66E1A From: "Stastny Richard" To: "Livingood, Jason" , "McCandless, Kevin" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org May I add: As long as not ALL E.164 numbers are in ENUM, in one tree and the PSTN exists for default fallback, VOID is useful, for the reasons Jason points out below. If finally ALL E.164 numbers are in ENUM in the long term (when we are all dead ;-), NXDOMAIN may replace it, but even then direct response may be useful because of time-out purposes. There is only one problem with this: for "privacy?" and competitive reasons it currently looks like that ALL numbers of a number range assigned to an operator will be entered into Infrastructure ENUM (except the ported-out) and the signalling of "number not in service" will be left to the destination network. I do not consider this useful, but ... Even in the PSTN devices exist to "war-dial" number ranges and find out not-in-service numbers, so what? Richard > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of > Livingood, Jason > Sent: Wednesday, November 16, 2005 8:16 PM > To: McCandless, Kevin; enum@ietf.org > Subject: RE: [Enum] please post issues from yesterdays session >=20 >=20 > Kevin McCandless wrote: > > I still think that using VOID is cleaner the NXDOMAIN. You > > could have VOID for two reasons. Record does not exist for > > VoIP and there is no LNP data available. >=20 > I have been thinking more about this discussion since the IETF meeting. > A VOID is intended to be used to tag a number as not in service, as > compared with NXDOMAIN being for no record found. >=20 > In the call routing process, VOID should trigger a switch/proxy/user > agent to play an announcement to the effect that a number is not in > service. This typically stops any further call routing or call > progression. >=20 > A query response of NXDOMAIN will result in a switch/proxy/user agent in > progressing to the next step in the call lookup process. After failing > all of the lookups, this may mean there is a default PSTN route of last > resort which is used, or that a route to an IXC is used, or whatever. >=20 > A primary purpose of using E2U+PSTN is to consolidate "on-net" and > "off-net" call queries into a single DNS lookup (rather than say a DNS > lookup, followed by an LNP dip, followed by a lookup in a LERG table, > etc.). A service provider would typically create VOID records just for > their numbers that were inactive so that takes care of that use case. > And if there is no LNP data, there may still be an E2U+PSTN record; keep > in mind that these records could very well include ported, pooled, and > block numbers. >=20 > In any case, I think you want a return of NXDOMAIN if no record is found > so that the call lookup process continues. Thus, I don't see a need for > VOID records specific to E2U+PSTN as the existing VOID Enumservice type > can be used by a service provider to indicate which of their numbers is > not in service. >=20 >=20 > Jason >=20 >=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 Nov 17 09:29:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcklA-0002Ip-GK; Thu, 17 Nov 2005 09:29:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eckl9-0002Ik-Er for enum@megatron.ietf.org; Thu, 17 Nov 2005 09:29:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26957 for ; Thu, 17 Nov 2005 09:28:32 -0500 (EST) Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecl2n-0003ud-0e for enum@ietf.org; Thu, 17 Nov 2005 09:47:22 -0500 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id jAHET4f0009055; Thu, 17 Nov 2005 06:29:04 -0800 Received: from OVE1WNEXCB02.vcorp.ad.vrsn.com ([10.60.13.34]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 17 Nov 2005 06:29:06 -0800 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] please post issues from yesterdays session Date: Thu, 17 Nov 2005 08:29:02 -0600 Message-ID: <122A5731B827474C99ED552C6BFE23ED133D04@OVE1WNEXCB02.vcorp.ad.vrsn.com> Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcXm7nXP2qzoZwA2T0uw5GIotrXTVgAA4uEYAJRVj7AACIw+oACHXrNQ From: "McCandless, Kevin" To: "Livingood, Jason" , X-OriginalArrivalTime: 17 Nov 2005 14:29:06.0419 (UTC) FILETIME=[44029430:01C5EB83] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Good summary Jason. NXDOMAIN then for no records. -----Original Message----- From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 Sent: Wednesday, November 16, 2005 1:16 PM To: McCandless, Kevin; enum@ietf.org Subject: RE: [Enum] please post issues from yesterdays session Kevin McCandless wrote: > I still think that using VOID is cleaner the NXDOMAIN. You=20 > could have VOID for two reasons. Record does not exist for=20 > VoIP and there is no LNP data available. I have been thinking more about this discussion since the IETF meeting. A VOID is intended to be used to tag a number as not in service, as compared with NXDOMAIN being for no record found. =20 In the call routing process, VOID should trigger a switch/proxy/user agent to play an announcement to the effect that a number is not in service. This typically stops any further call routing or call progression. =20 A query response of NXDOMAIN will result in a switch/proxy/user agent in progressing to the next step in the call lookup process. After failing all of the lookups, this may mean there is a default PSTN route of last resort which is used, or that a route to an IXC is used, or whatever. A primary purpose of using E2U+PSTN is to consolidate "on-net" and "off-net" call queries into a single DNS lookup (rather than say a DNS lookup, followed by an LNP dip, followed by a lookup in a LERG table, etc.). A service provider would typically create VOID records just for their numbers that were inactive so that takes care of that use case. And if there is no LNP data, there may still be an E2U+PSTN record; keep in mind that these records could very well include ported, pooled, and block numbers. =20 In any case, I think you want a return of NXDOMAIN if no record is found so that the call lookup process continues. Thus, I don't see a need for VOID records specific to E2U+PSTN as the existing VOID Enumservice type can be used by a service provider to indicate which of their numbers is not in service. Jason =20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Nov 18 20:51:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdHt4-0001TZ-2T; Fri, 18 Nov 2005 20:51:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdHt3-0001TU-2C for enum@megatron.ietf.org; Fri, 18 Nov 2005 20:51:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28201 for ; Fri, 18 Nov 2005 20:50:53 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdIAy-0003Xc-36 for enum@ietf.org; Fri, 18 Nov 2005 21:10:02 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jAJ1plRd015988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 18 Nov 2005 17:51:50 -0800 Message-ID: <437E8508.5050407@shockey.us> Date: Fri, 18 Nov 2005 20:51:04 -0500 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: multipart/mixed; boundary="------------050700090607050505030605" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Subject: [Enum] [Fwd: RFC 4143 on Facsimile Using Internet Mail (IFAX) Service of ENUM] 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --------------050700090607050505030605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: RFC 4143 on Facsimile Using Internet Mail (IFAX) Service of ENUM Date: Fri, 18 Nov 2005 15:17:59 -0800 From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org CC: ietf-fax@imc.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 4143 Title: Facsimile Using Internet Mail (IFAX) Service of ENUM Author(s): K. Toyoda, D. Crocker Status: Standards Track Date: November 2005 Mailbox: toyoda.kiyoshi@jp.panasonic.com, dcrocker@bbiw.net Pages: 5 Characters: 8642 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-fax-faxservice-enum-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4143.txt This document describes the functional specification and definition of the ENUM Naming Authority Pointer (NAPTR) record for IFax service. IFax is "facsimile using Internet mail". For this use, the Domain Name System (DNS) returns the email address of the referenced IFax system. This mechanism allows email-based fax communication to use telephone numbers instead of requiring the sender to already know the recipient email address. This document is a product of the Internet Fax Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< --------------050700090607050505030605 Content-Type: Message/External-body; name="rfc4143.txt" Content-Disposition: inline; filename="rfc4143.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <051118151649.RFC@RFC-EDITOR.ORG> --------------050700090607050505030605 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --------------050700090607050505030605 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 --------------050700090607050505030605-- From enum-bounces@ietf.org Mon Nov 21 14:00:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeGtf-00082C-Kt; Mon, 21 Nov 2005 14:00:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeGte-000821-0R for enum@megatron.ietf.org; Mon, 21 Nov 2005 14:00:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23819 for ; Mon, 21 Nov 2005 13:59:31 -0500 (EST) Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeHC6-0004Yn-8P for enum@ietf.org; Mon, 21 Nov 2005 14:19:17 -0500 Received: from g8ibr.kiel01.telekom.de by tcmail31.dmz.telekom.de with ESMTP for enum@ietf.org; Mon, 21 Nov 2005 19:59:47 +0100 Received: by G8IBR.kiel01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Nov 2005 19:59:47 +0100 Message-Id: From: "Schiefner, Carsten" To: enum@ietf.org Subject: RE: [Enum] please post issues from yesterdays session Date: Mon, 21 Nov 2005 19:59:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Jason, all - > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Wednesday, November 09, 2005 8:08 PM > To: Alexander Mayrhofer; enum@ietf.org > Subject: RE: [Enum] please post issues from yesterdays session > > [...] > 2. Must revisit the section on Distribution of Data to note > that it may > or may not be done on a private basis. This will be primarily > determined based on regulatory requirements in a particular > country. I > have not determined the exact wording of this yet. even in the absence of any regulatory requirement, the LNP club itself might decide to not disclose this data to the public. Should that be reflected in your I-D, too - as a sort of fallback? Best, Carsten -- Carsten Schiefner | p: +49 441 234-4571 Deutsche Telekom AG | f: +49 431 7163-3972 T-Com Zentrale TK44 | m: +49 151 14525458 Ammerlander Heerstr. 138 | mailto:Carsten.Schiefner@t-com.net D-26129 Oldenburg | http://www.t-com.de/kundendienst _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 22 03:50:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeTr4-0004Hv-3O; Tue, 22 Nov 2005 03:50:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeTr3-0004Hq-3D for enum@megatron.ietf.org; Tue, 22 Nov 2005 03:50:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18487 for ; Tue, 22 Nov 2005 03:49:41 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeU9Z-0006nv-Ks for enum@ietf.org; Tue, 22 Nov 2005 04:09:36 -0500 Received: from [10.134.11.108] ([80.187.145.53]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jAM8oZM7012511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 22 Nov 2005 00:50:38 -0800 Message-ID: <4382DBAF.1000802@shockey.us> Date: Tue, 22 Nov 2005 03:49:51 -0500 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: [Enum] Reminder to ID authors. 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Documents approved as WG items in Vancouver etc should be resubmitted in the official manner of draft-ietf-enum-name-version00.txt as soon a reasonably possible so we can get them in the document tracking mechanism. Copies of ID submitted as WG items for the first time .. aka .00.txt versions must be submitted to the chairs so they can approve their submission to the ID editors. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 22 07:38:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeXPZ-0002Dd-VC; Tue, 22 Nov 2005 07:38:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeXPY-0002A7-2R for enum@megatron.ietf.org; Tue, 22 Nov 2005 07:38:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11635 for ; Tue, 22 Nov 2005 07:37:33 -0500 (EST) Received: from [193.80.224.123] (helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeXiB-0000Pz-GL for enum@ietf.org; Tue, 22 Nov 2005 07:57:28 -0500 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; Tue, 22 Nov 2005 13:37:36 +0100 id 0006840D.43831114.000063DE Message-ID: <438310FC.7070105@enum.at> Date: Tue, 22 Nov 2005 13:37:16 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5 (Windows/20051025) 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.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Subject: [Enum] vCard-draft - subtype considerations 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi, I'm updating the vCard Enumservice draft (http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-vcard-00.txt) to include subtypes. This would make the enumservice registration extensible once new methods of fetching vCards come up. I've came up with the following options: Enumservice URI scheme Note ----------- ---------- ---- vcard:plain http, https, ftp? RFC2426 - need better name? vcard:rdf http, https, ftp? http://www.w3.org/TR/vcard-rdf vcard:xml http, https, ftp? http://www.w3.org/TR/vcard-rdf vcard:carddav http, https draft-daboo-carddav-00.txt vcard:xmpp xmpp URI & vCard encap docs expired! vcard:ldap ldap, ldaps RFC2739 - URI reference, again! Anything else? It seems to me that the area of real time access to vCards is mostly undefined - i was unable to find out how vCards are supposed to be transported in the CALSCH framework, btw. I'd rather not like to include all of the methods above, mostly because that much choice would either lead to incompatibilities between implementations if methods are optional or to no implementations at all if _all_ protocols are mandatory... I've also done some "research" on clients & handsets using my "plain" vCard at http://nona.net/i/test.vcf (feel free to report more tests, esp. with mobile clients and groupware stuff!): - Windows with Palm Desktop installed: Both Firefox and IE open up Palm Desktop when visiting a vCard on http, Palm Desktop offers to add vCard to contact database - Windows with Outlook: Both Firefox and IE open up outlook, which offers to add it to the contacts - Nokia 6630: "object not supported" - SonyEricsson V800: offers to add contact to phone book - wow! I'd like to get the feeling of the WG about which service types should go into the document - i'm a bit nervous about adding too much of those, just to find out afterwards that 90% of those are never gonna make it... comments appreciated. alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 22 12:43:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EecAe-0004PJ-Cs; Tue, 22 Nov 2005 12:43:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EecAc-0004OD-Qa for enum@megatron.ietf.org; Tue, 22 Nov 2005 12:43:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16942 for ; Tue, 22 Nov 2005 12:42:28 -0500 (EST) Received: from bay103-f36.bay103.hotmail.com ([65.54.174.46] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EecT0-0008FG-J0 for enum@ietf.org; Tue, 22 Nov 2005 13:02:08 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 22 Nov 2005 09:42:36 -0800 Message-ID: Received: from 65.54.174.200 by by103fd.bay103.hotmail.msn.com with HTTP; Tue, 22 Nov 2005 17:42:36 GMT X-Originating-IP: [69.239.157.169] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com In-Reply-To: <4382DBAF.1000802@shockey.us> From: "Peter Williams" To: enum@ietf.org Subject: RE: [Enum] Reminder to ID authors. Date: Tue, 22 Nov 2005 09:42:36 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 22 Nov 2005 17:42:36.0525 (UTC) FILETIME=[203CE9D0:01C5EF8C] X-Spam-Score: 0.8 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org >From: Richard Shockey >To: "'enum@ietf.org'" >Subject: [Enum] Reminder to ID authors. >Date: Tue, 22 Nov 2005 03:49:51 -0500 >Copies of ID submitted as WG items for the first time .. aka .00.txt >versions must be submitted to the chairs so they can approve their >submission to the ID editors. Which is not to say, I hope, that the chair is attempt to supress/approve the contribution of individually-sponsored IDs on ENUM topics? Lets recall that all individuals have IETF rights to use the internet draft directories, not only WG members (and the WG chairs). Mailing list members (who are NOT the WG, remember) are entitled to discuss individual contributions note, with or without chair/AD topic approval (within limits). Lots of political consensus processes are served by this IETF "right of open publication/discussion" feature, especially when there are schisms over approaches to problems. its a uniquely American feature of open forum standards making; an IETF tradition thats well-worth preserving and - indeed - fostering. Peter. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 22 12:56:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EecNM-0008NE-OY; Tue, 22 Nov 2005 12:56:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EecNK-0008MY-Pl for enum@megatron.ietf.org; Tue, 22 Nov 2005 12:56:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19259 for ; Tue, 22 Nov 2005 12:55:35 -0500 (EST) 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 1Eecg0-0000s6-NI for enum@ietf.org; Tue, 22 Nov 2005 13:15:34 -0500 Received: from ([10.52.116.10]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.15186799; Tue, 22 Nov 2005 12:55:30 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 12:55:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] please post issues from yesterdays session Date: Tue, 22 Nov 2005 12:55:43 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A399F1@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcXuzofdYjehsEtUT5+faNehuh1bcQAvYqag From: "Livingood, Jason" To: "Schiefner, Carsten" , X-OriginalArrivalTime: 22 Nov 2005 17:55:43.0997 (UTC) FILETIME=[F59B9AD0:01C5EF8D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > > 2. Must revisit the section on Distribution of Data to=20 > note that it=20 > > may or may not be done on a private basis. This will be primarily=20 > > determined based on regulatory requirements in a particular=20 > country. =20 > > I have not determined the exact wording of this yet. >=20 > even in the absence of any regulatory requirement, the LNP=20 > club itself might decide to not disclose this data to the=20 > public. Should that be reflected in your I-D, too - as a sort=20 > of fallback? I think you are correct. Here is the text of that section of the document. I have included IN CAPS the text I was considering adding to address this. Let me know what you think. 3. Distribution of Data The distribution of number portability data is often highly restricted either by contract or regulation of a National Regulatory Authority (NRA). The NAPTR records described herein probably would not be part of the e164.arpa DNS tree. Distribution of this NAPTR data would be either (a) on a private basis (within a service provider's internal network, or on a private basis between one or more parties using a variety of security mechanisms to prohibit general public access), (b) openly available on a national basis according to national regulatory policy, OR (C) DISTRIBUTED BY THE RELEVANT NUMBER PORTABILITY ORGANIZATION OR OTHER INDUSTRY ORGANIZATION.=20 The authors believe that it is more likely that these records will be distributed on a purely private basis. If such data was distributed nationally, the national telephone numbering authority, or some other regulatory body OR NUMBERING ORGANIZATION, may have jurisdiction. Such a body may choose to restrict distribution of the data in such a way that it may not pass over that country's national borders. How number portability data is collected and distributed is out of scope of this document. Thanks Jason Livingood _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 22 14:13:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EedaK-00071u-7p; Tue, 22 Nov 2005 14:13:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EedVY-0006A7-O0 for enum@megatron.ietf.org; Tue, 22 Nov 2005 14:08:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26802 for ; Tue, 22 Nov 2005 14:08:07 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeddV-0004ry-OI for enum@ietf.org; Tue, 22 Nov 2005 14:17:03 -0500 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id jAMIsGO22038; Tue, 22 Nov 2005 13:54:16 -0500 (EST) Received: from zcarhxs1.corp.nortel.com ([47.129.230.89]) by zrtphxm2.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 13:57:17 -0500 Received: from [127.0.0.1] ([47.130.18.39] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 13:57:16 -0500 Message-ID: <43836A07.3020404@nortel.com> Date: Tue, 22 Nov 2005 13:57:11 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Williams Subject: Re: [Enum] Reminder to ID authors. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Nov 2005 18:57:17.0026 (UTC) FILETIME=[8ED31C20:01C5EF96] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org No, Peter, no devious political agenda here -- just implementation of the WG's right to decide which documents are WG items. The I-D editor will not accept -00 draft-ietf- documents without the Chair's approval. Peter Williams wrote: >> From: Richard Shockey >> To: "'enum@ietf.org'" >> Subject: [Enum] Reminder to ID authors. >> Date: Tue, 22 Nov 2005 03:49:51 -0500 > > >> Copies of ID submitted as WG items for the first time .. aka .00.txt >> versions must be submitted to the chairs so they can approve their >> submission to the ID editors. > > > Which is not to say, I hope, that the chair is attempt to > supress/approve the contribution of individually-sponsored IDs on ENUM > topics? > > Lets recall that all individuals have IETF rights to use the internet > draft directories, not only WG members (and the WG chairs). > > Mailing list members (who are NOT the WG, remember) are entitled to > discuss individual contributions note, with or without chair/AD topic > approval (within limits). > > Lots of political consensus processes are served by this IETF "right of > open publication/discussion" feature, especially when there are schisms > over approaches to problems. its a uniquely American feature of open > forum standards making; an IETF tradition thats well-worth preserving > and - indeed - fostering. > > Peter. > > > > _______________________________________________ > 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 Nov 28 05:21:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egg8P-0004Yh-Ua; Mon, 28 Nov 2005 05:21:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egg8P-0004Xn-53 for enum@megatron.ietf.org; Mon, 28 Nov 2005 05:21:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11821 for ; Mon, 28 Nov 2005 05:20:36 -0500 (EST) Received: from saturn.time-travellers.org ([193.0.0.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EggSC-0007Vc-SU for enum@ietf.org; Mon, 28 Nov 2005 05:41:52 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by saturn.time-travellers.org (Postfix) with ESMTP id 33239146D63 for ; Mon, 28 Nov 2005 11:20:55 +0100 (CET) Message-ID: <438ADA06.7020109@schiefner.de> Date: Mon, 28 Nov 2005 11:20:54 +0100 From: Carsten Schiefner User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org Subject: Re: [Enum] please post issues from yesterdays session References: <6EEEACD9D7F52940BEE26F5467C02C7302A399F1@PACDCEXCMB01.cable.comcast.com> In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C7302A399F1@PACDCEXCMB01.cable.comcast.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Jason, > I think you are correct. Here is the text of that section of the > document. I have included IN CAPS the text I was considering adding to > address this. Let me know what you think. how about: === 3. Distribution of Data The distribution of number portability data is often highly restricted either by contract or regulation of a National Regulatory Authority (NRA), THEREFORE NAPTR records described herein MAY OR MAY not be part of the e164.arpa DNS tree. Distribution of this NAPTR data would be either (a) on a private basis (within a service provider's internal network, or on a private basis between one or more parties using a variety of security mechanisms to prohibit general public access), (b) openly available, BUT MAYBE on a national basis ONLY according to national regulatory policy, OR (C) DISTRIBUTED BY THE RELEVANT NUMBER PORTABILITY ORGANIZATION OR OTHER INDUSTRY ORGANIZATION. The authors believe that it is more likely that these records will be distributed on a purely private basis. If such data was distributed nationally, the national telephone numbering authority, or some other regulatory body OR NUMBERING ORGANIZATION, may have jurisdiction. Such a body may choose to restrict distribution of the data in such a way that it may not pass over that country's national borders. How number portability data is collected and distributed is out of scope of this document. === Best, Carsten _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Nov 28 10:05:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgkZW-0000s9-DQ; Mon, 28 Nov 2005 10:05:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgkZU-0000s4-Sr for enum@megatron.ietf.org; Mon, 28 Nov 2005 10:05:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16735 for ; Mon, 28 Nov 2005 10:04:52 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgktN-0000f6-3C for enum@ietf.org; Mon, 28 Nov 2005 10:26:10 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jASF59B06046; Mon, 28 Nov 2005 10:05:09 -0500 (EST) 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] please post issues from yesterdays session Date: Mon, 28 Nov 2005 10:05:06 -0500 Message-ID: Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcX0BZrRFWbbW8FHTfeS/A4xFYv+GAAJ1WxQ From: "James McEachern" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: Carsten Schiefner 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This proposed text looks good to me. Jim -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of = Carsten Schiefner Sent: Monday, November 28, 2005 5:21 AM To: enum@ietf.org Subject: Re: [Enum] please post issues from yesterdays session Jason, > I think you are correct. Here is the text of that section of the > document. I have included IN CAPS the text I was considering adding = to > address this. Let me know what you think. how about: =3D=3D=3D 3. Distribution of Data The distribution of number portability data is often highly restricted=20 either by contract or regulation of a National Regulatory Authority=20 (NRA), THEREFORE NAPTR records described herein MAY OR MAY not be part=20 of the e164.arpa DNS tree. Distribution of this NAPTR data would be either (a) on a private basis=20 (within a service provider's internal network, or on a private basis=20 between one or more parties using a variety of security mechanisms to=20 prohibit general public access), (b) openly available, BUT MAYBE on a=20 national basis ONLY according to national regulatory policy, OR (C)=20 DISTRIBUTED BY THE RELEVANT NUMBER PORTABILITY ORGANIZATION OR OTHER=20 INDUSTRY ORGANIZATION. The authors believe that it is more likely that these records will be=20 distributed on a purely private basis. If such data was distributed=20 nationally, the national telephone numbering authority, or some other=20 regulatory body OR NUMBERING ORGANIZATION, may have jurisdiction. Such=20 a body may choose to restrict distribution of the data in such a way=20 that it may not pass over that country's national borders. How number=20 portability data is collected and distributed is out of scope of this=20 document. =3D=3D=3D Best, Carsten _______________________________________________ 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 Nov 28 11:27:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eglr5-0004Oe-4H; Mon, 28 Nov 2005 11:27:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eglr3-0004Mz-OH for enum@megatron.ietf.org; Mon, 28 Nov 2005 11:27:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26915 for ; Mon, 28 Nov 2005 11:27:04 -0500 (EST) Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgmAx-0003Z5-Sm for enum@ietf.org; Mon, 28 Nov 2005 11:48:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] please post issues from yesterdays session Date: Mon, 28 Nov 2005 11:24:38 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A39A3A@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcX0BaBzuFGV21bSQuCcvCZL49HDdwAMmw5A From: "Livingood, Jason" To: "Carsten Schiefner" , X-OriginalArrivalTime: 28 Nov 2005 16:24:41.0939 (UTC) FILETIME=[3C723230:01C5F438] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: Richard Shockey 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org All those changes look fine with one exception in wording on the 2nd change you requested. I have worded it as such: "Distribution of this NAPTR data would be either (a) on a private basis (within a service provider's internal network, or on a private basis between one or more parties using a variety of security mechanisms to prohibit general public access), (b) openly available, but possibly on a national basis and subject to or in accordance with national regulatory policy, or (c) distributed by the relevant number portability organization or other industry organization." I think this still captures what you were looking for. Let me know if that is not the case and I will take a second crack at it. Jason=20 > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of Carsten Schiefner > Sent: Monday, November 28, 2005 5:21 AM > To: enum@ietf.org > Subject: Re: [Enum] please post issues from yesterdays session >=20 > Jason, >=20 > > I think you are correct. Here is the text of that section of the=20 > > document. I have included IN CAPS the text I was=20 > considering adding=20 > > to address this. Let me know what you think. >=20 > how about: >=20 > =3D=3D=3D >=20 > 3. Distribution of Data >=20 > The distribution of number portability data is often highly=20 > restricted either by contract or regulation of a National=20 > Regulatory Authority (NRA), THEREFORE NAPTR records described=20 > herein MAY OR MAY not be part of the e164.arpa DNS tree. >=20 > Distribution of this NAPTR data would be either (a) on a=20 > private basis (within a service provider's internal network,=20 > or on a private basis between one or more parties using a=20 > variety of security mechanisms to prohibit general public=20 > access), (b) openly available, BUT MAYBE on a national basis=20 > ONLY according to national regulatory policy, OR (C)=20 > DISTRIBUTED BY THE RELEVANT NUMBER PORTABILITY ORGANIZATION=20 > OR OTHER INDUSTRY ORGANIZATION. >=20 > The authors believe that it is more likely that these records=20 > will be distributed on a purely private basis. If such data=20 > was distributed nationally, the national telephone numbering=20 > authority, or some other regulatory body OR NUMBERING=20 > ORGANIZATION, may have jurisdiction. Such a body may choose=20 > to restrict distribution of the data in such a way that it=20 > may not pass over that country's national borders. How=20 > number portability data is collected and distributed is out=20 > of scope of this document. >=20 > =3D=3D=3D >=20 > Best, >=20 > Carsten >=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 From enum-bounces@ietf.org Tue Nov 29 03:52:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh1E2-0006dj-0o; Tue, 29 Nov 2005 03:52:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh1E0-0006dX-87 for enum@megatron.ietf.org; Tue, 29 Nov 2005 03:52:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03801 for ; Tue, 29 Nov 2005 03:51:47 -0500 (EST) Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh1Xy-0002bl-VN for enum@ietf.org; Tue, 29 Nov 2005 04:13:15 -0500 Received: from g8ibr.kiel01.telekom.de by tcmail31.dmz.telekom.de with ESMTP for enum@ietf.org; Tue, 29 Nov 2005 09:46:35 +0100 Received: by G8IBR.kiel01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Nov 2005 09:46:32 +0100 Message-Id: From: "Schiefner, Carsten" To: enum@ietf.org Subject: RE: [Enum] please post issues from yesterdays session Date: Tue, 29 Nov 2005 09:46:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Jason, > All those changes look fine with one exception in wording on the 2nd > change you requested. I have worded it as such: > > [...] > > I think this still captures what you were looking for. exactly - thanks! :-) Best, Carsten _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 29 06:05:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh3IY-00007X-7O; Tue, 29 Nov 2005 06:05:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh3IK-0008Ow-Hv for enum@megatron.ietf.org; Tue, 29 Nov 2005 06:05:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17892 for ; Tue, 29 Nov 2005 06:04:22 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eh3cN-0006wK-Gk for enum@ietf.org; Tue, 29 Nov 2005 06:25:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] please post issues from yesterdays session Date: Tue, 29 Nov 2005 12:08:28 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B224D@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcX0BaBzuFGV21bSQuCcvCZL49HDdwAMmw5AACcSgRA= From: "Stastny Richard" To: "Livingood, Jason" , "Carsten Schiefner" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable Cc: lconroy@insensate.co.uk, Richard Shockey 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Folks, apologies for jumping in, I did not completely follow this thread being busy otherwise, but could anybody please explain to me how this is intended to be implemented technically? > (b) openly available, but possibly on a > national basis and subject to or in accordance with national regulatory > policy, How is data in the DNS openly available, but only on a national basis? Please elaborate Richard > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of > Livingood, Jason > Sent: Monday, November 28, 2005 5:25 PM > To: Carsten Schiefner; enum@ietf.org > Cc: Richard Shockey > Subject: RE: [Enum] please post issues from yesterdays session >=20 > All those changes look fine with one exception in wording on the 2nd > change you requested. I have worded it as such: >=20 > "Distribution of this NAPTR data would be either (a) on a private basis > (within a service provider's internal network, or on a private basis > between one or more parties using a variety of security mechanisms to > prohibit general public access), (b) openly available, but possibly on a > national basis and subject to or in accordance with national regulatory > policy, or (c) distributed by the relevant number portability > organization or other industry organization." >=20 > I think this still captures what you were looking for. Let me know if > that is not the case and I will take a second crack at it. >=20 > Jason >=20 > > -----Original Message----- > > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On > > Behalf Of Carsten Schiefner > > Sent: Monday, November 28, 2005 5:21 AM > > To: enum@ietf.org > > Subject: Re: [Enum] please post issues from yesterdays session > > > > Jason, > > > > > I think you are correct. Here is the text of that section of the > > > document. I have included IN CAPS the text I was > > considering adding > > > to address this. Let me know what you think. > > > > how about: > > > > =3D=3D=3D > > > > 3. Distribution of Data > > > > The distribution of number portability data is often highly > > restricted either by contract or regulation of a National > > Regulatory Authority (NRA), THEREFORE NAPTR records described > > herein MAY OR MAY not be part of the e164.arpa DNS tree. > > > > Distribution of this NAPTR data would be either (a) on a > > private basis (within a service provider's internal network, > > or on a private basis between one or more parties using a > > variety of security mechanisms to prohibit general public > > access), (b) openly available, BUT MAYBE on a national basis > > ONLY according to national regulatory policy, OR (C) > > DISTRIBUTED BY THE RELEVANT NUMBER PORTABILITY ORGANIZATION > > OR OTHER INDUSTRY ORGANIZATION. > > > > The authors believe that it is more likely that these records > > will be distributed on a purely private basis. If such data > > was distributed nationally, the national telephone numbering > > authority, or some other regulatory body OR NUMBERING > > ORGANIZATION, may have jurisdiction. Such a body may choose > > to restrict distribution of the data in such a way that it > > may not pass over that country's national borders. How > > number portability data is collected and distributed is out > > of scope of this document. > > > > =3D=3D=3D > > > > Best, > > > > Carsten > > > > _______________________________________________ > > 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 Tue Nov 29 09:07:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh69C-0002Gk-1v; Tue, 29 Nov 2005 09:07:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh699-0002DE-Pv for enum@megatron.ietf.org; Tue, 29 Nov 2005 09:07:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07945 for ; Tue, 29 Nov 2005 09:07:07 -0500 (EST) 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 1Eh6TD-0004Yx-8g for enum@ietf.org; Tue, 29 Nov 2005 09:28:37 -0500 Received: from ([10.20.9.174]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.15290810; Tue, 29 Nov 2005 09:07:12 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Nov 2005 09:07:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] please post issues from yesterdays session Date: Tue, 29 Nov 2005 09:07:09 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A39A5E@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcX0BaBzuFGV21bSQuCcvCZL49HDdwAMmw5AACcSgRAABaJScA== From: "Livingood, Jason" To: "Stastny Richard" , "Carsten Schiefner" , X-OriginalArrivalTime: 29 Nov 2005 14:07:11.0988 (UTC) FILETIME=[31815340:01C5F4EE] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Cc: lconroy@insensate.co.uk, Richard Shockey 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > apologies for jumping in, I did not completely follow this=20 > thread being busy otherwise, but could anybody please explain=20 > to me how this is intended to be implemented technically? >=20 > > (b) openly available, but possibly on a national basis and=20 > subject to=20 > > or in accordance with national > regulatory > > policy, >=20 > How is data in the DNS openly available, but only on a national basis? Below is the full text of section 3, as it stands right now, for your review. To answer your question, we see three ways this could be distributed: 1. ("a" in the list below) Privately. For example, by agreement between a data provider (Verisign, Telcordia, Neustar, etc.) and a service provider. 2. ("c" in the list below) Distributed by the NRA or other industry organization. For example, in Austria, you may decide to create an industry group to enable LNP and then have that entity distribute the data via these NAPTRs to member companies or other relevant users inside and outside of Austria in accordance with whatever policy is put in place by the group or NRA. =20 3. ("b" in the list below -- this is the one you are questioning) Openly available. For example, in Austria, you create NAPTRs for LNP and make it available to anyone who wishes to use it but in accordance with rules of the NRA. These items have evolved quickly over the past few days. I think what you have done is pointed out a flaw in the logic that has developed between options "c" and "b." =20 Perhaps it is best to simply leave "b" as "openly available" and make "c" read as such: (c) distributed by the relevant number portability organization or other industry organization, but possibly on a national basis and subject to or in accordance with national regulatory policy . Thoughts on this? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D 3. Distribution of Data The distribution of number portability data is often highly restricted either by contract or regulation of a National Regulatory Authority (NRA), therefore NAPTR records specified herein may or may not be part of the e164.arpa DNS tree. The NAPTR records described herein probably would not be part of the e164.arpa DNS tree. Distribution of this NAPTR data would be either (a) on a private basis (within a service provider's internal network, or on a private basis between one or more parties using a variety of security mechanisms to prohibit general public access), (b) openly available, but possibly on a national basis and subject to or in accordance with national regulatory policy, or (c) distributed by the relevant number portability organization or other industry organization. The authors believe that it is more likely that these records will be distributed on a purely private basis. If such data was distributed nationally, the national telephone numbering authority, or some other regulatory body or numbering organization, may have jurisdiction. Such a body may choose to restrict distribution of the data in such a way that it may not pass over that country's national borders. How number portability data is collected and distributed is out of scope of this document. Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 29 09:59:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh6wl-0007wA-Ow; Tue, 29 Nov 2005 09:59:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh6wk-0007w5-2w for enum@megatron.ietf.org; Tue, 29 Nov 2005 09:59:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15880 for ; Tue, 29 Nov 2005 09:58:21 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh7Gp-0006UX-S5 for enum@ietf.org; Tue, 29 Nov 2005 10:19:52 -0500 Received: from [10.31.32.103] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jATExWuH031165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Nov 2005 06:59:33 -0800 Message-ID: <438C6CA8.5060700@shockey.us> Date: Tue, 29 Nov 2005 09:58:48 -0500 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Livingood, Jason" Subject: Re: [Enum] please post issues from yesterdays session References: <6EEEACD9D7F52940BEE26F5467C02C7302A39A5E@PACDCEXCMB01.cable.comcast.com> In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C7302A39A5E@PACDCEXCMB01.cable.comcast.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, Stastny Richard , lconroy@insensate.co.uk, Carsten Schiefner 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Livingood, Jason wrote: >>apologies for jumping in, I did not completely follow this >>thread being busy otherwise, but could anybody please explain >>to me how this is intended to be implemented technically? >> >> >>>(b) openly available, but possibly on a national basis and >> >>subject to >> >>>or in accordance with national >> >>regulatory >> >>>policy, >> >>How is data in the DNS openly available, but only on a national basis? > > > Below is the full text of section 3, as it stands right now, for your > review. > > To answer your question, we see three ways this could be distributed: > 1. ("a" in the list below) Privately. For example, by agreement > between a data provider (Verisign, Telcordia, Neustar, etc.) and a > service provider. Exactly ... this BTW is how LNP data is distrubuted now in the US via a private d/l ( known as a LSMS interface) into a network service providers signalling infrastructure. There it is merged with other internal signalling data to create a comprehensive routing table. In PSTN terms this is known as a Service Control Point or SCP. > > 2. ("c" in the list below) Distributed by the NRA or other industry > organization. For example, in Austria, you may decide to create an > industry group to enable LNP and then have that entity distribute the > data via these NAPTRs to member companies or other relevant users inside > and outside of Austria in accordance with whatever policy is put in > place by the group or NRA. > > 3. ("b" in the list below -- this is the one you are questioning) > Openly available. For example, in Austria, you create NAPTRs for LNP > and make it available to anyone who wishes to use it but in accordance > with rules of the NRA. Just because we do it this way in the US does not mean that it has to be that way in other jurisdictions. Policy over LNP data is presumed to be a national matter. > > These items have evolved quickly over the past few days. I think what > you have done is pointed out a flaw in the logic that has developed > between options "c" and "b." What seems to confuse everyone looking at this is the difference between the DNS as the global distributed directory for domain names and the use of DNS "technology" as a query response mechanism to a database. The use case here is for the query response to a highly cached local database of routing data to be DNS. Of course it could be SIP redirect but the DNS is prefered for several reasons, principally speed and the ability to look at multiple trees internally cached or externally visable for a SIP proxy or other network element to delier the data necessary for a routing decision. The use case justification is that major service providers want the query to be executed as close to the network elements as possible for speed redundancy and optimization. This then puts a burden on T1 like registries to be able to PUSH data into private network configurations. > > Perhaps it is best to simply leave "b" as "openly available" and make > "c" read as such: (c) distributed by the relevant number portability > organization or other industry organization, but possibly > on a national basis and subject to or in accordance with national > regulatory policy . > > Thoughts on this? > > =============================== > 3. Distribution of Data > > The distribution of number portability data is often highly restricted > either by contract or regulation of a National Regulatory Authority > (NRA), therefore NAPTR records specified herein may or may not be part > of the e164.arpa DNS tree. > > The NAPTR records described herein probably would not be part of the > e164.arpa DNS tree. Distribution of this NAPTR data would be either (a) > on a private basis (within a service provider's internal network, or on > a private basis between one or more parties using a variety of security > mechanisms to prohibit general public access), (b) openly available, but > possibly on a national basis and subject to or in accordance with > national regulatory policy, or (c) distributed by the relevant number > portability organization or other industry organization. > > The authors believe that it is more likely that these records will be > distributed on a purely private basis. If such data was distributed > nationally, the national telephone numbering authority, or some other > regulatory body or numbering organization, may have jurisdiction. Such > a body may choose to restrict distribution of the data in such a way > that it may not pass over that country's national borders. How number > portability data is collected and distributed is out of scope of this > document. > > Jason > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 29 10:07:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh752-0002xC-Pt; Tue, 29 Nov 2005 10:07:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh750-0002wK-KS for enum@megatron.ietf.org; Tue, 29 Nov 2005 10:07:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17163 for ; Tue, 29 Nov 2005 10:06:53 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eh7P6-0006nY-AP for enum@ietf.org; Tue, 29 Nov 2005 10:28:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] please post issues from yesterdays session Date: Tue, 29 Nov 2005 16:11:07 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B2254@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] please post issues from yesterdays session Thread-Index: AcX09f1Gx9fy5vo1QuKY9dJYiCfAsgAAIm1g From: "Stastny Richard" To: "Richard Shockey" , "Livingood, Jason" X-Spam-Score: 0.8 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, lconroy@insensate.co.uk, Carsten Schiefner 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org For the avoidance of doubt, I did not question cases a) or c), and as Rich explained, they are completely feasible. What I questioned was the statement in b) "to make data public available on a national basis" and=20 how this works. IMHO data are either public available or not, there is no way now-a-days to make data public available on a national basis. Richard > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Tuesday, November 29, 2005 3:59 PM > To: Livingood, Jason > Cc: Stastny Richard; Carsten Schiefner; enum@ietf.org; > lconroy@insensate.co.uk > Subject: Re: [Enum] please post issues from yesterdays session >=20 > Livingood, Jason wrote: > >>apologies for jumping in, I did not completely follow this > >>thread being busy otherwise, but could anybody please explain > >>to me how this is intended to be implemented technically? > >> > >> > >>>(b) openly available, but possibly on a national basis and > >> > >>subject to > >> > >>>or in accordance with national > >> > >>regulatory > >> > >>>policy, > >> > >>How is data in the DNS openly available, but only on a national basis? > > > > > > Below is the full text of section 3, as it stands right now, for your > > review. > > > > To answer your question, we see three ways this could be distributed: > > 1. ("a" in the list below) Privately. For example, by agreement > > between a data provider (Verisign, Telcordia, Neustar, etc.) and a > > service provider. >=20 >=20 > Exactly ... this BTW is how LNP data is distrubuted now in the US via a > private d/l ( known as a LSMS interface) into a network service > providers signalling infrastructure. There it is merged with other > internal signalling data to create a comprehensive routing table. >=20 > In PSTN terms this is known as a Service Control Point or SCP. >=20 > > > > 2. ("c" in the list below) Distributed by the NRA or other industry > > organization. For example, in Austria, you may decide to create an > > industry group to enable LNP and then have that entity distribute the > > data via these NAPTRs to member companies or other relevant users inside > > and outside of Austria in accordance with whatever policy is put in > > place by the group or NRA. >=20 >=20 > > > > 3. ("b" in the list below -- this is the one you are questioning) > > Openly available. For example, in Austria, you create NAPTRs for LNP > > and make it available to anyone who wishes to use it but in accordance > > with rules of the NRA. >=20 > Just because we do it this way in the US does not mean that it has to be > that way in other jurisdictions. Policy over LNP data is presumed to be > a national matter. >=20 > > > > These items have evolved quickly over the past few days. I think what > > you have done is pointed out a flaw in the logic that has developed > > between options "c" and "b." >=20 >=20 > What seems to confuse everyone looking at this is the difference between > the DNS as the global distributed directory for domain names and the use > of DNS "technology" as a query response mechanism to a database. >=20 > The use case here is for the query response to a highly cached local > database of routing data to be DNS. Of course it could be SIP redirect > but the DNS is prefered for several reasons, principally speed and the > ability to look at multiple trees internally cached or externally > visable for a SIP proxy or other network element to delier the data > necessary for a routing decision. >=20 >=20 > The use case justification is that major service providers want the > query to be executed as close to the network elements as possible for > speed redundancy and optimization. >=20 > This then puts a burden on T1 like registries to be able to PUSH data > into private network configurations. >=20 >=20 >=20 >=20 > > > > Perhaps it is best to simply leave "b" as "openly available" and make > > "c" read as such: (c) distributed by the relevant number portability > > organization or other industry organization, but possibly > > on a national basis and subject to or in accordance with national > > regulatory policy . > > > > Thoughts on this? > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > 3. Distribution of Data > > > > The distribution of number portability data is often highly restricted > > either by contract or regulation of a National Regulatory Authority > > (NRA), therefore NAPTR records specified herein may or may not be part > > of the e164.arpa DNS tree. > > > > The NAPTR records described herein probably would not be part of the > > e164.arpa DNS tree. Distribution of this NAPTR data would be either (a) > > on a private basis (within a service provider's internal network, or on > > a private basis between one or more parties using a variety of security > > mechanisms to prohibit general public access), (b) openly available, but > > possibly on a national basis and subject to or in accordance with > > national regulatory policy, or (c) distributed by the relevant number > > portability organization or other industry organization. > > > > The authors believe that it is more likely that these records will be > > distributed on a purely private basis. If such data was distributed > > nationally, the national telephone numbering authority, or some other > > regulatory body or numbering organization, may have jurisdiction. Such > > a body may choose to restrict distribution of the data in such a way > > that it may not pass over that country's national borders. How number > > portability data is collected and distributed is out of scope of this > > document. > > > > Jason > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > >=20 >=20 > -- >=20 >=20 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Director - Member of Technical Staff > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 > Fax: +1 815.333.1237 > or > > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 29 12:08:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh8xa-0008Kd-JJ; Tue, 29 Nov 2005 12:08:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh8xZ-0008KV-Cw for enum@megatron.ietf.org; Tue, 29 Nov 2005 12:08:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04270 for ; Tue, 29 Nov 2005 12:07:19 -0500 (EST) Received: from mail2.hutchison.com.au ([203.18.188.195] helo=mailsweeper2.orange.net.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh9Hf-0003E1-3P for enum@ietf.org; Tue, 29 Nov 2005 12:28:52 -0500 Received: from mail.hutch.com.au (unverified [203.31.24.24]) by mailsweeper2.orange.net.au (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Wed, 30 Nov 2005 04:07:19 +1100 Received: from GWACCESS-MTA by mail.hutch.com.au with Novell_GroupWise; Wed, 30 Nov 2005 04:07:53 +1100 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Date: Wed, 30 Nov 2005 04:07:35 +1100 From: "Philip Walls" To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Subject: [Enum] Re: enum Digest, Vol 19, Issue 20 (Out of office) 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Thanks for your email. Sorry, but I'll be out of the office from Wed 30 Nov until Mon 16 Jan. =20 In my absence, please contact Angus Clearie +61 (0)433-132-823. Hope you have a Merry Christmas & a safe & happy New Year. Cheers Phil _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Nov 29 19:25:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhFmr-00023Z-SG; Tue, 29 Nov 2005 19:25:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhFmp-00023T-HD for enum@megatron.ietf.org; Tue, 29 Nov 2005 19:25:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03008 for ; Tue, 29 Nov 2005 19:24:41 -0500 (EST) Received: from 213-152-49-123.dsl.eclipse.net.uk ([213.152.49.123] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhG70-0004JU-2U for enum@ietf.org; Tue, 29 Nov 2005 19:46:18 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 4899E7598B; Wed, 30 Nov 2005 00:24:48 +0000 (GMT) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B2254@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D461B2254@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] please post issues from yesterdays session Date: Wed, 30 Nov 2005 00:24:46 +0000 To: Stastny Richard X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.8 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, Carsten Schiefner , "Livingood, Jason" , Richard Shockey 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi folks, To reinforce this question... B is the only question. (a) and (c) are fine - do whatever you (and your regulator) want; technically these options both work (one can use DNS, the other using whatever arcane distribution method seems suitable - CSV, ...). (b) is the big issue - if this data is shipped over the Internet [you did say freely available, right?], then you can't restrict this to a national basis. Perhaps some people have been breathing the air in Tunis too much. Outside of the great fireWall of China, possibly Iran, and (in their dreams) a few other Countries, the Internet doesn't stop at National borders. Please explain in detail how (b) is going to work technically with any protocol; if there is no such explanation, then it should not be in the document, IMHO. all the best, Lawrence On 29 Nov 2005, at 15:11, Stastny Richard wrote: > For the avoidance of doubt, I did not question cases a) or > c), and as Rich explained, they are completely feasible. > > What I questioned was the statement in b) "to make > data public available on a national basis" and > how this works. > > IMHO data are either public available or not, > there is no way now-a-days to make data public > available on a national basis. > > Richard > >> -----Original Message----- >> From: Richard Shockey [mailto:richard@shockey.us] >> Sent: Tuesday, November 29, 2005 3:59 PM >> To: Livingood, Jason >> Cc: Stastny Richard; Carsten Schiefner; enum@ietf.org; >> lconroy@insensate.co.uk >> Subject: Re: [Enum] please post issues from yesterdays session >> >> Livingood, Jason wrote: >>>> apologies for jumping in, I did not completely follow this >>>> thread being busy otherwise, but could anybody please explain >>>> to me how this is intended to be implemented technically? >>>> >>>> >>>>> (b) openly available, but possibly on a national basis and >>>> >>>> subject to >>>> >>>>> or in accordance with national >>>> >>>> regulatory >>>> >>>>> policy, >>>> >>>> How is data in the DNS openly available, but only on a national > basis? >>> >>> >>> Below is the full text of section 3, as it stands right now, for > your >>> review. >>> >>> To answer your question, we see three ways this could be > distributed: >>> 1. ("a" in the list below) Privately. For example, by agreement >>> between a data provider (Verisign, Telcordia, Neustar, etc.) and a >>> service provider. >> >> >> Exactly ... this BTW is how LNP data is distrubuted now in the US via > a >> private d/l ( known as a LSMS interface) into a network service >> providers signalling infrastructure. There it is merged with other >> internal signalling data to create a comprehensive routing table. >> >> In PSTN terms this is known as a Service Control Point or SCP. >> >>> >>> 2. ("c" in the list below) Distributed by the NRA or other industry >>> organization. For example, in Austria, you may decide to create an >>> industry group to enable LNP and then have that entity distribute > the >>> data via these NAPTRs to member companies or other relevant users > inside >>> and outside of Austria in accordance with whatever policy is put in >>> place by the group or NRA. >> >> >>> >>> 3. ("b" in the list below -- this is the one you are questioning) >>> Openly available. For example, in Austria, you create NAPTRs for > LNP >>> and make it available to anyone who wishes to use it but in > accordance >>> with rules of the NRA. >> >> Just because we do it this way in the US does not mean that it has to > be >> that way in other jurisdictions. Policy over LNP data is presumed to > be >> a national matter. >> >>> >>> These items have evolved quickly over the past few days. I think > what >>> you have done is pointed out a flaw in the logic that has developed >>> between options "c" and "b." >> >> >> What seems to confuse everyone looking at this is the difference > between >> the DNS as the global distributed directory for domain names and the > use >> of DNS "technology" as a query response mechanism to a database. >> >> The use case here is for the query response to a highly cached local >> database of routing data to be DNS. Of course it could be SIP >> redirect >> but the DNS is prefered for several reasons, principally speed and >> the >> ability to look at multiple trees internally cached or externally >> visable for a SIP proxy or other network element to delier the data >> necessary for a routing decision. >> >> >> The use case justification is that major service providers want the >> query to be executed as close to the network elements as possible for >> speed redundancy and optimization. >> >> This then puts a burden on T1 like registries to be able to PUSH data >> into private network configurations. >> >> >> >> >>> >>> Perhaps it is best to simply leave "b" as "openly available" and > make >>> "c" read as such: (c) distributed by the relevant number portability >>> organization or other industry organization, but > possibly >>> on a national basis and subject to or in accordance with national >>> regulatory policy . >>> >>> Thoughts on this? >>> >>> =============================== >>> 3. Distribution of Data >>> >>> The distribution of number portability data is often highly > restricted >>> either by contract or regulation of a National Regulatory Authority >>> (NRA), therefore NAPTR records specified herein may or may not be > part >>> of the e164.arpa DNS tree. >>> >>> The NAPTR records described herein probably would not be part of the >>> e164.arpa DNS tree. Distribution of this NAPTR data would be either > (a) >>> on a private basis (within a service provider's internal network, or > on >>> a private basis between one or more parties using a variety of > security >>> mechanisms to prohibit general public access), (b) openly available, > but >>> possibly on a national basis and subject to or in accordance with >>> national regulatory policy, or (c) distributed by the relevant > number >>> portability organization or other industry organization. >>> >>> The authors believe that it is more likely that these records will > be >>> distributed on a purely private basis. If such data was distributed >>> nationally, the national telephone numbering authority, or some > other >>> regulatory body or numbering organization, may have jurisdiction. > Such >>> a body may choose to restrict distribution of the data in such a way >>> that it may not pass over that country's national borders. How > number >>> portability data is collected and distributed is out of scope of > this >>> document. >>> >>> Jason >>> >>> _______________________________________________ >>> enum mailing list >>> enum@ietf.org >>> https://www1.ietf.org/mailman/listinfo/enum >>> >> >> >> -- >> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> Richard Shockey, Director - Member of Technical Staff >> NeuStar Inc. >> 46000 Center Oak Plaza - Sterling, VA 20166 >> sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com >> ENUM +87810-13313-31331 >> PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 >> Fax: +1 815.333.1237 >> or >> >> ; >> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > _______________________________________________ > 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 Nov 30 15:07:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYEc-0006Vh-3I; Wed, 30 Nov 2005 15:07:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYEa-0006Ub-96 for enum@megatron.ietf.org; Wed, 30 Nov 2005 15:07:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05806 for ; Wed, 30 Nov 2005 15:06:32 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhYVr-0000m4-L3 for enum@ietf.org; Wed, 30 Nov 2005 15:25:12 -0500 Received: from [10.31.13.186] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jAUK4Y48010014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 30 Nov 2005 12:04:35 -0800 Message-ID: <438E05AC.4020707@shockey.us> Date: Wed, 30 Nov 2005 15:03:56 -0500 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'enum@ietf.org'" Content-Type: text/plain; charset=windows-1252; format=flowed X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sb7.songbird.com id jAUK4Y48010014 X-Spam-Score: 0.8 (/) X-Scan-Signature: d115f8e98afb84ba4860c5c6ee611921 Content-Transfer-Encoding: quoted-printable Subject: [Enum] IETF-64 Vancouver ENUM WG meeting minutes - Preliminary 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Chair(s): Patrik Faltstrom Richard Shockey WG Secretary: Alex Mayrhofer Transport Area Director(s): Allison Mankin Jon Peterson Transport Area Advisor: Allison Mankin TUESDAY, November 8, 2005 AGENDA BASHING (5 min) ---------------------- The chairs open the meeting. Agenda as well as the location of=20 presentations were posted to list. The proposed agenda is accepted=20 without comments by the WG. RECHARTER DISCUSSION (CURRENT PROPOSAL) (15 MIN ) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The ENUM working group has defined a DNS-based architecture and protocol=20 [RFC 3761] by which an E.164 number, as defined in ITU Recommendation=20 E.164, can be expressed as a Fully Qualified Domain Name in a specific=20 Internet Infrastructure domain defined for this purpose (e164.arpa). Background: E.164 numbers are globally unique, language independent identifiers for=20 resources on Public Telecommunication Networks that can support many=20 different services and protocols. There is an emerging desire for=20 network operators to utilize aspects of RFC 3761 to discover points of=20 interconnection necessary to terminate communications sessions=20 identified by a E164 number, in addition to identifying end point=20 protocols and services. Working Group Revised Goals and Scope: 1. The working group will update RFC 3761 and advance to Draft Standard. 2. The working group will examine and document the use of RFC 3761 to facilitate network interconnection for services using E.164 addressing. The working group will coordinate its activities with other IETF working=20 groups, existing or to be chartered, that are investigating elements of=20 peering and or interconnection for VoIP or other services that typically=20 use E.164 addressing. 3. The working group will continue examine and document various aspects=20 of ENUM administrative and /or operational procedures irrespective of=20 whether e164.arpa domain is used. 4. The working group will also examine the use of RFC 3761 technology=20 for storing and delivering other information about services addressed by=20 E.164 numbers, for example PSTN call routing and signaling data. 5. The Working Group will continue to maintain appropriate contact and=20 liaison with other standards bodies and groups, specifically ITU-T G2,to=20 provide technical or educational information and address, as needed,=20 issues related to the use of the E.164 numbering plan for services on IP=20 networks. In addition the Working Group will continue to encourage the=20 exchange of technical information within the emerging global ENUM=20 community as well as documentation on practical experiences with=20 implementations, alternate technology uses and the administration and=20 provisioning of RFC 3761. 6. As described in RFC 3761, the IETF documents and registers the ENUMservices. While extant, it is the ENUM working group that performs the technical review and development of the ENUMservices for the=20 Internet community. The working group determines whether to advance=20 them and how to progress them technically. Coordination with other WGs=20 will be taken into account on these. Other than ENUMservices, all proposed deliverables of the working group=20 will be discussed with and approved by the Area Directors, who may=20 require wider review due to the broad impact of the subject. Goals and Milestones March 06 ENUMservice Registration for Local Number Portability=20 and Related Data as a Proposed Standard April 06 Requirements for Carrier Interconnection using ENUM=20 as an Informational June 06 Carrier Interconnection using ENUM as a Proposed Standard July 06 ENUM Privacy and Security Considerations as an=20 Informational Standard August 06 Advancement of RFC 3761 to Draft Standard ---- DISCUSSION: Most of the issues of the recharter have been discussed on the list=20 already. Includes moving RFC3761 up to draft standard, which needs=20 interoperable implementations. Documentation on this will be first step=20 towards draft standard. Scope now includes investigating possible carrier ENUM implementations, and continues registration of ENUMservices. Milestones: Draft on number portability to be completed this fall,=20 carrier enum requirements in spring. Shockey will probably work on a=20 privacy and security draft to be submitted soon, and finally asks for=20 comments of objections to the charter. There are neither questions nor objections. ---- ENUM Implementers Draft: (Final Version) 5 MIN =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-03.txt Pages : 33 Date : 2005-10-18 =09 This document captures experience in implementing systems based on the=20 ENUM protocol, and experience of ENUM data that have been created by=20 others. As such, it is advisory, and produced as a help to others in=20 reporting what is "out there" and the potential pitfalls in=20 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-03.txt ---- DISCUSSION: Shockey explains the roadmap of the document - this could go to last call fairly shortly. Only few comments have been posted to the list so that seems ready to go. When further experiences are to be added, a new version of the document could be done. Ken Cartwright: This could probably have an impact on RFC3761 and the DDDS documents - it's unclear who owns the DDDS documents. Faltstrom: No one owns the DDDS RFCs - revising them would probably require to reopen the WG. Updates to RFC3761 will be baked into the next version experiences docume= nt. ---- DNS issues 10-M =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D B. Title : ENUM Requirement for EDNS0 Support Author(s) : L. Conroy, J. Reid Filename : draft-conroy-enum-edns0-01.txt Pages : 16 Date : 2005-10-25 =09 This document mandates support for EDNS0 (Extension Mechanisms for=20 DNS) in DNS entities claiming to support ENUM query resolution (as=20 defined in RFC3761). This requirement is needed as DNS responses to=20 ENUM-related questions return larger sets of Resource Records than=20 typical DNS messages. Without EDNS0 support in all the involved=20 entities, a fallback to TCP transport for ENUM queries and responses=20 would typically occur. That has a severe impact on DNS Server load,=20 and on latency of ENUM 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-01.txt ---- DISCUSSION: The draft was discussed in the DNSOP WG just before the ENUM wg meeting. Wimmreuter presents the draft as a proxy: - ENUM features large responses - could lead to lots of TCP queries if EDNS0 size option not used - draft mandates EDNS0 size support on all entities involved in ENUM DNS lookups. - middleboxes could additionally mess up with fragmentation & truncation=20 of responses The document does mandate EDNS0 size option, but does not recommend a=20 certain size (1200 bytes could be a good value, however). Wimmreuter asks to make this draft a WG item, and let the DNSOP WG have=20 a look at it. He points out that a generic document about how DNS should=20 be operated could be much bigger, and would probably be too late for=20 many implementers. If this draft is accepted, the corresponding section could be removed=20 from the experiences draft discussed before. Faltstrom: Question was proposed to DNSOP if they could write a Document=20 on how to run DNS - they were very interested. However, they were=20 nervous about writing a doc about how to run DNS, because that could be=20 400 pages. One suggestion was to just have a very brief document with=20 normative references (MUSTs SHOULDs etc.) that they are going to review.=20 Suggestion is to not decide now about the EDNS0 draft, but instead take=20 EDNS0 and the relevant part from experiences together, with brief=20 references WG ACTION : Shockey comments that such a document should be made WG item. Jean Francois: There are strong reasons to allow corner cases where EDNS0 support should NOT be a requirement. Is 3761 the right place for DNS requirements? Faltstrom: Suggests to discuss the list document once available with dnsops, and not mess with 3761 for now. Shockey: Should not stop RFC3671 from progressing Koch: There's a difference between "protocol" and "operations".=20 "Operations" cannot be regulated by RFCs. Depends on who reads this document: implementers or eg. firewall operators. Stastny: asks if experiences draft goes to last call under the light of=20 this. Faltstrom suggests another quick round, and then to publish what we have=20 there, because this is a live document. ---- IANA Registration for ENUMservice vCard 10-Min =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Author(s) : A. Mayrhofer, D. Lindner Filename : draft-mayrhofer-enum-vcard-00.txt Pages : 7 Date : 2005-10-5 =09 This memo registers the ENUMservice "vCard" using the URI schemes=20 http" and "https" according to the IANA ENUMservice registration process=20 described in RFC3671. This ENUMservice is to be used to refer from an=20 ENUM domain name to the vCard of the entity using the corresponding=20 E.164 number. Clients may use information gathered from those vCards before, during=20 or after inbound or outbound communication takes place. For example, a=20 callee might be presented with the name and association of the caller=20 before he picks up the call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-vcard-00.txt DISCUSSION: ENUMservice for refering from phone numbers to URIs containing vCard. Came from questions from service providers which wanted to publish. Usage scenario: query for number, receive vCard URI, fetch vCard. No subtypes defined right now, two URI schemes (http and https) proposed=20 now. Feedback received about subtypes: Should subtypes reflect protocol? Faltstrom (as WG member): Privacy constriants, and granularity limits of HTTP. vCards could be synthesized based on authentication. HTTP not optimal for detailed access constraints. A bit nervous that=20 usage of http is too quick. Recommend at least subtyping because good WP=20 systems should not use http, but could be started with http now. Suggestion is to check HTTP, LDAP, IRIS Shockey: Want to see granularity on access control as well. Schiefner: Would like to see this a WG item, looking at moving that forwa= rd. Levi ??: vCards heavily used in XMPP. Should look at this. Not sure if granularity is what people expect from publishing a vCard. Jimmy ??: Suggestions to granularity on access controls could be out of scope of the ENUM WG? Mayrhofer: Could simply say "we make the reference, what behind this is out of scope for ENUM". Faltstrom: Clarification on privacy needed. Baskin: Privacy needs to be highlighted each time. However, "ENUM" does not the vCard, ENUM just returns a reference. It's done after the lookup. Faltstrom: Agreed, need to be subtyped to differentiated. ??: There is a draft about vCard over WebDAV in the calendaring for WebDAV. draft-debut-carddav? Schwartz: Issues on identifying when using HTTP. WG ACTION: Based on a hum of the WG, consensus for adopting this as WG it= em. ---- IANA Registration for IAX ENUMservice ( 10-Min ) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Author(s) : E. Guy Filename : draft-guy-enumiax-00.txt Pages : 11 Date : 2005-10-20 This document registers the IAX2 ENUMservice using the URI scheme=20 'iax2:' as per the IANA registration process defined in the ENUM=20 specification RFC3761. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-guy-enumiax-00.txt ---- Ed Guy presents the document: registers IAX ENUMservice with iax2 URI. The URI definition itself is in the protocol spec itself (aims at=20 Informational). Some feedback on formatting was received. Rosenberg: Passwords in URI are bad. Guy: addressed in doc as "bad thing". Peterson: There is a list on reviewing URI, comments expected from there Faltstrom: Peer review between W3C and IETF exists =2E Cartwright: empty subtype causes headache for implementors, URI scheme Recommended Shockey: Underlying protocol informational, going for proposed standard? Stastny: same with h323. Was that an informational? Cartwright: Uncertainty about subtype - what is it supposed to contain? Clarification desired. Faltstrom: Subtypes were actually requested. Anyway, Subtype is not=20 equal to URI scheme, must look up IANA registration for relation between=20 subtype and protocol URI. WG ACTION : The WG hums in favor of accepting this draft as a WG item. An ENUM Library API ( 5 Min WG Chairs will lead discussion ) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Author(s) : T. Sajitha Filename : draft-sajitha-enum-api-00.txt Pages : 7 Date : 2005-10-21 =09 This draft defines a library API for ENUM. The API takes telephone number as input and returns the URI associated with that telephone number. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sajitha-enum-api-00.txt ---- WG Chairs have made the decision that API is out of scope, and will not=20 be discussed here. ---- Carrier ENUM Requirements? ( 15 - M ) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Title : Carrier/Infrastructure ENUM Requirements Author(s) : S. Lind, et al. Filename : draft-lind-infrastructure-enum-reqs-01.txt Pages : 7 Date : 2005-10-21 =09 This document provides requirements for "infrastructure" or "carrier"=20 ENUM, defined as the use of RFC 3761 technology to facilitate=20 interconnection of networks for E.164 number addressed services, in=20 particular but not restricted to VoIP A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lind-infrastructure-enum-reqs-0= 1.txt ---- DISCUSSION: ( Shockey for Pfautz, Lind) This document will be core requirements document for of carrier enum=20 moving forward. "Carrier enum is usage of ENUM technology by carrier of record, carrier=20 of record is the carrier providing PSTN service to a number, definition=20 ultimately national matter". DNS must return a result, and can identify=20 a point of interconnection. User ENUM and carrier ENUM must coexist. Document a WG item since Paris, because requirements are first step. Schiefner: Common terminology? "Infrastructure" vs "carrier" Baskin: no preference on terminology, but political burden on the word "carrier" to be considered. Shockey: voipeer was unable to define what a "carrier" is. Baskin: Requirements as they are? Shockey: No, continue to work on this, guidance on next steps. ??: "provides PSTN service" too restrictive - excludes IMS users. ??: Requirements doc without statements on problems to be solved? Schaefer: ETSI doc on "infrastructure ENUM". choice of "infrastructure" could be interpreted as association to this doc. WG ACTION: Humm taken on "carrier" vs "infrastructure" usage in future=20 discussion and documents. Chairs consensus that =93infrastructure=94 is=20 preferred to =93carrier=94 Peterson: Stronger hum on "infrastructure", should be taken to list. Shockey: Next revision of document should refer to "infrastructure". ---- Combined User and Carrier ENUM in the e164.arpa tree ( 15 - M ) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Author(s) : M. Haberler, R. Stastny Filename : draft-haberler-carrier-enum-01.txt Pages : 15 Date : 2005-10-21 =09 ENUM as defined now in RFC3761 [1] is not well suited for the purpose=20 of interconnection by carriers, as can be seen by the use of various=20 private tree arrangements based on ENUM mechanisms. A combined end-=20 user and carrier ENUM tree solution would leverage the ENUM=20 infrastructure in e164.arpa, increase resolution rates, and decrease=20 the cost per registered telephone number. This document describes a=20 minimally invasive scheme to provide both end-user and carrier data in=20 ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-01.txt ---- Haberler presents the draft: Use of a single tree for infrastructure purposes has economic=20 advantages, draft introduces resolution on texts, tried to generalize=20 that to possible other trees. Draft does not imply that actual data is=20 in e164.arpa (can be decided at country level). Indication where branch goes off is indicated by "branch location=20 record=94, which is put into the DNS itself at the cc level. Assumption=20 left is knowledge about country codes (back-off algorithm described in=20 draft). This is a change from -00 (dropped the table about branch locatio= n). Not documented in the current draft: Make label configurable, or insert a zero length label. Could also refer other apexes (generalization). open issue: Feedback required on branch location record, currently using=20 TXT record in prototypes. Assumption is that a NAPTR service would be=20 the most flexeble. Peterson: Might an appropriate case for TXT record. Is just additional information that has no programmatic function for limited audience, so that might be OK. However, should be discussed in the WG. ??: TXT bad idea because of overloading, and multiple records with multiple semantics. Koch: Make a problem statement, and take it to appropriate DNS WG.=20 Asking early might save you problems. There are already prototypes for Asterisk and SER,they are using TXT records for now. Roadmap: integrate suggestions received here, add detailed resolver behavior by copying and modifying from RFC3761. Will make a problem statement about branch location record. Shockey: need finish requirements draft before this is promoted to WG item status - but expects work to continued on this doc, and reconsider it once requirements are stable. Cartwright: Doc has overlapping with Lind doc - requirements should be=20 copied over. Would like to see guidance on conflicts between=20 infrastructure and user contexts (SIP records in both) Haberler: Precedence will be given to one tree depending on contexts=20 (carriers only looking at carrier part, user only in users), but=20 probably resorting to other tree will happen. However, might be local=20 policy. Cartwright: concerns about conflicting data Shockey: Important: There is no _conflicting_ data. It's up to policy to define precedence, if one uses both. Various national policies and best current practices will probably exist. Stastny: Carriers will probably look up carrier enum, but user might ask carrier to use look up user enum first for his calls. ---- IANA Registration for an ENUMservice Containing PSTN Signaling Informatio= n draft-ietf-enum-pstn-01 ( 10 Min ) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ---- Livingood presents draft: History: Was submitted as non-wg item in Paris, where it was formally adopted - renaming etc. IPTEL WG is doing registration for tel-URI parameters, might need updating this doc. Service type was changed from "npd" to "pstn". Suggestions on CNAM received. Document added SIP URI as well as=20 examples. We added section about distribution of data (data to be=20 distributed privately) and section about record conflict resolution.=20 Section 7 talks now about implementation suggestions (from feedback=20 about implementation questions), additional section talks about call=20 flows would work in practice. Update references to reflect tel-URI=20 registration and SIP adoption. Will work with various vendors to test=20 this out with practical data. DISCUSSION: Shockey: Draft currently focused on number portability, will look into other things (CNAM, probably global title translation). Feedback from WG desired on other forms of PSTN SS7 data to be incorporated. Schiefner: Why data private? Shockey: Restrictions on npd in various jurisdictions, so service cannot=20 happen in a public visible domain (IPsec or caching DNS structures) McCandless: Why registration if it happens in private space? People=20 might starting use that in public space. Faltstrom: Private stuff always leaks into public space =96 registration=20 prevents clashes, and should be performed in any case. ---- ENUM validation drafts =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D draft-ietf-enum-validation-arch-00.txt, draft-ietf-enum-validation-token-00.txt draft-ietf-enum-validation-epp-01.txt) ---- Bernie Hoeneisen & Alex Mayrhofer present updates to the three document. ENUM validation is checking that only the one who owns the number gets the ENUM registration. Three drafts: Architecture, transport of=20 validation data via EPP, and validation data format. Changes to architecture: Name change to reflect WG acceptance, minor cleanups. Changes to EPP draft: Aligned with other two drafts, input on ID attribute baked in document. Changes to validation token: added number range option (input from Sweden), synchronize tag names with IRIS EREG and other drafts, cleanup. Will probably look at SAML, which was not considered yet. Requesting input from GEOPRIV because of civic address format. No comments. Next steps? Meeting is concluded. ---- Issues posted to the list after the meeting =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IANA Registration for an ENUMservice Containing PSTN Signaling Informatio= n Livingood noted: that during my presentation on=20 "draft-ietf-enum-pstn-00" the following issues were discussed and=20 decided upon: 1. Minor nits with the draft will be resolved and I will re-submit to up-rev to -01. 2. Must revisit the section on Distribution of Data to note that it may=20 or may not be done on a private basis. This will be primarily=20 determined based on regulatory requirements in a particular country. I have not determined the exact wording of this yet. 3. After fixing the nits and word-smithing #2 above (resulting in=20 -01),we will work on -02 with new suggested data types. These include=20 CNAM and 800 number data, per feedback from Kevin McCandless. (This=20 would not include Global Title Translation - which was a question raised=20 by the co-chair.) The co-authors are open to any other suggestions. Separately, the need was again confirmed for a guide to creating an ENUMservice I-D. This work will be undertaken by members of the WG in the near future. Regards Jason Livingood ---- One issue raised during the discussion on Ed Guys IAX was to finally clarify the rules for subtyping of ENUMservices. 1. should there be subtypes or not 2. what should be used at subtypes (e.g. the URI) This discussion is not new, some years? ago it was discussed if you need subtypes indication the URI on the right side at all, because you just have to look at the right side of the NAPTR to see it So basically the registration template is indicating which URI are valid to be used with this ENUMservice type This was rejected because then a client is required to evaluate ALL NAPTRs for this ENUMservice type (including regexp) to find out the URI and then decide which object to take As stated by Patrik this must not be the case, it must be possible by the client to select the NAPTR only by the information in the ENUMservice field, taking stupid clients into account. Therefore the praxis was established to use subtypes indication the URI on the right side, and also to use the URI name itself, to avoid=20 confusion, although this is not necessary. If only one URI is possible,=20 no subtype is used (e.g. ENUMservice sip or H323). The only problem here exists when an ENUMservice is defined which contains at the moment only one URI, but MAY be expanded later with an additional URI. We (e.g. Lawrence, Rudi and I) prefer in this also to use a subtype (the URI), even if it seems not necessary, just to be on the save side for future extensions. My proposal is that in future all new ENUMservice registration SHOULD contain the URI as subtype regards Richard Stastny ---- This was not brought up by me, but concerns our draft: The definitions and terminology used in draft-haberler-carrier-enum-01 should be moved over and aligned with the definitions and terminology in draft-lind-infrastructure-enum-reqs-01 Richard Stastny ---- I think it's a vital point that Patrik and Richard schooled me on: The=20 fact that the IETF will make *no* judgments or statements about the=20 appropriateness, precedence, or "conflict" resolution of NAPTRs in the=20 User ENUM tree and the Carrier ENUM tree for the same TN. The Carrier=20 ENUM tree may very well have NAPTRs for any ENUM service type for a=20 given TN, while NAPTRs for the same TN and the same ENUM service types,=20 but with perhaps different URIs, may also reside in the User ENUM tree=20 at the same time. The decision on which tree to query, and perhaps in=20 what order to query them, and perhaps how to resolve "conflicts" (I=20 don't use the term "conflict" in a negative sense) is entirely up to the=20 ENUM client application. I had not heard this said before or seen it=20 written, but it certainly simplifies the problem of having two trees. Kenneth Cartwright --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 30 15:51:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYvC-0001vR-UV; Wed, 30 Nov 2005 15:51:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYu0-0001Cx-7j; Wed, 30 Nov 2005 15:50:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11422; Wed, 30 Nov 2005 15:49:22 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhZEH-0002el-Q7; Wed, 30 Nov 2005 16:11:07 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EhYtu-0006uV-UQ; Wed, 30 Nov 2005 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 30 Nov 2005 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-vcard-00.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: , Sender: enum-bounces@ietf.org 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 Enumservice vCard Author(s) : A. Mayrhofer, D. Lindner Filename : draft-ietf-enum-vcard-00.txt Pages : 9 Date : 2005-11-30 This memo registers the Enumservice "vCard" with several subtypes according to the IANA Enumservice registration process described in RFC3671. 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-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-ietf-enum-vcard-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-ietf-enum-vcard-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 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: <2005-11-30143510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-vcard-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-vcard-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-30143510.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 Nov 30 16:20:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhZMw-0002Cj-Cd; Wed, 30 Nov 2005 16:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhZMu-00028q-Od for enum@megatron.ietf.org; Wed, 30 Nov 2005 16:20:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23989 for ; Wed, 30 Nov 2005 16:19:15 -0500 (EST) Received: from mail120.messagelabs.com ([216.82.255.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EhZhC-00070a-Vz for enum@ietf.org; Wed, 30 Nov 2005 16:41:02 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-10.tower-120.messagelabs.com!1133385570!10066912!4 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 8451 invoked from network); 30 Nov 2005 21:19:45 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-10.tower-120.messagelabs.com with SMTP; 30 Nov 2005 21:19:45 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 4380ACBE0014EE91; Wed, 30 Nov 2005 16:19:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Nov 2005 16:19:43 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0BA6BD9E@ACCLUST02EVS1.ugd.att.com> Thread-Topic: Update of Carrier ENUM requirements I-D Thread-Index: AcXvQtDoGgu1n6MlSM6XnmIG+V5LWwGsCJ5A From: "Pfautz, Penn L, NEO" To: "Richard Shockey" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Enum] Update of Carrier ENUM requirements I-D 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Having looked over the Vancouver minutes of the WG I want to ask if I should replace "carrier ENUM" with "infrastructure ENUM" before resubmitting draft-lind-infrastructure-enum-reqs-01 as draft-ietf-enum-infrastructure-enum-reqs-00. If so, I would also propose to render "carrier of record" as "service provider of record" going forward. Your views? Thanks, Penn -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Tuesday, November 22, 2005 3:50 AM To: 'enum@ietf.org' Subject: [Enum] Reminder to ID authors. Documents approved as WG items in Vancouver etc should be resubmitted in the official manner of draft-ietf-enum-name-version00.txt as soon a=20 reasonably possible so we can get them in the document tracking mechanism. Copies of ID submitted as WG items for the first time .. aka .00.txt=20 versions must be submitted to the chairs so they can approve their=20 submission to the ID editors. _______________________________________________ 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 Nov 30 16:31:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhZXl-0002td-Hz; Wed, 30 Nov 2005 16:31:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhZXj-0002sp-6i for enum@megatron.ietf.org; Wed, 30 Nov 2005 16:31:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00280 for ; Wed, 30 Nov 2005 16:30:25 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhZs1-0000jT-VS for enum@ietf.org; Wed, 30 Nov 2005 16:52:13 -0500 Received: from [10.31.13.186] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jAULVX1n021984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Nov 2005 13:31:35 -0800 Message-ID: <438E1A06.1010306@shockey.us> Date: Wed, 30 Nov 2005 16:30:46 -0500 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pfautz, Penn L, NEO" References: <34DA635B184A644DA4588E260EC0A25A0BA6BD9E@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0BA6BD9E@ACCLUST02EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org Subject: [Enum] Re: Update of Carrier ENUM requirements I-D 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: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Pfautz, Penn L, NEO wrote: > Having looked over the Vancouver minutes of the WG I want to ask if I > should replace "carrier ENUM" with "infrastructure ENUM" before > resubmitting draft-lind-infrastructure-enum-reqs-01 as > draft-ietf-enum-infrastructure-enum-reqs-00. Yes .. it seemed to be the consensus of the WG that the word carrier seems to be associated with some form of disease. > If so, I would also propose to render "carrier of record" as "service > provider of record" going forward. excellent idea. > > Your views? > > Thanks, > Penn -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Nov 30 16:50:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhZq2-0003hl-OJ; Wed, 30 Nov 2005 16:50:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhZq0-0003hV-WC for enum@megatron.ietf.org; Wed, 30 Nov 2005 16:50:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03413 for ; Wed, 30 Nov 2005 16:49:19 -0500 (EST) Received: from pmesmtp02.wcom.com ([199.249.20.2] helo=pmesmtp02.mci.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhaAH-0001m8-Oe for enum@ietf.org; Wed, 30 Nov 2005 17:11:07 -0500 Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0IQS009KKF6K4M@firewall.mci.com> for enum@ietf.org; Wed, 30 Nov 2005 21:47:08 +0000 (GMT) Received: from dgismtp06.wcomnet.com by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0IQS00001F5DNS@dgismtp06.mcilink.com> for enum@ietf.org; Wed, 30 Nov 2005 21:47:08 +0000 (GMT) Received: from XS107V7775199 ([166.50.70.96]) by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0IQS000Q5F6CFR@dgismtp06.mcilink.com> for enum@ietf.org; Wed, 30 Nov 2005 21:47:00 +0000 (GMT) Date: Wed, 30 Nov 2005 15:47:00 -0600 From: Tim Dwight Subject: RE: [Enum] Re: Update of Carrier ENUM requirements I-D In-reply-to: <438E1A06.1010306@shockey.us> To: enum@ietf.org Message-id: <0IQS000Q6F6CFR@dgismtp06.mcilink.com> Organization: MCI MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcX19hQ5kDDrOXUGRGOfsUpG5sUE/wAAFYSA X-Spam-Score: 0.8 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: timothy.dwight@mci.com List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I'm not sure that I agree with changing "carrier of record" to "service provider of record". Depends on what the latter means I suppose. If (as seems intuitive) "service provider" means "the entity that the customer perceives as providing the service", and "carrier of record" means "the entity providing PSTN access for calls to or from the customer", then is a "service provider of record" an entity that does both? And is that the appropriate semantic? At the risk of inviting flames I'd say that "carrier of record" is the appropriate term and the Telco-bashing that seems to motivate this change, is juvenile. Tim -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Wednesday, November 30, 2005 3:31 PM To: Pfautz, Penn L, NEO Cc: enum@ietf.org Subject: [Enum] Re: Update of Carrier ENUM requirements I-D Pfautz, Penn L, NEO wrote: > Having looked over the Vancouver minutes of the WG I want to ask if I > should replace "carrier ENUM" with "infrastructure ENUM" before > resubmitting draft-lind-infrastructure-enum-reqs-01 as > draft-ietf-enum-infrastructure-enum-reqs-00. Yes .. it seemed to be the consensus of the WG that the word carrier seems to be associated with some form of disease. > If so, I would also propose to render "carrier of record" as "service > provider of record" going forward. excellent idea. > > Your views? > > Thanks, > Penn -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ 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