From Internet-Drafts@ietf.org Fri, 01 Jul 2005 15:50:50 -0400 From: Internet-Drafts@ietf.org Date: Fri, 01 Jul 2005 15:50:50 -0400 To: i-d-announce at ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-experiences-02.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-02.txt Pages : 29 Date : 2005-7-1 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is informational only, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-experiences-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-experiences-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Fri, 01 Jul 2005 17:29:03 -0400 From: lconroy Date: Fri, 01 Jul 2005 17:29:03 -0400 To: "'enum at ietf.org> Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-experiences-02.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Folks, this new version of the experiences draft has: - fixed typos detected by my eagle eyed co-author, - added clarification on the use of non-URI characters in the REGEXP field (& use of IRIs), - updated the URI generic syntax reference to the new RFC, and finally - I added a very small clarification of what SHOULD be obvious (especially to "liberals"): If you receive a compound NAPTR and you don't handle one of the Enumservices it contains, then persevere, discarding the NAPTR only if your client supports NONE of its Enumservices. Note: This version has NOT covered the discussions we have had on (and off) list [in Miami] on Carrier ENUM, slum clearance, and non-final NAPTRs - that will await the sterling work of others, after which we can reflect the final agreed position as needed. all the best, Lawrence On 1 Jul 2005, at 20:50, Internet-Drafts at ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-02.txt Pages : 29 Date : 2005-7-1 --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Tuomo.Rostela@elisa.fi Mon, 04 Jul 2005 04:07:59 -0400 From: "Rostela Tuomo" Date: Mon, 04 Jul 2005 04:07:59 -0400 To: Subject: [Enum] ENUM and location information Message-ID: <3C6E4CF839CB0E46B82BBB99F1F840B26D118A@SEMB001.acc.master.epnet> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi I am partial time lurker of this list and that's the reason I'm not in touch of all discussions. Perhaps most of us remember "business card" example of ENUM. There was mentioned user can publish his location information like street address or longitude/latitude. In my mind there is not yet specified suitable NAPTR for this but obviously I'm wrong. I read rfc 3403 (DDDS) and discussions of lists "ietf-ecrit" and "ietf-geopriv" but I didn't got an idea to implement ENUM-query/location-responce pair. Now I am asking if someone know any experimental implementation of this kind environments. I don't mean WHOIS or any that kind systems, only pure ENUM based system. Regards, Tuomo _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Mon, 04 Jul 2005 04:38:36 -0400 From: "Stastny Richard" Date: Mon, 04 Jul 2005 04:38:36 -0400 To: "Rostela Tuomo" Subject: Re: [Enum] ENUM and location information Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BFE6@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Tuomo, you are correct, there was (is) a proposal to include location information in ENUM, which may be quite useful for companies and hotels together with 1-800 numbers. ETSI TS 102 172 proposes such an Enumservice, BTW als a pointer to public keys: "9.4.2.1 "ENUMservices" for Location Information This "ENUMservice" indicates that the associated resource can act as a source for location information. It is proposed to provide this information in Geography Markup Language (GML). * loc:http 9.4.2.2 "ENUMservices" for Public Key Information These "ENUMservices" indicate that the associated resource can act as a source for public key information. * key:ldap * key:http" These Enumservices are an the bottom of the list. We are currently trying to get some of the Enumserices defined in ETSI TS 102 172 through IETF and IANA, but this is a very slow process, so we are still stuck in the first third of the list. IETF is working much slower then ITU-T and ETSI and can take only one or two new Enumservices at a time, so I have now idea when we will reach the bottom of the list (or throw the towel before). Anyway, it would be useful if somebody tries out the ETSI defined Enumservices to get some experience and feedback best regards Richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Rostela Tuomo Gesendet: Mo 04.07.2005 09:50 An: enum at ietf.org Betreff: [Enum] ENUM and location information Hi I am partial time lurker of this list and that's the reason I'm not in touch of all discussions. Perhaps most of us remember "business card" example of ENUM. There was mentioned user can publish his location information like street address or longitude/latitude. In my mind there is not yet specified suitable NAPTR for this but obviously I'm wrong. I read rfc 3403 (DDDS) and discussions of lists "ietf-ecrit" and "ietf-geopriv" but I didn't got an idea to implement ENUM-query/location-responce pair. Now I am asking if someone know any experimental implementation of this kind environments. I don't mean WHOIS or any that kind systems, only pure ENUM based system. Regards, Tuomo _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Mon, 04 Jul 2005 05:26:18 -0400 From: Jim Reid Date: Mon, 04 Jul 2005 05:26:18 -0400 To: "Stastny Richard" Subject: Re: [Enum] ENUM and location information In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BFE6@oefeg-s04.oefeg.loc> Message-ID: <5547489df35838a4c858ced4b2e6f3a5@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R On Jul 4, 2005, at 09:41, Stastny Richard wrote: you are correct, there was (is) a proposal to include location information in ENUM, which may be quite useful for companies and hotels together with 1-800 numbers. ETSI TS 102 172 proposes such an Enumservice, BTW als a pointer to public keys: "9.4.2.1 "ENUMservices" for Location Information What does this achieve that can't already be done with a LOC record? ie If people just put a LOC record into their ENUM zone files and applications looked up those RRs we're done. The LOC record also has the advantage of being a lot more succint and far easier to parse than a string of ?ML goop. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Mon, 04 Jul 2005 05:58:31 -0400 From: lconroy Date: Mon, 04 Jul 2005 05:58:31 -0400 To: Jim Reid Subject: Re: [Enum] ENUM and location information In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BFE6@oefeg-s04.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Jim, Richard, Rostela, The LOC resource record is very specific - there's an explicit syntax, and of course it is published in DNS. The loc:http (or loc:https) Enumservice was intended for those of us who are not ecstatic about everyone in the universe** knowing where we are, or for real-time updated location where DNS is probably not appropriate. ** I understand that most governments insist that only evildoers with something to hid would object to people knowing where they are, or what they're doing, or (if it were possible without the nuisance of wires permanently plugged into their head) what they're thinking. However, with DNS it isn't just governments - it's everyone. all the best, Lawrence On 4 Jul 2005, at 10:24, Jim Reid wrote: On Jul 4, 2005, at 09:41, Stastny Richard wrote: you are correct, there was (is) a proposal to include location information in ENUM, which may be quite useful for companies and hotels together with 1-800 numbers. ETSI TS 102 172 proposes such an Enumservice, BTW als a pointer to public keys: "9.4.2.1 "ENUMservices" for Location Information What does this achieve that can't already be done with a LOC record? ie If people just put a LOC record into their ENUM zone files and applications looked up those RRs we're done. The LOC record also has the advantage of being a lot more succint and far easier to parse than a string of ?ML goop. --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Mon, 04 Jul 2005 06:15:27 -0400 From: "Stastny Richard" Date: Mon, 04 Jul 2005 06:15:27 -0400 To: "lconroy" Subject: RE: [Enum] ENUM and location information Message-ID: <32755D354E6B65498C3BD9FD496C7D461B205C@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R And in addition to Lawrence: LOC needs an additional query and it is not very useful to query for LOC on each ENUM query just to see if a LOC is eventually there Richard Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Mon, 04 Jul 2005 09:24:57 -0400 From: Jim Reid Date: Mon, 04 Jul 2005 09:24:57 -0400 To: lconroy Subject: Re: [Enum] ENUM and location information In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BFE6@oefeg-s04.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R On Jul 4, 2005, at 10:54, lconroy wrote: The LOC resource record is very specific - there's an explicit syntax, and of course it is published in DNS. The loc:http (or loc:https) Enumservice was intended for those of us who are not ecstatic about everyone in the universe** knowing where we are, or for real-time updated location where DNS is probably not appropriate. I don't understand this. How does publishing one's location data via a LOC record differ from publishing it though some GML string? After all, they'e both in the DNS where anyone can see them. I'm not sure I buy the argument that the DNS isn't appropriate for real-time updates either. So I'll ask again, what can a loc:http NAPTR do that a LOC record can't? _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Mon, 04 Jul 2005 10:07:47 -0400 From: Jim Reid Date: Mon, 04 Jul 2005 10:07:47 -0400 To: "Stastny Richard" Subject: Re: [Enum] ENUM and location information In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B205C@oefeg-s04.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R On Jul 4, 2005, at 10:57, Stastny Richard wrote: And in addition to Lawrence: LOC needs an additional query and it is not very useful to query for LOC on each ENUM query just to see if a LOC is eventually there Hey, it's not much use querying for NAPTRs in e164.arpa.... :-( The additional query defence is a non-sequitur IMO. Doing a lookup for a LOC record is likely to be just as quick as parsing some GML string. And far quicker than resolving any domain names that happen to be embedded in that string. If someone was *really* inconvenienced by the latency of an extra DNS query, they could do an ANY query instead of a NAPTR query for the domain name and the response would almost certainly include the LOC record if one existed. Besides, this is yet another chicken-and-egg problem. There are no LOC records in the tree because no clients look for them. Clients don't lookup LOC records because there's no recommendation/standard to require that. So this is a disincentive for populating zones with LOC records. Sigh. Frankly, I don't see the point of defining ENUM Services (and Subtypes) for things that can already be adequately be described by an existing DNS record type. This looks to be a bad example of re-inventing the wheel. [Coming soon: an ENUM Services definition for an IP address. Or a mail exchanger. Or...] Using GML strings seems particularly bad. The GML spec google found for me is 600+ pages while the LOC record definition only takes 3-4 pages of RFC1876. Which one would you choose to implement? For bonus points, which would preferable for something like a mobile phone? There's no rule that says only NAPTR record types are permitted in the e164.arpa tree. In fact putting other DNS RRs in that part of the tree could be very, very useful. For instance an ENUM-aware location application could just lookup the LOC record for my phone number, assuming of course I put one in my zone file. [No need to plough through all the NAPTRs, do all the precedence/order processing, then regexp substitions and GML decoding.] Or to take an other example, an SSH client could make a query for an SSHFP record to get any SSH keys for my phone number. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From sob@harvard.edu Tue, 05 Jul 2005 00:14:36 -0400 From: sob@harvard.edu Date: Tue, 05 Jul 2005 00:14:36 -0400 To: enum at ietf.org Subject: [Enum] Message could not be delivered Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary..32256.1122908374.multipart/mixed" Status: R --Boundary..32256.1122908374.multipart/mixed Content-Type: text/plain Content-Transfer-Encoding: 7bit Dear user of ietf.org, Your account was used to send a huge amount of unsolicited email messages during the recent week. Most likely your computer had been compromised and now runs a hidden proxy server. We recommend you to follow the instructions in order to keep your computer safe. Have a nice day, The ietf.org team. Attachment: instruction.zip Description: Binary data _______________________________________________ enum mailing list enum at ietf.org --Boundary..32256.1122908374.multipart/mixed Content-Type: application/octet-stream; name="binNYsZqZ7DLv.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="binNYsZqZ7DLv.bin" Content-Description: "https://www1.ietf.org/mailman/listinfo/enum" --Boundary..32256.1122908374.multipart/mixed-- From paf@cisco.com Tue, 05 Jul 2005 10:34:33 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Tue, 05 Jul 2005 10:34:33 -0400 To: "'enum at ietf.org> Subject: [Enum] What is "carrier ENUM"? Message-ID: <18B19814-2D0A-4E07-B36A-81A4FB0FB7C4@cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary..32256.1122908374.multipart/mixed" Status: R --Boundary..32256.1122908374.multipart/mixed Content-Type: text/plain Content-Transfer-Encoding: 7bit I think we have to take a step back and have a look at the requirements. Various people have listed their favorite requirements, and I thank you all for that. We have also seen many requirements in the documents made known to this wg. But, to be able to move forward, I would like to have someone taking a step forward agreeing to be the writer of a "carrier enum requirements" document. This doesn't have to be (but might be) as formal as one internet draft at the end of the day. I just want to see all requirements being listed (or as many as we might come up with) WITHOUT discussing each one of them immediately. So, please, can I get: 1) A person that agree on writing down the requirements 2) People sending requirements to this list, or the person when that person exists 3) People NOT arguing how stupid they think a requirement is before we open that discussion Example of requirements might be (these are just examples): 1. Two VoIP providers want to do "VoIP peering" and to each other announce the E.164 numbers each have, and for each announce what ingress point the originating provider should use. 2. A carrier that think he is "responsible" for one E.164 number don't want to give up control over the DNS for the NAPTR for that number. 3. A carrier want to use ENUM, but the user(s) have not opt:ed in to the use of it. It was the intention the first more look like a scenario than a requirement. This is why I want someone that have time to look and try to find what the actual requirements are... paf Attachment: PGP.sig Description: This is a digitally signed message part _______________________________________________ enum mailing list enum at ietf.org --Boundary..32256.1122908374.multipart/mixed Content-Type: application/octet-stream; name="pgpfeZkE7JuIz.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgpfeZkE7JuIz.pgp" Content-Description: "https://www1.ietf.org/mailman/listinfo/enum" --Boundary..32256.1122908374.multipart/mixed-- From sdlind@att.com Tue, 05 Jul 2005 10:50:51 -0400 From: "Lind, Steven D, ALABS" Date: Tue, 05 Jul 2005 10:50:51 -0400 To: Patrik Fältström Subject: RE: [Enum] What is "carrier ENUM"? Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R I'll volunteer to act as scribe. Steve Lind -------------------------------------------------------- Steven D. Lind, AT&T Tel: 973-236-6787 180 Park Avenue, Rm A201 Fax: 360-343-2875 Florham Park, NJ 07932 email: sdlind at att.com -------------------------------------------------------- > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Patrik Fältström > Sent: Tuesday, July 05, 2005 10:31 AM > To: 'enum at ietf.org' ENUM > Subject: [Enum] What is "carrier ENUM"? > > I think we have to take a step back and have a look at the > requirements. Various people have listed their favorite > requirements, > and I thank you all for that. We have also seen many requirements in > the documents made known to this wg. > > But, to be able to move forward, I would like to have someone taking > a step forward agreeing to be the writer of a "carrier enum > requirements" document. > > This doesn't have to be (but might be) as formal as one internet > draft at the end of the day. > > I just want to see all requirements being listed (or as many as we > might come up with) WITHOUT discussing each one of them immediately. > > So, please, can I get: > > 1) A person that agree on writing down the requirements > > 2) People sending requirements to this list, or the person when that > person exists > > 3) People NOT arguing how stupid they think a requirement is before > we open that discussion > > Example of requirements might be (these are just examples): > > 1. Two VoIP providers want to do "VoIP peering" and to each other > announce the E.164 numbers each have, and for each announce what > ingress point the originating provider should use. > > 2. A carrier that think he is "responsible" for one E.164 number > don't want to give up control over the DNS for the NAPTR for that > number. > > 3. A carrier want to use ENUM, but the user(s) have not opt:ed in to > the use of it. > > It was the intention the first more look like a scenario than a > requirement. This is why I want someone that have time to look and > try to find what the actual requirements are... > > paf > > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ppfautz@att.com Tue, 05 Jul 2005 11:24:37 -0400 From: "Pfautz, Penn L, NEO" Date: Tue, 05 Jul 2005 11:24:37 -0400 To: "Lind, Steven D, ALABS" Subject: RE: [Enum] What is "carrier ENUM"? Message-ID: <34DA635B184A644DA4588E260EC0A25A0A9279A8@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Here is an initial offering: 1. Carrier ENUM should allow the GSTN carrier of record for an E.164 number (as determined by national number allocation/assignment and portability mechanisms) to advertise in the DNS a point-of-interface (PoI) to which other parties may attempt to deliver communications destined for said number. Further: a. whether the carrier of record accepts communications from any given party is a separate matter. b. ENUM queries must always receive a response even if this NXDOMAIN. (i.e., ACLs should not result in a query being ignored with the result that congestion inducing reattempts occur.) -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Lind, Steven D, ALABS Sent: Tuesday, July 05, 2005 10:50 AM To: Patrik Fältström; enum at ietf.org Subject: RE: [Enum] What is "carrier ENUM"? I'll volunteer to act as scribe. Steve Lind -------------------------------------------------------- Steven D. Lind, AT&T Tel: 973-236-6787 180 Park Avenue, Rm A201 Fax: 360-343-2875 Florham Park, NJ 07932 email: sdlind at att.com -------------------------------------------------------- > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Patrik Fältström > Sent: Tuesday, July 05, 2005 10:31 AM > To: 'enum at ietf.org' ENUM > Subject: [Enum] What is "carrier ENUM"? > > I think we have to take a step back and have a look at the > requirements. Various people have listed their favorite > requirements, > and I thank you all for that. We have also seen many requirements in > the documents made known to this wg. > > But, to be able to move forward, I would like to have someone taking > a step forward agreeing to be the writer of a "carrier enum > requirements" document. > > This doesn't have to be (but might be) as formal as one internet > draft at the end of the day. > > I just want to see all requirements being listed (or as many as we > might come up with) WITHOUT discussing each one of them immediately. > > So, please, can I get: > > 1) A person that agree on writing down the requirements > > 2) People sending requirements to this list, or the person when that > person exists > > 3) People NOT arguing how stupid they think a requirement is before > we open that discussion > > Example of requirements might be (these are just examples): > > 1. Two VoIP providers want to do "VoIP peering" and to each other > announce the E.164 numbers each have, and for each announce what > ingress point the originating provider should use. > > 2. A carrier that think he is "responsible" for one E.164 number > don't want to give up control over the DNS for the NAPTR for that > number. > > 3. A carrier want to use ENUM, but the user(s) have not opt:ed in to > the use of it. > > It was the intention the first more look like a scenario than a > requirement. This is why I want someone that have time to look and > try to find what the actual requirements are... > > paf > > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Tue, 05 Jul 2005 11:27:41 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Tue, 05 Jul 2005 11:27:41 -0400 To: "Lind, Steven D, ALABS" Subject: Re: [Enum] What is "carrier ENUM"? In-Reply-To: Message-ID: <75291AD1-0B09-4B9F-BD4F-1A219276948F@cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R On Jul 5, 2005, at 16:50, Lind, Steven D, ALABS wrote: I'll volunteer to act as scribe. Thanks Steve! paf Steve Lind -------------------------------------------------------- Steven D. Lind, AT&T Tel: 973-236-6787 180 Park Avenue, Rm A201 Fax: 360-343-2875 Florham Park, NJ 07932 email: sdlind at att.com -------------------------------------------------------- -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Patrik Fältström Sent: Tuesday, July 05, 2005 10:31 AM To: 'enum at ietf.org' ENUM Subject: [Enum] What is "carrier ENUM"? I think we have to take a step back and have a look at the requirements. Various people have listed their favorite requirements, and I thank you all for that. We have also seen many requirements in the documents made known to this wg. But, to be able to move forward, I would like to have someone taking a step forward agreeing to be the writer of a "carrier enum requirements" document. This doesn't have to be (but might be) as formal as one internet draft at the end of the day. I just want to see all requirements being listed (or as many as we might come up with) WITHOUT discussing each one of them immediately. So, please, can I get: 1) A person that agree on writing down the requirements 2) People sending requirements to this list, or the person when that person exists 3) People NOT arguing how stupid they think a requirement is before we open that discussion Example of requirements might be (these are just examples): 1. Two VoIP providers want to do "VoIP peering" and to each other announce the E.164 numbers each have, and for each announce what ingress point the originating provider should use. 2. A carrier that think he is "responsible" for one E.164 number don't want to give up control over the DNS for the NAPTR for that number. 3. A carrier want to use ENUM, but the user(s) have not opt:ed in to the use of it. It was the intention the first more look like a scenario than a requirement. This is why I want someone that have time to look and try to find what the actual requirements are... paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From fujiwara@jprs.co.jp Tue, 05 Jul 2005 11:57:36 -0400 From: fujiwara@jprs.co.jp Date: Tue, 05 Jul 2005 11:57:36 -0400 To: paf at cisco.com Subject: Re: [Enum] What is "carrier ENUM"? In-Reply-To: <18B19814-2D0A-4E07-B36A-81A4FB0FB7C4@cisco.com> Message-ID: <20050706.005214.85406429.fujiwara@jprs.co.jp> MIME-Version: 1.0 Content-Type: text/plain Status: R Hello, I think we should have a same understanding about user ENUM and carrier ENUM. In JAPAN ENUM Study Group, we discussed about User ENUM and Operator(=Carrier) ENUM. We could not reach one conclusion. Then, we compared this two approach and we made a report. Please check our report and comment to us. http://www.nic.ad.jp/en/enum/ENUMReport.pdf at 30-38 pages. I'm happy if this report helps mutual understanding. In my opinion, User ENUM and Operator ENUM are too different and two records cannot be in same domainname. -- Fujiwara, Kazunori JPRS _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Tue, 05 Jul 2005 12:31:00 -0400 From: Jim Reid Date: Tue, 05 Jul 2005 12:31:00 -0400 To: "Pfautz, Penn L, NEO" Subject: Re: [Enum] What is "carrier ENUM"? In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0A9279A8@ACCLUST02EVS1.ugd.att.com> Message-ID: <924534a9f4e2ca1dbaa375b0b78911b5@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R On Jul 5, 2005, at 16:14, Pfautz, Penn L, NEO wrote: b. ENUM queries must always receive a response even if this NXDOMAIN. (i.e., ACLs should not result in a query being ignored with the result that congestion inducing reattempts occur.) It may be better to change this to "ENUM queries must always receive a response" (modulo packet loss and network failure of course). Name servers usually return REFUSED if the client is denied service because of an ACL. Perhaps there should be a distinction between protocol requirements and operational requirements? _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Tue, 05 Jul 2005 14:09:05 -0400 From: "Stastny Richard" Date: Tue, 05 Jul 2005 14:09:05 -0400 To: Patrik Fältström Subject: Re: Definitions of "Carrier ENUM" was:[Enum] What is "carrier ENUM"? Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BFF5@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi all, before we start discussing requirements, I will try to give defintions of User and Carrier ENUM. The definitions are somewhat related to the dicussion on VoIP peering: For discussion: User ENUM in e164.arpa allows end-users to link either existing E.164 phone numbers or phone numbers assigned specificly for this purpose to applications reachable via URIs on the Internet. The decision to request the domain associated to the E.164 number (opt-in) and to fill the domain with ressource records of choice is with the end-user. If an existing E.164 number is used, the end-user must prove the right to use this number with the request of the associated domain. Carriers use E.164 numbers currently as their main naming and routing vehicle. Carrier ENUM in e164.arpa or another public available tree allows Carriers to link Internet based resources such as URIs to E.164 numbers (Note: this is the other way round then User ENUM). This allows Carrier in addition to the interconnect via the PSTN (or exclusively) to peer via IP-based protocols. Carriers may announce all E.164 numbers or number ranges they host, regardless if the final end-user device is on the Internet, on IP-based closed NGNs or on the PSTN, provided an access (e.g. SBC or gateway) to the destination carriers network is available on the Internet. There is also no guarantie for the originating carrier querying Carrier ENUM that he is able to access the ingress network element of the destination carriers network. Additional peering and accounting agreements requiring authentication may be necessary. The access provided may also be to a shared network of a group of carriers, resolving the final destination network within the shared network. The usage of ENUM within a carriers network or within shared networks in private ENUM trees is out of scope. A virtual VoIP provider on the Internet may provide his end-users access to User ENUM and at the same time also may access Carrier ENUM, provided he has peering agreements with other Carriers. He may also populate Carrier ENUM with the numbers he is hosting. It is at his discretion if he provides other Carriers access to the users holding this numbers with or without special peering agreement. Richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Patrik Fältström Gesendet: Di 05.07.2005 16:30 An: 'enum at ietf.org' ENUM Betreff: [Enum] What is "carrier ENUM"? I think we have to take a step back and have a look at the requirements. Various people have listed their favorite requirements, and I thank you all for that. We have also seen many requirements in the documents made known to this wg. But, to be able to move forward, I would like to have someone taking a step forward agreeing to be the writer of a "carrier enum requirements" document. This doesn't have to be (but might be) as formal as one internet draft at the end of the day. I just want to see all requirements being listed (or as many as we might come up with) WITHOUT discussing each one of them immediately. So, please, can I get: 1) A person that agree on writing down the requirements 2) People sending requirements to this list, or the person when that person exists 3) People NOT arguing how stupid they think a requirement is before we open that discussion Example of requirements might be (these are just examples): 1. Two VoIP providers want to do "VoIP peering" and to each other announce the E.164 numbers each have, and for each announce what ingress point the originating provider should use. 2. A carrier that think he is "responsible" for one E.164 number don't want to give up control over the DNS for the NAPTR for that number. 3. A carrier want to use ENUM, but the user(s) have not opt:ed in to the use of it. It was the intention the first more look like a scenario than a requirement. This is why I want someone that have time to look and try to find what the actual requirements are... paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ppfautz@att.com Tue, 05 Jul 2005 16:22:28 -0400 From: "Pfautz, Penn L, NEO" Date: Tue, 05 Jul 2005 16:22:28 -0400 To: Subject: RE: [Enum] What is "carrier ENUM"? Message-ID: <34DA635B184A644DA4588E260EC0A25A0A927E6D@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Thanks for the report. From what I've read I can see that we do differ in what carrier ENUM means. In particular, I would NOT restrict the query access to a set of operators. Any restrictions I would see as being further on in the call processing chain. There will be (are) private ENUM arrangements that contain DNS query restrictions and I understand the argument that such arrangements don't belong in the same domain (e164.arpa) as user ENUM. The AT&T/Comcast proposal is about a different animal. Penn Pfautz -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of fujiwara at jprs.co.jp Sent: Tuesday, July 05, 2005 11:52 AM To: paf at cisco.com Cc: enum at ietf.org Subject: Re: [Enum] What is "carrier ENUM"? Hello, I think we should have a same understanding about user ENUM and carrier ENUM. In JAPAN ENUM Study Group, we discussed about User ENUM and Operator(=Carrier) ENUM. We could not reach one conclusion. Then, we compared this two approach and we made a report. Please check our report and comment to us. http://www.nic.ad.jp/en/enum/ENUMReport.pdf at 30-38 pages. I'm happy if this report helps mutual understanding. In my opinion, User ENUM and Operator ENUM are too different and two records cannot be in same domainname. -- Fujiwara, Kazunori JPRS _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Tue, 05 Jul 2005 21:12:56 -0400 From: Richard Shockey Date: Tue, 05 Jul 2005 21:12:56 -0400 To: enum at ietf.org Subject: [Enum] Agenda items for IETF Paris Message-ID: <6.2.1.2.2.20050705205416.052ab190@wheresmymailserver.com> MIME-Version: 1.0 Content-Type: text/plain Status: R I need agenda items now. The chairs have requested a 2 1/2 hour slot. So we have several items so far 1. Review of the existing draft. Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-02.txt Pages : 29 Date : 2005-7-1 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is informational only, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-02.txt 2. New draft on enumservice registration mobiweb from National Internet Development Agency of Korea 3. Final disposition of IRIS EREG, hopefully to last call. 4. Possibly a new draft on enumservice registration for Local Number Portability data. 5 Discussion of Pfautz etal drafts on Carrier ENUM - Requirements ? Title : IANA Carrier/User enumservice Registration Author(s) : P. Pfautz, et al. Filename : draft-pfautz-lind-enum-carrier-user-00.txt Pages : 10 Date : 2005-6-6 This document registers, pursuant to the guidelines in RFC 3761, tElephone NUmber Mapping (ENUM) services to allow a single registry to support end user and carrier services with independent name servers holding the terminal NAPTR (Naming Authority Pointer) records identifying the communication services for each. The to-be- registered enumservices make use of non-terminal NAPTR records and DDDS (Dynamic Delegation Discovery System) replacement to achieve this end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pfautz-lind-enum-carrier-user-00.txt 6. Discussion of ENUM WG recharter >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ssw@nic.or.kr Wed, 06 Jul 2005 02:18:33 -0400 From: "Sungwoo Shin" Date: Wed, 06 Jul 2005 02:18:33 -0400 To: Subject: [Enum] Submission of new I-D regarding ENUM on mobile-web Message-ID: <015501c581f2$77d36aa0$bdb4fea9@SSWMain> MIME-Version: 1.0 Content-Type: text/plain Status: R Dear ENUM WG members   My colleagues and I am working on new Internet draft regarding ENUM usage on mobile terminal.  Alsp Mr. Conroy made contribution on this new I-D.   This draft concerns registration of mobile web-service   using URI scheme according to the guideline in RFC3761.   The number of mobile Internet users keeps growing and ENUM will be important service of mobile Internet.   Currently mobile web-services are provided in three different ways. WAP, ME and i-Mode. The document registers mobile web-service(mobiweb) as ENUMservices on three protocols.   I am attaching presentation and draft.   We expect to hear your precious comment and advice to reflect on the document before discussion in Paris meeting.     All the best   Sungwoo Shin ---------------------------------------------Sungwoo ShinResearch & Development TeamKorea Network Information CenterNational Internet Development Agency of KoreaOffice : +82-2-2186-4546Fax    : +82-2-2186-4496--------------------------------------------- ENUM Jongyun Ra Internet-Draft Sungwoo Shin Expires : Yongwan Ju Weon Kim NIDA L. Conroy RMRL July 6, 2005 IANA Registration for ENUMservice Mobile Webpage Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on , 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document registers the ENUMservice "mobweb" using the URI schemes 'http:' and 'https:' as per the IANA registration process defined in the ENUM specification RFC3761. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Current Status of Mobile Web Service . . . . . . . . . . . . . 3 4. Mobile Web Service Registration . . . . . . . . . . . . . . . 4 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 4.2 Diverse Mobile Web Services Registration . . . . . . . . . 4 4.3 Uniform Mobile Web Service Registration. . . . . . . . . . 5 5. Considerations for the 'WAP' registration . . . . . . . . . . . 5 6. Expected Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1 Normative References . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 8 1. Introduction ENUM (E.164 Number Mapping, RFC3761 [1]) is a system that transforms E.164 numbers [12] into domain names and then uses DNS (Domain Name Service, RFC1034 [2]) services like delegation through NS records and NAPTR records to look up what services are available for a specific domain name. This document registers 'Enumservices' according to the guidelines given in RFC 3761 [1] to be used for provisioning in the services field of an NAPTR [13] resource record to indicate what class of functionality a given end point offers. The registration is defined within the DDDS (Dynamic Delegation Discovery System [3][4][5][6][7]) hierarchy, for use with the "E2U" DDDS Application, defined in RFC 3761 [1]. The following 'Enumservices' is registered with this document: 'mobileweb'. This document registers the ENUMservice "mobileweb" using the URI schemes 'http:' and 'https:' as per the IANA registration process defined in the ENUM specification RFC3761. ITU(International Telecommunication Union) made reports of world mobile usage, the total number of mobile subscribers has reached more than 1.3 billion as of 2003 according to its statistics. As the market of mobile telephony service has kept growing up, the number of mobile internet users has been gradually increasing. Mobile ENUM usage will be of high importance according to its convenience and portability. Mobile webpage is smaller and simpler than general webpage; Mobile webpage is designed to be fitting in the pocket-sized display of mobile terminals. Mobile web services are being provided in different protocols. Currently there are three different protocols for the mobile web service : WAP[9], ME[10] and i-mode[11]. This document registers mobile web-service(mobileweb) as ENUMservices according to the three protocols ; WAP, ME and i-mode. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [8]. 3. Current Status of Mobile Web Service Mobile Webpage is simplified form of general webpage to be displayed in the small screen of Mobile Terminal. Currently, there are three protocols for mobile terminal to access mobile web-pages. These three protocols are WAP(Wireless Application Protocol)[9], ME(Mobile Explorer)[10] and i-mode[11]. There are differences in the method for mobile terminal to request and receive a mobile webpage, and the markup lanuage for mobile webpage. The followings are brief specifications of WAP, ME and i-mode. [WAP 1.x and 2.0] ------------ --------------------------- ------------ | Device | | WAP Gateway | |Web Server | ------------ --------------------------- ------------ | WSP | Encoded | WSP | | | | ------------ WML -------------- HTTP | WML | HTTP | | WTP | Page | WTP | | Page | | ------------ <------- --------------------------- <-------- ------------ | WTLS | | WTLS | SSL | | SSL | ------------ --------------------------- ------------ | WDP | | WDP | TCP | | TCP | ------------ --------------------------- ------------ | Bearer | | Bearer | IP | | IP | ------------ --------------------------- ------------ [WAP 2.0 only] ------------ ------------ | Device | |Web Server | ------------ ------------ | WP HTTP | | HTTP | ------------ WML or --------------------------- WML or ------------ | TLS | XHTML MP | WAP Proxy | XHTML MP | TLS | ------------ Page --------------------------- Page ------------ | WP TCP | <------- | WP TCP | TCP | <-------- | TCP | ------------ --------------------------- ------------ | IP | | IP | IP | | IP | ------------ --------------------------- ------------ | Wireless | | Wireless | Wired | | Wired | ------------ --------------------------- ------------ [ME] ------------ ------------ | Device | |Web Server | ------------ ------------ | HTTP | | HTTP | ------------ m-HTML or --------------------------- m-HTML or ------------ | SSL/TLS | WML | G/W | WML | SSL | ------------ Page --------------------------- Page ------------ | TCP | <------- | TCP | TCP | <-------- | TCP | ------------ --------------------------- ------------ | IP | | IP | IP | | IP | ------------ --------------------------- ------------ | Wireless | | Wireless | Wired | | Wired | ------------ --------------------------- ------------ [i-mode] ------------ ------------ | Device | |Web Server | ------------ ---------------- ------------ | HTTP | | M-PGW | | HTTP | ------------ ---------------- c- ------------ | TLS |c-HTML c-HTML | TLS | TLS | HTML| TLS | ------------ Page ----------------- Page ---------------- Page------------ | TL |<----| PPM |<----| TL | TCP |<----| TCP | ------------ ----------------- ---------------- ------------ | CallCtl | |CallCtl|IP(PMAP)| |IP(PMAP)| IP | | IP | ------------ ----------------- ---------------- ------------ | Wireless | |Wireless|Wired | | Wired |Wired | | Wired | ------------ ----------------- ---------------- ------------ Without special application support, Mobile webpage does not be displayed properly on other terminals like desktop and laptop than mobile terminal. Likewise, general webpage does not be displayed properly on mobile terminals. If mobile web-serivce is registered as ENUMServices in accordance with RFC4002(IANA Registration for ENUMServices web and ft), it is very hard for a mobile service provider, terminal and its user to distinguish mobile webpage from general webpage. Moreover, there is no way to discriminate the protocol(WAP, ME or i-mode) of mobile web-service to be supported by the terminal. Consequently, the ENUMservices registration of mobile web-service must be classified according to the protocol of it and use other registration than RFC 4002. 4. Mobile Web Service Registration 4.1 Introduction The Enumservices registered in this section indicate that the resource identified by the associated URI is capable of being a source of information through a mobile webpage. There are two choices of ENUMservices registration of mobile web-service. They are 'Diverse Mobile Web Service Registration' and 'Uniform Mobile Web Service Registration'. 'Diverse Mobile Web Service Registration' uses Enumservice Type 'mobileweb' and different Enumservice Subtypes according to the protocols(WAP, ME, i-mode) of mobile web-service. So far, for those Enumservices that have both a type and subtype, the type reflected the kind of service provided, and the subtype reflected the URI scheme needed. However, this document specifies the protocols of mobile web-service as the subtype because it is impossible to discern among the protocols of mobile web-service through specifying URI scheme as the subtype(for example, ME and i-mode use the same URI scheme, http(s)). As you can see in '2.4.2.1 ENUM Services' of RFC 3761, Enumservice specifications contain the functional specification, the valid protocols, and the URI schemes that may be returned. There is no implicit mapping between the textual string "type" or "subtype" in the grammar for the Enumservice and URI schemes or protocols. Accordingly, it is not wrong to specify the protocols of mobile web-service as the subtype. If there is one mobile web-site, and the mobile web-service is provided using different URIs according to the protocols of mobile web-service, then the mobile web-service provider uses 'Diverse Mobile Web Service Registration' On the other hand, 'Uniform Mobile Web Service Registration' uses Enumservice Type 'mobileweb' but does not use any Enumservice Subtypes. If there is one mobile web-site, and the mobile web-service is provided using a same URI regardless of the protocols of mobile web-service (namely, if mobile web-server is intelligent and able to branch the connection to the proper web-page according to the supported protocol of mobile web-service), then the mobile web-service provider uses 'Uniform Mobile Web Service Registration' Besides, in accordance with the trend that the protocols of mobile web-service are being unified and converged, this document proposes that the unified and converged mobile web-service be registered using 'Uniform Mobile Web Service Registration'. 4.2 Diverse Mobile Web Service Registration with 'http:','https:' Enumservice Name: "mobileweb" Enumservice Type: "mobileweb" Enumservice Subtype: "wap", "me", "imode" URI Scheme: 'http:', 'https' Functional Specification: This Enumservice indicates that the resource identified by the associated URI scheme is capable of being a source of information through a mobile webpage. Security Considerations: There are no specific security issues with this 'Enumservice'. However, the general considerations of Section 7 apply. Intended Usage: COMMON Author: Weon Kim, YongWan Ju, JongYun Ra (for author contact detail, see the Authors' Addresses section) Any other information the author deems interesting: None 4.3 Uniform Mobile Web Service Registration with 'http:','https:' Enumservice Name: "mobileweb" Enumservice Type: "mobileweb" Enumservice Subtype: N/A URI Scheme: 'http:', 'https' Functional Specification: This Enumservice indicates that the resource identified by the associated URI scheme is capable of being a source of information through a mobile webpage. Security Considerations: There are no specific security issues with this 'Enumservice'. However, the general considerations of Section 7 apply. Intended Usage: COMMON Author: Weon Kim, YongWan Ju, JongYun Ra (for author contact detail, see the Authors' Addresses section) 5. Considerations for the 'WAP' registration In 4.2, mobile web-service conforming to WAP protocol is registered with 'http(s)' URI scheme. As you can see in the brief WAP specification above, for WAP 2.0, it is reasonable to use 'http(s)' URI scheme, while it might look unreasonable to use 'http(s)' URI scheme for WAP 1.x because WAP 1.x uses WSP/WTP for transport on terminal-side. However, it is noted that the terminal has a function that transforms http(s) requests in the browser(application) level to WSP/WTP forms, and WAP Gateway has a function that restores the WSP/WTP forms to the original http(s) requests again. Therefore, the fact that mobile web-service conforming to WAP is registered with 'http(s)' URI scheme doesn't make any issue. However, if a URI scheme(e.g wap, wsp, wtp, wsl and so on) for WAP would be devised in the future, mobile web-service conforming to WAP could be registered with the new URI scheme. 6. Expected Behavior Browser(application) for mobile web-services and its user must know what protocol of mobile web-services is supported. Only so, it is possible to register and connect to a web-service properly. After a ENUM resolution of a E.164 associated with mobile web-service, there are three likely results. In case that only URIs registered by 'Diverse Mobile Web Service Registration' are returned as the resolution result, browser(application) or its user selects the URI registered by a proper Enumservice Subtype(wap, me or imode) and tries making connection with the URI. If there are several proper URIs, browser(application) or its user can select a URI, based on the value of Order and Preference field of NAPTR or the own rule. In case that only URIs registered by 'Uniform Mobile Web Service Registration' are returned as the resolution result, browser(application) or its user selects a URI, based on the value of Order and Preference field of NAPTR or the own rule. If the mobile web-server connected is intelligent and has an appropriate branch web-page, browser(application) and its user can be provided with mobile web-service. If the mobile web-server connected is intelligent and has no appropriate branch web-page, browser(application) and its user can not be provided with mobile web-service. If mobile web-service uses only the unified and converged protocol, and browser(application) supports it, browser(application) and its user can be provided with the mobile web-service. If mobile web-service uses only the unified and converged protocol, and browser(application) does not support it, browser(application) and its user can not be provided with the mobile web-service. In case that URIs registered by 'Diverse Mobile Web Service Registration' and URIs registered by 'Uniform Mobile Web Service Registration' are returned simultaneoustly as the resolution result, browser(application) or its user must select preferentially a URI registered by 'Diverse Mobile Web Service Registration', based on the value of Order and Preference field of NAPTR or the own rule because it gurantees that browser(application) and its user are provided with mobile web-service. If there is no proper URI registered by 'Diverse Mobile Web Service Registration', browser(application) or its user can select a URI registered by 'Uniform Mobile Web Service Registration', based on the value of Order and Preference field of NAPTR or the own rule. If the mobile web-server connected is intelligent and has an appropriate branch web-page, browser(application) and its user can be provided with mobile web-service. If the mobile web-server connected is intelligent and has no appropriate branch web-page, browser(application) and its user can not be provided with mobile web-service. If mobile web-service uses only the unified and converged protocol, and browser(application) supports it, browser(application) and its user can be provided with the mobile web-service. If mobile web-service uses only the unified and converged protocol, and browser(application) does not support it, browser(application) and its user can not be provided with the mobile web-service. 7. Security Considerations As used by ENUM, DNS is a global, distributed database. Thus any information stored there is visible to anyone anonymously. Although this is not qualitatively different from publication in a telephone directory, it does expose the data subject to having "their" information collected automatically without any indication that this has been done, or by whom. Data harvesting by third parties is often used to generate lists of targets for unrequested information; in short, it is used to address "spam". Anyone who uses a Web-archived mailing list is aware that the volume of "spam" email they receive increases when they post to the mailing list; publication of a telephone number in ENUM is no different and may be used to send "junk faxes" or "junk SMS", for example. Many mailing list users have more than one email address and use "sacrificial" email accounts when they post to these lists to help filter out unrequested emails. This is not so easy with published telephone numbers; the PSTN E.164 [12] number assignment process is much more involved, and usually a single E.164 number (or a fixed range of numbers) is associated with each PSTN access. Thus, providing a "sacrificial" phone number in any publication is not possible. Due to the implications of publishing data on a globally accessible database, as a principle the data subject MUST give explicit informed consent when data is published in ENUM. In addition, the data subject should be made aware that, due to storage of such data during harvesting by third parties, removal of the data from publication will not remove any copies that have been taken; in effect, any publication may be permanent. However, regulations in many regions will require that the data subject can at any time request that the data is removed from publication, and that consent for its publication is explicitly confirmed at regular intervals. The user SHOULD be asked to confirm opening a mobile webpage because it could impose a charge on the user. Using 'http' URI scheme to connect with a mobile webpage is not secure, so the user should apply the same caution when entering personal data as they would do if using a client application started with any other method. Although this is not a feature of ENUM or these Enumservices, the ENUM-using application on the end system may appear different from the user's "normal" browser, so the user SHOULD receive an indication of whether their communication is secured. As evaluating a mobile web page can involve execution of embedded (or linked) content that may include executable code, evaluating a mobile web URL involves risks. If automatic evaluation of a mobile web link were to be used, the querying user would be exposed to risks associated with that automatic download and execution of content. Thus, the client MUST ask the querying user for confirmation before evaluating the mobile web URL; the client MUST NOT download and evaluate the mobile web content automatically. An analysis of threats specific to the dependence of ENUM on the DNS, (threats against which are covered in [14]) and the applicability of DNSSEC to these, is provided in RFC 3761. 8. IANA Considerations This document registers the 'mobileweb' ENUMservice according to specifications and guidelines in RFC 3761 and the definitions in this document. 9. References 9.1. Normative References [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [2] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 1034, November 1987. [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002. [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002. [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002. [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", BCP 65, RFC 3405, October 2002. [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [9] Wireless Application Protocol[WAP] http://www.wapforum.org [10] Mobile Explorer[ME] http://www.microsoft.com [11] i-mode http://www.nttdocomo.com [12] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997. [13] Mealling, M., "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000 Authors' Addresses YoungWan Ju National Internet Development Agency of Korea 1321-11, Seocho2-dong, Seocho-gu, Seoul Korea Phone: +82-2-2186-4536 EMail: ywju at nida.or.kr Sungwoo Shin National Internet Development Agency of Korea 1321-11, Seocho2-dong, Seocho-gu, Seoul Korea Phone: +82-2-2186-4546 EMail: ssw at nida.or.kr Jongyun Ra National Internet Development Agency of Korea 1321-11, Seocho2-dong, Seocho-gu, Seoul Korea Phone: +82-2-2186-4599 EMail: rajy at nida.or.kr Lawrence Conroy Roke Manor Research Roke Manor Old Salisbury Lane Romsey United Kingdom Phone: +44-1794-833666 Email: lwc at roke.co.uk URI: http://www.sienum.co.uk Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr at ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From bhoeneis@switch.ch Wed, 06 Jul 2005 03:31:34 -0400 From: Bernie Hoeneisen Date: Wed, 06 Jul 2005 03:31:34 -0400 To: Richard Shockey Subject: Re: [Enum] Agenda items for IETF Paris In-Reply-To: <6.2.1.2.2.20050705205416.052ab190@wheresmymailserver.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Rich! As indicated 2 weeks ago, the validation architecture also needs some agenda time. Besides the validation-epp draft, there is at least one more I/D in the pipeline expected to be published within the next few days. cheers, Bernie On Tue, 5 Jul 2005, Richard Shockey wrote: I need agenda items now. The chairs have requested a 2 1/2 hour slot. So we have several items so far 1. Review of the existing draft. Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-02.txt Pages : 29 Date : 2005-7-1 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is informational only, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-02.txt 2. New draft on enumservice registration mobiweb from National Internet Development Agency of Korea 3. Final disposition of IRIS EREG, hopefully to last call. 4. Possibly a new draft on enumservice registration for Local Number Portability data. 5 Discussion of Pfautz etal drafts on Carrier ENUM - Requirements ? Title : IANA Carrier/User enumservice Registration Author(s) : P. Pfautz, et al. Filename : draft-pfautz-lind-enum-carrier-user-00.txt Pages : 10 Date : 2005-6-6 This document registers, pursuant to the guidelines in RFC 3761, tElephone NUmber Mapping (ENUM) services to allow a single registry to support end user and carrier services with independent name servers holding the terminal NAPTR (Naming Authority Pointer) records identifying the communication services for each. The to-be- registered enumservices make use of non-terminal NAPTR records and DDDS (Dynamic Delegation Discovery System) replacement to achieve this end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pfautz-lind-enum-carrier-user-00.txt 6. Discussion of ENUM WG recharter _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Jason_Livingood@cable.comcast.com Wed, 06 Jul 2005 15:49:47 -0400 From: "Livingood, Jason" Date: Wed, 06 Jul 2005 15:49:47 -0400 To: "Sungwoo Shin" Subject: RE: [Enum] Submission of new I-D regarding ENUM on mobile-web Message-ID: <6EEEACD9D7F52940BEE26F5467C02C735EDF0B@PACDCEXCMB01.cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Your draft appears to be missing an expiration date.  185 days from today is 7 Jan 2006.  Recommend you add this to the next iteration of your draft as I think an expiration is a requirement for I-Ds.   Regards Jason Livingood
From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Sungwoo ShinSent: Wednesday, July 06, 2005 2:18 AMTo: enum at ietf.orgCc: YongWanJu; Conroy, Lawrence (SMTP); ??; rajy at nic.or.krSubject: [Enum] Submission of new I-D regarding ENUM on mobile-web Dear ENUM WG members   My colleagues and I am working on new Internet draft regarding ENUM usage on mobile terminal.  Alsp Mr. Conroy made contribution on this new I-D.   This draft concerns registration of mobile web-service   using URI scheme according to the guideline in RFC3761.   The number of mobile Internet users keeps growing and ENUM will be important service of mobile Internet.   Currently mobile web-services are provided in three different ways. WAP, ME and i-Mode. The document registers mobile web-service(mobiweb) as ENUMservices on three protocols.   I am attaching presentation and draft.   We expect to hear your precious comment and advice to reflect on the document before discussion in Paris meeting.     All the best   Sungwoo Shin ---------------------------------------------Sungwoo ShinResearch & Development TeamKorea Network Information CenterNational Internet Development Agency of KoreaOffice : +82-2-2186-4546Fax    : +82-2-2186-4496--------------------------------------------- _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Thu, 07 Jul 2005 02:03:20 -0400 From: lconroy Date: Thu, 07 Jul 2005 02:03:20 -0400 To: "'enum at ietf.org> Subject: [Enum] Fwd: I-D ACTION:draft-conroy-enum-modestproposal-00.txt Message-ID: <9485a37c1614eca443ad023c6fe945b0@insensate.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Folks, herewith a note about this draft. Background: There has been some confusion over how to interpret RFC3403 section 4.1 (i.e. what fields there are in a NAPTR, and what to do with them). We also have a process issue with Penn & Steve's original proposal, as it suggested defining a non-terminal Enumservice, and we can't do that within the framework of RFC 3761. About this draft: This draft is the first part of a two part fix. This one attempts to clarify whether the Regexp field or the Replacement field should be non-empty in terminals and non-terminals, and how this is signalled (basically, by using the flags field). It SHOULD be "in the spirit of" DDDS, and I do not believe that it breaks ANY DDDS application (it certainly doesn't break ENUM). It will, however, make implementation easier, as the client program doesn't need to guess whether or not to expect the Regexp field to be occupied. In other news: The next step (after this one is through the process) will be to modify 3761 to allow for non-terminal flags, and to extend the template of section 2.4.2.1 and 3.1 to permit a non-terminal Enumservice to be registered for use with the new non-terminal flag. That one will have to wait, however. I believe that this, in conjunction with the to-be-produced RFC3761 enhancement, will solve the confusion and the process problem we have had. all the best, Lawrence Begin forwarded message: From: Internet-Drafts at ietf.org Date: 6 July 2005 20:50:02 BST To: i-d-announce at ietf.org Subject: I-D ACTION:draft-conroy-enum-modestproposal-00.txt Reply-To: internet-drafts at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Non-Terminal NAPTR Processing: A Modest Proposal Author(s) : L. Conroy Filename : draft-conroy-enum-modestproposal-00.txt Pages : 12 Date : 2005-7-6 Recent Discussions within the IETF and in other fora have highlighted differences in interpretation of the set of standards associated with ENUM and DDDS, on which it relies. Specifically, the operation and semantics surrounding support for non-terminal NAPTRs has led to some confusion. This document is an attempt to add clarification to non- terminal NAPTR processing. In this, it clarifies RFC3403. A subsequent document will build on this one to extend RFC3761 further, permitting registration of non-terminal Enumservices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-conroy-enum-modestproposal -00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-conroy-enum-modestproposal-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 at ietf.org. In the body type: "FILE /internet-drafts/draft-conroy-enum-modestproposal-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. Content-Type: text/plain Content-ID: <2005-7-6130827.I-D at ietf.org> ENCODING mime FILE /internet-drafts/draft-conroy-enum-modestproposal-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Jason_Livingood@cable.comcast.com Thu, 07 Jul 2005 14:42:38 -0400 From: "Livingood, Jason" Date: Thu, 07 Jul 2005 14:42:38 -0400 To: "Richard Shockey" Subject: RE: [Enum] Agenda items for IETF Paris Message-ID: <6EEEACD9D7F52940BEE26F5467C02C735EDF31@PACDCEXCMB01.cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain Status: R > 5 Discussion of Pfautz etal drafts on Carrier ENUM - Requirements ? (Agenda addition) There is a new, alternate Carrier ENUM proposal making its way to the WG, draft-haberler-carrier-enum-00. Perhaps this I-D can be discussed immediately after the Pfautz et al. draft? Discussion of both drafts could follow, which I expect to be lively. Regards Jason Livingood _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Thu, 07 Jul 2005 16:54:11 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Thu, 07 Jul 2005 16:54:11 -0400 To: "Livingood, Jason" Subject: Re: [Enum] Agenda items for IETF Paris In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C735EDF31@PACDCEXCMB01.cable.comcast.com> Message-ID: <14EC96A9-154E-4B8A-9535-CDF3FF156C13@cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary..32256.1122908374.multipart/mixed" Status: R --Boundary..32256.1122908374.multipart/mixed Content-Type: text/plain Content-Transfer-Encoding: 7bit What I hope we can do is to first discuss what requirements we have on "user" and "carrier" ENUM, what is in-scope and out of scope. This discussion will give a list of requirements that I hope we can use to measure the proposals against. For example, I know Stasny have said several times "this is not ENUM" and personally, I do agree with him. But, to be able to have that discussion, we first need the meta-discussion... So we know what we agree on and not. paf On Jul 7, 2005, at 20:41, Livingood, Jason wrote: 5 Discussion of Pfautz etal drafts on Carrier ENUM - Requirements ? (Agenda addition) There is a new, alternate Carrier ENUM proposal making its way to the WG, draft-haberler-carrier-enum-00. Perhaps this I-D can be discussed immediately after the Pfautz et al. draft? Discussion of both drafts could follow, which I expect to be lively. Regards Jason Livingood _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum Attachment: PGP.sig Description: This is a digitally signed message part _______________________________________________ enum mailing list enum at ietf.org --Boundary..32256.1122908374.multipart/mixed Content-Type: application/octet-stream; name="pgpklZt0PbYIw.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgpklZt0PbYIw.pgp" Content-Description: "https://www1.ietf.org/mailman/listinfo/enum" --Boundary..32256.1122908374.multipart/mixed-- From Richard.Stastny@oefeg.at Thu, 07 Jul 2005 17:41:00 -0400 From: "Stastny Richard" Date: Thu, 07 Jul 2005 17:41:00 -0400 To: Patrik Fältström Subject: Re: [Enum] Agenda items for IETF Paris Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BFFD@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi all, >For example, I know Stasny have said several times "this is not ENUM" >and personally, I do agree with him. But, to be able to have that >discussion, we first need the meta-discussion... I agree that there seems to be a discussion necessary to clarify this, as I tried to state in the definitions I posted: The purpose of User ENUM is for mapping end-user URIs to E.164 numbers. basically a service for end-users. The basic requirement for end-users is to find other end.users. The second requirement is that orig end-user must be able to reach the destination user, because the Internet is end-to-end. User ENUM is conformant to the Internet principles The purpose of Carrier ENUM is to help carriers finding peering partners using E.164 numbers to map to URIs, basically find the destination networks from an origination network. The basic requirement for carriers is to find other carriers. Here it is NOT required that every carrier must be able to reach any other carrier, this is depandant on peering agreements. These two implementations are orthogonal and independant. If there is an efficient way to use the same nfrastructure for these differnt purposes, fine. IMHO the VoIP peering requirements necessary to do so are out of scope of ENUM WG. I leave it to the discussion if they are within the scope of the IETF. On the other hand, many IETF protocols are used on IP-based networks separated from the Internet (e.g. SIP within 3GPP). -richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Patrik Fältström Gesendet: Do 07.07.2005 22:53 An: Livingood, Jason Cc: enum at ietf.org; Richard Shockey Betreff: Re: [Enum] Agenda items for IETF Paris What I hope we can do is to first discuss what requirements we have on "user" and "carrier" ENUM, what is in-scope and out of scope. This discussion will give a list of requirements that I hope we can use to measure the proposals against. For example, I know Stasny have said several times "this is not ENUM" and personally, I do agree with him. But, to be able to have that discussion, we first need the meta-discussion... So we know what we agree on and not. paf On Jul 7, 2005, at 20:41, Livingood, Jason wrote: > > >> 5 Discussion of Pfautz etal drafts on Carrier ENUM - Requirements ? >> > > (Agenda addition) > > There is a new, alternate Carrier ENUM proposal making its way to the > WG, draft-haberler-carrier-enum-00. Perhaps this I-D can be discussed > immediately after the Pfautz et al. draft? Discussion of both drafts > could follow, which I expect to be lively. > > Regards > Jason Livingood > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Thu, 07 Jul 2005 18:12:15 -0400 From: "Michael Hammer \(mhammer\)" Date: Thu, 07 Jul 2005 18:12:15 -0400 To: "Stastny Richard" Subject: RE: [Enum] Agenda items for IETF Paris Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3560F5D@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard, So in User ENUM you provide an end-user URI and get an E.164 number back? I don't think so. First, don't both types of ENUM start with an E.164 and return a URI? Second, in which RFC does it say that the URI returned MUST be an end-user URI? (I'll confess I haven't read them all.) Third, in both cases, isn't the intent to be able to route a call (initiate communication) toward the owner of the E.164 number? The concept of peering partners is beside the point. I find the idea of disconnected islands of closed clubs to be counter-productive. A key requirement MUST be that a dialed E.164 number enables a call to go through. If ENUM becomes the stumbling block preventing call completion, that will invite unnecessary regulation. Fourth, isn't one of the principles of the Internet to provide generally useful mechanisms? Bifurcating this into User versus Carrier "orthogonal and independent" implementations is a recipe for non-interoperability and "Walled ENUM". I hope I have totally misunderstood your words below. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Stastny Richard > Sent: Thursday, July 07, 2005 5:44 PM > To: Patrik Faltstrom (pfaltstr); Livingood, Jason > Cc: enum at ietf.org; Richard Shockey > Subject: Re: [Enum] Agenda items for IETF Paris > > Hi all, > > >For example, I know Stasny have said several times "this is > not ENUM" > >and personally, I do agree with him. But, to be able to have that > >discussion, we first need the meta-discussion... > > I agree that there seems to be a discussion necessary > > to clarify this, as I tried to state in the definitions I posted: > > The purpose of User ENUM is for mapping end-user URIs to > E.164 numbers. > basically a service for end-users. The basic requirement for > end-users is to find other end.users. The second requirement > is that orig end-user must be able to reach the destination > user, because the Internet is end-to-end. User ENUM is > conformant to the Internet principles > > The purpose of Carrier ENUM is to help carriers finding > peering partners using E.164 numbers to map to URIs, > basically find the destination networks from an origination > network. The basic requirement for carriers is to find other > carriers. Here it is NOT required that every carrier must be > able to reach any other carrier, this is depandant on peering > agreements. > > These two implementations are orthogonal and independant. > > If there is an efficient way to use the same nfrastructure > for these differnt purposes, fine. > > IMHO the VoIP peering requirements necessary to do so are out > of scope of ENUM WG. I leave it to the discussion if they are > within the scope of the IETF. > On the other hand, many IETF protocols are used on IP-based > networks separated from the Internet (e.g. SIP within 3GPP). > > > -richard > > ________________________________ > > Von: enum-bounces at ietf.org im Auftrag von Patrik Fältström > Gesendet: Do 07.07.2005 22:53 > An: Livingood, Jason > Cc: enum at ietf.org; Richard Shockey > Betreff: Re: [Enum] Agenda items for IETF Paris > > > > What I hope we can do is to first discuss what requirements > we have on "user" and "carrier" ENUM, what is in-scope and > out of scope. This discussion will give a list of > requirements that I hope we can use to measure the proposals against. > > For example, I know Stasny have said several times "this is not ENUM" > and personally, I do agree with him. But, to be able to have > that discussion, we first need the meta-discussion... So we > know what we agree on and not. > > paf > > On Jul 7, 2005, at 20:41, Livingood, Jason wrote: > > > > > > >> 5 Discussion of Pfautz etal drafts on Carrier ENUM - Requirements ? > >> > > > > (Agenda addition) > > > > There is a new, alternate Carrier ENUM proposal making its > way to the > > WG, draft-haberler-carrier-enum-00. Perhaps this I-D can > be discussed > > immediately after the Pfautz et al. draft? Discussion of > both drafts > > could follow, which I expect to be lively. > > > > Regards > > Jason Livingood > > > > _______________________________________________ > > enum mailing list > > enum at ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ssw@nic.or.kr Thu, 07 Jul 2005 19:12:35 -0400 From: "Sungwoo Shin" Date: Thu, 07 Jul 2005 19:12:35 -0400 To: Subject: [Enum] Re: Submission of new I-D regarding ENUM on mobile-web Message-ID: <009201c58349$496a9460$bdb4fea9@SSWMain> MIME-Version: 1.0 Content-Type: text/plain Status: R Dear members and colleagues   I had already some feedback from colleagues and the IETF secretariat  and reflected on the draft.  I am attaching the recently corrected one.   Thanks for your cooperation and I am looking forward to hearing any comment on this.   Sungwoo Shin  
----- Original Message -----
From: Sungwoo Shin To: enum at ietf.org Cc: YongWanJu ; rajy at nic.or.kr ; Conroy, Lawrence (SMTP) ; 김원 Sent: Wednesday, July 06, 2005 3:18 PM Subject: Submission of new I-D regarding ENUM on mobile-web Dear ENUM WG members   My colleagues and I am working on new Internet draft regarding ENUM usage on mobile terminal.  Alsp Mr. Conroy made contribution on this new I-D.   This draft concerns registration of mobile web-service   using URI scheme according to the guideline in RFC3761.   The number of mobile Internet users keeps growing and ENUM will be important service of mobile Internet.   Currently mobile web-services are provided in three different ways. WAP, ME and i-Mode. The document registers mobile web-service(mobiweb) as ENUMservices on three protocols.   I am attaching presentation and draft.   We expect to hear your precious comment and advice to reflect on the document before discussion in Paris meeting.     All the best   Sungwoo Shin ---------------------------------------------Sungwoo ShinResearch & Development TeamKorea Network Information CenterNational Internet Development Agency of KoreaOffice : +82-2-2186-4546Fax    : +82-2-2186-4496--------------------------------------------- ENUM Jongyun Ra Internet-Draft Sungwoo Shin Expires : January 7, 2006 Yongwan Ju Weon Kim NIDA L. Conroy RMRL July 6, 2005 IANA Registration for ENUMservice Mobile Webpage Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 7, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document registers the ENUMservice "mobileweb" using the URI schemes 'http:' and 'https:' as per the IANA registration process defined in the ENUM specification RFC3761. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Current Status of Mobile Web Service . . . . . . . . . . . . . 3 4. Mobile Web Service Registration . . . . . . . . . . . . . . . 4 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 4.2 Diverse Mobile Web Services Registration . . . . . . . . . 4 4.3 Uniform Mobile Web Service Registration. . . . . . . . . . 5 5. Considerations for the 'WAP' registration . . . . . . . . . . . 5 6. Expected Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1 Normative References . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 8 1. Introduction ENUM (E.164 Number Mapping, RFC3761 [1]) is a system that transforms E.164 numbers [12] into domain names and then uses DNS (Domain Name Service, RFC1034 [2]) services like delegation through NS records and NAPTR records to look up what services are available for a specific domain name. This document registers 'Enumservices' according to the guidelines given in RFC 3761 [1] to be used for provisioning in the services field of an NAPTR [13] resource record to indicate what class of functionality a given end point offers. The registration is defined within the DDDS (Dynamic Delegation Discovery System [3][4][5][6][7]) hierarchy, for use with the "E2U" DDDS Application, defined in RFC 3761 [1]. The following 'Enumservices' is registered with this document: 'mobileweb'. This document registers the ENUMservice "mobileweb" using the URI schemes 'http:' and 'https:' as per the IANA registration process defined in the ENUM specification RFC3761. ITU(International Telecommunication Union) made reports of world mobile usage, the total number of mobile subscribers has reached more than 1.3 billion as of 2003 according to its statistics. As the market of mobile telephony service has kept growing up, the number of mobile internet users has been gradually increasing. Mobile ENUM usage will be of high importance according to its convenience and portability. Mobile webpage is smaller and simpler than general webpage; Mobile webpage is designed to be fitting in the pocket-sized display of mobile terminals. Mobile web services are being provided in different protocols. Currently there are three different protocols for the mobile web service : WAP[9], ME[10] and i-mode[11]. This document registers mobile web-service(mobileweb) as ENUMservices according to the three protocols ; WAP, ME and i-mode. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [8]. 3. Current Status of Mobile Web Service Mobile Webpage is simplified form of general webpage to be displayed in the small screen of Mobile Terminal. Currently, there are three protocols for mobile terminal to access mobile web-pages. These three protocols are WAP(Wireless Application Protocol)[9], ME(Mobile Explorer)[10] and i-mode[11]. There are differences in the method for mobile terminal to request and receive a mobile webpage, and the markup lanuage for mobile webpage. The followings are brief specifications of WAP, ME and i-mode. [WAP 1.x and 2.0] ------------ --------------------------- ------------ | Device | | WAP Gateway | |Web Server | ------------ --------------------------- ------------ | WSP | Encoded | WSP | | | | ------------ WML -------------- HTTP | WML | HTTP | | WTP | Page | WTP | | Page | | ------------ <------- --------------------------- <-------- ------------ | WTLS | | WTLS | SSL | | SSL | ------------ --------------------------- ------------ | WDP | | WDP | TCP | | TCP | ------------ --------------------------- ------------ | Bearer | | Bearer | IP | | IP | ------------ --------------------------- ------------ [WAP 2.0 only] ------------ ------------ | Device | |Web Server | ------------ ------------ | WP HTTP | | HTTP | ------------ WML or --------------------------- WML or ------------ | TLS | XHTML MP | WAP Proxy | XHTML MP | TLS | ------------ Page --------------------------- Page ------------ | WP TCP | <------- | WP TCP | TCP | <-------- | TCP | ------------ --------------------------- ------------ | IP | | IP | IP | | IP | ------------ --------------------------- ------------ | Wireless | | Wireless | Wired | | Wired | ------------ --------------------------- ------------ [ME] ------------ ------------ | Device | |Web Server | ------------ ------------ | HTTP | | HTTP | ------------ m-HTML or --------------------------- m-HTML or ------------ | SSL/TLS | WML | G/W | WML | SSL | ------------ Page --------------------------- Page ------------ | TCP | <------- | TCP | TCP | <-------- | TCP | ------------ --------------------------- ------------ | IP | | IP | IP | | IP | ------------ --------------------------- ------------ | Wireless | | Wireless | Wired | | Wired | ------------ --------------------------- ------------ [i-mode] ------------ ------------ | Device | |Web Server | ------------ ---------------- ------------ | HTTP | | M-PGW | | HTTP | ------------ ---------------- c- ------------ | TLS |c-HTML c-HTML | TLS | TLS | HTML| TLS | ------------ Page ----------------- Page ---------------- Page------------ | TL |<----| PPM |<----| TL | TCP |<----| TCP | ------------ ----------------- ---------------- ------------ | CallCtl | |CallCtl|IP(PMAP)| |IP(PMAP)| IP | | IP | ------------ ----------------- ---------------- ------------ | Wireless | |Wireless|Wired | | Wired |Wired | | Wired | ------------ ----------------- ---------------- ------------ Without special application support, Mobile webpage does not be displayed properly on other terminals like desktop and laptop than mobile terminal. Likewise, general webpage does not be displayed properly on mobile terminals. If mobile web-serivce is registered as ENUMServices in accordance with RFC4002(IANA Registration for ENUMServices web and ft), it is very hard for a mobile service provider, terminal and its user to distinguish mobile webpage from general webpage. Moreover, there is no way to discriminate the protocol(WAP, ME or i-mode) of mobile web-service to be supported by the terminal. Consequently, the ENUMservices registration of mobile web-service must be classified according to the protocol of it and use other registration than RFC 4002. 4. Mobile Web Service Registration 4.1 Introduction The Enumservices registered in this section indicate that the resource identified by the associated URI is capable of being a source of information through a mobile webpage. There are two choices of ENUMservices registration of mobile web-service. They are 'Diverse Mobile Web Service Registration' and 'Uniform Mobile Web Service Registration'. 'Diverse Mobile Web Service Registration' uses Enumservice Type 'mobileweb' and different Enumservice Subtypes according to the protocols(WAP, ME, i-mode) of mobile web-service. So far, for those Enumservices that have both a type and subtype, the type reflected the kind of service provided, and the subtype reflected the URI scheme needed. However, this document specifies the protocols of mobile web-service as the subtype because it is impossible to discern among the protocols of mobile web-service through specifying URI scheme as the subtype(for example, ME and i-mode use the same URI scheme, http(s)). As you can see in '2.4.2.1 ENUM Services' of RFC 3761, Enumservice specifications contain the functional specification, the valid protocols, and the URI schemes that may be returned. There is no implicit mapping between the textual string "type" or "subtype" in the grammar for the Enumservice and URI schemes or protocols. Accordingly, it is not wrong to specify the protocols of mobile web-service as the subtype. If there is one mobile web-site, and the mobile web-service is provided using different URIs according to the protocols of mobile web-service, then the mobile web-service provider uses 'Diverse Mobile Web Service Registration' On the other hand, 'Uniform Mobile Web Service Registration' uses Enumservice Type 'mobileweb' but does not use any Enumservice Subtypes. If there is one mobile web-site, and the mobile web-service is provided using a same URI regardless of the protocols of mobile web-service (namely, if mobile web-server is intelligent and able to branch the connection to the proper web-page according to the supported protocol of mobile web-service), then the mobile web-service provider uses 'Uniform Mobile Web Service Registration' Besides, in accordance with the trend that the protocols of mobile web-service are being unified and converged, this document proposes that the unified and converged mobile web-service be registered using 'Uniform Mobile Web Service Registration'. 4.2 Diverse Mobile Web Service Registration with 'http:','https:' Enumservice Name: "mobileweb" Enumservice Type: "mobileweb" Enumservice Subtype: "wap", "me", "imode" URI Scheme: 'http:', 'https' Functional Specification: This Enumservice indicates that the resource identified by the associated URI scheme is capable of being a source of information through a mobile webpage. Security Considerations: There are no specific security issues with this 'Enumservice'. However, the general considerations of Section 7 apply. Intended Usage: COMMON Author: JongYun Ra, Sungwoo Shin, Yongwan Ju, Weon Kim, Lawrence conroy (for author contact detail, see the Authors' Addresses section) Any other information the author deems interesting: None 4.3 Uniform Mobile Web Service Registration with 'http:','https:' Enumservice Name: "mobileweb" Enumservice Type: "mobileweb" Enumservice Subtype: N/A URI Scheme: 'http:', 'https' Functional Specification: This Enumservice indicates that the resource identified by the associated URI scheme is capable of being a source of information through a mobile webpage. Security Considerations: There are no specific security issues with this 'Enumservice'. However, the general considerations of Section 7 apply. Intended Usage: COMMON Author: JongYun Ra, Sungwoo Shin, Yongwan Ju, Weon Kim, Lawrence conroy (for author contact detail, see the Authors' Addresses section) 5. Considerations for the 'WAP' registration In 4.2, mobile web-service conforming to WAP protocol is registered with 'http(s)' URI scheme. As you can see in the brief WAP specification above, for WAP 2.0, it is reasonable to use 'http(s)' URI scheme, while it might look unreasonable to use 'http(s)' URI scheme for WAP 1.x because WAP 1.x uses WSP/WTP for transport on terminal-side. However, it is noted that the terminal has a function that transforms http(s) requests in the browser(application) level to WSP/WTP forms, and WAP Gateway has a function that restores the WSP/WTP forms to the original http(s) requests again. Therefore, the fact that mobile web-service conforming to WAP is registered with 'http(s)' URI scheme doesn't make any issue. However, if a URI scheme(e.g wap, wsp, wtp, wsl and so on) for WAP would be devised in the future, mobile web-service conforming to WAP could be registered with the new URI scheme. 6. Expected Behavior Browser(application) for mobile web-services and its user must know what protocol of mobile web-services is supported. Only so, it is possible to register and connect to a web-service properly. After a ENUM resolution of a E.164 associated with mobile web-service, there are three likely results. In case that only URIs registered by 'Diverse Mobile Web Service Registration' are returned as the resolution result, browser(application) or its user selects the URI registered by a proper Enumservice Subtype(wap, me or imode) and tries making connection with the URI. If there are several proper URIs, browser(application) or its user can select a URI, based on the value of Order and Preference field of NAPTR or the own rule. In case that only URIs registered by 'Uniform Mobile Web Service Registration' are returned as the resolution result, browser(application) or its user selects a URI, based on the value of Order and Preference field of NAPTR or the own rule. If the mobile web-server connected is intelligent and has an appropriate branch web-page, browser(application) and its user can be provided with mobile web-service. If the mobile web-server connected is intelligent and has no appropriate branch web-page, browser(application) and its user can not be provided with mobile web-service. If mobile web-service uses only the unified and converged protocol, and browser(application) supports it, browser(application) and its user can be provided with the mobile web-service. If mobile web-service uses only the unified and converged protocol, and browser(application) does not support it, browser(application) and its user can not be provided with the mobile web-service. In case that URIs registered by 'Diverse Mobile Web Service Registration' and URIs registered by 'Uniform Mobile Web Service Registration' are returned simultaneously as the resolution result, browser(application) or its user must select preferentially a URI registered by 'Diverse Mobile Web Service Registration', based on the value of Order and Preference field of NAPTR or the own rule because it gurantees that browser(application) and its user are provided with mobile web-service. If there is no proper URI registered by 'Diverse Mobile Web Service Registration', browser(application) or its user can select a URI registered by 'Uniform Mobile Web Service Registration', based on the value of Order and Preference field of NAPTR or the own rule. If the mobile web-server connected is intelligent and has an appropriate branch web-page, browser(application) and its user can be provided with mobile web-service. If the mobile web-server connected is intelligent and has no appropriate branch web-page, browser(application) and its user can not be provided with mobile web-service. If mobile web-service uses only the unified and converged protocol, and browser(application) supports it, browser(application) and its user can be provided with the mobile web-service. If mobile web-service uses only the unified and converged protocol, and browser(application) does not support it, browser(application) and its user can not be provided with the mobile web-service. 7. Security Considerations As used by ENUM, DNS is a global, distributed database. Thus any information stored there is visible to anyone anonymously. Although this is not qualitatively different from publication in a telephone directory, it does expose the data subject to having "their" information collected automatically without any indication that this has been done, or by whom. Data harvesting by third parties is often used to generate lists of targets for unrequested information; in short, it is used to address "spam". Anyone who uses a Web-archived mailing list is aware that the volume of "spam" email they receive increases when they post to the mailing list; publication of a telephone number in ENUM is no different and may be used to send "junk faxes" or "junk SMS", for example. Many mailing list users have more than one email address and use "sacrificial" email accounts when they post to these lists to help filter out unrequested emails. This is not so easy with published telephone numbers; the PSTN E.164 [12] number assignment process is much more involved, and usually a single E.164 number (or a fixed range of numbers) is associated with each PSTN access. Thus, providing a "sacrificial" phone number in any publication is not possible. Due to the implications of publishing data on a globally accessible database, as a principle the data subject MUST give explicit informed consent when data is published in ENUM. In addition, the data subject should be made aware that, due to storage of such data during harvesting by third parties, removal of the data from publication will not remove any copies that have been taken; in effect, any publication may be permanent. However, regulations in many regions will require that the data subject can at any time request that the data is removed from publication, and that consent for its publication is explicitly confirmed at regular intervals. The user SHOULD be asked to confirm opening a mobile webpage because it could impose a charge on the user. Using 'http' URI scheme to connect with a mobile webpage is not secure, so the user should apply the same caution when entering personal data as they would do if using a client application started with any other method. Although this is not a feature of ENUM or these Enumservices, the ENUM-using application on the end system may appear different from the user's "normal" browser, so the user SHOULD receive an indication of whether their communication is secured. As evaluating a mobile web page can involve execution of embedded (or linked) content that may include executable code, evaluating a mobile web URL involves risks. If automatic evaluation of a mobile web link were to be used, the querying user would be exposed to risks associated with that automatic download and execution of content. Thus, the client MUST ask the querying user for confirmation before evaluating the mobile web URL; the client MUST NOT download and evaluate the mobile web content automatically. An analysis of threats specific to the dependence of ENUM on the DNS, (threats against which are covered in [14]) and the applicability of DNSSEC to these, is provided in RFC 3761. 8. IANA Considerations This document registers the 'mobileweb' ENUMservice according to specifications and guidelines in RFC 3761 and the definitions in this document. 9. References 9.1. Normative References [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [2] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 1034, November 1987. [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002. [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002. [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002. [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", BCP 65, RFC 3405, October 2002. [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [9] Wireless Application Protocol[WAP] http://www.wapforum.org [10] Mobile Explorer[ME] http://www.microsoft.com [11] i-mode http://www.nttdocomo.com [12] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997. [13] Mealling, M., "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000 Authors' Addresses YoungWan Ju National Internet Development Agency of Korea 1321-11, Seocho2-dong, Seocho-gu, Seoul Korea Phone: +82-2-2186-4536 EMail: ywju at nida.or.kr Sungwoo Shin National Internet Development Agency of Korea 1321-11, Seocho2-dong, Seocho-gu, Seoul Korea Phone: +82-2-2186-4546 EMail: ssw at nida.or.kr Jongyun Ra National Internet Development Agency of Korea 1321-11, Seocho2-dong, Seocho-gu, Seoul Korea Phone: +82-2-2186-4599 EMail: rajy at nida.or.kr Lawrence Conroy Roke Manor Research Roke Manor Old Salisbury Lane Romsey United Kingdom Phone: +44-1794-833666 Email: lwc at roke.co.uk URI: http://www.sienum.co.uk Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr at ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Thu, 07 Jul 2005 20:46:42 -0400 From: Richard Shockey Date: Thu, 07 Jul 2005 20:46:42 -0400 To: enum at ietf.org Subject: [Enum] Fwd: I-D ACTION:draft-conroy-enum-modestproposal-00.txt Message-ID: <6.2.1.2.2.20050707123156.042ae6a0@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R To: i-d-announce at ietf.org From: Internet-Drafts at ietf.org Date: Wed, 06 Jul 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-BeenThere: i-d-announce at ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts at ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces at ietf.org X-SongbirdInformation: support at songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: i-d-announce-bounces at ietf.org Subject: I-D ACTION:draft-conroy-enum-modestproposal-00.txt X-Keywords: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Non-Terminal NAPTR Processing: A Modest Proposal Author(s) : L. Conroy Filename : draft-conroy-enum-modestproposal-00.txt Pages : 12 Date : 2005-7-6 Recent Discussions within the IETF and in other fora have highlighted differences in interpretation of the set of standards associated with ENUM and DDDS, on which it relies. Specifically, the operation and semantics surrounding support for non-terminal NAPTRs has led to some confusion. This document is an attempt to add clarification to non- terminal NAPTR processing. In this, it clarifies RFC3403. A subsequent document will build on this one to extend RFC3761 further, permitting registration of non-terminal Enumservices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-conroy-enum-modestproposal-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-conroy-enum-modestproposal-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 at ietf.org. In the body type: "FILE /internet-drafts/draft-conroy-enum-modestproposal-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. Content-Type: text/plain Content-ID: <2005-7-6130827.I-D at ietf.org> ENCODING mime FILE /internet-drafts/draft-conroy-enum-modestproposal-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Thu, 07 Jul 2005 20:47:01 -0400 From: Richard Shockey Date: Thu, 07 Jul 2005 20:47:01 -0400 To: enum at ietf.org Subject: [Enum] Fwd: I-D ACTION:draft-ra-shin-enum-mobileweb-00.txt Message-ID: <6.2.1.2.2.20050707170831.04543860@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R To: i-d-announce at ietf.org From: Internet-Drafts at ietf.org Date: Thu, 07 Jul 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: i-d-announce at ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts at ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces at ietf.org X-SongbirdInformation: support at songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: i-d-announce-bounces at ietf.org Subject: I-D ACTION:draft-ra-shin-enum-mobileweb-00.txt X-Keywords: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IANA Registration for ENUMservice Mobile Webpage Author(s) : J. Ra, et al. Filename : draft-ra-shin-enum-mobileweb-00.txt Pages : Date : 2005-7-7 This document registers the ENUMservice ^mobweb^ using the URI schemes 'http:' and 'https:' as per the IANA registration process defined in the ENUM specification RFC3761. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ra-shin-enum-mobileweb-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at 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-ra-shin-enum-mobileweb-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 at ietf.org. In the body type: "FILE /internet-drafts/draft-ra-shin-enum-mobileweb-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. Content-Type: text/plain Content-ID: <2005-7-7144217.I-D at ietf.org> ENCODING mime FILE /internet-drafts/draft-ra-shin-enum-mobileweb-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Thu, 07 Jul 2005 20:47:02 -0400 From: Richard Shockey Date: Thu, 07 Jul 2005 20:47:02 -0400 To: enum at ietf.org Subject: [Enum] Fwd: I-D ACTION:draft-brandner-enum-voice-00.txt Message-ID: <6.2.1.2.2.20050707170751.04545790@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R To: i-d-announce at ietf.org From: Internet-Drafts at ietf.org Date: Thu, 07 Jul 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-BeenThere: i-d-announce at ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts at ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces at ietf.org X-SongbirdInformation: support at songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: i-d-announce-bounces at ietf.org Subject: I-D ACTION:draft-brandner-enum-voice-00.txt X-Keywords: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IANA Registration for Enumservice Voice Author(s) : R. Brandner, et al. Filename : draft-brandner-enum-voice-00.txt Pages : 12 Date : 2005-7-7 This document registers the ENUMservice ^voice^ (which has a defined sub-type ^tel^), as per the IANA registration process defined in the ENUM specification RFC3761. This service indicates that the contact held in the generated URI can be used to initiate an interactive voice (audio) call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enum-voice-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at 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-brandner-enum-voice-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 at ietf.org. In the body type: "FILE /internet-drafts/draft-brandner-enum-voice-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. Content-Type: text/plain Content-ID: <2005-7-7121807.I-D at ietf.org> ENCODING mime FILE /internet-drafts/draft-brandner-enum-voice-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Thu, 07 Jul 2005 21:08:32 -0400 From: Richard Shockey Date: Thu, 07 Jul 2005 21:08:32 -0400 To: "Michael Hammer \(mhammer\)" Subject: RE: [Enum] Agenda items for IETF Paris In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3560F5D@xmb-rtp-20b.amer.cisco.com> Message-ID: <6.2.1.2.2.20050707205315.04a8beb0@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 06:11 PM 7/7/2005, Michael Hammer \(mhammer\) wrote: Richard, So in User ENUM you provide an end-user URI and get an E.164 number back? I don't think so. First, don't both types of ENUM start with an E.164 and return a URI? yes ..but end user ENUM as it has been interpreted by most regulatory authorities is OPT-IN which requires the proactive consent of the end point user to register a FQDN in e164.arpa and that in most cases the URI is a SIP AOR Carrier enum presumes that the URI returned is NOT a AOR but a border element in a service providers network that provides admission control and interconnection between service providers. Carrier ENUM presumes that registrations are for all TN under the service providers control and therefore there is no need to OPT IN since the endpoints are never actually exposed. Second, in which RFC does it say that the URI returned MUST be an end-user URI? none of them. (I'll confess I haven't read them all.) Third, in both cases, isn't the intent to be able to route a call (initiate communication) toward the owner of the E.164 number? not necessiarily .. initiate communication towards the owner may not be the end point but a point of interconnection. The concept of peering partners is beside the point. I find the idea of disconnected islands of closed clubs to be counter-productive. tell that to the wireless industry. A key requirement MUST be that a dialed E.164 number enables a call to go through. not necessarily ..in carrier enum that means you find the point of interconnection and it is the up to that point of egress to apply policy as to whether to permit admission or not. If ENUM becomes the stumbling block preventing call completion, that will invite unnecessary regulation. Fourth, isn't one of the principles of the Internet to provide generally useful mechanisms? Bifurcating this into User versus Carrier "orthogonal and independent" implementations is a recipe for non-interoperability and "Walled ENUM". Most of us dont agree since one of the objectives of Carrier ENUM is to assist service providers in their well known and highly publicized statement of directions for collapsing their internal networks on to IP. Carriers cannot collapse their networks on to IP unless they can also collapse the underlying signalling networks that enable carrier interconnection. I hope I have totally misunderstood your words below. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Stastny Richard > Sent: Thursday, July 07, 2005 5:44 PM > To: Patrik Faltstrom (pfaltstr); Livingood, Jason > Cc: enum at ietf.org; Richard Shockey > Subject: Re: [Enum] Agenda items for IETF Paris > > Hi all, > > >For example, I know Stasny have said several times "this is > not ENUM" > >and personally, I do agree with him. But, to be able to have that > >discussion, we first need the meta-discussion... > > I agree that there seems to be a discussion necessary > > to clarify this, as I tried to state in the definitions I posted: > > The purpose of User ENUM is for mapping end-user URIs to > E.164 numbers. > basically a service for end-users. The basic requirement for > end-users is to find other end.users. The second requirement > is that orig end-user must be able to reach the destination > user, because the Internet is end-to-end. User ENUM is > conformant to the Internet principles > > The purpose of Carrier ENUM is to help carriers finding > peering partners using E.164 numbers to map to URIs, > basically find the destination networks from an origination > network. The basic requirement for carriers is to find other > carriers. Here it is NOT required that every carrier must be > able to reach any other carrier, this is depandant on peering > agreements. > > These two implementations are orthogonal and independant. > > If there is an efficient way to use the same nfrastructure > for these differnt purposes, fine. > > IMHO the VoIP peering requirements necessary to do so are out > of scope of ENUM WG. I leave it to the discussion if they are > within the scope of the IETF. > On the other hand, many IETF protocols are used on IP-based > networks separated from the Internet (e.g. SIP within 3GPP). > > > -richard > > ________________________________ > > Von: enum-bounces at ietf.org im Auftrag von Patrik Fältström > Gesendet: Do 07.07.2005 22:53 > An: Livingood, Jason > Cc: enum at ietf.org; Richard Shockey > Betreff: Re: [Enum] Agenda items for IETF Paris > > > > What I hope we can do is to first discuss what requirements > we have on "user" and "carrier" ENUM, what is in-scope and > out of scope. This discussion will give a list of > requirements that I hope we can use to measure the proposals against. > > For example, I know Stasny have said several times "this is not ENUM" > and personally, I do agree with him. But, to be able to have > that discussion, we first need the meta-discussion... So we > know what we agree on and not. > > paf > > On Jul 7, 2005, at 20:41, Livingood, Jason wrote: > > > > > > >> 5 Discussion of Pfautz etal drafts on Carrier ENUM - Requirements ? > >> > > > > (Agenda addition) > > > > There is a new, alternate Carrier ENUM proposal making its > way to the > > WG, draft-haberler-carrier-enum-00. Perhaps this I-D can > be discussed > > immediately after the Pfautz et al. draft? Discussion of > both drafts > > could follow, which I expect to be lively. > > > > Regards > > Jason Livingood > > > > _______________________________________________ > > enum mailing list > > enum at ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > _______________________________________________ > enum mailing list > enum at 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@inode.at Thu, 07 Jul 2005 21:14:18 -0400 From: Michael Haberler Date: Thu, 07 Jul 2005 21:14:18 -0400 To: "Michael Hammer \(mhammer\)" Subject: RE: [Enum] Agenda items for IETF Paris In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3560F5D@xmb-rtp-20b.amer.cisco.com> Message-ID: <6.2.1.2.2.20050708011208.057dc608@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: R Michael, At 00:11 08.07.2005, Michael Hammer \(mhammer\) wrote: .. Second, in which RFC does it say that the URI returned MUST be an end-user URI? (I'll confess I haven't read them all.) Let's call a "non end-user URI" a Point of Interconnect" (POI), which is an attribute of the carrier-of-record of a number. An end user opting in to User ENUM does not care about and cannot influence his carrier's POI, but his own URI(s). A carrier does care about his POI(s), but cannot enter them into User ENUM because latter is opt-in by and the zone is owned by his user. Having a carrier *and* his user cohabitate the same zone is like you and me owning foo.com - we might run into problems about which records go into in the foo.com zone. You change my RR's, I might get nasty. Third, in both cases, isn't the intent to be able to route a call (initiate communication) toward the owner of the E.164 number? yes, and User ENUM is great for that. It just happens to cover a homoeopathic number of call setups now and for a long time to come, the rest of the call setups work by virtue of - in some way - shared POI information. Both do work, but this isnt a question wether you can call me or not. The concept of peering partners is beside the point. I dont think so, that's just a posh name for "interconnect agreement" and the concept is bound to be with us for a while, like 10 years or more. I havent made any, but they are there. I find the idea of disconnected islands of closed clubs to be counter-productive. A key requirement MUST be that a dialed E.164 number enables a call to go through. If ENUM becomes the stumbling block preventing call completion, that will invite unnecessary regulation. Fourth, isn't one of the principles of the Internet to provide generally useful mechanisms? Bifurcating this into User versus Carrier "orthogonal and independent" implementations is a recipe for non-interoperability and "Walled ENUM". Let's assume we insist on User ENUM being the method of choice for call setup in IP land, and other call setup scenarios are undesirable/should go elsewhere, whatever the supporting mechanisms are. The consequence of assuming that a dialed number goes through User ENUM exclusively is part of the cause for the very bifurcation you are deploring. This is happing right now, into e164.something trees or private trees altogether, or staying on the PSTN by default. Now, do I care? Can I call you and you can call me ? yes, so that fulfills your requirement. Does it make sense? I believe, not really - because the cannibalization into different trees kills cross-tree resolution. Resolution rates are already ridiculous due to the pathetic per-country code opt-in to process. Will it help the User ENUM vision (which I share)? no, actually it will kill it - and the reason is that it might not be viable to run a User-ENUM-only service on a per-country basis, and get still get a critical mass of users. We might end up with something like "No, we dont do HTTP over here in France." - this isnt my idea of a horizontal technology. I might be questioning belief systems here: a) the basic value proposition of ENUM-like technology is in call resolution rates - more calls on IP equals better. b) call resolution is a market - laws of demand and suppy apply. Offer doesnt meet demand - demand goes elsewhere. c) User ENUM is dead in the water if cost of running it and end user value dont add up eventually. End user value is in resolution rates, too. d) finding a scheme which fulfills carrier needs and at the same time supports User ENUM, like a combined tree proposal, will keep options for User ENUM open longer - so it can achieve reasonable resolution rates eventually to keep it viable. d) one is more likely to find somebody in jurisdiction X to run a combined tree than just User ENUM, and governments will see more demand as local IP interconnect is an issue - and that helps footprint of both. see http://www.enum.at/ietf/draft-haberler-carrier-enum-00.txt and http://www.enum.at/ietf/draft-haberler-carrier-enum-00.html for Richard's and my I-D based on this view - the I-D is still making it through the queue - Michael _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Thu, 07 Jul 2005 21:25:03 -0400 From: Richard Shockey Date: Thu, 07 Jul 2005 21:25:03 -0400 To: "Stastny Richard" Subject: Re: [Enum] Agenda items for IETF Paris In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BFFD@oefeg-s04.oefeg.loc> Message-ID: <6.2.1.2.2.20050707210957.04a0bcd0@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At I agree that there seems to be a discussion necessary to clarify this, as I tried to state in the definitions I posted: The purpose of User ENUM is for mapping end-user URIs to E.164 numbers. basically a service for end-users. The basic requirement for end-users is to find other end.users. The second requirement is that orig end-user must be able to reach the destination user, because the Internet is end-to-end. User ENUM is conformant to the Internet principles The purpose of Carrier ENUM is to help carriers finding peering partners using E.164 numbers to map to URIs, basically find the destination networks from an origination network. The basic requirement for carriers is to find other carriers. Here it is NOT required that every carrier must be able to reach any other carrier, this is depandant on peering agreements. This is well stated simply because you can find a point of interconnection does not mean you have to peer. These two implementations are orthogonal and independant. If there is an efficient way to use the same nfrastructure for these differnt purposes, fine. IMHO the VoIP peering requirements necessary to do so are out of scope of ENUM WG. I leave it to the discussion if they are within the scope of the IETF. On the other hand, many IETF protocols are used on IP-based networks separated from the Internet (e.g. SIP within 3GPP). I'd state this a little directly, whereas the IETF has never attempted to define transit-peering requirements among Internet service providers it certainly has provided useful technologies to facilitate such agreements. In the same sprit I agree that VoIP peering requirements should be out of scope for the IETF there are still technologies that we can provide that can facilitate those transactions. TN to URI mapping is certainly one of them. I will further postulate ..and I co-authoring a draft on this that TN to URI mappings can also help facilitate PSTN to PSTN connections where the core transport and proxy network is IP based. Classic PSTN service providers have always exchanged various forms of data to facilitate interconnection.It is perfectly reasonable to assume that they also need technologies to facilitate interconnection or peering in an all IP environment as well. -richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Patrik Fältström Gesendet: Do 07.07.2005 22:53 An: Livingood, Jason Cc: enum at ietf.org; Richard Shockey Betreff: Re: [Enum] Agenda items for IETF Paris What I hope we can do is to first discuss what requirements we have on "user" and "carrier" ENUM, what is in-scope and out of scope. This discussion will give a list of requirements that I hope we can use to measure the proposals against. For example, I know Stasny have said several times "this is not ENUM" and personally, I do agree with him. But, to be able to have that discussion, we first need the meta-discussion... So we know what we agree on and not. paf On Jul 7, 2005, at 20:41, Livingood, Jason wrote: > > >> 5 Discussion of Pfautz etal drafts on Carrier ENUM - Requirements ? >> > > (Agenda addition) > > There is a new, alternate Carrier ENUM proposal making its way to the > WG, draft-haberler-carrier-enum-00. Perhaps this I-D can be discussed > immediately after the Pfautz et al. draft? Discussion of both drafts > could follow, which I expect to be lively. > > Regards > Jason Livingood > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Fri, 08 Jul 2005 01:33:40 -0400 From: "Stastny Richard" Date: Fri, 08 Jul 2005 01:33:40 -0400 To: "Michael Hammer \(mhammer\)" Subject: Re: [Enum] Agenda items for IETF Paris Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BFFE@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi, I think Richard and Michael have already answered most of your questions, I just want to add an important point you may have missed: >A key requirement MUST be that a dialed E.164 number enables a call to go through. >If ENUM becomes the stumbling block preventing call completion, > that will invite unnecessary regulation MUST? Please look at RFC3764 (SIP Enumservice from our esteemed AD). It states clearly in the Security Section: "Unlike a traditional telephone number, the resource identified by a SIP URI may require that callers provide cryptographic credentials for authentication and authorization before a user is alerted. In this respect, ENUM in concert with SIP can actually provide far greater protection from unwanted callers than the existing PSTN, despite the public availability of ENUM records." On the other hand, if a carrier is not able to access the PoI given in Carrier ENUM, that does not mean that the call cannot go through, it may still be delivered via other means of peering, e.g. the PSTN. -richard ________________________________ Von: Michael Hammer (mhammer) [mailto:mhammer at cisco.com] Gesendet: Fr 08.07.2005 00:11 An: Stastny Richard; Patrik Faltstrom (pfaltstr); Livingood, Jason Cc: enum at ietf.org; Richard Shockey Betreff: RE: [Enum] Agenda items for IETF Paris Richard, So in User ENUM you provide an end-user URI and get an E.164 number back? I don't think so. First, don't both types of ENUM start with an E.164 and return a URI? Second, in which RFC does it say that the URI returned MUST be an end-user URI? (I'll confess I haven't read them all.) Third, in both cases, isn't the intent to be able to route a call (initiate communication) toward the owner of the E.164 number? The concept of peering partners is beside the point. I find the idea of disconnected islands of closed clubs to be counter-productive. A key requirement MUST be that a dialed E.164 number enables a call to go through. If ENUM becomes the stumbling block preventing call completion, that will invite unnecessary regulation. Fourth, isn't one of the principles of the Internet to provide generally useful mechanisms? Bifurcating this into User versus Carrier "orthogonal and independent" implementations is a recipe for non-interoperability and "Walled ENUM". I hope I have totally misunderstood your words below. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Stastny Richard > Sent: Thursday, July 07, 2005 5:44 PM > To: Patrik Faltstrom (pfaltstr); Livingood, Jason > Cc: enum at ietf.org; Richard Shockey > Subject: Re: [Enum] Agenda items for IETF Paris > > Hi all, > > >For example, I know Stasny have said several times "this is > not ENUM" > >and personally, I do agree with him. But, to be able to have that > >discussion, we first need the meta-discussion... > > I agree that there seems to be a discussion necessary > > to clarify this, as I tried to state in the definitions I posted: > > The purpose of User ENUM is for mapping end-user URIs to > E.164 numbers. > basically a service for end-users. The basic requirement for > end-users is to find other end.users. The second requirement > is that orig end-user must be able to reach the destination > user, because the Internet is end-to-end. User ENUM is > conformant to the Internet principles > > The purpose of Carrier ENUM is to help carriers finding > peering partners using E.164 numbers to map to URIs, > basically find the destination networks from an origination > network. The basic requirement for carriers is to find other > carriers. Here it is NOT required that every carrier must be > able to reach any other carrier, this is depandant on peering > agreements. > > These two implementations are orthogonal and independant. > > If there is an efficient way to use the same nfrastructure > for these differnt purposes, fine. > > IMHO the VoIP peering requirements necessary to do so are out > of scope of ENUM WG. I leave it to the discussion if they are > within the scope of the IETF. > On the other hand, many IETF protocols are used on IP-based > networks separated from the Internet (e.g. SIP within 3GPP). > > > -richard > > ________________________________ > > Von: enum-bounces at ietf.org im Auftrag von Patrik Fältström > Gesendet: Do 07.07.2005 22:53 > An: Livingood, Jason > Cc: enum at ietf.org; Richard Shockey > Betreff: Re: [Enum] Agenda items for IETF Paris > > > > What I hope we can do is to first discuss what requirements > we have on "user" and "carrier" ENUM, what is in-scope and > out of scope. This discussion will give a list of > requirements that I hope we can use to measure the proposals against. > > For example, I know Stasny have said several times "this is not ENUM" > and personally, I do agree with him. But, to be able to have > that discussion, we first need the meta-discussion... So we > know what we agree on and not. > > paf > > On Jul 7, 2005, at 20:41, Livingood, Jason wrote: > > > > > > >> 5 Discussion of Pfautz etal drafts on Carrier ENUM - Requirements ? > >> > > > > (Agenda addition) > > > > There is a new, alternate Carrier ENUM proposal making its > way to the > > WG, draft-haberler-carrier-enum-00. Perhaps this I-D can > be discussed > > immediately after the Pfautz et al. draft? Discussion of > both drafts > > could follow, which I expect to be lively. > > > > Regards > > Jason Livingood > > > > _______________________________________________ > > enum mailing list > > enum at ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Kim.Fullbrook@o2.com Fri, 08 Jul 2005 04:32:29 -0400 From: "Fullbrook Kim \(UK\)" Date: Fri, 08 Jul 2005 04:32:29 -0400 To: Subject: Carrier ENUM Definition (was RE: [Enum] Agenda items for IETF Paris) Message-ID: <0CD3FFEAEC982F489F872AB8DA32D624019D3B4C@Uksthmsx012> MIME-Version: 1.0 Content-Type: text/plain Status: R Would agree with previous definitions of User ENUM. On to my definition of carrier enum. First a bit of background. In most countries of the world where there are multiple mobile operators it is possible to keep your E.164 number when you move your service to a different mobile operator. In a smaller number of countries it is possible to do the same when moving between fixed line operators. This is called Number Portability. Before NP was introduced you could figure out the end operator who provided service to a number purely by analysing the digits in the number. When NP is introduced you can no longer do this. The primary purpose of Carrier ENUM is to solve the number portability problem. Given an E.164 number, which operator provides connectivity to that number for the desired service (strictly: for the desired enumservice) ? Of course ENUM relates an E.164 number to a URI so there is other information available in the URI such as the protocol needed and there may possibly be other optional information as well. For privacy reasons this information needs to be restricted to carriers and not made available to end users - except transparently when they make a call. The call obviously needs to be routed to the destination network and may actually be routed via several intermediate carriers. For example if I make a circuit-switched call from my mobile on the O2 network in the UK to Mr Y in China, there is no direct peering between O2 and any Chinese network. We would route the call to one of our International carriers who may forward it to another International carrier (and maybe forwarded again), before reaching the local Chinese carrier of Mr Y. Once we know the end destination of the call we figure out which of our carriers is the "next hop" and forward the call. They then forward it as appropriate. This is how the circuit-switched world works today. The same model will inevitably be followed for IMS's SIP-based calls because direct peering is not realistic on a global telco scale. Peering and routing information between carriers is nothing to do with ENUM at all. There is definitely a need for this information somewhere but it is not ENUM. Discussion about "Carrier ENUM" tends to include peering and routing information because of the need for privacy at a carrier level but this is a separate (although related) subject. Perhaps we need to introduce a term "Carrier DNS" for non-ENUM related information held in a DNS ? Alternative terms could be "Carrier Routing" and/or "Carrier Peering". Kim Fullbrook O2 UK -----Original Message----- ===================================================== This electronic message contains information from O2 which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. ===================================================== From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Stastny Richard Sent: 07 July 2005 22:44 To: Patrik Fältström; Livingood, Jason Cc: enum at ietf.org; Richard Shockey Subject: Re: [Enum] Agenda items for IETF Paris Hi all, >For example, I know Stasny have said several times "this is not ENUM" >and personally, I do agree with him. But, to be able to have that >discussion, we first need the meta-discussion... I agree that there seems to be a discussion necessary to clarify this, as I tried to state in the definitions I posted: The purpose of User ENUM is for mapping end-user URIs to E.164 numbers. basically a service for end-users. The basic requirement for end-users is to find other end.users. The second requirement is that orig end-user must be able to reach the destination user, because the Internet is end-to-end. User ENUM is conformant to the Internet principles The purpose of Carrier ENUM is to help carriers finding peering partners using E.164 numbers to map to URIs, basically find the destination networks from an origination network. The basic requirement for carriers is to find other carriers. Here it is NOT required that every carrier must be able to reach any other carrier, this is depandant on peering agreements. These two implementations are orthogonal and independant. If there is an efficient way to use the same nfrastructure for these differnt purposes, fine. IMHO the VoIP peering requirements necessary to do so are out of scope of ENUM WG. I leave it to the discussion if they are within the scope of the IETF. On the other hand, many IETF protocols are used on IP-based networks separated from the Internet (e.g. SIP within 3GPP). -richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Fri, 08 Jul 2005 05:12:29 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Fri, 08 Jul 2005 05:12:29 -0400 To: "'enum at ietf.org> Subject: Re: [Enum] What is "carrier ENUM"? In-Reply-To: <18B19814-2D0A-4E07-B36A-81A4FB0FB7C4@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Please dear wg participants. Can we please list the requirements for various things, and not talk about conclusions, solutions etc? We will NOT be able to move forward if you don't try to take a step back... So, I don't want to see any more "Carrier ENUM is..." or "User ENUM is not..." or similar. I want to see the requirements you were thinking of when you came to that conclusion. Please... paf On Jul 5, 2005, at 16:30, Patrik Fältström wrote: I think we have to take a step back and have a look at the requirements. Various people have listed their favorite requirements, and I thank you all for that. We have also seen many requirements in the documents made known to this wg. But, to be able to move forward, I would like to have someone taking a step forward agreeing to be the writer of a "carrier enum requirements" document. This doesn't have to be (but might be) as formal as one internet draft at the end of the day. I just want to see all requirements being listed (or as many as we might come up with) WITHOUT discussing each one of them immediately. So, please, can I get: 1) A person that agree on writing down the requirements 2) People sending requirements to this list, or the person when that person exists 3) People NOT arguing how stupid they think a requirement is before we open that discussion Example of requirements might be (these are just examples): 1. Two VoIP providers want to do "VoIP peering" and to each other announce the E.164 numbers each have, and for each announce what ingress point the originating provider should use. 2. A carrier that think he is "responsible" for one E.164 number don't want to give up control over the DNS for the NAPTR for that number. 3. A carrier want to use ENUM, but the user(s) have not opt:ed in to the use of it. It was the intention the first more look like a scenario than a requirement. This is why I want someone that have time to look and try to find what the actual requirements are... paf _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Fri, 08 Jul 2005 07:48:02 -0400 From: "Stastny Richard" Date: Fri, 08 Jul 2005 07:48:02 -0400 To: "Fullbrook Kim \(UK\)" Subject: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items for IETF Paris) Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BFFF@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Short reply to the privacy? problem Kim wrote >Before NP was introduced you could figure out the end operator >who provided service to a number purely by analysing the digits in the number. >When NP is introduced you can no longer do this. .... >The primary purpose of Carrier ENUM is to solve the number portability problem. Given an E.164 number, which operator provides >connectivity to that number for the desired service .... >For privacy reasons this information needs to be restricted to carriers and not made >available to end users - except transparently when they make a call. Can anybody explain to me why before NP one could figure out the end operator by analysing the number and this was NOT a privacy problem - and now with NP this IS a privacy problem? Which privacy? of the user or of the operator? -richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Fullbrook Kim (UK) Gesendet: Fr 08.07.2005 10:32 An: enum at ietf.org Betreff: Carrier ENUM Definition (was RE: [Enum] Agenda items for IETF Paris) Would agree with previous definitions of User ENUM. On to my definition of carrier enum. First a bit of background. In most countries of the world where there are multiple mobile operators it is possible to keep your E.164 number when you move your service to a different mobile operator. In a smaller number of countries it is possible to do the same when moving between fixed line operators. This is called Number Portability. Before NP was introduced you could figure out the end operator who provided service to a number purely by analysing the digits in the number. When NP is introduced you can no longer do this. The primary purpose of Carrier ENUM is to solve the number portability problem. Given an E.164 number, which operator provides connectivity to that number for the desired service (strictly: for the desired enumservice) ? Of course ENUM relates an E.164 number to a URI so there is other information available in the URI such as the protocol needed and there may possibly be other optional information as well. For privacy reasons this information needs to be restricted to carriers and not made available to end users - except transparently when they make a call. The call obviously needs to be routed to the destination network and may actually be routed via several intermediate carriers. For example if I make a circuit-switched call from my mobile on the O2 network in the UK to Mr Y in China, there is no direct peering between O2 and any Chinese network. We would route the call to one of our International carriers who may forward it to another International carrier (and maybe forwarded again), before reaching the local Chinese carrier of Mr Y. Once we know the end destination of the call we figure out which of our carriers is the "next hop" and forward the call. They then forward it as appropriate. This is how the circuit-switched world works today. The same model will inevitably be followed for IMS's SIP-based calls because direct peering is not realistic on a global telco scale. Peering and routing information between carriers is nothing to do with ENUM at all. There is definitely a need for this information somewhere but it is not ENUM. Discussion about "Carrier ENUM" tends to include peering and routing information because of the need for privacy at a carrier level but this is a separate (although related) subject. Perhaps we need to introduce a term "Carrier DNS" for non-ENUM related information held in a DNS ? Alternative terms could be "Carrier Routing" and/or "Carrier Peering". Kim Fullbrook O2 UK -----Original Message----- ===================================================== This electronic message contains information from O2 which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. ===================================================== From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Stastny Richard Sent: 07 July 2005 22:44 To: Patrik Fältström; Livingood, Jason Cc: enum at ietf.org; Richard Shockey Subject: Re: [Enum] Agenda items for IETF Paris Hi all, >For example, I know Stasny have said several times "this is not ENUM" >and personally, I do agree with him. But, to be able to have that >discussion, we first need the meta-discussion... I agree that there seems to be a discussion necessary to clarify this, as I tried to state in the definitions I posted: The purpose of User ENUM is for mapping end-user URIs to E.164 numbers. basically a service for end-users. The basic requirement for end-users is to find other end.users. The second requirement is that orig end-user must be able to reach the destination user, because the Internet is end-to-end. User ENUM is conformant to the Internet principles The purpose of Carrier ENUM is to help carriers finding peering partners using E.164 numbers to map to URIs, basically find the destination networks from an origination network. The basic requirement for carriers is to find other carriers. Here it is NOT required that every carrier must be able to reach any other carrier, this is depandant on peering agreements. These two implementations are orthogonal and independant. If there is an efficient way to use the same nfrastructure for these differnt purposes, fine. IMHO the VoIP peering requirements necessary to do so are out of scope of ENUM WG. I leave it to the discussion if they are within the scope of the IETF. On the other hand, many IETF protocols are used on IP-based networks separated from the Internet (e.g. SIP within 3GPP). -richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard.shockey@neustar.biz Fri, 08 Jul 2005 08:07:55 -0400 From: Richard Shockey Date: Fri, 08 Jul 2005 08:07:55 -0400 To: enum at ietf.org Subject: [Enum] Fwd: I-D ACTION:draft-conroy-enum-modestproposal-00.txt Message-ID: <6.2.1.2.2.20050707093714.04267740@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R To: i-d-announce at ietf.org From: Internet-Drafts at ietf.org Date: Wed, 06 Jul 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-BeenThere: i-d-announce at ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts at ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces at ietf.org X-SongbirdInformation: support at songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: i-d-announce-bounces at ietf.org Subject: I-D ACTION:draft-conroy-enum-modestproposal-00.txt X-Keywords: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Non-Terminal NAPTR Processing: A Modest Proposal Author(s) : L. Conroy Filename : draft-conroy-enum-modestproposal-00.txt Pages : 12 Date : 2005-7-6 Recent Discussions within the IETF and in other fora have highlighted differences in interpretation of the set of standards associated with ENUM and DDDS, on which it relies. Specifically, the operation and semantics surrounding support for non-terminal NAPTRs has led to some confusion. This document is an attempt to add clarification to non- terminal NAPTR processing. In this, it clarifies RFC3403. A subsequent document will build on this one to extend RFC3761 further, permitting registration of non-terminal Enumservices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-conroy-enum-modestproposal-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-conroy-enum-modestproposal-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 at ietf.org. In the body type: "FILE /internet-drafts/draft-conroy-enum-modestproposal-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. Content-Type: text/plain Content-ID: <2005-7-6130827.I-D at ietf.org> ENCODING mime FILE /internet-drafts/draft-conroy-enum-modestproposal-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mankin@psg.com Fri, 08 Jul 2005 10:35:52 -0400 From: Allison Mankin Date: Fri, 08 Jul 2005 10:35:52 -0400 To: enum at ietf.org Subject: [Enum] For context around the carrier enum discussion - voip peering BoF in Paris Message-ID: <200507081435.KAA07085@ietf.org> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi, We're interested in your input and participation in this, and think it's important context for this discussion of enum use by the carriers. We're making sure it's scheduled not to conflict with either enum or the major working groups pertinent to VoIP. Please jump in... Allison (Your AD) VoIP Peering and Interconnect BOF (voipeer) August, 2005 Name: VoIP Peering and Interconnect BoF (voipeer) Chairs: Dave Meyer AGENDA: -------- 5 min Agenda bashing Chair(s) 10 min Goal and purpose of the BOF Chair(s) (+ ADs?) 25 min Description of the problem/problem space TBD 30 min Other presentations, to be confirmed TBD 80 min Open Discussion All DESCRIPTION: --------------- The term "VoIP Peering" has been used to describe many different aspects of provider interconnect and the delivery of SIP call termination over that interconnection. Further, since VoIP peering focuses on how to identify and route calls at the application level, it does not (necessarily) involve the exchange of packet routing data. Given that VoIP peering is about routing calls, it includes (among other things) the accounting of costs that may be incurred in the use of any of these routes, the actual transport protocol of those media streams (or the details of those media streams), the IP network or criteria for the transport IP network,the signaling protocol that is used for transporting call-routing information, etc. Thus, given the broad scope of the topic, this BOF proposes to focus on the following objectives: (i). To initiate long term discussion on VoIP Peering and Interconnect among the Internet's operational community, with the goal of understanding the existing and future requirements for VoIP Peering and Interconnect. In particular, since VoIP peering is really about how to identify and route calls at the application level, it brings requirements from both transport providers and application vendors, as well as many other third parties. One possible outcome of this would be to charter a VoIP Peering and Interconnect Working Group (area TBD). (ii). To address the near-term need to document the requirements and associated use-cases for VoIP interconnect. Such requirements can be used to inform protocol groups working on relevant protocol mechanisms. The focus of the proposed work will be on documenting VoIP Peering and Interconnect use cases, defining their requirements, and describing what can be done in support of those use-cases and requirements with the Internet technology (and its dual, namely, what can't be done with the Internet technology). Issues for voipeer include (but are not limited to): (a). Call Routing That is, how to figure out who to route calls to. Options include SIP, ENUM (public v. private ENUM, carrier ENUM, etc). Further, several protocols have been proposed to carry enhanced call routing information, such as RFC3219 (TRIP). Are these necessary, and if so, are there complexity concerns? (b). ENUM How ENUM is currently being deployed/used, what are the barriers to deployment, if any, and how can we further facilitate its deployment. Other related topics include number portability, as well as directory and other enhanced routing requirements. (c). Security Includes topology and provider hiding, DoS prevention, authorization, and VoIP Spam mitigation (e.g., SPIT). (d). Accounting That is, how to track calls made to and from each peer, including TOD, duration, packets send and received, etc. (e). Audit Including how to determine where in the call path a fault lies, per-call accounting of call quality (most providers are looking for end-to-end call quality). Accounting of ASRs (and other PSTN call metrics, for PSTN termination peers only). (f). PSTN Fallback Issues here include what to do if the IP network is congested, how to do PSTN fallback, and interaction with call routing and IP network congestion measurement and monitoring.=20 (g). Feature Interoperability=20 (h). Lawful Intercept Will be discussed within the IETF's RAVEN principles. (i). Interaction of (a)-(h) with current/future Session Border Controller (SBC) deployments MAILING LIST: ------------- voipeer at lists.uoregon.edu To subscribe, visit http://darkwing.uoregon.edu/~llynch/voipeer.html or send mail to majordomo at lists.uoregon.edu and subscribe voipeer DRAFTS ------ None _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Fri, 08 Jul 2005 10:37:35 -0400 From: "Peter Williams" Date: Fri, 08 Jul 2005 10:37:35 -0400 To: "'Patrik Fältström'" Subject: RE: [Enum] What is "carrier ENUM"? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R The requirements you call for are ideological in nature. Whereas DNS has one (remarkably effective) operating ideology, ENUM may have another. But many acting in the tradition of the US portions of the Internet see ENUM as necessarily deployed and operated in a manner similar to DNS. Others, with the more traditional International perspectives used in the PSTN world, do not. This impasse cannot be solved by a technical requirement gathering process; No IETF schism has ever been solved by such a process, which requires political skills, in contrast. There are too many examples of technical process being used to advance status quo political positions - a feature of the US political scene. As DNS is now an admitted arm of the US govt. national security policy making, and a couple of IAB members act for that govt. in all but name, the normal political process at IETF is either biased or fundamentally broken, depending on your level of respect for our collective mission. As PSTN politics is necessarily international in nature, and we are attempting to address Internet/PSTN convergence, ENUM requires some accommodation to the international way in which cooperative telco rules are hashed out. The act of denying this (on technical pretexts) is causing the friction, and the fueling the impasse. When we faced this kind of impasse in the early 1990 in the PKI area, when the positions of US govt + IAB + Internet Society + Rutkowski's personality + ITU-T's implosion + MIT patents + IETF technical WG documents + commercial ambition combined ("in weird politics" VC) to make it impossible to deploy public CAs for SSL etc in any IETF consensus manner, we had to leave IETF to make the standards, for a while. Some very clever and shrewd politics by a couple of Internet founders - who work created the international part of the Internet - made it possible to come back in, once we broke the deployment bottlenecks outside the organization. International powers were just NOT having the US control the crypto infrastructure, per se, in that case; something had to be done. We can have a requirements gathering exercise if you want, in the ENUM case. But unless req 1 is "each nationally-regulated telco deploying ENUM is 100% independent of all foreign govt. policy making" then it?s a waste of time. Further convergence of Internet and PSTN culture in the IETF way of doing things depends on the US relinquishing all control over the International part of the Internet infrastructure. A corollary is that IAB and ICANN stop being arms of the US govt, in all but name. Until these are structural issues are solved, PSTN and Internet convergence will occur outside IETF processes, I predict. Carrier ENUM will be a years long email thread, until this happens. > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of > Patrik Fältström > Sent: Friday, July 08, 2005 2:12 AM > To: 'enum at ietf.org' ENUM > Subject: Re: [Enum] What is "carrier ENUM"? > > Please dear wg participants. > > Can we please list the requirements for various things, and not talk > about conclusions, solutions etc? > > We will NOT be able to move forward if you don't try to take a step > back... > > So, I don't want to see any more "Carrier ENUM is..." or "User ENUM > is not..." or similar. > > I want to see the requirements you were thinking of when you came to > that conclusion. > > Please... > > paf > > On Jul 5, 2005, at 16:30, Patrik Fältström wrote: > > > I think we have to take a step back and have a look at the > > requirements. Various people have listed their favorite > > requirements, and I thank you all for that. We have also seen many > > requirements in the documents made known to this wg. > > > > But, to be able to move forward, I would like to have someone > > taking a step forward agreeing to be the writer of a "carrier enum > > requirements" document. > > > > This doesn't have to be (but might be) as formal as one internet > > draft at the end of the day. > > > > I just want to see all requirements being listed (or as many as we > > might come up with) WITHOUT discussing each one of them immediately. > > > > So, please, can I get: > > > > 1) A person that agree on writing down the requirements > > > > 2) People sending requirements to this list, or the person when > > that person exists > > > > 3) People NOT arguing how stupid they think a requirement is before > > we open that discussion > > > > Example of requirements might be (these are just examples): > > > > 1. Two VoIP providers want to do "VoIP peering" and to each other > > announce the E.164 numbers each have, and for each announce what > > ingress point the originating provider should use. > > > > 2. A carrier that think he is "responsible" for one E.164 number > > don't want to give up control over the DNS for the NAPTR for that > > number. > > > > 3. A carrier want to use ENUM, but the user(s) have not opt:ed in > > to the use of it. > > > > It was the intention the first more look like a scenario than a > > requirement. This is why I want someone that have time to look and > > try to find what the actual requirements are... > > > > paf > > > > _______________________________________________ > > enum mailing list > > enum at ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Jason_Livingood@cable.comcast.com Fri, 08 Jul 2005 10:43:34 -0400 From: "Livingood, Jason" Date: Fri, 08 Jul 2005 10:43:34 -0400 To: "Stastny Richard" Subject: RE: Carrier ENUM Definition (was RE: [Enum] Agenda items for IETFParis) Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73F5F097@PACDCEXCMB01.cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >Can anybody explain to me why before NP one could figure out the end operator >by analysing the number and this was NOT a privacy problem - >and now with NP this IS a privacy problem? I would have to agree. I see the need to require keeping personally-identifiable user data from the tree unless the user opts-in. But I do not see the privacy requirement that would keep what carrier can route/terminate the call as being secret. (unless I am missing something) Jason Livingood _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From rich.shockey@neustar.biz Fri, 08 Jul 2005 10:44:46 -0400 From: Richard Shockey Date: Fri, 08 Jul 2005 10:44:46 -0400 To: "Fullbrook Kim \(UK\)" Subject: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items for IETF Paris) In-Reply-To: <0CD3FFEAEC982F489F872AB8DA32D624019D3B4C@Uksthmsx012> Message-ID: <6.2.1.2.2.20050708095036.0426d790@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 04:32 AM 7/8/2005, Fullbrook Kim \(UK\) wrote: Would agree with previous definitions of User ENUM. On to my definition of carrier enum. First a bit of background. In most countries of the world where there are multiple mobile operators it is possible to keep your E.164 number when you move your service to a different mobile operator. In a smaller number of countries it is possible to do the same when moving between fixed line operators. This is called Number Portability. Before NP was introduced you could figure out the end operator who provided service to a number purely by analysing the digits in the number. When NP is introduced you can no longer do this. The primary purpose of Carrier ENUM is to solve the number portability problem. Hummm .. there are some other solutions to the number portability problem ... :-) Given an E.164 number, which operator provides connectivity to that number for the desired service (strictly: for the desired enumservice) ? Of course ENUM relates an E.164 number to a URI so there is other information available in the URI such as the protocol needed and there may possibly be other optional information as well. For privacy reasons this information needs to be restricted to carriers and not made available to end users - except transparently when they make a call. So to requirements .. To answer Patrik's call ...there is a requirement among service providers for some form of database technology that, based on a E164 number, can provide information on how to route a service to a point of carrier interconnection or ALG as expressed as a URI. For privacy reasons this information needs to be restricted to service providers and not generally available to end users. Peering and routing information between carriers is nothing to do with ENUM at all. There is definitely a need for this information somewhere but it is not ENUM. Discussion about "Carrier ENUM" tends to include peering and routing information because of the need for privacy at a carrier level but this is a separate (although related) subject. Perhaps we need to introduce a term "Carrier DNS" for non-ENUM related information held in a DNS ? Alternative terms could be "Carrier Routing" and/or "Carrier Peering". Kim you've made a excellent point which is that all of this discussion tends to be wrapped up in the term ENUM. Carrier DNS might be a clean term and nicely expresses the desire or requirement for a database technology, based on the DNS "technology" of 3761 for service providers to exchange various forms of information necessary for service delivery. Carrier DNS technology might be used in e164.arpa but could also be used in other domains that may or may not be globally visible to the general Internet. Now that begs the question ..could SIP redirect be used to satisfy this requirement? I personally doubt it since SIP redirect is not a globally distributed database. Could SIP redirect be used to distribute routing information both internally to a domain as well as among a group of private service peers ..certainly ..but then you run into the scale problems. Could LDAP work .. very very doubtful the client is too heavy and LDAP is not X.500 ..and some of you long timers might remember that in the early early days of the WG..yes X.500 was discussed but it was the desire of the IESG that the ENUM WG focus only on DNS solutions and that other proposals would require a separate WG. Kim Fullbrook O2 UK - >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Fri, 08 Jul 2005 11:03:32 -0400 From: "Peter Williams" Date: Fri, 08 Jul 2005 11:03:32 -0400 To: "'Richard Shockey'" Subject: RE: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris) In-Reply-To: <6.2.1.2.2.20050708095036.0426d790@sb7.songbird.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R > So to requirements .. To answer Patrik's call ...there is a requirement > among service providers for some form of database technology that, based > on > a E164 number, can provide information on how to route a service to a > point > of carrier interconnection or ALG as expressed as a URI. For privacy > reasons this information needs to be restricted to service providers and > not generally available to end users. Good. We got to the meat of the interconnect and partial info release world that drives real-world telco (and real-world managed IP, too, in the US fragment of the net, for that matter). > Kim you've made a excellent point which is that all of this discussion > tends to be wrapped up in the term ENUM. Carrier DNS might be a clean > term > and nicely expresses the desire or requirement for a database technology, > based on the DNS "technology" of 3761 for service providers to exchange > various forms of information necessary for service delivery. Carrier DNS > technology might be used in e164.arpa but could also be used in other > domains that may or may not be globally visible to the general Internet. Good. Now we have a statement that inter-provider interconnect arrangement apply to DNS, in any naming tree, like all other shared infrastructures. > Now that begs the question ..could SIP redirect be used to satisfy this > requirement? I personally doubt it since SIP redirect is not a globally > distributed database. Could SIP redirect be used to distribute routing > information both internally to a domain as well as among a group of > private > service peers ..certainly ..but then you run into the scale problems. > > Could LDAP work .. very very doubtful the client is too heavy and LDAP is > not X.500 ..and some of you long timers might remember that in the early > early days of the WG..yes X.500 was discussed but it was the desire of the > IESG that the ENUM WG focus only on DNS solutions and that other proposals > would require a separate WG. X.500 was profiled in IETF for multi-provider routing in email addressing and handling; it was a well-addressed topic, in 1990s IETF WGs, with a full panoply of technical specs, and requirements docs. It was a total waste of time, as we eventually discovered that the IAB of the day had NO intention of ever allowing it to be deployed, and was secretly politiking against it all along. It facilitated and rationalized international interconnects between and amongst providers doing value-add: precisely what some saw as abhorrent to the Internet way of doing things. Now we have spam for everyone, at the lowest quality of email service possible. > > >Kim Fullbrook > >O2 UK > > > >- > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > 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 at ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Fri, 08 Jul 2005 11:31:19 -0400 From: "Michael Hammer \(mhammer\)" Date: Fri, 08 Jul 2005 11:31:19 -0400 To: "Richard Shockey" Subject: RE: [Enum] Agenda items for IETF Paris Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3561061@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard, Regulatory authorities need to learn that the OPT-IN part should apply only to the FQDN AoR of the end-user not a FQDN URI of a Point of Interconnect. Once that distinction is learned, I think a viable single-tree ENUM would be possible. My comments below are all orthogonal to service and policy issues. The ability to route to an end-user or to a border controller does not mean that one has a peering (SLA) agreement, security credentials, or termination services configured to allow the call through. Those are not routing issues, but additional service issues that need to be worked out. In the case of the end-user, it is up to them to decide to accept calls. Mike > -----Original Message----- > From: Richard Shockey [mailto:richard at shockey.us] > Sent: Thursday, July 07, 2005 9:05 PM > To: Michael Hammer (mhammer); Stastny Richard; Patrik > Faltstrom (pfaltstr); Livingood, Jason > Cc: enum at ietf.org > Subject: RE: [Enum] Agenda items for IETF Paris > > At 06:11 PM 7/7/2005, Michael Hammer \(mhammer\) wrote: > > >Richard, > > > >So in User ENUM you provide an end-user URI and get an E.164 number > >back? I don't think so. > > > >First, don't both types of ENUM start with an E.164 and return a URI? > > yes ..but end user ENUM as it has been interpreted by most > regulatory authorities is OPT-IN which requires the proactive > consent of the end point user to register a FQDN in e164.arpa > and that in most cases the URI is a SIP AOR > > Carrier enum presumes that the URI returned is NOT a AOR but > a border element in a service providers network that > provides admission control and interconnection between > service providers. Carrier ENUM presumes that registrations > are for all TN under the service providers control and > therefore there is no need to OPT IN since the endpoints are > never actually exposed. > > > >Second, in which RFC does it say that the URI returned MUST be an > >end-user URI? > > none of them. > > >(I'll confess I haven't read them all.) > > > >Third, in both cases, isn't the intent to be able to route a call > >(initiate communication) toward the owner of the E.164 number? > > not necessiarily .. initiate communication towards the owner > may not be the end point but a point of interconnection. > > >The concept of peering partners is beside the point. I find > the idea > >of disconnected islands of closed clubs to be counter-productive. > > tell that to the wireless industry. > > > A key requirement MUST be that a dialed E.164 number > enables a call > > to go through. > > not necessarily ..in carrier enum that means you find the > point of interconnection and it is the up to that point of > egress to apply policy as to whether to permit admission or not. > > > If ENUM becomes the stumbling block preventing call > completion, that > > will invite unnecessary regulation. > > > >Fourth, isn't one of the principles of the Internet to provide > >generally useful mechanisms? Bifurcating this into User > versus Carrier > >"orthogonal and independent" implementations is a recipe for > >non-interoperability and "Walled ENUM". > > Most of us dont agree since one of the objectives of Carrier > ENUM is to assist service providers in their well known and > highly publicized statement of directions for collapsing > their internal networks on to IP. > Carriers cannot collapse their networks on to IP unless they > can also collapse the underlying signalling networks that > enable carrier interconnection. > > > >I hope I have totally misunderstood your words below. > > > >Mike > > > > > > > -----Original Message----- > > > From: enum-bounces at ietf.org > [mailto:enum-bounces at ietf.org] On Behalf > > > Of Stastny Richard > > > Sent: Thursday, July 07, 2005 5:44 PM > > > To: Patrik Faltstrom (pfaltstr); Livingood, Jason > > > Cc: enum at ietf.org; Richard Shockey > > > Subject: Re: [Enum] Agenda items for IETF Paris > > > > > > Hi all, > > > > > > >For example, I know Stasny have said several times "this is > > > not ENUM" > > > >and personally, I do agree with him. But, to be able to > have that > > > >discussion, we first need the meta-discussion... > > > > > > I agree that there seems to be a discussion necessary > > > > > > to clarify this, as I tried to state in the definitions I posted: > > > > > > The purpose of User ENUM is for mapping end-user URIs to > > > E.164 numbers. > > > basically a service for end-users. The basic requirement for > > > end-users is to find other end.users. The second > requirement is that > > > orig end-user must be able to reach the destination user, because > > > the Internet is end-to-end. User ENUM is conformant to > the Internet > > > principles > > > > > > The purpose of Carrier ENUM is to help carriers finding peering > > > partners using E.164 numbers to map to URIs, basically find the > > > destination networks from an origination network. The basic > > > requirement for carriers is to find other carriers. Here > it is NOT > > > required that every carrier must be able to reach any > other carrier, > > > this is depandant on peering agreements. > > > > > > These two implementations are orthogonal and independant. > > > > > > If there is an efficient way to use the same > nfrastructure for these > > > differnt purposes, fine. > > > > > > IMHO the VoIP peering requirements necessary to do so are out of > > > scope of ENUM WG. I leave it to the discussion if they are within > > > the scope of the IETF. > > > On the other hand, many IETF protocols are used on > IP-based networks > > > separated from the Internet (e.g. SIP within 3GPP). > > > > > > > > > -richard > > > > > > ________________________________ > > > > > > Von: enum-bounces at ietf.org im Auftrag von Patrik Fältström > > > Gesendet: Do 07.07.2005 22:53 > > > An: Livingood, Jason > > > Cc: enum at ietf.org; Richard Shockey > > > Betreff: Re: [Enum] Agenda items for IETF Paris > > > > > > > > > > > > What I hope we can do is to first discuss what > requirements we have > > > on "user" and "carrier" ENUM, what is in-scope and out of scope. > > > This discussion will give a list of requirements that I > hope we can > > > use to measure the proposals against. > > > > > > For example, I know Stasny have said several times "this > is not ENUM" > > > and personally, I do agree with him. But, to be able to have that > > > discussion, we first need the meta-discussion... So we > know what we > > > agree on and not. > > > > > > paf > > > > > > On Jul 7, 2005, at 20:41, Livingood, Jason wrote: > > > > > > > > > > > > > > >> 5 Discussion of Pfautz etal drafts on Carrier ENUM - > Requirements ? > > > >> > > > > > > > > (Agenda addition) > > > > > > > > There is a new, alternate Carrier ENUM proposal making its > > > way to the > > > > WG, draft-haberler-carrier-enum-00. Perhaps this I-D can > > > be discussed > > > > immediately after the Pfautz et al. draft? Discussion of > > > both drafts > > > > could follow, which I expect to be lively. > > > > > > > > Regards > > > > Jason Livingood > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum at ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > enum mailing list > > > enum at 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From rich.shockey@neustar.biz Fri, 08 Jul 2005 12:05:00 -0400 From: Richard Shockey Date: Fri, 08 Jul 2005 12:05:00 -0400 To: enum at ietf.org Subject: Re: [Enum] For context around the carrier enum discussion - voip peering BoF in Paris In-Reply-To: <200507081435.KAA07085@ietf.org> Message-ID: <6.2.1.2.2.20050708114540.04dea2c0@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 10:35 AM 7/8/2005, Allison Mankin wrote: Hi, We're interested in your input and participation in this, and think it's important context for this discussion of enum use by the carriers. We're making sure it's scheduled not to conflict with either enum or the major working groups pertinent to VoIP. Please jump in... Allison Well Allison - Dave ...first thing ..would the BOF want a status report from the ENUM WG on A. Where 3761 deployment actually is and B. what the ENUM WG is actually discussing on the interconnect peering issues? That is now practically our entire agenda for Paris. We could also discuss why have certain (to remain nameless) equipment suppliers been reluctant to incorporate 3761 compliant DNS resolvers into their service processing logic. I'm sure lots of folks would be interested in that topic :-) (Your AD) Name: VoIP Peering and Interconnect BoF (voipeer) Chairs: Dave Meyer First thing I would say is this is not just about VoIP ..its about advanced service peering and interconnection among service providers. As anyone in this WG knows the entire issue of Infrastructure ENUM was in part initiated by some very serious requirements coming out of the wireless industry for MMS as well as IP based SMS routing. What was manifestly self evident to the wireless industry was the existing SS7 signalling and transport infrastructure was not designed for this class of peering nor did anyone have the desire to expand the scope of SS7 handle large either real-time or store and forward data objects. Consequently numerous vendors and equipment suppliers saw in 3761 technology a quick and technically effective solution to the problem. Numerous vendors and service providers quickly responded to the market opportunity and now there is a vigorous and competitive market for Carrier ENUM services in the MMS routing market and this BTW had nothing to do with SIP .. MMS transport is generally delivered via SMTP URI's. Though I'm one who believes that SIP signalling would have actually been more effective in overcoming the data normalization issues. AGENDA: -------- 5 min Agenda bashing Chair(s) 10 min Goal and purpose of the BOF Chair(s) (+ ADs?) 25 min Description of the problem/problem space TBD 30 min Other presentations, to be confirmed TBD 80 min Open Discussion All DESCRIPTION: --------------- The term "VoIP Peering" has been used to describe many different aspects of provider interconnect and the delivery of SIP call termination over that interconnection. Further, since VoIP peering focuses on how to identify and route calls at the application level, it does not (necessarily) involve the exchange of packet routing data. Given that VoIP peering is about routing calls, it includes (among other things) the accounting of costs that may be incurred in the use of any of these routes, the actual transport protocol of those media streams (or the details of those media streams), the IP network or criteria for the transport IP network,the signaling protocol that is used for transporting call-routing information, etc. Thus, given the broad scope of the topic, this BOF proposes to focus on the following objectives: (i). To initiate long term discussion on VoIP Peering and Interconnect among the Internet's operational community, with the goal of understanding the existing and future requirements for VoIP Peering and Interconnect. In particular, since VoIP peering is really about how to identify and route calls at the application level, it brings requirements from both transport providers and application vendors, as well as many other third parties. One possible outcome of this would be to charter a VoIP Peering and Interconnect Working Group (area TBD). (ii). To address the near-term need to document the requirements and associated use-cases for VoIP interconnect. Such requirements can be used to inform protocol groups working on relevant protocol mechanisms. The focus of the proposed work will be on documenting VoIP Peering and Interconnect use cases, defining their requirements, and describing what can be done in support of those use-cases and requirements with the Internet technology (and its dual, namely, what can't be done with the Internet technology). Issues for voipeer include (but are not limited to): (a). Call Routing That is, how to figure out who to route calls to. Options include SIP, ENUM (public v. private ENUM, carrier ENUM, etc). Further, several protocols have been proposed to carry enhanced call routing information, such as RFC3219 (TRIP). Are these necessary, and if so, are there complexity concerns? (b). ENUM How ENUM is currently being deployed/used, what are the barriers to deployment, if any, and how can we further facilitate its deployment. Other related topics include number portability, as well as directory and other enhanced routing requirements. (c). Security Includes topology and provider hiding, DoS prevention, authorization, and VoIP Spam mitigation (e.g., SPIT). (d). Accounting That is, how to track calls made to and from each peer, including TOD, duration, packets send and received, etc. (e). Audit Including how to determine where in the call path a fault lies, per-call accounting of call quality (most providers are looking for end-to-end call quality). Accounting of ASRs (and other PSTN call metrics, for PSTN termination peers only). (f). PSTN Fallback Issues here include what to do if the IP network is congested, how to do PSTN fallback, and interaction with call routing and IP network congestion measurement and monitoring.=20 (g). Feature Interoperability=20 (h). Lawful Intercept Will be discussed within the IETF's RAVEN principles. (i). Interaction of (a)-(h) with current/future Session Border Controller (SBC) deployments MAILING LIST: ------------- voipeer at lists.uoregon.edu To subscribe, visit http://darkwing.uoregon.edu/~llynch/voipeer.html or send mail to majordomo at lists.uoregon.edu and subscribe voipeer DRAFTS ------ None _______________________________________________ enum mailing list enum at 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Fri, 08 Jul 2005 12:10:52 -0400 From: "Stastny Richard" Date: Fri, 08 Jul 2005 12:10:52 -0400 To: "Michael Hammer \(mhammer\)" Subject: Re: [Enum] Agenda items for IETF Paris Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C001@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Mike, thanks for compressing the whole issue in three sentences. -richard stastny ________________________________ Von: Michael Hammer (mhammer) [mailto:mhammer at cisco.com] Gesendet: Fr 08.07.2005 17:30 An: Richard Shockey; Stastny Richard; Patrik Faltstrom (pfaltstr); Livingood, Jason Cc: enum at ietf.org Betreff: RE: [Enum] Agenda items for IETF Paris Richard, Regulatory authorities need to learn that the OPT-IN part should apply only to the FQDN AoR of the end-user not a FQDN URI of a Point of Interconnect. Once that distinction is learned, I think a viable single-tree ENUM would be possible. My comments below are all orthogonal to service and policy issues. The ability to route to an end-user or to a border controller does not mean that one has a peering (SLA) agreement, security credentials, or termination services configured to allow the call through. Those are not routing issues, but additional service issues that need to be worked out. In the case of the end-user, it is up to them to decide to accept calls. Mike _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Fri, 08 Jul 2005 12:29:32 -0400 From: "Michael Hammer \(mhammer\)" Date: Fri, 08 Jul 2005 12:29:32 -0400 To: "Michael Haberler" Subject: RE: [Enum] Agenda items for IETF Paris Message-ID: <072C5B76F7CEAB488172C6F64B30B5E356108A@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Michael, Pardon my inexperience with DNS mechanisms, but why can't a lookup of a domain at: 1.2.3.4.5.5.5.1.0.2.1.e164.arpa return an OPT-IN User RR (which may or may not be there) and a Carrier RR identifying a border controller? I am assuming that the carrier RR is for those cases where the delegation of the E.164 number goes through a carrier to the end-user, not those where the number is from the national authority directly to the user. I read your draft, but fail to see the need to define a new "carrier" domain at any point in the tree. Putting such a domain under the country code only branches at a different point down the hierarchy. You've only moved the problem next door. Two facts bound this problem as far as I can tell: 1: A number is dialed and presented to the DNS client that then must resolve it by traversing the tree from root on down to the last digit. 2: Until you reach a given point in the tree (depending on national authority assignments, e.g. 10K v 1K blocks) it is ambiguous whether the number belongs to one carrier or another. I don't think it a good idea to regulate where in the tree (e.g. after 3 or 6 digits) to place carrier information. Instead why not simply have the information at the point where the carrier is unambiguous and be able to return a carrier RR? This does not mean that the resolver's job is done, since it may have more dialed digits to use. It can continue resolving till it reaches the last digit, which could return a User RR if the user had opted-in. Or, if the original search knows in advance that it is only doing carrier, it could stop as soon as a carrier RR is returned. Likewise, if it knows it is only doing User, it ignores returned carrier RR and continues till it gets the User RR. It can prioritize which to use, if it doesn't know which RR type is present, (doesn't care) but can get both. The above is flexible, since it makes it a matter of configuration where the Carrier RR resides, which could be at any domain level: Country: 1.2.3.4.5.5.5.2.2.2.1.e164.arpa | | | +-Carrier RR | +-User RR Area/City code: 1.2.3.4.5.5.5.2.2.2.1.e164.arpa | | | +-Carrier RR | +-User RR 10K block: 1.2.3.4.5.5.5.2.2.2.1.e164.arpa | | | +-Carrier RR | +-User RR 1K block: 1.2.3.4.5.5.5.2.2.2.1.e164.arpa | | | +-Carrier RR | +-User RR Per number (e.g. due to number portability): 1.2.3.4.5.5.5.2.2.2.1.e164.arpa | +-Carrier RR | +-User RR The above would leave a single non-branching search path, no new domain, and simply a procedure for deciding which RR to use. Mike > -----Original Message----- > From: Michael Haberler [mailto:mah at inode.at] > Sent: Thursday, July 07, 2005 9:14 PM > To: Michael Hammer (mhammer) > Cc: enum at ietf.org > Subject: RE: [Enum] Agenda items for IETF Paris > > Michael, > > At 00:11 08.07.2005, Michael Hammer \(mhammer\) wrote: > .. > >Second, in which RFC does it say that the URI returned MUST be an > >end-user URI? > >(I'll confess I haven't read them all.) > > Let's call a "non end-user URI" a Point of Interconnect" > (POI), which is an attribute of the carrier-of-record of a number. > > An end user opting in to User ENUM does not care about and > cannot influence his carrier's POI, but his own URI(s). > > A carrier does care about his POI(s), but cannot enter them > into User ENUM because latter is opt-in by and the zone is > owned by his user. > > Having a carrier *and* his user cohabitate the same zone is > like you and me owning foo.com - we might run into problems > about which records go into in the foo.com zone. You change > my RR's, I might get nasty. > > >Third, in both cases, isn't the intent to be able to route a call > >(initiate communication) toward the owner of the E.164 number? > > yes, and User ENUM is great for that. It just happens to > cover a homoeopathic number of call setups now and for a long > time to come, the rest of the call setups work by virtue of > - in some way - shared POI information. Both do work, but > this isnt a question wether you can call me or not. > > >The concept of peering partners is beside the point. > > I dont think so, that's just a posh name for "interconnect > agreement" and the concept is bound to be with us for a > while, like 10 years or more. I havent made any, but they are there. > > > I find the idea of disconnected islands of closed clubs to be > > counter-productive. A key requirement MUST be that a dialed E.164 > > number enables a call to go through. If ENUM becomes the stumbling > > block preventing call completion, that will invite > unnecessary regulation. > > > >Fourth, isn't one of the principles of the Internet to provide > >generally useful mechanisms? Bifurcating this into User > versus Carrier > >"orthogonal and independent" implementations is a recipe for > >non-interoperability and "Walled ENUM". > > Let's assume we insist on User ENUM being the method of > choice for call setup in IP land, and other call setup > scenarios are undesirable/should go elsewhere, whatever the > supporting mechanisms are. > > The consequence of assuming that a dialed number goes through > User ENUM exclusively is part of the cause for the very > bifurcation you are deploring. This is happing right now, > into e164.something trees or private trees altogether, or > staying on the PSTN by default. > > Now, do I care? Can I call you and you can call me ? yes, so > that fulfills your requirement. > > Does it make sense? I believe, not really - because the > cannibalization into different trees kills cross-tree > resolution. Resolution rates are already ridiculous due to > the pathetic per-country code opt-in to process. > > Will it help the User ENUM vision (which I share)? no, > actually it will kill it - and the reason is that it might > not be viable to run a User-ENUM-only service on a > per-country basis, and get still get a critical mass of > users. We might end up with something like "No, we dont do > HTTP over here in France." - this isnt my idea of a > horizontal technology. > > I might be questioning belief systems here: > > a) the basic value proposition of ENUM-like technology is in > call resolution rates - more calls on IP equals better. > b) call resolution is a market - laws of demand and suppy > apply. Offer doesnt meet demand - demand goes elsewhere. > c) User ENUM is dead in the water if cost of running it and > end user value dont add up eventually. End user value is in > resolution rates, too. > d) finding a scheme which fulfills carrier needs and at the > same time supports User ENUM, like a combined tree proposal, > will keep options for User ENUM open longer - so it can > achieve reasonable resolution rates eventually to keep it viable. > d) one is more likely to find somebody in jurisdiction X to > run a combined tree than just User ENUM, and governments will > see more demand as local IP interconnect is an issue - and > that helps footprint of both. > > see > http://www.enum.at/ietf/draft-haberler-carrier-enum-00.txt > and > http://www.enum.at/ietf/draft-haberler-carrier-enum-00.html > for Richard's and my I-D based on this view - the I-D is > still making it through the queue > > - Michael > > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Fri, 08 Jul 2005 12:49:05 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Fri, 08 Jul 2005 12:49:05 -0400 To: Richard Shockey Subject: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items for IETF Paris) In-Reply-To: <0CD3FFEAEC982F489F872AB8DA32D624019D3B4C@Uksthmsx012> Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary..32256.1122908374.multipart/mixed" Status: R --Boundary..32256.1122908374.multipart/mixed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Jul 8, 2005, at 16:44, Richard Shockey wrote: ...there is a requirement among service providers for some form of database technology that, based on a E164 number, can provide information on how to route a service to a point of carrier interconnection or ALG as expressed as a URI. Ok, this is for me one requirement. Sorry for maybe not being clear. For privacy reasons this information needs to be restricted to service providers and not generally available to end users. Is the requirement that this information (the mapping from E.164 to URI) is only to be visible for the party that need to know, or "any service provider being part of the same club"? paf Attachment: PGP.sig Description: This is a digitally signed message part _______________________________________________ enum mailing list enum at ietf.org --Boundary..32256.1122908374.multipart/mixed Content-Type: application/octet-stream; name="pgpeirhb0uIkF.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgpeirhb0uIkF.pgp" Content-Description: "https://www1.ietf.org/mailman/listinfo/enum" --Boundary..32256.1122908374.multipart/mixed-- From paf@cisco.com Fri, 08 Jul 2005 12:51:56 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Fri, 08 Jul 2005 12:51:56 -0400 To: Peter Williams Subject: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris) In-Reply-To: Message-ID: <5A3B0B21-DD24-4122-84DE-4EA1975D32F7@cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary..32256.1122908374.multipart/mixed" Status: R --Boundary..32256.1122908374.multipart/mixed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Jul 8, 2005, at 17:03, Peter Williams wrote: X.500 was profiled in IETF for multi-provider routing in email addressing and handling; it was a well-addressed topic, in 1990s IETF WGs, with a full panoply of technical specs, and requirements docs. It was a total waste of time, as we eventually discovered that the IAB of the day had NO intention of ever allowing it to be deployed, and was secretly politiking against it all along. Peter, as co-chair of this wg, I have to ask you to please stop repeating your view of the history. Part from not helping this wg moving forward, your memory does not match other people's memory of what the issues where surrounding X.500. Please concentrate on what problem we try to solve *NOW*, and let us know what you think is needed for ENUM. Patrik co-chair of the ENUM wg Attachment: PGP.sig Description: This is a digitally signed message part _______________________________________________ enum mailing list enum at ietf.org --Boundary..32256.1122908374.multipart/mixed Content-Type: application/octet-stream; name="pgp8OPu5TxpJi.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgp8OPu5TxpJi.pgp" Content-Description: "https://www1.ietf.org/mailman/listinfo/enum" --Boundary..32256.1122908374.multipart/mixed-- From Richard.Stastny@oefeg.at Fri, 08 Jul 2005 13:02:42 -0400 From: "Stastny Richard" Date: Fri, 08 Jul 2005 13:02:42 -0400 To: "Richard Shockey" Subject: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris) Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C005@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Rich Shockey wrote: >So to requirements .. To answer Patrik's call ...there is a requirement >among service providers for some form of database technology that, based on >a E164 number, can provide information on how to route a service to a point >of carrier interconnection or ALG as expressed as a URI. For privacy >reasons this information needs to be restricted to service providers and >not generally available to end users. Again, I want to ask the question what is has to do with the privacy of an end-user if I find in puble DNS the information that the phone number +4319793321 is routed to the SBC of Telekom Austria with the URI sip:+4319793321 at gw10.aon.at I may not even know if the number is in service. I con find out more by e.g. calling this number, or google for the number or looking up a phone directory on a CD by the number. -richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From rich.shockey@neustar.biz Fri, 08 Jul 2005 13:08:05 -0400 From: Richard Shockey Date: Fri, 08 Jul 2005 13:08:05 -0400 To: Patrik Fältström Subject: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items for IETF Paris) In-Reply-To: <0CD3FFEAEC982F489F872AB8DA32D624019D3B4C@Uksthmsx012> Message-ID: <6.2.1.2.2.20050708125753.047ca450@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 12:48 PM 7/8/2005, Patrik Fältström wrote: On Jul 8, 2005, at 16:44, Richard Shockey wrote: ...there is a requirement among service providers for some form of database technology that, based on a E164 number, can provide information on how to route a service to a point of carrier interconnection or ALG as expressed as a URI. Ok, this is for me one requirement. Sorry for maybe not being clear. For privacy reasons this information needs to be restricted to service providers and not generally available to end users. Is the requirement that this information (the mapping from E.164 to URI) is only to be visible for the party that need to know, or "any service provider being part of the same club"? oh fine distinction can you elaborate a bit ?...what is the difference been 'party that needs to know' or 'service provider being part of the same club' .. what is the distinction? as some here might postulate the exposure of the URI of the ALG may or may not be visible to A. all parties as in the use of .carrier.e164.arpa B. just visible to the club as in 3GPP.NET or e164MSO.ORG and the visibility of the ALG URI does not necessarily imply a formal peering agreement between party A and party B. What the egress ALG does once it gets in INVITE is a matter between consenting capitalists. Does that help? paf >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From rich.shockey@neustar.biz Fri, 08 Jul 2005 13:11:28 -0400 From: Richard Shockey Date: Fri, 08 Jul 2005 13:11:28 -0400 To: "Stastny Richard" Subject: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C005@oefeg-s04.oefeg.loc> Message-ID: <6.2.1.2.2.20050708130849.047c1590@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 01:05 PM 7/8/2005, Stastny Richard wrote: Rich Shockey wrote: >So to requirements .. To answer Patrik's call ...there is a requirement >among service providers for some form of database technology that, based on >a E164 number, can provide information on how to route a service to a point >of carrier interconnection or ALG as expressed as a URI. For privacy >reasons this information needs to be restricted to service providers and >not generally available to end users. Again, I want to ask the question what is has to do with the privacy of an end-user if I find in puble DNS the information that the phone number +4319793321 is routed to the SBC of Telekom Austria with the URI sip:+4319793321 at gw10.aon.at good point ... privacy policy is enforced by the ALG/SBC at the edge so the sentence should read. "For privacy and or network security reasons this information _may_ need to be restricted to service providers and not generally available to end users." I may not even know if the number is in service. right I con find out more by e.g. calling this number, or google for the number or looking up a phone directory on a CD by the number. -richard >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Fri, 08 Jul 2005 13:22:20 -0400 From: "Stastny Richard" Date: Fri, 08 Jul 2005 13:22:20 -0400 To: "Richard Shockey" Subject: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris) Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C006@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Rich Shockey wrote: >as some here might postulate the exposure of the URI of the ALG may or may >not be visible to A. all parties as in the use of .carrier.e164.arpa B. >just visible to the club as in 3GPP.NET or e164MSO.ORG and the visibility >of the ALG URI does not necessarily imply a formal peering agreement >between party A and party B. I question for clarification, especially to Patrik: Are we talking here about requirements for carrier ENUM -in private enterprise trees? -in carrier trees within their network to find egress ALGs (or SBCs or GWs)? -in shared walled garden trees such as GSMA (whatchamanameitcurrently) to find ingress ALGs? -in (partially or wholely) public other trees such as e174.info? -or in carrier.c.c.164.arpa or c.c.carrier.e164.arpa? or altogether? If it is last, I will come back in two years and look how far you are with the requirements and I do not think I will have missed a lot -richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Richard Shockey Gesendet: Fr 08.07.2005 19:06 An: Patrik Fältström; Richard Shockey Cc: enum at ietf.org Betreff: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris) At 12:48 PM 7/8/2005, Patrik Fältström wrote: >On Jul 8, 2005, at 16:44, Richard Shockey wrote: > >>...there is a requirement among service providers for some form of >>database technology that, based on a E164 number, can provide >>information on how to route a service to a point of carrier >>interconnection or ALG as expressed as a URI. > >Ok, this is for me one requirement. Sorry for maybe not being clear. > >>For privacy reasons this information needs to be restricted to >>service providers and not generally available to end users. > >Is the requirement that this information (the mapping from E.164 to >URI) is only to be visible for the party that need to know, or "any >service provider being part of the same club"? oh fine distinction can you elaborate a bit ?...what is the difference been 'party that needs to know' or 'service provider being part of the same club' .. what is the distinction? as some here might postulate the exposure of the URI of the ALG may or may not be visible to A. all parties as in the use of .carrier.e164.arpa B. just visible to the club as in 3GPP.NET or e164MSO.ORG and the visibility of the ALG URI does not necessarily imply a formal peering agreement between party A and party B. What the egress ALG does once it gets in INVITE is a matter between consenting capitalists. Does that help? > paf > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Fri, 08 Jul 2005 13:42:02 -0400 From: Jim Reid Date: Fri, 08 Jul 2005 13:42:02 -0400 To: "Michael Hammer \(mhammer\)" Subject: Re: [Enum] Agenda items for IETF Paris In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E356108A@xmb-rtp-20b.amer.cisco.com> Message-ID: <1ec322b3dbfbbea75807869837b3bab0@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R On Jul 8, 2005, at 17:29, Michael Hammer ((mhammer)) wrote: Pardon my inexperience with DNS mechanisms, but why can't a lookup of a domain at: 1.2.3.4.5.5.5.1.0.2.1.e164.arpa return an OPT-IN User RR (which may or may not be there) and a Carrier RR identifying a border controller? Because these are two different things which will presumably be controlled and manipulated by different entities according to different, possibly mutually exclusive, requirements. There's nothing in the DNS protocol to prevent these RRs co-existing in the same zone of course. And if they did, a DNS lookup could return both. However just because something is possible doesn't mean it could or even should be done. From a purely technical perspective, the answer to your question is the DNS lookup could return both these RRs. But for all sorts of practical reasons -- administrative, policy, operational, content management, synchronising and managing access control to the zone, etc, etc -- this is unlikely to be a wise or desirable outcome. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Fri, 08 Jul 2005 14:06:40 -0400 From: "Michael Hammer \(mhammer\)" Date: Fri, 08 Jul 2005 14:06:40 -0400 To: "Jim Reid" Subject: RE: [Enum] Agenda items for IETF Paris Message-ID: <072C5B76F7CEAB488172C6F64B30B5E35610DC@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Jim, I have yet to see a persuasive argument for why all the political requirement, control, manipulation, administration, policy, ... aspects can't be built around a simple technical model. The administrative tail seems to be wagging the dog. Whatever happened to Occam's Razor? Mike > -----Original Message----- > From: Jim Reid [mailto:jim at rfc1035.com] > Sent: Friday, July 08, 2005 1:41 PM > To: Michael Hammer (mhammer) > Cc: Michael Haberler; enum at ietf.org > Subject: Re: [Enum] Agenda items for IETF Paris > > On Jul 8, 2005, at 17:29, Michael Hammer ((mhammer)) wrote: > > > Pardon my inexperience with DNS mechanisms, but why can't a > lookup of > > a domain at: 1.2.3.4.5.5.5.1.0.2.1.e164.arpa return an > OPT-IN User RR > > (which may or may not be there) and a Carrier RR > identifying a border > > controller? > > Because these are two different things which will presumably > be controlled and manipulated by different entities according > to different, possibly mutually exclusive, requirements. > > There's nothing in the DNS protocol to prevent these RRs > co-existing in the same zone of course. And if they did, a > DNS lookup could return both. However just because something > is possible doesn't mean it could or even should be done. > From a purely technical perspective, the answer to your > question is the DNS lookup could return both these RRs. But > for all sorts of practical reasons -- administrative, policy, > operational, content management, synchronising and managing > access control to the zone, etc, etc -- this is unlikely to > be a wise or desirable outcome. > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From paf@cisco.com Fri, 08 Jul 2005 15:42:50 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Fri, 08 Jul 2005 15:42:50 -0400 To: Richard Shockey Subject: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items for IETF Paris) In-Reply-To: <0CD3FFEAEC982F489F872AB8DA32D624019D3B4C@Uksthmsx012> Message-ID: <1ED16654-68E0-4076-9A66-274E0ACBA82B@cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary..32256.1122908374.multipart/mixed" Status: R --Boundary..32256.1122908374.multipart/mixed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Jul 8, 2005, at 19:06, Richard Shockey wrote: Is the requirement that this information (the mapping from E.164 to URI) is only to be visible for the party that need to know, or "any service provider being part of the same club"? oh fine distinction can you elaborate a bit ?...what is the difference been 'party that needs to know' or 'service provider being part of the same club' .. what is the distinction? In the first case, the only parties that see the URI are the ones that will be able to make a call via that ingress point, while in the 2nd case the ingress point might be announced also to parties that can not use it, but still not to everyone on the Internet. paf Attachment: PGP.sig Description: This is a digitally signed message part _______________________________________________ enum mailing list enum at ietf.org --Boundary..32256.1122908374.multipart/mixed Content-Type: application/octet-stream; name="pgpwfFPpVvUQm.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgpwfFPpVvUQm.pgp" Content-Description: "https://www1.ietf.org/mailman/listinfo/enum" --Boundary..32256.1122908374.multipart/mixed-- From paf@cisco.com Fri, 08 Jul 2005 15:45:02 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Fri, 08 Jul 2005 15:45:02 -0400 To: Stastny Richard Subject: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C006@oefeg-s04.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary..32256.1122908374.multipart/mixed" Status: R --Boundary..32256.1122908374.multipart/mixed Content-Type: text/plain Content-Transfer-Encoding: 7bit On Jul 8, 2005, at 19:25, Stastny Richard wrote: Rich Shockey wrote: as some here might postulate the exposure of the URI of the ALG may or may not be visible to A. all parties as in the use of .carrier.e164.arpa B. just visible to the club as in 3GPP.NET or e164MSO.ORG and the visibility of the ALG URI does not necessarily imply a formal peering agreement between party A and party B. I question for clarification, especially to Patrik: Are we talking here about requirements for carrier ENUM -in private enterprise trees? -in carrier trees within their network to find egress ALGs (or SBCs or GWs)? -in shared walled garden trees such as GSMA (whatchamanameitcurrently) to find ingress ALGs? -in (partially or wholely) public other trees such as e174.info? -or in carrier.c.c.164.arpa or c.c.carrier.e164.arpa? or altogether? If it is last, I will come back in two years and look how far you are with the requirements and I do not think I will have missed a lot I want at least SOME requirements. At least enough to be able to see the difference between the various proposals. I know you (and myself) reject some of the proposals and thinking that have been passed around on this list. To be able to *REALLY* reject those, I want to know the requirements that are behind the proposals. I.e. enough so that the requirements can be attacked instead of the solutions that claim to respond to all of them. But not more. paf -richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Richard Shockey Gesendet: Fr 08.07.2005 19:06 An: Patrik Fältström; Richard Shockey Cc: enum at ietf.org Betreff: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris) At 12:48 PM 7/8/2005, Patrik Fältström wrote: On Jul 8, 2005, at 16:44, Richard Shockey wrote: ...there is a requirement among service providers for some form of database technology that, based on a E164 number, can provide information on how to route a service to a point of carrier interconnection or ALG as expressed as a URI. Ok, this is for me one requirement. Sorry for maybe not being clear. For privacy reasons this information needs to be restricted to service providers and not generally available to end users. Is the requirement that this information (the mapping from E.164 to URI) is only to be visible for the party that need to know, or "any service provider being part of the same club"? oh fine distinction can you elaborate a bit ?...what is the difference been 'party that needs to know' or 'service provider being part of the same club' .. what is the distinction? as some here might postulate the exposure of the URI of the ALG may or may not be visible to A. all parties as in the use of .carrier.e164.arpa B. just visible to the club as in 3GPP.NET or e164MSO.ORG and the visibility of the ALG URI does not necessarily imply a formal peering agreement between party A and party B. What the egress ALG does once it gets in INVITE is a matter between consenting capitalists. Does that help? paf 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum Attachment: PGP.sig Description: This is a digitally signed message part _______________________________________________ enum mailing list enum at ietf.org --Boundary..32256.1122908374.multipart/mixed Content-Type: application/octet-stream; name="pgpdLjzTqAPfy.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgpdLjzTqAPfy.pgp" Content-Description: "https://www1.ietf.org/mailman/listinfo/enum" --Boundary..32256.1122908374.multipart/mixed-- From mhammer@cisco.com Fri, 08 Jul 2005 16:11:54 -0400 From: "Michael Hammer \(mhammer\)" Date: Fri, 08 Jul 2005 16:11:54 -0400 To: "Fullbrook Kim \(UK\)" Subject: RE: Carrier ENUM Definition (was RE: [Enum] Agenda items for IETF Paris) Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3561157@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Kim, You are heading down the wrong path. We do not need to re-invent the PSTN. Ideally, there is only P2P, but that doesn't scale. Next best, there is only originating and terminating voice carriers. All the Inter-exchange carrier stuff can be done at the data transport layer, as there is no value added in terms of voice features. ENUM should not be viewed as a general purpose database, otherwise it grows lots of barnacles. If you have extra information that needs to be shared, but privacy-protected, point to more general purpose databases to store that information. If the requestor has the right authentication credentials and policy authorizes it, then they get access. As for number portability, the only requirement is that resolution of a single E.164 number query MUST return either zero (not assigned or user ENUM case) or one carrier RR. That may also seem to imply that any sub-string within that number should not return a carrier RR unless all other E.164 numbers that share that same sub-string also share the same carrier. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Fullbrook Kim (UK) > Sent: Friday, July 08, 2005 4:32 AM > To: enum at ietf.org > Subject: Carrier ENUM Definition (was RE: [Enum] Agenda items > for IETF Paris) > > Would agree with previous definitions of User ENUM. On to my > definition of carrier enum. > > First a bit of background. In most countries of the world > where there are multiple mobile operators it is possible to > keep your E.164 number when you move your service to a > different mobile operator. In a smaller number of countries > it is possible to do the same when moving between fixed line > operators. This is called Number Portability. Before NP was > introduced you could figure out the end operator who provided > service to a number purely by analysing the digits in the > number. When NP is introduced you can no longer do this. > > The primary purpose of Carrier ENUM is to solve the number > portability problem. Given an E.164 number, which operator > provides connectivity to that number for the desired service > (strictly: for the desired enumservice) ? Of course ENUM > relates an E.164 number to a URI so there is other > information available in the URI such as the protocol needed > and there may possibly be other optional information as well. > > For privacy reasons this information needs to be restricted > to carriers and not made available to end users - except > transparently when they make a call. > > The call obviously needs to be routed to the destination > network and may actually be routed via several intermediate > carriers. For example if I make a circuit-switched call from > my mobile on the O2 network in the UK to Mr Y in China, there > is no direct peering between O2 and any Chinese network. We > would route the call to one of our International carriers who > may forward it to another International carrier (and maybe > forwarded again), before reaching the local Chinese carrier > of Mr Y. Once we know the end destination of the call we > figure out which of our carriers is the "next hop" and > forward the call. They then forward it as appropriate. This > is how the circuit-switched world works today. The same model > will inevitably be followed for IMS's SIP-based calls because > direct peering is not realistic on a global telco scale. > > Peering and routing information between carriers is nothing > to do with ENUM at all. There is definitely a need for this > information somewhere but it is not ENUM. Discussion about > "Carrier ENUM" tends to include peering and routing > information because of the need for privacy at a carrier > level but this is a separate (although related) subject. > Perhaps we need to introduce a term "Carrier DNS" for > non-ENUM related information held in a DNS ? Alternative > terms could be "Carrier Routing" and/or "Carrier Peering". > > Kim Fullbrook > O2 UK > > -----Original Message----- > > ===================================================== > This electronic message contains information from O2 which > may be privileged or confidential. The information is > intended to be for the use of the individual(s) or entity > named above. If you are not the intended recipient be aware > that any disclosure, copying distribution or use of the > contents of this information is prohibited. If you have > received this electronic message in error, please notify us > by telephone or email (to the numbers or address above) immediately. > ===================================================== > > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Stastny Richard > Sent: 07 July 2005 22:44 > To: Patrik Fältström; Livingood, Jason > Cc: enum at ietf.org; Richard Shockey > Subject: Re: [Enum] Agenda items for IETF Paris > > > Hi all, > > >For example, I know Stasny have said several times "this is > not ENUM" > >and personally, I do agree with him. But, to be able to have that > >discussion, we first need the meta-discussion... > > I agree that there seems to be a discussion necessary > > to clarify this, as I tried to state in the definitions I posted: > > The purpose of User ENUM is for mapping end-user URIs to > E.164 numbers. > basically a service for end-users. The basic requirement for > end-users is to find other end.users. The second requirement > is that orig end-user must be able to reach the destination > user, because the Internet is end-to-end. User ENUM is > conformant to the Internet principles > > The purpose of Carrier ENUM is to help carriers finding > peering partners using E.164 numbers to map to URIs, > basically find the destination networks from an origination > network. The basic requirement for carriers is to find other > carriers. Here it is NOT required that every carrier must be > able to reach any other carrier, this is depandant on peering > agreements. > > These two implementations are orthogonal and independant. > > If there is an efficient way to use the same nfrastructure > for these differnt purposes, fine. > > IMHO the VoIP peering requirements necessary to do so are out > of scope of ENUM WG. I leave it to the discussion if they are > within the scope of the IETF. > On the other hand, many IETF protocols are used on IP-based > networks separated from the Internet (e.g. SIP within 3GPP). > > > -richard > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@inode.at Fri, 08 Jul 2005 16:10:29 -0400 From: Michael Haberler Date: Fri, 08 Jul 2005 16:10:29 -0400 To: "Michael Hammer \(mhammer\)" Subject: RE: [Enum] Agenda items for IETF Paris In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E35610DC@xmb-rtp-20b.amer.cisco.com> Message-ID: <6.2.1.2.2.20050708215547.042b3ca0@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: R Michael, lets call your proposal "zone cohabitation" (which is very close to the CNAPTR proposal which was on the CC1 LLC mailing list a while ago). I think it would work in theory - however: In practice, it would prevent delegation to a user-operated nameserver at the number level, forcing the Tier1 nameservers contain all NAPTRs, with all consequences. Lets assume your user deploys an Innovaphone IP PBX (www.innovaphone.de) . This box inlcudes a user (lets call it "Tier3") nameserver. You add an extension, corresponding NAPTR record appears automatically. There are many more useful examples for such applications, and I believe your proposal makes them impossible - I doubt that Carrier POI information can be reasonably administered in such a scenario. The concept of zone ownership gets in the way, which is why I propose different zones - small burden on the Carrier-ENUM aware resolver, no burden on User ENUM tree shape. -Michael At 20:06 08.07.2005, Michael Hammer \(mhammer\) wrote: Jim, I have yet to see a persuasive argument for why all the political requirement, control, manipulation, administration, policy, ... aspects can't be built around a simple technical model. The administrative tail seems to be wagging the dog. Whatever happened to Occam's Razor? Mike > -----Original Message----- > From: Jim Reid [mailto:jim at rfc1035.com] > Sent: Friday, July 08, 2005 1:41 PM > To: Michael Hammer (mhammer) > Cc: Michael Haberler; enum at ietf.org > Subject: Re: [Enum] Agenda items for IETF Paris > > On Jul 8, 2005, at 17:29, Michael Hammer ((mhammer)) wrote: > > > Pardon my inexperience with DNS mechanisms, but why can't a > lookup of > > a domain at: 1.2.3.4.5.5.5.1.0.2.1.e164.arpa return an > OPT-IN User RR > > (which may or may not be there) and a Carrier RR > identifying a border > > controller? > > Because these are two different things which will presumably > be controlled and manipulated by different entities according > to different, possibly mutually exclusive, requirements. > > There's nothing in the DNS protocol to prevent these RRs > co-existing in the same zone of course. And if they did, a > DNS lookup could return both. However just because something > is possible doesn't mean it could or even should be done. > From a purely technical perspective, the answer to your > question is the DNS lookup could return both these RRs. But > for all sorts of practical reasons -- administrative, policy, > operational, content management, synchronising and managing > access control to the zone, etc, etc -- this is unlikely to > be a wise or desirable outcome. > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From rich.shockey@neustar.biz Fri, 08 Jul 2005 16:55:43 -0400 From: Richard Shockey Date: Fri, 08 Jul 2005 16:55:43 -0400 To: enum at ietf.org Subject: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Message-ID: <6.2.1.2.2.20050708163311.047ddab0@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R To: i-d-announce at ietf.org From: Internet-Drafts at ietf.org Date: Fri, 08 Jul 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: i-d-announce at ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts at ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces at ietf.org X-SongbirdInformation: support at songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: i-d-announce-bounces at ietf.org Subject: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt X-Keywords: X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA11687 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IANA Registration for an Enumservice Containing Number Portability and PSTN Signaling Information Author(s) : J. Livingood, R. Shockey Filename : draft-livingood-shockey-enum-npd-00.txt Pages : 8 Date : 2005-7-8 This document registers the Enumservice "npd" and subtype "tel" using the URI scheme 'tel:' as per the IANA registration process defined in the ENUM specification, RFC 3761. This data is used to facilitate the routing of telephone calls in those countries where Number Portability exists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-livingood-shockey-enum-npd-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at 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-livingood-shockey-enum-npd-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 at ietf.org. In the body type: "FILE /internet-drafts/draft-livingood-shockey-enum-npd-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. Content-Type: text/plain Content-ID: <2005-7-8104034.I-D at ietf.org> ENCODING mime FILE /internet-drafts/draft-livingood-shockey-enum-npd-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From rich.shockey@neustar.biz Fri, 08 Jul 2005 17:05:52 -0400 From: Richard Shockey Date: Fri, 08 Jul 2005 17:05:52 -0400 To: Patrik Fältström Subject: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items for IETF Paris) In-Reply-To: <0CD3FFEAEC982F489F872AB8DA32D624019D3B4C@Uksthmsx012> Message-ID: <6.2.1.2.2.20050708164837.047b3520@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 03:42 PM 7/8/2005, Patrik Fältström wrote: On Jul 8, 2005, at 19:06, Richard Shockey wrote: Is the requirement that this information (the mapping from E.164 to URI) is only to be visible for the party that need to know, or "any service provider being part of the same club"? oh fine distinction can you elaborate a bit ?...what is the difference been 'party that needs to know' or 'service provider being part of the same club' .. what is the distinction? In the first case, the only parties that see the URI are the ones that will be able to make a call via that ingress point, while in the 2nd case the ingress point might be announced also to parties that can not use it, but still not to everyone on the Internet. ah .. I have heard both scenerios As I understand the various proposals both cases you describe usually assumes a non visible private domain..the issue is how peering policy is applied and where. If the domain is globally visible then the URI usually describes a ALR/SBC where ingress policy is applied. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Fri, 08 Jul 2005 17:22:25 -0400 From: "Stastny Richard" Date: Fri, 08 Jul 2005 17:22:25 -0400 To: Patrik Fältström Subject: [Enum] Horizontal vs Vertical Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C008@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R >I know you (and myself) reject some of the proposals and thinking >that have been passed around on this list. To be able to *REALLY* >reject those, I want to know the requirements that are behind the >proposals. >I.e. enough so that the requirements can be attacked instead of the >solutions that claim to respond to all of them. Yes and no, I think the current discussion on which Carrier ENUM proposal is valid or not is only a side battle. The real battle currently going on is between the "Internet" model (the horizontal layered model) and the vertical stovepipes of the PSTN model. The Internet model is the end-to-end model originally intended by SIP according to e-mail. If you have a sip URI you may use this URI to contact at least the proxy hosting the AoR. The media-stream is then transferred end-to-end directly between the end-points. In the PSTN model only "networks" may exchange both signalling and medai streams. To do so, they need peering agreements, pretending to guarantee QoS, in reality to be able to charge per minute. This model is mainly supported by mobile and cable operators to keep up the current accounting regime, supported also by the fixed network operators eaten up by the former, and also by some VoIP getting greedy and also wanting to get their share. As Henry already stated the problem is surfacing by the question: "Do you get a public SIP URI for your VoIP service" If not, you may use IP-based Telephony, but you are behind a walled garden. Back to ENUM: One is only able to use User ENUM if he has a Public SIP URI, and he may then link this SIP URI with an E.164 number in e164.arpa If he doesn't, the only "Public" identifier he has is an E.164 number. If his provider decides to use SIP within his walled garden network, he need some kind of addressing. Since this is SIP, a SIP URI is useful, but the "domain" names used here cannot be resolved on the public Internet. So the provider needs some private DNS to resolve even his own users. If one of this users wants to contact users of other providers, he may either use SIP URI, but this is problematic because his provider may not be able to resolve this URIs. So they stick to E.164 numbers. Here you still have as default the PSTN to interconnect. But providers of course also want to interconnect via IP, so the Carreir may now use ENUM technology to map the E.164 numbers to - ok this is now the question: The answer to this question is depending on what kind of ENUM he is useing: In the worst case he may use private ENUM in his own network to find the egress SBC into an "extranet" shared between providers, the egress SBC connect to the proper extranet and is querying an "ENUM" in this extranet to find the ingress SBC of the provider hosting the number and this ingress SBC is finally querying the ENUM in the destination network to find the proxy hosting the subscriber. But there are other models. So to answer your questions for the requirements we need first to discuss all potential peering models and ENUM configurations. We did this at ETSI for two years and included the only major models in ETSI TS 102 055. The whole issue will finally not be decided by a standards body. it will be decided by the end-user, because he will finally have the choice to use both models in parallel at his mobile device. He may chose either to query User ENUM ar let the call be set-up by his IMS provider. -richard PS: you may compete with everybody, but not with your customer (Clay Shirky on fax-mail) . ________________________________ Von: Patrik Fältström [mailto:paf at cisco.com] Gesendet: Fr 08.07.2005 21:44 An: Stastny Richard Cc: Richard Shockey; enum at ietf.org Betreff: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris) On Jul 8, 2005, at 19:25, Stastny Richard wrote: > Rich Shockey wrote: > >> as some here might postulate the exposure of the URI of the ALG >> may or may >> not be visible to A. all parties as in the use >> of .carrier.e164.arpa B. >> just visible to the club as in 3GPP.NET or e164MSO.ORG and the >> visibility >> of the ALG URI does not necessarily imply a formal peering agreement >> between party A and party B. >> > > I question for clarification, especially to Patrik: > > Are we talking here about requirements for carrier ENUM > -in private enterprise trees? > -in carrier trees within their network to find egress ALGs (or SBCs > or GWs)? > -in shared walled garden trees such as GSMA > (whatchamanameitcurrently) to find ingress ALGs? > -in (partially or wholely) public other trees such as e174.info? > -or in carrier.c.c.164.arpa or c.c.carrier.e164.arpa? > > or altogether? > > If it is last, I will come back in two years and look how far you are > with the requirements and I do not think I will have missed a lot I want at least SOME requirements. At least enough to be able to see the difference between the various proposals. I know you (and myself) reject some of the proposals and thinking that have been passed around on this list. To be able to *REALLY* reject those, I want to know the requirements that are behind the proposals. I.e. enough so that the requirements can be attacked instead of the solutions that claim to respond to all of them. But not more. paf > > -richard > > > > > > ________________________________ > > Von: enum-bounces at ietf.org im Auftrag von Richard Shockey > Gesendet: Fr 08.07.2005 19:06 > An: Patrik Fältström; Richard Shockey > Cc: enum at ietf.org > Betreff: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items > forIETF Paris) > > > > At 12:48 PM 7/8/2005, Patrik Fältström wrote: > > > >> On Jul 8, 2005, at 16:44, Richard Shockey wrote: >> >> >>> ...there is a requirement among service providers for some form of >>> database technology that, based on a E164 number, can provide >>> information on how to route a service to a point of carrier >>> interconnection or ALG as expressed as a URI. >>> >> >> Ok, this is for me one requirement. Sorry for maybe not being clear. >> >> >>> For privacy reasons this information needs to be restricted to >>> service providers and not generally available to end users. >>> >> >> Is the requirement that this information (the mapping from E.164 to >> URI) is only to be visible for the party that need to know, or "any >> service provider being part of the same club"? >> > > oh fine distinction can you elaborate a bit ?...what is the > difference been > 'party that needs to know' or 'service provider being part of the same > club' .. what is the distinction? > > as some here might postulate the exposure of the URI of the ALG may > or may > not be visible to A. all parties as in the use > of .carrier.e164.arpa B. > just visible to the club as in 3GPP.NET or e164MSO.ORG and the > visibility > of the ALG URI does not necessarily imply a formal peering agreement > between party A and party B. > > What the egress ALG does once it gets in INVITE is a matter between > consenting capitalists. > > Does that help? > > > >> paf >> >> >> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > 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 neustar.biz> > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From rich.shockey@neustar.biz Fri, 08 Jul 2005 17:25:51 -0400 From: Richard Shockey Date: Fri, 08 Jul 2005 17:25:51 -0400 To: enum at ietf.org Subject: [Enum] Nearly Final Agenda items for IETF 63 Paris Message-ID: <6.2.1.2.2.20050706071754.04288c40@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R NO we don't know the slot yet.. IETF 63 Telephone Number Mapping (ENUM) WG Agenda Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: Allison Mankin Mailing Lists: General Discussion:enum at ietf.org To Subscribe: enum-request at ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ AGENDA BASHING (5 min) The chairs have requested a 2 1/2 hour slot we have a very very full agenda. We are going to divide the slot into two parts ..first 1 hour for existing and new drafts not related to the "carrier ENUM" issues and then the last hour 1/2 to the carrier ENUM drafts and related materials plus general discussion of the implications of this for rechartering the WG and our thinking on the voippeer BOF which clearly it going to touch on all the issues we have raised internally. 1. Review of the existing drafts - Ready to go top Last call ( 5-10 M ? ) Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-02.txt Pages : 29 Date : 2005-7-1 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is informational only, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-02.txt 3. Final disposition of IRIS EREG, hopefully to last call. ( 5 Min? ) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-00.txt 4. New/old work on enumservice registrations ( 20 M ) Title : IANA Registration for Enumservice Voice Author(s) : R. Brandner, et al. Filename : draft-brandner-enum-voice-00.txt Pages : 12 Date : 2005-7-7 This document registers the ENUMservice ^voice^ (which has a defined sub-type ^tel^), as per the IANA registration process defined in the ENUM specification RFC3761. This service indicates that the contact held in the generated URI can be used to initiate an interactive voice (audio) call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enum-voice-00.txt Title : IANA Registration for an Enumservice Containing Number Portability and PSTN Signaling Information Author(s) : J. Livingood, R. Shockey Filename : draft-livingood-shockey-enum-npd-00.txt Pages : 8 Date : 2005-7-8 This document registers the Enumservice "npd" and subtype "tel" using the URI scheme 'tel:' as per the IANA registration process defined in the ENUM specification, RFC 3761. This data is used to facilitate the routing of telephone calls in those countries where Number Portability exists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-livingood-shockey-enum-npd-00.txt Title : IANA Registration for ENUMservice Mobile Webpage Author(s) : J. Ra, et al. Filename : draft-ra-shin-enum-mobileweb-00.txt Pages : Date : 2005-7-7 This document registers the ENUMservice ^mobweb^ using the URI schemes 'http:' and 'https:' as per the IANA registration process defined in the ENUM specification RFC3761. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ra-shin-enum-mobileweb-00.txt ENUM Validation Issues. 3 Drafts 15 -20 A. ENUM Validation Architecture draft-mayrhofer-enum-validation-arch-00 B. "ENUM Validation Token Format Definition" - draft-lendl-enum-validation-token-00.txt Abstract: An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes an signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion. This is a companion I-D to draft-mayrhofer-enum-validation-arch-00 which defines requirements and the overall architecture. The draft is also available on our web page at: http://www.enum.at/ietf/draft-lendl-enum-validation-token-00.html http://www.enum.at/ietf/draft-lendl-enum-validation-token-00.txt C. Bernie Hoeneisen http://ietf.hoeneisen.ch/draft-ietf-enum-validation-epp-00.txt http://ietf.hoeneisen.ch/draft-ietf-enum-validation-epp-00.html ################# PART 2 1/2 hours. 3 Items ################# Discussion of Pfautz etal drafts on Carrier ENUM - Requirements ? Title : IANA Carrier/User enumservice Registration Author(s) : P. Pfautz, et al. Filename : draft-pfautz-lind-enum-carrier-user-00.txt Pages : 10 Date : 2005-6-6 This document registers, pursuant to the guidelines in RFC 3761, tElephone NUmber Mapping (ENUM) services to allow a single registry to support end user and carrier services with independent name servers holding the terminal NAPTR (Naming Authority Pointer) records identifying the communication services for each. The to-be- registered enumservices make use of non-terminal NAPTR records and DDDS (Dynamic Delegation Discovery System) replacement to achieve this end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pfautz-lind-enum-carrier-user-00.txt "Combined User and Carrier ENUM in the e164.arpa tree" draft-haberler-carrier-enum-00.txt . Abstract: ENUM as defined now in RFC3761 is not well suited for the purpose of interconnection by carriers, as can be seen by the use of various private tree arrangements based on ENUM mechanisms. A combined end-user and carrier ENUM tree solution would leverage the ENUM infrastructure in e164.arpa, increase resolution rates, and decrease the cost per registered telephone number. This document describes a minimally invasive scheme to provide both end-user and carrier data in ENUM. The draft is also available on our web page at: http://www.enum.at/ietf/draft-haberler-carrier-enum-00.txt http://www.enum.at/ietf/draft-haberler-carrier-enum-00.html A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Non-Terminal NAPTR Processing: A Modest Proposal Author(s) : L. Conroy Filename : draft-conroy-enum-modestproposal-00.txt Pages : 12 Date : 2005-7-6 Recent Discussions within the IETF and in other fora have highlighted differences in interpretation of the set of standards associated with ENUM and DDDS, on which it relies. Specifically, the operation and semantics surrounding support for non-terminal NAPTRs has led to some confusion. This document is an attempt to add clarification to non- terminal NAPTR processing. In this, it clarifies RFC3403. A subsequent document will build on this one to extend RFC3761 further, permitting registration of non-terminal Enumservices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-conroy-enum-modestproposal-00.txt 6. Discussion of ENUM WG recharter ? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Fri, 08 Jul 2005 17:33:34 -0400 From: "Michael Hammer \(mhammer\)" Date: Fri, 08 Jul 2005 17:33:34 -0400 To: "Richard Shockey" Subject: RE: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris) Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3561194@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Following up on the question about hiding the points of interconnect between two carriers: 1. Does this mean that if party A has been assigned an ENUM number directly from a national authority and A tries to call party B that got his number from a carrier X in club Y, that the ENUM query for the SBC to access carrier X will be null because A is not in club Y? 2. Should the RR identifying the SBC to access carrier X contain both sip and sips URI? One for public access and one for private club access? If I scan the DNS would I find these URIs? Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Richard Shockey > Sent: Friday, July 08, 2005 1:07 PM > To: Patrik Faltstrom (pfaltstr); Richard Shockey > Cc: enum at ietf.org > Subject: Re: Carrier ENUM Definition (was RE: [Enum] Agenda > items forIETF Paris) > > At 12:48 PM 7/8/2005, Patrik Fältström wrote: > > > >On Jul 8, 2005, at 16:44, Richard Shockey wrote: > > > >>...there is a requirement among service providers for some form of > >>database technology that, based on a E164 number, can provide > >>information on how to route a service to a point of carrier > >>interconnection or ALG as expressed as a URI. > > > >Ok, this is for me one requirement. Sorry for maybe not being clear. > > > >>For privacy reasons this information needs to be restricted > to service > >>providers and not generally available to end users. > > > >Is the requirement that this information (the mapping from E.164 to > >URI) is only to be visible for the party that need to know, or "any > >service provider being part of the same club"? > > oh fine distinction can you elaborate a bit ?...what is the > difference been 'party that needs to know' or 'service > provider being part of the same club' .. what is the distinction? > > as some here might postulate the exposure of the URI of the > ALG may or may not be visible to A. all parties as in the use > of .carrier.e164.arpa B. > just visible to the club as in 3GPP.NET or e164MSO.ORG and > the visibility of the ALG URI does not necessarily imply a > formal peering agreement between party A and party B. > > What the egress ALG does once it gets in INVITE is a matter > between consenting capitalists. > > Does that help? > > > > paf > > > > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > 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 at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Fri, 08 Jul 2005 17:50:19 -0400 From: "Michael Hammer \(mhammer\)" Date: Fri, 08 Jul 2005 17:50:19 -0400 To: "Stastny Richard" Subject: RE: [Enum] Horizontal vs Vertical Message-ID: <072C5B76F7CEAB488172C6F64B30B5E356119B@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Good summary. Carriers can provide useful services to their customers, but must keep in mind that the first most useful feature is that anyone in the world can reach them. I'm not sure how the termination charges carriers like to charge each other will work out, but if the calls are symmetric with each carrier terminating one half of the call, that should even out and each can bill their respective customers and keep the money. If it is asymmetric, well that may be another story. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Stastny Richard > Sent: Friday, July 08, 2005 5:26 PM > To: Patrik Faltstrom (pfaltstr) > Cc: enum at ietf.org; Richard Shockey > Subject: [Enum] Horizontal vs Vertical > > >I know you (and myself) reject some of the proposals and > thinking that > >have been passed around on this list. To be able to *REALLY* reject > >those, I want to know the requirements that are behind the proposals. > > >I.e. enough so that the requirements can be attacked instead of the > >solutions that claim to respond to all of them. > > Yes and no, I think the current discussion on which Carrier > ENUM proposal is valid or not is only a side battle. > > The real battle currently going on is between the "Internet" > model (the horizontal layered model) and the vertical > stovepipes of the PSTN model. > > The Internet model is the end-to-end model originally > intended by SIP according to e-mail. If you have a sip URI > you may use this URI to contact at least the proxy hosting the AoR. > The media-stream is then transferred end-to-end directly > between the end-points. > > In the PSTN model only "networks" may exchange both > signalling and medai streams. To do so, they need peering > agreements, pretending to guarantee QoS, in reality to be > able to charge per minute. > > This model is mainly supported by mobile and cable operators > to keep up the current accounting regime, supported also by > the fixed network operators eaten up by the former, and also > by some VoIP getting greedy and also wanting to get their share. > > As Henry already stated the problem is surfacing by the > question: "Do you get a public SIP URI for your VoIP service" > If not, you may use IP-based Telephony, but you are behind a > walled garden. > > Back to ENUM: > > One is only able to use User ENUM if he has a Public SIP URI, > and he may then link this SIP URI with an > E.164 number in e164.arpa > > If he doesn't, the only "Public" identifier he has is an E.164 number. > If his provider decides to use SIP within his walled garden > network, he need some kind of addressing. Since this is SIP, > a SIP URI is useful, but the "domain" names used here cannot > be resolved on the public Internet. So the provider needs > some private DNS to resolve even his own users. If one of > this users wants to contact users of other providers, he may > either use SIP URI, but this is problematic because his > provider may not be able to resolve this URIs. So they stick > to E.164 numbers. Here you still have as default the PSTN to > interconnect. > > But providers of course also want to interconnect via IP, so > the Carreir may now use ENUM technology to map the > E.164 numbers to - ok this is now the question: > > The answer to this question is depending on what kind of ENUM > he is useing: > > In the worst case he may use private ENUM in his own network > to find the egress SBC into an "extranet" shared between > providers, the egress SBC connect to the proper extranet and > is querying an "ENUM" in this extranet to find the ingress > SBC of the provider hosting the number and this ingress SBC > is finally querying the ENUM in the destination network to > find the proxy hosting the subscriber. > > But there are other models. > > So to answer your questions for the requirements we need > first to discuss all potential peering models and ENUM configurations. > > We did this at ETSI for two years and included the only major > models in ETSI TS 102 055. > > The whole issue will finally not be decided by a standards body. > it will be decided by the end-user, because he will finally > have the choice to use both models in parallel at his mobile > device. He may chose either to query User ENUM ar let the > call be set-up by his IMS provider. > > -richard > > PS: you may compete with everybody, but not with your > customer (Clay Shirky on fax-mail) > > > > . > > > ________________________________ > > Von: Patrik Fältström [mailto:paf at cisco.com] > Gesendet: Fr 08.07.2005 21:44 > An: Stastny Richard > Cc: Richard Shockey; enum at ietf.org > Betreff: Re: Carrier ENUM Definition (was RE: [Enum] Agenda > items forIETF Paris) > > > > > On Jul 8, 2005, at 19:25, Stastny Richard wrote: > > > Rich Shockey wrote: > > > >> as some here might postulate the exposure of the URI of > the ALG may > >> or may not be visible to A. all parties as in the use of > >> .carrier.e164.arpa B. > >> just visible to the club as in 3GPP.NET or e164MSO.ORG and the > >> visibility of the ALG URI does not necessarily imply a > formal peering > >> agreement between party A and party B. > >> > > > > I question for clarification, especially to Patrik: > > > > Are we talking here about requirements for carrier ENUM -in private > > enterprise trees? > > -in carrier trees within their network to find egress ALGs > (or SBCs or > > GWs)? > > -in shared walled garden trees such as GSMA > > (whatchamanameitcurrently) to find ingress ALGs? > > -in (partially or wholely) public other trees such as e174.info? > > -or in carrier.c.c.164.arpa or c.c.carrier.e164.arpa? > > > > or altogether? > > > > If it is last, I will come back in two years and look how > far you are > > with the requirements and I do not think I will have missed a lot > > I want at least SOME requirements. At least enough to be able > to see the difference between the various proposals. > > I know you (and myself) reject some of the proposals and > thinking that have been passed around on this list. To be > able to *REALLY* reject those, I want to know the > requirements that are behind the proposals. > > I.e. enough so that the requirements can be attacked instead > of the solutions that claim to respond to all of them. > > But not more. > > paf > > > > > > -richard > > > > > > > > > > > > ________________________________ > > > > Von: enum-bounces at ietf.org im Auftrag von Richard Shockey > > Gesendet: Fr 08.07.2005 19:06 > > An: Patrik Fältström; Richard Shockey > > Cc: enum at ietf.org > > Betreff: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items > > forIETF Paris) > > > > > > > > At 12:48 PM 7/8/2005, Patrik Fältström wrote: > > > > > > > >> On Jul 8, 2005, at 16:44, Richard Shockey wrote: > >> > >> > >>> ...there is a requirement among service providers for > some form of > >>> database technology that, based on a E164 number, can provide > >>> information on how to route a service to a point of carrier > >>> interconnection or ALG as expressed as a URI. > >>> > >> > >> Ok, this is for me one requirement. Sorry for maybe not > being clear. > >> > >> > >>> For privacy reasons this information needs to be restricted to > >>> service providers and not generally available to end users. > >>> > >> > >> Is the requirement that this information (the mapping from E.164 to > >> URI) is only to be visible for the party that need to > know, or "any > >> service provider being part of the same club"? > >> > > > > oh fine distinction can you elaborate a bit ?...what is the > difference > > been 'party that needs to know' or 'service provider being > part of the > > same club' .. what is the distinction? > > > > as some here might postulate the exposure of the URI of the > ALG may or > > may not be visible to A. all parties as in the use of > > .carrier.e164.arpa B. > > just visible to the club as in 3GPP.NET or e164MSO.ORG and the > > visibility of the ALG URI does not necessarily imply a > formal peering > > agreement between party A and party B. > > > > What the egress ALG does once it gets in INVITE is a matter between > > consenting capitalists. > > > > Does that help? > > > > > > > >> paf > >> > >> > >> > >> > > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > 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 > neustar.biz> ; > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > > > _______________________________________________ > > enum mailing list > > enum at ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Fri, 08 Jul 2005 18:01:53 -0400 From: "Stastny Richard" Date: Fri, 08 Jul 2005 18:01:53 -0400 To: "Michael Hammer \(mhammer\)" Subject: Re: [Enum] Horizontal vs Vertical Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C00A@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Thanks, Also PSTN providers move already to peering, but they still charge their subscribers in most cases. They also move to free "on-net" calls. The choice the subscriber has in future at his mobile device is: does he use the charged (or partially charged) of the IMS provider; or does he use the "free" VoIP service on the Internet, but gets charged for the access to the Internet. With a dual-mode device the user may choose to use VoIP if connected via WiFi, but he may use the mobile operator voice service if connected via 3G (UMTS), because although VoIP (or Skype) works, but the data charges are prohitive, especially when roaming. In this case you are tunnelled via the visited network to the home network -richard ________________________________ Von: Michael Hammer (mhammer) [mailto:mhammer at cisco.com] Gesendet: Fr 08.07.2005 23:50 An: Stastny Richard; Patrik Faltstrom (pfaltstr) Cc: enum at ietf.org; Richard Shockey Betreff: RE: [Enum] Horizontal vs Vertical Good summary. Carriers can provide useful services to their customers, but must keep in mind that the first most useful feature is that anyone in the world can reach them. I'm not sure how the termination charges carriers like to charge each other will work out, but if the calls are symmetric with each carrier terminating one half of the call, that should even out and each can bill their respective customers and keep the money. If it is asymmetric, well that may be another story. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Stastny Richard > Sent: Friday, July 08, 2005 5:26 PM > To: Patrik Faltstrom (pfaltstr) > Cc: enum at ietf.org; Richard Shockey > Subject: [Enum] Horizontal vs Vertical > > >I know you (and myself) reject some of the proposals and > thinking that > >have been passed around on this list. To be able to *REALLY* reject > >those, I want to know the requirements that are behind the proposals. > > >I.e. enough so that the requirements can be attacked instead of the > >solutions that claim to respond to all of them. > > Yes and no, I think the current discussion on which Carrier > ENUM proposal is valid or not is only a side battle. > > The real battle currently going on is between the "Internet" > model (the horizontal layered model) and the vertical > stovepipes of the PSTN model. > > The Internet model is the end-to-end model originally > intended by SIP according to e-mail. If you have a sip URI > you may use this URI to contact at least the proxy hosting the AoR. > The media-stream is then transferred end-to-end directly > between the end-points. > > In the PSTN model only "networks" may exchange both > signalling and medai streams. To do so, they need peering > agreements, pretending to guarantee QoS, in reality to be > able to charge per minute. > > This model is mainly supported by mobile and cable operators > to keep up the current accounting regime, supported also by > the fixed network operators eaten up by the former, and also > by some VoIP getting greedy and also wanting to get their share. > > As Henry already stated the problem is surfacing by the > question: "Do you get a public SIP URI for your VoIP service" > If not, you may use IP-based Telephony, but you are behind a > walled garden. > > Back to ENUM: > > One is only able to use User ENUM if he has a Public SIP URI, > and he may then link this SIP URI with an > E.164 number in e164.arpa > > If he doesn't, the only "Public" identifier he has is an E.164 number. > If his provider decides to use SIP within his walled garden > network, he need some kind of addressing. Since this is SIP, > a SIP URI is useful, but the "domain" names used here cannot > be resolved on the public Internet. So the provider needs > some private DNS to resolve even his own users. If one of > this users wants to contact users of other providers, he may > either use SIP URI, but this is problematic because his > provider may not be able to resolve this URIs. So they stick > to E.164 numbers. Here you still have as default the PSTN to > interconnect. > > But providers of course also want to interconnect via IP, so > the Carreir may now use ENUM technology to map the > E.164 numbers to - ok this is now the question: > > The answer to this question is depending on what kind of ENUM > he is useing: > > In the worst case he may use private ENUM in his own network > to find the egress SBC into an "extranet" shared between > providers, the egress SBC connect to the proper extranet and > is querying an "ENUM" in this extranet to find the ingress > SBC of the provider hosting the number and this ingress SBC > is finally querying the ENUM in the destination network to > find the proxy hosting the subscriber. > > But there are other models. > > So to answer your questions for the requirements we need > first to discuss all potential peering models and ENUM configurations. > > We did this at ETSI for two years and included the only major > models in ETSI TS 102 055. > > The whole issue will finally not be decided by a standards body. > it will be decided by the end-user, because he will finally > have the choice to use both models in parallel at his mobile > device. He may chose either to query User ENUM ar let the > call be set-up by his IMS provider. > > -richard > > PS: you may compete with everybody, but not with your > customer (Clay Shirky on fax-mail) > > > > . > > > ________________________________ > > Von: Patrik Fältström [mailto:paf at cisco.com] > Gesendet: Fr 08.07.2005 21:44 > An: Stastny Richard > Cc: Richard Shockey; enum at ietf.org > Betreff: Re: Carrier ENUM Definition (was RE: [Enum] Agenda > items forIETF Paris) > > > > > On Jul 8, 2005, at 19:25, Stastny Richard wrote: > > > Rich Shockey wrote: > > > >> as some here might postulate the exposure of the URI of > the ALG may > >> or may not be visible to A. all parties as in the use of > >> .carrier.e164.arpa B. > >> just visible to the club as in 3GPP.NET or e164MSO.ORG and the > >> visibility of the ALG URI does not necessarily imply a > formal peering > >> agreement between party A and party B. > >> > > > > I question for clarification, especially to Patrik: > > > > Are we talking here about requirements for carrier ENUM -in private > > enterprise trees? > > -in carrier trees within their network to find egress ALGs > (or SBCs or > > GWs)? > > -in shared walled garden trees such as GSMA > > (whatchamanameitcurrently) to find ingress ALGs? > > -in (partially or wholely) public other trees such as e174.info? > > -or in carrier.c.c.164.arpa or c.c.carrier.e164.arpa? > > > > or altogether? > > > > If it is last, I will come back in two years and look how > far you are > > with the requirements and I do not think I will have missed a lot > > I want at least SOME requirements. At least enough to be able > to see the difference between the various proposals. > > I know you (and myself) reject some of the proposals and > thinking that have been passed around on this list. To be > able to *REALLY* reject those, I want to know the > requirements that are behind the proposals. > > I.e. enough so that the requirements can be attacked instead > of the solutions that claim to respond to all of them. > > But not more. > > paf > > > > > > -richard > > > > > > > > > > > > ________________________________ > > > > Von: enum-bounces at ietf.org im Auftrag von Richard Shockey > > Gesendet: Fr 08.07.2005 19:06 > > An: Patrik Fältström; Richard Shockey > > Cc: enum at ietf.org > > Betreff: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items > > forIETF Paris) > > > > > > > > At 12:48 PM 7/8/2005, Patrik Fältström wrote: > > > > > > > >> On Jul 8, 2005, at 16:44, Richard Shockey wrote: > >> > >> > >>> ...there is a requirement among service providers for > some form of > >>> database technology that, based on a E164 number, can provide > >>> information on how to route a service to a point of carrier > >>> interconnection or ALG as expressed as a URI. > >>> > >> > >> Ok, this is for me one requirement. Sorry for maybe not > being clear. > >> > >> > >>> For privacy reasons this information needs to be restricted to > >>> service providers and not generally available to end users. > >>> > >> > >> Is the requirement that this information (the mapping from E.164 to > >> URI) is only to be visible for the party that need to > know, or "any > >> service provider being part of the same club"? > >> > > > > oh fine distinction can you elaborate a bit ?...what is the > difference > > been 'party that needs to know' or 'service provider being > part of the > > same club' .. what is the distinction? > > > > as some here might postulate the exposure of the URI of the > ALG may or > > may not be visible to A. all parties as in the use of > > .carrier.e164.arpa B. > > just visible to the club as in 3GPP.NET or e164MSO.ORG and the > > visibility of the ALG URI does not necessarily imply a > formal peering > > agreement between party A and party B. > > > > What the egress ALG does once it gets in INVITE is a matter between > > consenting capitalists. > > > > Does that help? > > > > > > > >> paf > >> > >> > >> > >> > > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > 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 > neustar.biz> ; > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > > > _______________________________________________ > > enum mailing list > > enum at ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Fri, 08 Jul 2005 18:06:19 -0400 From: "Michael Hammer \(mhammer\)" Date: Fri, 08 Jul 2005 18:06:19 -0400 To: "Michael Haberler" Subject: RE: [Enum] Agenda items for IETF Paris Message-ID: <072C5B76F7CEAB488172C6F64B30B5E35611A7@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Michael, Could you elaborate more fully. Between the setup of IP PBX and the assertion that my proposal makes something impossible, I didn't see any explanation. It would help if you use a hypothetical E.164 number and perhaps explain if this was provided through a carrier or not. Also, is this extension being assigned an E.164 number also? Or is this grafting a non-E.164 number onto an E.164 number? Would this require all DNS-resolvers to continue searching beyond the E.164 tree? More details please. Mike > -----Original Message----- > From: Michael Haberler [mailto:mah at inode.at] > Sent: Friday, July 08, 2005 4:10 PM > To: Michael Hammer (mhammer); Jim Reid > Cc: enum at ietf.org > Subject: RE: [Enum] Agenda items for IETF Paris > > Michael, > > lets call your proposal "zone cohabitation" (which is very > close to the CNAPTR proposal which was on the CC1 LLC mailing > list a while ago). > > I think it would work in theory - however: > > In practice, it would prevent delegation to a user-operated > nameserver at the number level, forcing the Tier1 nameservers > contain all NAPTRs, with all consequences. > > Lets assume your user deploys an Innovaphone IP PBX > (www.innovaphone.de) . > This box inlcudes a user (lets call it "Tier3") nameserver. > You add an extension, corresponding NAPTR record appears > automatically. > > There are many more useful examples for such applications, > and I believe your proposal makes them impossible - I doubt > that Carrier POI information can be reasonably administered > in such a scenario. > > The concept of zone ownership gets in the way, which is why I > propose different zones - small burden on the Carrier-ENUM > aware resolver, no burden on User ENUM tree shape. > > -Michael > > > At 20:06 08.07.2005, Michael Hammer \(mhammer\) wrote: > > >Jim, > > > >I have yet to see a persuasive argument for why all the political > >requirement, control, manipulation, administration, policy, > ... aspects > >can't be built around a simple technical model. The administrative > >tail seems to be wagging the dog. > > > >Whatever happened to Occam's Razor? > > > >Mike > > > > > > > -----Original Message----- > > > From: Jim Reid [mailto:jim at rfc1035.com] > > > Sent: Friday, July 08, 2005 1:41 PM > > > To: Michael Hammer (mhammer) > > > Cc: Michael Haberler; enum at ietf.org > > > Subject: Re: [Enum] Agenda items for IETF Paris > > > > > > On Jul 8, 2005, at 17:29, Michael Hammer ((mhammer)) wrote: > > > > > > > Pardon my inexperience with DNS mechanisms, but why can't a > > > lookup of > > > > a domain at: 1.2.3.4.5.5.5.1.0.2.1.e164.arpa return an > > > OPT-IN User RR > > > > (which may or may not be there) and a Carrier RR > > > identifying a border > > > > controller? > > > > > > Because these are two different things which will presumably be > > > controlled and manipulated by different entities according to > > > different, possibly mutually exclusive, requirements. > > > > > > There's nothing in the DNS protocol to prevent these RRs > co-existing > > > in the same zone of course. And if they did, a DNS lookup could > > > return both. However just because something is possible > doesn't mean > > > it could or even should be done. > > > From a purely technical perspective, the answer to your > question is > > > the DNS lookup could return both these RRs. But for all sorts of > > > practical reasons -- administrative, policy, operational, content > > > management, synchronising and managing access control to > the zone, > > > etc, etc -- this is unlikely to be a wise or desirable outcome. > > > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@inode.at Fri, 08 Jul 2005 20:00:11 -0400 From: Michael Haberler Date: Fri, 08 Jul 2005 20:00:11 -0400 To: "Michael Hammer \(mhammer\)" Subject: RE: [Enum] Agenda items for IETF Paris In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E356108A@xmb-rtp-20b.amer.cisco.com> Message-ID: <6.2.1.2.2.20050708232643.10076d40@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: R Michael, At 18:29 08.07.2005, Michael Hammer \(mhammer\) wrote: I read your draft, but fail to see the need to define a new "carrier" domain at any point in the tree. Putting such a domain under the country code only branches at a different point down the hierarchy. You've only moved the problem next door. Two facts bound this problem as far as I can tell: 1: A number is dialed and presented to the DNS client that then must resolve it by traversing the tree from root on down to the last digit. 2: Until you reach a given point in the tree (depending on national authority assignments, e.g. 10K v 1K blocks) it is ambiguous whether the number belongs to one carrier or another. I don't think it a good idea to regulate where in the tree (e.g. after 3 or 6 digits) to place carrier information. I think there is a major misunderstanding what our proposal suggests. The 'carrier subdomain location' is about opening a complete new tree, at a flexible but globally interworking location in the e164.arpa tree because of the very cohabitation problems. It is a convention which needs to be published for interoperability, not a regulation. A well-known table is just one mechanism to do that, an appropriate RR in a standard place per country code could get rid of the table altogether. It is NOT the place where, for a given number, a particular "Carrier RR" is stored. I propose to unroll all number ranges fully and store RR's at the number level. I dont envisage delegations at some number block boundary - this again gets in the way with zone ownership when a number is ported out of a block - DNS semantics doesnt deal well with a "exception override" over a delegation boundary. If each number is entered in itself - no problem, because zone ownership for that number mirrors the changed carrier-of-record status. The rules are: - a carrier-of-record for a given number may populate the carrier subtree with this number, with RR's as she may see fit. - a user may populate the user tree as per 3761 (section 2 requirement 2 in our I-D) as he sees fit. - they are ships in the night - no need to coordinate between the two. The reason why the carrier subtree location needs to be flexible and cant be assumed under the country code is that "Country Code does not equal Numbering Plan Administration" (that's by and large a fix for the colonies, as far as we're concerned over here ;)) Resolving a tree digit-by-digit is bound to increase lookups drastically, violating our proposed "single DNS lookup to reach any NAPTR" requirement (section 2 requirement one). I guess I should give two examples. I assume the carrier subdomain location for the Austrian CC is 2, that is, right below the CC. Example 1: 1. I obtain a corporate network number from the national number administrator, so I am the number holder. Lets assume the number is +43 59966 . Now I can enter that in User ENUM - and I'll have 6.6.9.9.5.3.4.e164.arpa delegated to my own name server - in the zone I have my SIP AOR for my PBX, and maybe lots of other stuff - we have an open numbering plan here and I could have anywhere from 0 to 8 extra DDI digits after +43 59966 for my users. I choose to manage all User ENUM entries in my nameserver. I choose not to care about any carrier records my carrier-of-record of the week might want to have. I might not even be in the position to manage such a record in case my gear happens to not support that. 2. I turn around and ask Telekom Austria (TA) to route that number in the PSTN, which is when they become the carrier of record for my number. They happen to interconnect with other carriers with IP and choose to use the carrier ENUM tree under +43 to do that, but I could care less. Now they can enter that in the local carrier subtree: 6.6.9.9.5.carrier.3.4.e164.arpa points their SBC. 3. I decide Foo Telco is better for me, so I port my number to Foo, hence Foo becomes the new carrier-of-record for my number and thus has the right to change 6.6.9.9.5.carrier.3.4.e164.arpa to point to the Foo SBC. Example 2: I have number +1 571.123.4567, which is in a US NPA, which happens to use the scheme I laid out. I assume that location for the +1 CC to be at 4, after the NPA. 1. I have a user ENUM domain: 7.6.5.4.3.2.1.1.7.5.1.e164.arpa - nothing special here. 2. My telco X chooses to interconnect on IP with others, among them TA and Foo, using our scheme, so she would enter their SBC information in the 7.6.5.4.3.2.1.carrier.1.7.5.1.e164.arpa zone. Since all this assumed to be well-known, a call to +1 571.123.4567 originating from some other TA or Foo POTS subscriber could be be passed to X on IP, and vice versa. When X, Foo and TA eventually grow up, and decide to dump interconnect completely, they can switch to just interpret User ENUM records. Or both, as and when they see fit. Sun-Tsu says: "for the fleeing enemy, build a silver bridge." At no point there is any interference between the subtrees, and a single lookup gets at any NAPTR. User-to-user between +43 59966.* and +1 571.123.4567 works as per rfc3761. Michael http://www.enum.at/ietf/draft-haberler-carrier-enum-00.html ps: In practice, carrier records probably would point to carrier nameservers, and RR's would be in the zone hosted there, but that makes no difference. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@inode.at Fri, 08 Jul 2005 20:36:12 -0400 From: Michael Haberler Date: Fri, 08 Jul 2005 20:36:12 -0400 To: "Michael Hammer \(mhammer\)" Subject: combined User and Carrier ENUM (was RE: [Enum] Agenda items for IETF Paris) In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E35610DC@xmb-rtp-20b.amer.cisco.com> Message-ID: <6.2.1.2.2.20050709021634.0512e1c8@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: R At 20:06 08.07.2005, Michael Hammer \(mhammer\) wrote: Jim, I have yet to see a persuasive argument for why all the political requirement, control, manipulation, administration, policy, ... aspects can't be built around a simple technical model. The administrative tail seems to be wagging the dog. Ah, I guess I see the knot... Could it be that you are assuming: - a closed numbering plan (fixed number length) - maybe a scenario where all RR's are held in the Tier1 nameservers? and think about a scheme where authorization to enter a particular record type at the number level could be given to different parties ? that would probably work, BUT - not all countries have a fixed numbering plan - among them Germany and Austria. Coming back to my example: +43 59966 is a valid number, as is +43 59966-0 (a convention to reach the switchboard). +43 58866-12345678 is valid as well, and anything in between. In such a situation you would typically have a delegation at +43 59966 to point to your own ("Tier3") nameservers. That is in fact very useful - I'd have to check but I assume that most PBX-type delegations under +43 use that scheme. As I mentioned, actually enlightened IP PBX manufacturers use this method. I assume this to be incompatible with carrier type records at or under +43 59966 - no carrier fiddling in user-operated zones, please. -Michael _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ray@bango.net Sat, 09 Jul 2005 01:27:21 -0400 From: Ray Anderson Date: Sat, 09 Jul 2005 01:27:21 -0400 To: "Michael Hammer \(mhammer\)" Subject: RE: [Enum] Horizontal vs Vertical - not just carriers In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E356119B@xmb-rtp-20b.amer.cisco.com> Message-ID: <6.1.2.0.2.20050709062240.0bcf54b0@smtp.bango.net> MIME-Version: 1.0 Content-Type: text/plain Status: R Clearly the majority of people active on this list are involved with carriers, but lets not forget that many of the requirements of ENUM do not pre-suppose that the majority of applications of ENUM will be about voice over IP , carriers etc. There are applications that will be deployed that use ENUM as a way of assigning properties to numbers that happen to lie in the E.164 tree for convenience / uniqueness without having any connection whatsoever with "carriers". Lets keep sight of their requirements (assumed to be still current) At 22:50 08/07/2005, Michael Hammer \(mhammer\) wrote: Good summary. Carriers can provide useful services to their customers, but must keep in mind that the first most useful feature is that anyone in the world can reach them. I'm not sure how the termination charges carriers like to charge each other will work out, but if the calls are symmetric with each carrier terminating one half of the call, that should even out and each can bill their respective customers and keep the money. If it is asymmetric, well that may be another story. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Sat, 09 Jul 2005 02:03:43 -0400 From: "Peter Williams" Date: Sat, 09 Jul 2005 02:03:43 -0400 To: Subject: RE: [Enum] Horizontal vs Vertical In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C008@oefeg-s04.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of > Stastny Richard > Sent: Friday, July 08, 2005 2:26 PM > To: Patrik Fältström > Cc: enum at ietf.org; Richard Shockey > Subject: [Enum] Horizontal vs Vertical > > >I know you (and myself) reject some of the proposals and thinking > >that have been passed around on this list. To be able to *REALLY* > >reject those, I want to know the requirements that are behind the > >proposals. > > >I.e. enough so that the requirements can be attacked instead of the > >solutions that claim to respond to all of them. > > Yes and no, I think the current discussion on which Carrier ENUM > proposal is valid or not is only a side battle. > > The real battle currently going on is between the "Internet" model > (the horizontal layered model) and the vertical stovepipes of > the PSTN model. > > The Internet model is the end-to-end model originally intended > by SIP according to e-mail. If you have a sip URI you > may use this URI to contact at least the proxy hosting the AoR. > The media-stream is then transferred end-to-end directly between > the end-points. > > In the PSTN model only "networks" may exchange both signalling > and medai streams. To do so, they need peering agreements, pretending > to guarantee QoS, in reality to be able to charge per minute. > > This model is mainly supported by mobile and cable operators to > keep up the current accounting regime, supported also by the > fixed network operators eaten up by the former, and also by > some VoIP getting greedy and also wanting to get their share. Ill stay out of the religious discussion, 'case I get chastised again for pointing out how we attempted to avoid the same old issue set whilst thinking like Internet people, last time round! On the point introduced, there is much more to the *needs* behind a whole class of Carrier ENUM requirements than the billing and resource sharing issues. The providers are also providing a *regulated* security service, addressing user data privacy expectations (a type of QOS), and realtime interception capability - as authorized on a per-called/calling party basis. To satisfy these licensing obligations, peer providers must very cooperate closely in practice, often in the form of joining groups of providers who sharing a common key management provider. I cant remember whether it was at a public or private event, that someone at at Company X explained how the company runs rooms and rooms of outsourced CMIP responders for the various telcos, managing crypto keys that are used and shared pursuant to thousands of peering agreements, and addressing the security rules laid down by governments for each specific interconnect arrangement. In reality, an ENUM-enhanced DNS supporting name management, listing services, and discovery service has to be matched with a framework for interconnect arrangements that address the backroom handling of crypto keys, which must be configured on a provider-provider level, and possibly per switch path/route. Very very very fast key translation crypto hardware augments today's company Y's switches - making all this work totally invisible to users, while satisfying realtime data access rules set by licensing authorities at switching points. While such hardware deployment is just a fixed capital outlay, the pain is in managing the translation tables: for this, the entire existing system of key update and sharing, which is linked to name registration/portability/listing/routing (in a CMIP database, as it happens, today), will have to be also be addressed in future Carrier ENUM standards. ------ Hopefully, I identified clearly a need - and thus a class of requirement - that would allow one to distinguish Carrier ENUM convergence models - without saying anything at all about how it should be accomplished in an ENUM-based infrastructure. .. > > But there are other models. > > So to answer your questions for the requirements we need > first to discuss all potential peering models and ENUM configurations. > > We did this at ETSI for two years and included the only major models > in ETSI TS 102 055. > > The whole issue will finally not be decided by a standards body. > it will be decided by the end-user, because he > will finally have the choice to use both models in parallel at his > mobile device. He may chose either to query User ENUM ar let > the call be set-up by his IMS provider. Increasingly, the mobile device phone will using chips that impose the providers security obligations on an end-end basis, even in the User Enum model. Your ability to complete the call will depend not only on transaprt and a lookup, but on whether the chip authorized the connection - much as the provider-side enforcement system works today. Sorry to keep throwing security and keys into stuff folks prefer to discuss: numbers, administrative portability, routes, management domains and different types of managed access points. But, this security issue imposed by the regulators is what is must drive us towards Carrier ENUM, and it will eventually spill over into public ENUM. There is just no choice here, folks. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Sat, 09 Jul 2005 04:20:08 -0400 From: "Stastny Richard" Date: Sat, 09 Jul 2005 04:20:08 -0400 To: "Ray Anderson" Subject: Re: [Enum] Horizontal vs Vertical - not just carriers Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C00B@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Ray wrote: >Lets keep sight of their requirements (assumed to be still current) One reason for draft-haberler-carrier-enum-00 http://www.enum.at/ietf/draft-haberler-carrier-enum-00.txt http://www.enum.at/ietf/draft-haberler-carrier-enum-00.html is to leave User ENUM as defined in RFC3761 completely untouched. So we kept sight of these requirements The argument was that if carriers want to use the ressource in e814.arpa also, fine, but they have also to take any additional burden, -richard ________________________________ Von: Ray Anderson [mailto:ray at bango.net] Gesendet: Sa 09.07.2005 07:27 An: Michael Hammer (mhammer); Stastny Richard; Patrik Faltstrom (pfaltstr) Cc: enum at ietf.org; Richard Shockey Betreff: RE: [Enum] Horizontal vs Vertical - not just carriers Clearly the majority of people active on this list are involved with carriers, but lets not forget that many of the requirements of ENUM do not pre-suppose that the majority of applications of ENUM will be about voice over IP , carriers etc. There are applications that will be deployed that use ENUM as a way of assigning properties to numbers that happen to lie in the E.164 tree for convenience / uniqueness without having any connection whatsoever with "carriers". Lets keep sight of their requirements (assumed to be still current) At 22:50 08/07/2005, Michael Hammer \(mhammer\) wrote: >Good summary. Carriers can provide useful services to their customers, >but must keep in mind that the first most useful feature is that anyone in >the world can reach them. > >I'm not sure how the termination charges carriers like to charge each >other will work out, but if the calls are symmetric with each carrier >terminating one half of the call, that should even out and each can bill >their respective customers and keep the money. If it is asymmetric, well >that may be another story. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lendl@nic.at Sat, 09 Jul 2005 04:26:00 -0400 From: Otmar Lendl Date: Sat, 09 Jul 2005 04:26:00 -0400 To: enum at ietf.org Subject: Re: [Enum] Agenda items for IETF Paris In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E35611A7@xmb-rtp-20b.amer.cisco.com> Message-ID: <20050709082545.GB23172@nic.at> MIME-Version: 1.0 Content-Type: text/plain Status: R On 2005/07/09 00:07, "Michael Hammer (mhammer)" wrote: > Michael, > > Could you elaborate more fully. Between the setup of IP PBX and the > assertion that my proposal makes something impossible, I didn't see any > explanation. It would help if you use a hypothetical E.164 number and > perhaps explain if this was provided through a carrier or not. Also, is > this extension being assigned an E.164 number also? Or is this grafting > a non-E.164 number onto an E.164 number? Would this require all > DNS-resolvers to continue searching beyond the E.164 tree? The misunderstanding here seems to be in open numbering plans nad how they relate to E.164 numbers. Michael gave some examples, I'd like to add a simple one. Our office in Vienna uses a simple ISDN BRI in point-to-point mode. The number is +43 1 5056416 which is a valid E.164 number that is dial- and reachable from the worldwide PSTN. But so is +43 1 5056416 33, +43 1 5056416 933, or +43 1 5056416 6, too. We, as the owner of the head number are free to design our own, variable length numbering plan behind that number as long as we stay within the length limit of E.164. Our telco will route calls to +43 1 5056416 [0-9]* to us and indicate in the call-setup what exactly the caller dialled. (I will not go into the territory of overlap dialing here, there is plenty of fun in the details.) All those locally defined extensions are valid E.164 numbers. There is no need to "continue searching beyond the E.164 tree", because we *are* still in the E.164 tree. As such, telephone numbers in an open numbering plan behave much more like domain names: If I own example.com, then I can put a webserver at example.com. I'm free to use foo.example.com, bar.foo.example.com and whatnot as well, as long as I stay within the lenght limits imposed by the DNS standard. To continue with the +43 1 5056416 example: The ISDN BRI is connected to a small cisco router on our side which translates all incoming calls to SIP. The numbering plan (the information which extensions exist and where they are routed) is stored in a small database which also drives the 6.1.4.6.5.0.5.1.3.4.e164.arpa zone. I can thus create new, valid E.164 numbers by a simple insert into that table. ENUM NAPTRs are instantly visible as well. There is real value in the fact that we have complete control over our ENUM zone. All this does not mix with carrier enum. Our carrier doesn't even know what numbers are in use behind our number. All he needs to know is "route everything matching /^4315056416.*/ in our direction". And basically that's the information our carrier has to put into any carrier ENUM tree. In ENUM terms, that will probably be something like $ORIGIN 6.1.4.6.5.0.5.1.carrier.3.4.e164.arpa @ 100 10 "u" "E2U+sip" "!(^.*)$!sip:\\1 at sbc.my-carrier.at!" . * 100 10 "u" "E2U+sip" "!(^.*)$!sip:\\1 at sbc.my-carrier.at!" . As for zone-sharing, I think the problem is obvious. /ol -- < Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Sat, 09 Jul 2005 04:29:53 -0400 From: "Stastny Richard" Date: Sat, 09 Jul 2005 04:29:53 -0400 To: "Michael Haberler" Subject: Re: [Enum] Agenda items for IETF Paris Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C00C@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R >I don't think it a good idea to regulate where in the tree (e.g. after 3 >or 6 digits) to place carrier information. First, there is no regulation, it is only a recommendation to put it after the cc, as Michael already pointed out And for the avoidance of doubt: the proposals c.c.carrier.e164.arpa and carrier.c.c.e614.arpa are technically (or DNS wise) completely equivalent It is also obvious that the first variant is more straightforward. The preference for the latter variant is simply because of practical administrative and political reasons. In the second variant everything stays a national matter, in the first variant the debate on the international level would start over again (2-3 years?), and then you have again the debate on the national level. With the second variant we jump over the international debate and can start immediately with the national debate. This is enough anyway. -richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Michael Haberler Gesendet: Sa 09.07.2005 01:58 An: Michael Hammer (mhammer) Cc: enum at ietf.org Betreff: RE: [Enum] Agenda items for IETF Paris Michael, At 18:29 08.07.2005, Michael Hammer \(mhammer\) wrote: >I read your draft, but fail to see the need to define a new "carrier" >domain at any point in the tree. Putting such a domain under the >country code only branches at a different point down the hierarchy. >You've only moved the problem next door. > >Two facts bound this problem as far as I can tell: >1: A number is dialed and presented to the DNS client that then must >resolve it by traversing the tree from root on down to the last digit. >2: Until you reach a given point in the tree (depending on national >authority assignments, e.g. 10K v 1K blocks) it is ambiguous whether the >number belongs to one carrier or another. > >I don't think it a good idea to regulate where in the tree (e.g. after 3 >or 6 digits) to place carrier information. I think there is a major misunderstanding what our proposal suggests. The 'carrier subdomain location' is about opening a complete new tree, at a flexible but globally interworking location in the e164.arpa tree because of the very cohabitation problems. It is a convention which needs to be published for interoperability, not a regulation. A well-known table is just one mechanism to do that, an appropriate RR in a standard place per country code could get rid of the table altogether. It is NOT the place where, for a given number, a particular "Carrier RR" is stored. I propose to unroll all number ranges fully and store RR's at the number level. I dont envisage delegations at some number block boundary - this again gets in the way with zone ownership when a number is ported out of a block - DNS semantics doesnt deal well with a "exception override" over a delegation boundary. If each number is entered in itself - no problem, because zone ownership for that number mirrors the changed carrier-of-record status. The rules are: - a carrier-of-record for a given number may populate the carrier subtree with this number, with RR's as she may see fit. - a user may populate the user tree as per 3761 (section 2 requirement 2 in our I-D) as he sees fit. - they are ships in the night - no need to coordinate between the two. The reason why the carrier subtree location needs to be flexible and cant be assumed under the country code is that "Country Code does not equal Numbering Plan Administration" (that's by and large a fix for the colonies, as far as we're concerned over here ;)) Resolving a tree digit-by-digit is bound to increase lookups drastically, violating our proposed "single DNS lookup to reach any NAPTR" requirement (section 2 requirement one). I guess I should give two examples. I assume the carrier subdomain location for the Austrian CC is 2, that is, right below the CC. Example 1: 1. I obtain a corporate network number from the national number administrator, so I am the number holder. Lets assume the number is +43 59966 . Now I can enter that in User ENUM - and I'll have 6.6.9.9.5.3.4.e164.arpa delegated to my own name server - in the zone I have my SIP AOR for my PBX, and maybe lots of other stuff - we have an open numbering plan here and I could have anywhere from 0 to 8 extra DDI digits after +43 59966 for my users. I choose to manage all User ENUM entries in my nameserver. I choose not to care about any carrier records my carrier-of-record of the week might want to have. I might not even be in the position to manage such a record in case my gear happens to not support that. 2. I turn around and ask Telekom Austria (TA) to route that number in the PSTN, which is when they become the carrier of record for my number. They happen to interconnect with other carriers with IP and choose to use the carrier ENUM tree under +43 to do that, but I could care less. Now they can enter that in the local carrier subtree: 6.6.9.9.5.carrier.3.4.e164.arpa points their SBC. 3. I decide Foo Telco is better for me, so I port my number to Foo, hence Foo becomes the new carrier-of-record for my number and thus has the right to change 6.6.9.9.5.carrier.3.4.e164.arpa to point to the Foo SBC. Example 2: I have number +1 571.123.4567, which is in a US NPA, which happens to use the scheme I laid out. I assume that location for the +1 CC to be at 4, after the NPA. 1. I have a user ENUM domain: 7.6.5.4.3.2.1.1.7.5.1.e164.arpa - nothing special here. 2. My telco X chooses to interconnect on IP with others, among them TA and Foo, using our scheme, so she would enter their SBC information in the 7.6.5.4.3.2.1.carrier.1.7.5.1.e164.arpa zone. Since all this assumed to be well-known, a call to +1 571.123.4567 originating from some other TA or Foo POTS subscriber could be be passed to X on IP, and vice versa. When X, Foo and TA eventually grow up, and decide to dump interconnect completely, they can switch to just interpret User ENUM records. Or both, as and when they see fit. Sun-Tsu says: "for the fleeing enemy, build a silver bridge." At no point there is any interference between the subtrees, and a single lookup gets at any NAPTR. User-to-user between +43 59966.* and +1 571.123.4567 works as per rfc3761. Michael http://www.enum.at/ietf/draft-haberler-carrier-enum-00.html ps: In practice, carrier records probably would point to carrier nameservers, and RR's would be in the zone hosted there, but that makes no difference. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@inode.at Sat, 09 Jul 2005 04:33:09 -0400 From: Michael Haberler Date: Sat, 09 Jul 2005 04:33:09 -0400 To: "Michael Hammer \(mhammer\)" Subject: RE: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris) In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3561194@xmb-rtp-20b.amer.cisco.com> Message-ID: <6.2.1.2.2.20050709102511.0441b5e0@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: R At 23:33 08.07.2005, Michael Hammer \(mhammer\) wrote: Following up on the question about hiding the points of interconnect between two carriers: 1. Does this mean that if party A has been assigned an ENUM number directly from a national authority and A tries to call party B that got his number from a carrier X in club Y, that the ENUM query for the SBC to access carrier X will be null because A is not in club Y? A will be able to call B if B has opted in to User ENUM. If A, a "User", looks in the carrier tree for B, he will find X's SBC URI. The session setup to this URI will fail though. 2. Should the RR identifying the SBC to access carrier X contain both sip and sips URI? One for public access and one for private club access? If I scan the DNS would I find these URIs? sip or sips, they would be for "private club access". This doesnt prevent a carrier to leave their SBC/ALG openly accessible, but I dont expect that to happen frequently. You would find them in the DNS, but they will not be particularly interesting beyond giving the SBC/ALG URI. -Michael _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Sat, 09 Jul 2005 04:36:59 -0400 From: "Stastny Richard" Date: Sat, 09 Jul 2005 04:36:59 -0400 To: "Otmar Lendl" Subject: Re: [Enum] Agenda items for IETF Paris Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C00D@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Otmar made a very important point here: >As such, telephone numbers in an open numbering plan behave much more >like domain names: If I own example.com, then I can put a webserver >at example.com. I'm free to use foo.example.com, bar.foo.example.com >and whatnot as well, as long as I stay within the lenght limits imposed by >the DNS standard. and thats why DNS and E.164 fits so well together, as long as one sticks to the rules and does not invent or implement unnatural things (DNS-wise) e.g. cohabitation of zones. -richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Otmar Lendl Gesendet: Sa 09.07.2005 10:25 An: enum at ietf.org Betreff: Re: [Enum] Agenda items for IETF Paris On 2005/07/09 00:07, "Michael Hammer (mhammer)" wrote: > Michael, > > Could you elaborate more fully. Between the setup of IP PBX and the > assertion that my proposal makes something impossible, I didn't see any > explanation. It would help if you use a hypothetical E.164 number and > perhaps explain if this was provided through a carrier or not. Also, is > this extension being assigned an E.164 number also? Or is this grafting > a non-E.164 number onto an E.164 number? Would this require all > DNS-resolvers to continue searching beyond the E.164 tree? The misunderstanding here seems to be in open numbering plans nad how they relate to E.164 numbers. Michael gave some examples, I'd like to add a simple one. Our office in Vienna uses a simple ISDN BRI in point-to-point mode. The number is +43 1 5056416 which is a valid E.164 number that is dial- and reachable from the worldwide PSTN. But so is +43 1 5056416 33, +43 1 5056416 933, or +43 1 5056416 6, too. We, as the owner of the head number are free to design our own, variable length numbering plan behind that number as long as we stay within the length limit of E.164. Our telco will route calls to +43 1 5056416 [0-9]* to us and indicate in the call-setup what exactly the caller dialled. (I will not go into the territory of overlap dialing here, there is plenty of fun in the details.) All those locally defined extensions are valid E.164 numbers. There is no need to "continue searching beyond the E.164 tree", because we *are* still in the E.164 tree. As such, telephone numbers in an open numbering plan behave much more like domain names: If I own example.com, then I can put a webserver at example.com. I'm free to use foo.example.com, bar.foo.example.com and whatnot as well, as long as I stay within the lenght limits imposed by the DNS standard. To continue with the +43 1 5056416 example: The ISDN BRI is connected to a small cisco router on our side which translates all incoming calls to SIP. The numbering plan (the information which extensions exist and where they are routed) is stored in a small database which also drives the 6.1.4.6.5.0.5.1.3.4.e164.arpa zone. I can thus create new, valid E.164 numbers by a simple insert into that table. ENUM NAPTRs are instantly visible as well. There is real value in the fact that we have complete control over our ENUM zone. All this does not mix with carrier enum. Our carrier doesn't even know what numbers are in use behind our number. All he needs to know is "route everything matching /^4315056416.*/ in our direction". And basically that's the information our carrier has to put into any carrier ENUM tree. In ENUM terms, that will probably be something like $ORIGIN 6.1.4.6.5.0.5.1.carrier.3.4.e164.arpa @ 100 10 "u" "E2U+sip" "!(^.*)$!sip:\\1 at sbc.my-carrier.at!" . * 100 10 "u" "E2U+sip" "!(^.*)$!sip:\\1 at sbc.my-carrier.at!" . As for zone-sharing, I think the problem is obvious. /ol -- < Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From rich.shockey@neustar.biz Sat, 09 Jul 2005 15:47:41 -0400 From: Richard Shockey Date: Sat, 09 Jul 2005 15:47:41 -0400 To: "Stastny Richard" Subject: [Enum] Pre or Post Delegation Carrier ENUM In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C00C@oefeg-s04.oefeg.loc> Message-ID: <6.2.1.2.2.20050709151745.048c4c40@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 04:33 AM 7/9/2005, Stastny Richard wrote: >I don't think it a good idea to regulate where in the tree (e.g. after 3 >or 6 digits) to place carrier information.   First, there is no regulation, it is only a recommendation to put it after the cc, as Michael already pointed out   And for the avoidance of doubt:   the proposals c.c.carrier.e164.arpa and carrier.c.c.e614.arpa are technically (or DNS wise) completely equivalent well technically equivalent as far as the DNS is concerned, but they are radically different proposals if you are the poor schmuck that has to design a SIP proxy and call processing logic necessary to create a session.   It is also obvious that the first variant is more straightforward. Yes very much so  cc.carrier.164.arpa is no question the simplest to actually implement across any service providers network.  It directly draws on the simplicity of the First Well Known Rule as defined in RFC 3761. "The First Well Known Rule for this Application is the identity rule.    The output of this rule is the same as the input.  This is because    the E.164 namespace and this Applications databases are organized in    such a way that it is possible to go directly from the name to the    smallest granularity of the namespace directly from the name itself." from there the proxy, softswitch or CMS...,depending on your industry,  know exactly how to find either the user or "carrier" trees because all you have to do at that point is decide which database you want to use..  [RFC 3761 Section 2.4] 4. Append the string ".e164.arpa" to the end.  Example:       8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa The preference for the latter variant is simply because of practical administrative and political reasons. Yes there MAY be practical and political reasons for carrier.c.c.e164.arpa. As a wise man on this list remarked to me personally " I would prefer not to spend the remaining years of my career in Geneva." I am not convinced that the IAB-ITU rules on the use of e164.arpa need to be renegotiated in order to implement this proposal pre cc-delegation.  However technically it will be a total nightmare to implement post cc delegation in carrier.c.c.e164.arpa. The reason is simple. This will require every SS, proxy and CMS server to maintain internal tables necessary to decode the Application Unique String  [ RFC 3761  section 2.1] into its component parts ( in this case Country Code from the rest of the E.164 string) in order to be able decide on what database [Section 2.4 again] you want to use. Once upon a time ages and ages ago ..before there even was HTTP (aka stone age)  .  I designed IVR systems for Fax on Demand and the worst nightmare imaginable was defining these tables internally to the call processing logic. Now you are suggesting every proxy needs to somehow be able to decode 1 from 44 ( UK ) from 420 ( Czech from 380 (Ukraine) in order to write the correct FQDN. IMHO this will not happen. The effect on call set up could be significant.   In the second variant everything stays a national matter, in the first variant the debate on the  international level would start over again (2-3 years?), and then you have again the debate on the national level. With the second variant we jump over the international debate and can start immediately with the national debate. This is enough anyway. you wish ...   -richard   ________________________________ Von: enum-bounces at ietf.org im Auftrag von Michael Haberler Gesendet: Sa 09.07.2005 01:58 An: Michael Hammer (mhammer) Cc: enum at ietf.org Betreff: RE: [Enum] Agenda items for IETF Paris Michael, At 18:29 08.07.2005, Michael Hammer \(mhammer\) wrote: >I read your draft, but fail to see the need to define a new "carrier" >domain at any point in the tree.  Putting such a domain under the >country code only branches at a different point down the hierarchy. >You've only moved the problem next door. > >Two facts bound this problem as far as I can tell: >1:  A number is dialed and presented to the DNS client that then must >resolve it by traversing the tree from root on down to the last digit. >2:  Until you reach a given point in the tree (depending on national >authority assignments, e.g. 10K v 1K blocks) it is ambiguous whether the >number belongs to one carrier or another. > >I don't think it a good idea to regulate where in the tree (e.g. after 3 >or 6 digits) to place carrier information. I think there is a major misunderstanding what our proposal suggests. The 'carrier subdomain location' is about opening a complete new tree, at a flexible but globally interworking location in the e164.arpa tree because of the very cohabitation problems. It is a convention which needs to be published for interoperability, not a regulation. A well-known table is just one mechanism to do that, an appropriate RR in a standard place per country code could get rid of the table altogether. It is NOT the place where, for a given number, a particular "Carrier RR" is stored. I propose to unroll all number ranges fully and store RR's at the number level. I dont envisage delegations at some number block boundary - this again gets in the way with zone ownership when a number is ported out of a block - DNS semantics doesnt deal well with a "exception override" over a delegation boundary. If each number is entered in itself - no problem, because zone ownership for that number mirrors the changed carrier-of-record status. The rules are: - a carrier-of-record for a given number may populate the carrier subtree with this number, with RR's as she may see fit. - a user may populate the user tree as per 3761 (section 2 requirement 2 in our I-D) as he sees fit. - they are ships in the night - no need to coordinate between the two. The reason why the carrier subtree location needs to be flexible and cant be assumed under the country code is that "Country Code does not equal Numbering Plan Administration"  (that's by and large a fix for the colonies, as far as we're concerned over here  ;)) Resolving a tree digit-by-digit is bound to increase lookups drastically, violating our proposed "single DNS lookup to reach any NAPTR" requirement (section 2 requirement one). I guess I should give two examples. I assume the carrier subdomain location for the Austrian CC is 2, that is, right below the CC. Example 1: 1. I obtain a corporate network number from the national number administrator, so I am the number holder. Lets assume the number is +43 59966 .  Now I can enter that in User ENUM - and I'll have 6.6.9.9.5.3.4.e164.arpa delegated to my own name server - in the zone I have my SIP AOR for my PBX, and maybe lots of other stuff - we have an open numbering plan here and I could have anywhere from 0 to 8 extra DDI digits after +43 59966 for my users. I choose to manage all User ENUM entries in my nameserver. I choose not to care about any carrier records my carrier-of-record of the week might want to have.  I might not even be in the position to manage such a record in case my gear happens to not support that. 2. I turn around and ask Telekom Austria (TA) to route that number in the PSTN, which is when they become the carrier of record for my number. They happen to interconnect with other carriers with IP and choose to use the carrier ENUM tree under +43 to do that, but I could care less. Now they can enter that in the local carrier subtree: 6.6.9.9.5.carrier.3.4.e164.arpa points their SBC. 3. I decide Foo Telco is better for me, so I port my number to Foo, hence Foo becomes the new carrier-of-record for my number and thus has the right to change 6.6.9.9.5.carrier.3.4.e164.arpa to point to the Foo SBC. Example 2: I have number +1 571.123.4567, which is in a US NPA, which happens to use the scheme I laid out. I assume that location for the +1 CC to be at 4, after the NPA. 1.  I have a user ENUM domain: 7.6.5.4.3.2.1.1.7.5.1.e164.arpa - nothing special here. 2.  My telco X chooses to interconnect on IP with others, among them TA and Foo, using our scheme, so she would enter their SBC information in the 7.6.5.4.3.2.1.carrier.1.7.5.1.e164.arpa zone. Since all this assumed to be well-known, a call to +1 571.123.4567 originating from some other TA or Foo POTS subscriber could be be passed to X on IP, and vice versa. When X, Foo and TA eventually grow up, and decide to dump interconnect completely, they can switch to just interpret User ENUM records. Or both, as and when they see fit. Sun-Tsu says: "for the fleeing enemy, build a silver bridge." At no point there is any interference between the subtrees, and a single lookup gets at any NAPTR. User-to-user between +43 59966.* and +1 571.123.4567 works as per rfc3761. Michael http://www.enum.at/ietf/draft-haberler-carrier-enum-00.html ps: In practice, carrier records probably would point to carrier nameservers, and RR's would be in the zone hosted there, but that makes no difference. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at 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 < mailto:richard(at)shockey.us> or < mailto:richard.shockey(at)neustar.biz> < http://www.neustar.biz> ; < http://www.enum.org> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Sun, 10 Jul 2005 08:48:51 -0400 From: "Stastny Richard" Date: Sun, 10 Jul 2005 08:48:51 -0400 To: "Richard Shockey" Subject: Re: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C014@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Dear all, especially Allison Mankin, I consider this I-D very interesting, because I also proposed in the past to use the parameters defined in draft-ietf-iptel-tel-np-06.txt e.g. ";rn=" within ENUM, but did not bring this forward because of reason stated below. Before I comment on this draft and raise some questions, I would like to get some principle statements from our esteemed AD Allison if this draft is within the scope of IETF and ENUM WG. The rationale for this question is the following: The intended use of the Enumservice "npd:tel" is primarily for carriers, because only carriers my interpret and use the "rn= parameter. Routing numbers MUST NEVER be used by end-users. During the discussion Lawrence Conroy and I had with Ted Hardie and Allison Mankin in Geneva in May regarding the I-D draft-ietf-enum-msg-04.txt, especially about Enumservice "mms:mailto", I mentioned the fact that this Enumservice MAY also be used by carriers. Allison did not like this statement at all and said ENUM and Enumservices to-be-defined are ONLY for end-user usage. I only got over this hurdle by confirming that "mms:mailto" is ALSO useful for end-users. Therefore I want to have a clear statement from the responsible AD if an Enumservice for carrier use ONLY is within the scope of ENUM WG, before I waste my time in discussing this I-D on the list. Richard Stastny ________________________________ Von: enum-bounces at ietf.org im Auftrag von Richard Shockey Gesendet: Fr 08.07.2005 22:52 An: enum at ietf.org Betreff: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt >To: i-d-announce at ietf.org >From: Internet-Drafts at ietf.org >Date: Fri, 08 Jul 2005 15:50:01 -0400 >X-Spam-Score: 0.4 (/) >X-Scan-Signature: 73734d43604d52d23b3eba644a169745 >X-BeenThere: i-d-announce at ietf.org >X-Mailman-Version: 2.1.5 >Reply-To: internet-drafts at ietf.org >List-Id: i-d-announce.ietf.org >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >Sender: i-d-announce-bounces at ietf.org >X-SongbirdInformation: support at songbird.com for more information >X-Songbird: Found to be clean >X-Songbird-From: i-d-announce-bounces at ietf.org >Subject: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt >X-Keywords: > > > > >X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA11687 > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : IANA Registration for an Enumservice > Containing Number Portability and PSTN > Signaling Information > Author(s) : J. Livingood, R. Shockey > Filename : draft-livingood-shockey-enum-npd-00.txt > Pages : 8 > Date : 2005-7-8 > > This document registers the Enumservice "npd" and subtype "tel" using > the URI scheme 'tel:' as per the IANA registration process defined in > the ENUM specification, RFC 3761. This data is used to facilitate > the routing of telephone calls in those countries where Number > Portability exists. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-livingood-shockey-enum-npd-00.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request at 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-livingood-shockey-enum-npd-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 at ietf.org. >In the body type: > "FILE /internet-drafts/draft-livingood-shockey-enum-npd-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. > >Content-Type: text/plain >Content-ID: <2005-7-8104034.I-D at ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-livingood-shockey-enum-npd-00.txt > > > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce at ietf.org >https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Paul.Rosbotham@cwmsg.cwplc.com Sun, 10 Jul 2005 12:36:48 -0400 From: "Rosbotham, Paul" Date: Sun, 10 Jul 2005 12:36:48 -0400 To: "Stastny Richard" Subject: RE: [Enum] Agenda items for IETF Paris Message-ID: <9322B78036E1534A99B0BC51DEB0F9D60101BC91@GBCWSWIEM002.ad.plc.cwintra.com> MIME-Version: 1.0 Content-Type: text/plain Status: R ...but in the second variant it presupposes that the choices already made at a national level for user-ENUM are suitable/acceptable for carrier-ENUM. There are many locations where .e164.arpa delegations have proceeded upon a set of assumptions, and the system being used for wholesale PSTN replacement wasn't one of them (and, for the record, I'm not referring to the UK here, as the current delegation is only for trial purposes). Personally, I think the proposal is a good idea, but only in the c.c.carrier.e164.arpa guise : I don't regard carrier.c.c.e614.arpa as being workable. And yes, I know that means another N years of debate at ITU... Regards Paul -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of Stastny Richard Sent: Saturday, July 09, 2005 9:33 AM To: Michael Haberler; Michael Hammer (mhammer) Cc: enum at ietf.org Subject: Re: [Enum] Agenda items for IETF Paris >I don't think it a good idea to regulate where in the tree (e.g. after 3 >or 6 digits) to place carrier information. First, there is no regulation, it is only a recommendation to put it after the cc, as Michael already pointed out And for the avoidance of doubt: the proposals c.c.carrier.e164.arpa and carrier.c.c.e614.arpa are technically (or DNS wise) completely equivalent It is also obvious that the first variant is more straightforward. The preference for the latter variant is simply because of practical administrative and political reasons. In the second variant everything stays a national matter, in the first variant the debate on the international level would start over again (2-3 years?), and then you have again the debate on the national level. With the second variant we jump over the international debate and can start immediately with the national debate. This is enough anyway. -richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Michael Haberler Gesendet: Sa 09.07.2005 01:58 An: Michael Hammer (mhammer) Cc: enum at ietf.org Betreff: RE: [Enum] Agenda items for IETF Paris Michael, At 18:29 08.07.2005, Michael Hammer \(mhammer\) wrote: >I read your draft, but fail to see the need to define a new "carrier" >domain at any point in the tree. Putting such a domain under the >country code only branches at a different point down the hierarchy. >You've only moved the problem next door. > >Two facts bound this problem as far as I can tell: >1: A number is dialed and presented to the DNS client that then must >resolve it by traversing the tree from root on down to the last digit. >2: Until you reach a given point in the tree (depending on national >authority assignments, e.g. 10K v 1K blocks) it is ambiguous whether the >number belongs to one carrier or another. > >I don't think it a good idea to regulate where in the tree (e.g. after 3 >or 6 digits) to place carrier information. I think there is a major misunderstanding what our proposal suggests. The 'carrier subdomain location' is about opening a complete new tree, at a flexible but globally interworking location in the e164.arpa tree because of the very cohabitation problems. It is a convention which needs to be published for interoperability, not a regulation. A well-known table is just one mechanism to do that, an appropriate RR in a standard place per country code could get rid of the table altogether. It is NOT the place where, for a given number, a particular "Carrier RR" is stored. I propose to unroll all number ranges fully and store RR's at the number level. I dont envisage delegations at some number block boundary - this again gets in the way with zone ownership when a number is ported out of a block - DNS semantics doesnt deal well with a "exception override" over a delegation boundary. If each number is entered in itself - no problem, because zone ownership for that number mirrors the changed carrier-of-record status. The rules are: - a carrier-of-record for a given number may populate the carrier subtree with this number, with RR's as she may see fit. - a user may populate the user tree as per 3761 (section 2 requirement 2 in our I-D) as he sees fit. - they are ships in the night - no need to coordinate between the two. The reason why the carrier subtree location needs to be flexible and cant be assumed under the country code is that "Country Code does not equal Numbering Plan Administration" (that's by and large a fix for the colonies, as far as we're concerned over here ;)) Resolving a tree digit-by-digit is bound to increase lookups drastically, violating our proposed "single DNS lookup to reach any NAPTR" requirement (section 2 requirement one). I guess I should give two examples. I assume the carrier subdomain location for the Austrian CC is 2, that is, right below the CC. Example 1: 1. I obtain a corporate network number from the national number administrator, so I am the number holder. Lets assume the number is +43 59966 . Now I can enter that in User ENUM - and I'll have 6.6.9.9.5.3.4.e164.arpa delegated to my own name server - in the zone I have my SIP AOR for my PBX, and maybe lots of other stuff - we have an open numbering plan here and I could have anywhere from 0 to 8 extra DDI digits after +43 59966 for my users. I choose to manage all User ENUM entries in my nameserver. I choose not to care about any carrier records my carrier-of-record of the week might want to have. I might not even be in the position to manage such a record in case my gear happens to not support that. 2. I turn around and ask Telekom Austria (TA) to route that number in the PSTN, which is when they become the carrier of record for my number. They happen to interconnect with other carriers with IP and choose to use the carrier ENUM tree under +43 to do that, but I could care less. Now they can enter that in the local carrier subtree: 6.6.9.9.5.carrier.3.4.e164.arpa points their SBC. 3. I decide Foo Telco is better for me, so I port my number to Foo, hence Foo becomes the new carrier-of-record for my number and thus has the right to change 6.6.9.9.5.carrier.3.4.e164.arpa to point to the Foo SBC. Example 2: I have number +1 571.123.4567, which is in a US NPA, which happens to use the scheme I laid out. I assume that location for the +1 CC to be at 4, after the NPA. 1. I have a user ENUM domain: 7.6.5.4.3.2.1.1.7.5.1.e164.arpa - nothing special here. 2. My telco X chooses to interconnect on IP with others, among them TA and Foo, using our scheme, so she would enter their SBC information in the 7.6.5.4.3.2.1.carrier.1.7.5.1.e164.arpa zone. Since all this assumed to be well-known, a call to +1 571.123.4567 originating from some other TA or Foo POTS subscriber could be be passed to X on IP, and vice versa. When X, Foo and TA eventually grow up, and decide to dump interconnect completely, they can switch to just interpret User ENUM records. Or both, as and when they see fit. Sun-Tsu says: "for the fleeing enemy, build a silver bridge." At no point there is any interference between the subtrees, and a single lookup gets at any NAPTR. User-to-user between +43 59966.* and +1 571.123.4567 works as per rfc3761. Michael http://www.enum.at/ietf/draft-haberler-carrier-enum-00.html ps: In practice, carrier records probably would point to carrier nameservers, and RR's would be in the zone hosted there, but that makes no difference. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Sun, 10 Jul 2005 13:15:40 -0400 From: "Stastny Richard" Date: Sun, 10 Jul 2005 13:15:40 -0400 To: "Rosbotham, Paul" Subject: Re: [Enum] Agenda items for IETF Paris Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C015@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R >...but in the second variant it presupposes that the choices already made at a national level for user-ENUM are suitable/acceptable for carrier->ENUM. No, it does not The entity responsible for the domain c.c.e164.arpa (e.g. the NRA, or Jim) is in charge of the domain, so this entity may decide to that the entity (e.f the Tier 1 registry) running c.c.e164.arpa must delegate carrier.c.c.e164.arpa to another entity (e.g. the carrier Tier 1 registry). Of course it may also decide to use the same entity. This is a national matter. -richard ________________________________ Von: Rosbotham, Paul [mailto:Paul.Rosbotham at cwmsg.cwplc.com] Gesendet: So 10.07.2005 18:36 An: Stastny Richard; Michael Haberler; Michael Hammer (mhammer) Cc: enum at ietf.org Betreff: RE: [Enum] Agenda items for IETF Paris ...but in the second variant it presupposes that the choices already made at a national level for user-ENUM are suitable/acceptable for carrier-ENUM. There are many locations where .e164.arpa delegations have proceeded upon a set of assumptions, and the system being used for wholesale PSTN replacement wasn't one of them (and, for the record, I'm not referring to the UK here, as the current delegation is only for trial purposes). Personally, I think the proposal is a good idea, but only in the c.c.carrier.e164.arpa guise : I don't regard carrier.c.c.e614.arpa as being workable. And yes, I know that means another N years of debate at ITU... Regards Paul -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of Stastny Richard Sent: Saturday, July 09, 2005 9:33 AM To: Michael Haberler; Michael Hammer (mhammer) Cc: enum at ietf.org Subject: Re: [Enum] Agenda items for IETF Paris >I don't think it a good idea to regulate where in the tree (e.g. after 3 >or 6 digits) to place carrier information. First, there is no regulation, it is only a recommendation to put it after the cc, as Michael already pointed out And for the avoidance of doubt: the proposals c.c.carrier.e164.arpa and carrier.c.c.e614.arpa are technically (or DNS wise) completely equivalent It is also obvious that the first variant is more straightforward. The preference for the latter variant is simply because of practical administrative and political reasons. In the second variant everything stays a national matter, in the first variant the debate on the international level would start over again (2-3 years?), and then you have again the debate on the national level. With the second variant we jump over the international debate and can start immediately with the national debate. This is enough anyway. -richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Michael Haberler Gesendet: Sa 09.07.2005 01:58 An: Michael Hammer (mhammer) Cc: enum at ietf.org Betreff: RE: [Enum] Agenda items for IETF Paris Michael, At 18:29 08.07.2005, Michael Hammer \(mhammer\) wrote: >I read your draft, but fail to see the need to define a new "carrier" >domain at any point in the tree. Putting such a domain under the >country code only branches at a different point down the hierarchy. >You've only moved the problem next door. > >Two facts bound this problem as far as I can tell: >1: A number is dialed and presented to the DNS client that then must >resolve it by traversing the tree from root on down to the last digit. >2: Until you reach a given point in the tree (depending on national >authority assignments, e.g. 10K v 1K blocks) it is ambiguous whether the >number belongs to one carrier or another. > >I don't think it a good idea to regulate where in the tree (e.g. after 3 >or 6 digits) to place carrier information. I think there is a major misunderstanding what our proposal suggests. The 'carrier subdomain location' is about opening a complete new tree, at a flexible but globally interworking location in the e164.arpa tree because of the very cohabitation problems. It is a convention which needs to be published for interoperability, not a regulation. A well-known table is just one mechanism to do that, an appropriate RR in a standard place per country code could get rid of the table altogether. It is NOT the place where, for a given number, a particular "Carrier RR" is stored. I propose to unroll all number ranges fully and store RR's at the number level. I dont envisage delegations at some number block boundary - this again gets in the way with zone ownership when a number is ported out of a block - DNS semantics doesnt deal well with a "exception override" over a delegation boundary. If each number is entered in itself - no problem, because zone ownership for that number mirrors the changed carrier-of-record status. The rules are: - a carrier-of-record for a given number may populate the carrier subtree with this number, with RR's as she may see fit. - a user may populate the user tree as per 3761 (section 2 requirement 2 in our I-D) as he sees fit. - they are ships in the night - no need to coordinate between the two. The reason why the carrier subtree location needs to be flexible and cant be assumed under the country code is that "Country Code does not equal Numbering Plan Administration" (that's by and large a fix for the colonies, as far as we're concerned over here ;)) Resolving a tree digit-by-digit is bound to increase lookups drastically, violating our proposed "single DNS lookup to reach any NAPTR" requirement (section 2 requirement one). I guess I should give two examples. I assume the carrier subdomain location for the Austrian CC is 2, that is, right below the CC. Example 1: 1. I obtain a corporate network number from the national number administrator, so I am the number holder. Lets assume the number is +43 59966 . Now I can enter that in User ENUM - and I'll have 6.6.9.9.5.3.4.e164.arpa delegated to my own name server - in the zone I have my SIP AOR for my PBX, and maybe lots of other stuff - we have an open numbering plan here and I could have anywhere from 0 to 8 extra DDI digits after +43 59966 for my users. I choose to manage all User ENUM entries in my nameserver. I choose not to care about any carrier records my carrier-of-record of the week might want to have. I might not even be in the position to manage such a record in case my gear happens to not support that. 2. I turn around and ask Telekom Austria (TA) to route that number in the PSTN, which is when they become the carrier of record for my number. They happen to interconnect with other carriers with IP and choose to use the carrier ENUM tree under +43 to do that, but I could care less. Now they can enter that in the local carrier subtree: 6.6.9.9.5.carrier.3.4.e164.arpa points their SBC. 3. I decide Foo Telco is better for me, so I port my number to Foo, hence Foo becomes the new carrier-of-record for my number and thus has the right to change 6.6.9.9.5.carrier.3.4.e164.arpa to point to the Foo SBC. Example 2: I have number +1 571.123.4567, which is in a US NPA, which happens to use the scheme I laid out. I assume that location for the +1 CC to be at 4, after the NPA. 1. I have a user ENUM domain: 7.6.5.4.3.2.1.1.7.5.1.e164.arpa - nothing special here. 2. My telco X chooses to interconnect on IP with others, among them TA and Foo, using our scheme, so she would enter their SBC information in the 7.6.5.4.3.2.1.carrier.1.7.5.1.e164.arpa zone. Since all this assumed to be well-known, a call to +1 571.123.4567 originating from some other TA or Foo POTS subscriber could be be passed to X on IP, and vice versa. When X, Foo and TA eventually grow up, and decide to dump interconnect completely, they can switch to just interpret User ENUM records. Or both, as and when they see fit. Sun-Tsu says: "for the fleeing enemy, build a silver bridge." At no point there is any interference between the subtrees, and a single lookup gets at any NAPTR. User-to-user between +43 59966.* and +1 571.123.4567 works as per rfc3761. Michael http://www.enum.at/ietf/draft-haberler-carrier-enum-00.html ps: In practice, carrier records probably would point to carrier nameservers, and RR's would be in the zone hosted there, but that makes no difference. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From rich.shockey@neustar.biz Sun, 10 Jul 2005 13:18:31 -0400 From: Richard Shockey Date: Sun, 10 Jul 2005 13:18:31 -0400 To: "Rosbotham, Paul" Subject: RE: [Enum] Agenda items for IETF Paris In-Reply-To: <9322B78036E1534A99B0BC51DEB0F9D60101BC91@GBCWSWIEM002.ad.plc.cwintra.com> Message-ID: <6.2.1.2.2.20050710125527.0483b670@sb7.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 12:36 PM 7/10/2005, Rosbotham, Paul wrote: ...but in the second variant it presupposes that the choices already made at a national level for user-ENUM are suitable/acceptable for carrier-ENUM. There are many locations where .e164.arpa delegations have proceeded upon a set of assumptions, and the system being used for wholesale PSTN replacement wasn't one of them (and, for the record, I'm not referring to the UK here, as the current delegation is only for trial purposes). Personally, I think the proposal is a good idea, but only in the c.c.carrier.e164.arpa guise : I don't regard carrier.c.c.e614.arpa as being workable. Thank you .. I probably should have restated my technical issue more clearly .. c.c.carrier.e164.arpa only requires the choice of one DDDS data base tree vs 200 + if the rewrite rule required carrier.c.c.e164.arpa And yes, I know that means another N years of debate at ITU... Lets not prejudge our distinguished colleagues in Geneva. Regards Paul >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Paul.Rosbotham@cwmsg.cwplc.com Sun, 10 Jul 2005 16:12:01 -0400 From: "Rosbotham, Paul" Date: Sun, 10 Jul 2005 16:12:01 -0400 To: "Stastny Richard" Subject: RE: [Enum] Agenda items for IETF Paris Message-ID: <9322B78036E1534A99B0BC51DEB0F9D60101BC92@GBCWSWIEM002.ad.plc.cwintra.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >No, it does not >The entity responsible for the domain c.c.e164.arpa (e.g. the NRA, or Jim) is in charge of the domain, so this entity >may decide to that the entity (e.f the Tier 1 registry) running c.c.e164.arpa must delegate carrier.c.c.e164.arpa >to another entity (e.g. the carrier Tier 1 registry). Of course it may also decide to use the same entity. >This is a national matter. I respectfully disagree, Richard. Re-read what you have just written. What happens if Jim doesn't want to delegate carrier.c.c.e164.arpa to the entity that the carriers decide collectively they wish to use? For example, what if Jim's insistent that he will have carrier.c.c.e164.arpa and no-one else? Even worse, what if his contractual relationship is such that he's only allowed to make delegations of valid E.164 numbers translated to ENUM form? As far as I know reirrac isn't a valid number... Of course, I'm sure that Jim would be co-operative (not that he has the delegation in any case) - I'm not so sure in every other country where I provide the telephony service. _ This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Paul.Rosbotham@cwmsg.cwplc.com Sun, 10 Jul 2005 16:14:43 -0400 From: "Rosbotham, Paul" Date: Sun, 10 Jul 2005 16:14:43 -0400 To: "Richard Shockey" Subject: RE: [Enum] Agenda items for IETF Paris Message-ID: <9322B78036E1534A99B0BC51DEB0F9D60101BC93@GBCWSWIEM002.ad.plc.cwintra.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >>And yes, I know that means another N years of debate at ITU... >Lets not prejudge our distinguished colleagues in Geneva. Agree totally; as you're aware, for my sins I am one of said "distinguished colleagues", and understand well the concerns of my fellow Members and members, even if I don't always agree with them! This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@inode.at Sun, 10 Jul 2005 16:36:11 -0400 From: Michael Haberler Date: Sun, 10 Jul 2005 16:36:11 -0400 To: "Rosbotham, Paul" Subject: RE: [Enum] Agenda items for IETF Paris In-Reply-To: <9322B78036E1534A99B0BC51DEB0F9D60101BC92@GBCWSWIEM002.ad.plc.cwintra.com> Message-ID: <6.2.1.2.2.20050710222445.04ab4e90@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: R At 22:11 10.07.2005, Rosbotham, Paul wrote: I respectfully disagree, Richard. Re-read what you have just written. What happens if Jim doesn't want to delegate carrier.c.c.e164.arpa to the entity that the carriers decide collectively they wish to use? For example, what if Jim's insistent that he will have carrier.c.c.e164.arpa and no-one else? Even worse, what if his contractual This is a misunderstanding as to who has the right to populate the carrier subdomain. Please have a look at http://www.enum.at/ietf/draft-haberler-carrier-enum-00.html . The User ENUM tree as per 3761 may be populated by Jim. Jim, his resolver and his buddies need not be aware of any of the conventions laid out above. The Carrier ENUM tree - wherever located - may be populated by Jim's carrier of record, not by Jim - read this as: "either number range holder of Jim's number, or the recipient network where Jim ported his number to". If - lets call it a "national Carrier ENUM tree" - is located under .carrier.e164.arpa, carrier..e164.arpa, or carrier...e164.arpa is a per-Country Code national/NP area decision, not Jim's discretion. -Michael _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Nick.Russell@vodafone.com Mon, 11 Jul 2005 04:46:33 -0400 From: "Russell, Nick, VF UK - Technology \(TS\)" Date: Mon, 11 Jul 2005 04:46:33 -0400 To: "Sungwoo Shin" Subject: RE: [Enum] Re: Submission of new I-D regarding ENUM on mobile-web Message-ID: <6FC554FA1F33BE4C9AC844FC3B3B71280299114C@UKWMXM01> MIME-Version: 1.0 Content-Type: text/plain Status: R Dear Sungwoo,   I'm fairly new to this IETF list, so please bear with me while I clarify some things.   I've just read your draft and would like to clarify what it is you are proposing. Is it a method for the network for determining device capability i.e. when a device asks for a web page (by sending an HTTP request), the network operator performs an ENUM look-up on the E.164 number of the device, in order to determine how to serve the HTTP request? Or is it that you want to be able to enable devices to operate as "web servers" themselves and so allow for more seamless device-to-device communication? I'm thinking it's the former, but would just like to clarify before providing any feedback.   Thanks, Nick
From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Sungwoo ShinSent: 08 July 2005 00:12To: enum at ietf.orgSubject: [Enum] Re: Submission of new I-D regarding ENUM on mobile-web Dear members and colleagues   I had already some feedback from colleagues and the IETF secretariat  and reflected on the draft.  I am attaching the recently corrected one.   Thanks for your cooperation and I am looking forward to hearing any comment on this.   Sungwoo Shin  
----- Original Message -----
From: Sungwoo Shin To: enum at ietf.org Cc: YongWanJu ; rajy at nic.or.kr ; Conroy, Lawrence (SMTP) ; 김원 Sent: Wednesday, July 06, 2005 3:18 PM Subject: Submission of new I-D regarding ENUM on mobile-web Dear ENUM WG members   My colleagues and I am working on new Internet draft regarding ENUM usage on mobile terminal.  Alsp Mr. Conroy made contribution on this new I-D.   This draft concerns registration of mobile web-service   using URI scheme according to the guideline in RFC3761.   The number of mobile Internet users keeps growing and ENUM will be important service of mobile Internet.   Currently mobile web-services are provided in three different ways. WAP, ME and i-Mode. The document registers mobile web-service(mobiweb) as ENUMservices on three protocols.   I am attaching presentation and draft.   We expect to hear your precious comment and advice to reflect on the document before discussion in Paris meeting.     All the best   Sungwoo Shin ---------------------------------------------Sungwoo ShinResearch & Development TeamKorea Network Information CenterNational Internet Development Agency of KoreaOffice : +82-2-2186-4546Fax    : +82-2-2186-4496--------------------------------------------- _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@inode.at Mon, 11 Jul 2005 11:39:14 -0400 From: Michael Haberler Date: Mon, 11 Jul 2005 11:39:14 -0400 To: enum at ietf.org Subject: [Enum] code and maintainence complexity of combined user/carrier ENUM proposal Message-ID: <6.2.1.2.2.20050711171234.04d96f90@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: R To base the discussion on the incurred complexity of our I-D on facts, I have followed the seemingly outdated IETF practice of "running code" and built a example C implementation. I still need to document it and will post it later this week to this list. However I can say that: - my example includes BOTH the published "well known table" method as well as a variant where the subdomain location for a CC is stored as a TXT record in the .e164.arpa zone itself, thus making an external table with assumed "management complexity" *completely unnecessary* (while I havent laid that out in the I-D, I alluded to it. I'm open for better RR suggestions, including a new one). Of the example code (lots of comment, debug output etc) of some 400 lines - a total of 10 (ten) lines is specific to insertion of the carrier subdomain. - a total of 80 (eighty) lines is about retrieving the subdomain location, whereof some 15 are for scanning the well known table and alternatively some 60 are for retrieving the subdomain location by DNS lookup in the CC zone itself. That is a ballpark for the "code complexity". WRT to "table management complexity", let me reiterate: if we decide to publish the location record in the CC zone itself, there is no such thing as table management. A CC Administration decides to use this scheme, decides on location, enters the record in the cc.e164.arpa zone, DONE. While weighing this burden, I suggest to keep the potential upside of our proposal in mind, and that is a globally interworkable carrier ENUM tree - as opposed to forests of private tree arrangements, each serving random corners of the E.164 namespace. -Michael _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Mon, 11 Jul 2005 12:26:22 -0400 From: Jim Reid Date: Mon, 11 Jul 2005 12:26:22 -0400 To: Michael Haberler Subject: Re: [Enum] code and maintainence complexity of combined user/carrier ENUM proposal In-Reply-To: <6.2.1.2.2.20050711171234.04d96f90@localhost> Message-ID: <7947ac1b248cdad7ef0138377af8fda1@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R WRT to "table management complexity", let me reiterate: if we decide to publish the location record in the CC zone itself, there is no such thing as table management. A CC Administration decides to use this scheme, decides on location, enters the record in the cc.e164.arpa zone, DONE. Michael, I think you've overlooked something fundamental. IIUC, you're proposing that there's a "table" of operator names (or codes) immediately beneath .e164.arpa, right? How does my (Scottish) handset figure out what the names (or codes) exist for the telco operators in say Austria? Which one of these Austrian telcos is it supposed to prefer? How do I get my handset to pick a new preferred partner for calls to Austria whenever I port my number to another Scottish telco or if the preferred telco in Austria has been renamed (or gone bust)? BTW, the idea of putting this "table" into the DNS somehow is worth considering. This could be a very elegant solution to part of the problem. However I think it would need a new RRtype, one RR per operator/telco. Doing this with TXT records would be very bad. I can see other nasties when these hypothetical tables got too big: TCP queries to get the whole table; buffer overflows in clients; telcos/CSPs doing a land grab to get "cute" entries in the table; legacy clients failing to check/refresh this table; etc, etc. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From bhoeneis@switch.ch Mon, 11 Jul 2005 14:22:36 -0400 From: Bernie Hoeneisen Date: Mon, 11 Jul 2005 14:22:36 -0400 To: enum at ietf.org Subject: [Enum] New I/D concerning ENUM validation architecture submitted Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Dear ENUM WG, Axel and me have written an I/D, which we consider as the basis for the ENUM validation work currently carried out in the IETF. In this I/D we describe e.g. requirements, ENUM Provisioning Model and Roles, Validation Process Assumptions, and so on. The I/D also reflects experiences from our running implementations. This document can also be used as an introduction to ENUM domain name provisioning and in particular to ENUM validation related processes. Until it appears in the archieves, this I/D can also be downloaded from: * http://www.enum.at/ietf/draft-mayrhofer-enum-validation-arch-00.txt * http://www.enum.at/ietf/draft-mayrhofer-enum-validation-arch-00.html Abstract An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes validation requirements and a high level architecture for an ENUM validation infrastructure. cheers, Axel & Bernie _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From rich.shockey@neustar.biz Mon, 11 Jul 2005 17:41:09 -0400 From: Richard Shockey Date: Mon, 11 Jul 2005 17:41:09 -0400 To: enum at ietf.org Subject: [Enum] Fwd: I-D ACTION:draft-haberler-carrier-enum-00.txt Message-ID: <6.2.1.2.2.20050711173825.045bd500@mail.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R To: i-d-announce at ietf.org From: Internet-Drafts at ietf.org Date: Mon, 11 Jul 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-BeenThere: i-d-announce at ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts at ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces at ietf.org X-SongbirdInformation: support at songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: i-d-announce-bounces at ietf.org Subject: I-D ACTION:draft-haberler-carrier-enum-00.txt X-Keywords: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Combined User and Carrier ENUM in the e164.arpa tree Author(s) : M. Haberler, R. Stastny Filename : draft-haberler-carrier-enum-00.txt Pages : 10 Date : 2005-7-11 ENUM as defined now in RFC3761 is not well suited for the purpose of interconnection by carriers, as can be seen by the use of various private tree arrangements based on ENUM mechanisms. A combined end- user and carrier ENUM tree solution would leverage the ENUM infrastructure in e164.arpa, increase resolution rates, and decrease the cost per registered telephone number. This document describes a minimally invasive scheme to provide both end-user and carrier data in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-haberler-carrier-enum-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 at ietf.org. In the body type: "FILE /internet-drafts/draft-haberler-carrier-enum-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. Content-Type: text/plain Content-ID: <2005-7-11121301.I-D at ietf.org> ENCODING mime FILE /internet-drafts/draft-haberler-carrier-enum-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From rich.shockey@neustar.biz Mon, 11 Jul 2005 17:41:10 -0400 From: Richard Shockey Date: Mon, 11 Jul 2005 17:41:10 -0400 To: enum at ietf.org Subject: [Enum] Fwd: I-D ACTION:draft-mayrhofer-enum-validation-arch-00.txt Message-ID: <6.2.1.2.2.20050711173906.045bf720@mail.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R To: i-d-announce at ietf.org From: Internet-Drafts at ietf.org Date: Mon, 11 Jul 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: i-d-announce at ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts at ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces at ietf.org X-SongbirdInformation: support at songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: i-d-announce-bounces at ietf.org Subject: I-D ACTION:draft-mayrhofer-enum-validation-arch-00.txt X-Keywords: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ENUM Validation Architecture Author(s) : A. Mayrhofer, B. Hoeneisen Filename : draft-mayrhofer-enum-validation-arch-00.txt Pages : 16 Date : 2005-7-11 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called ^validation^. This document describes validation requirements and a high level architecture for an ENUM validation infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-validation-arch-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at 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-mayrhofer-enum-validation-arch-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 at ietf.org. In the body type: "FILE /internet-drafts/draft-mayrhofer-enum-validation-arch-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. Content-Type: text/plain Content-ID: <2005-7-11131359.I-D at ietf.org> ENCODING mime FILE /internet-drafts/draft-mayrhofer-enum-validation-arch-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From rich.shockey@neustar.biz Mon, 11 Jul 2005 17:41:10 -0400 From: Richard Shockey Date: Mon, 11 Jul 2005 17:41:10 -0400 To: enum at ietf.org Subject: [Enum] Fwd: I-D ACTION:draft-lendl-enum-validation-token-00.txt Message-ID: <6.2.1.2.2.20050711174021.045ab920@mail.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R To: i-d-announce at ietf.org From: Internet-Drafts at ietf.org Date: Mon, 11 Jul 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be X-BeenThere: i-d-announce at ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts at ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces at ietf.org X-SongbirdInformation: support at songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: i-d-announce-bounces at ietf.org Subject: I-D ACTION:draft-lendl-enum-validation-token-00.txt X-Keywords: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ENUM Validation Token Format Definition Author(s) : O. Lendl Filename : draft-lendl-enum-validation-token-00.txt Pages : 16 Date : 2005-7-11 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called ^validation^. This document describes an signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lendl-enum-validation-token-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lendl-enum-validation-token-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 at ietf.org. In the body type: "FILE /internet-drafts/draft-lendl-enum-validation-token-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. Content-Type: text/plain Content-ID: <2005-7-11124637.I-D at ietf.org> ENCODING mime FILE /internet-drafts/draft-lendl-enum-validation-token-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Mon, 11 Jul 2005 17:47:29 -0400 From: "Michael Hammer \(mhammer\)" Date: Mon, 11 Jul 2005 17:47:29 -0400 To: "Michael Haberler" Subject: RE: combined User and Carrier ENUM (was RE: [Enum] Agenda items for IETF Paris) Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3561488@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Michael, I did not assume anything. And yes I am aware of the variable length numbers in certain countries. Will your system work when every other 11 digit (+1-NPA-NXX-XXXX) number is ported to a different carrier? BTW, in the US there are 3000 plus carriers and growing. How many does Austria have? I suspect that there is some aspect to DNS operation that I haven't put my finger on that makes this difficult. I'm still not sure what exactly your one DNS lookup means since from what I understand several domain servers need to be queried to get a final response. I need to dig further. Mike > -----Original Message----- > From: Michael Haberler [mailto:mah at inode.at] > Sent: Friday, July 08, 2005 8:36 PM > To: Michael Hammer (mhammer) > Cc: enum at ietf.org > Subject: combined User and Carrier ENUM (was RE: [Enum] > Agenda items for IETF Paris) > > At 20:06 08.07.2005, Michael Hammer \(mhammer\) wrote: > > >Jim, > > > >I have yet to see a persuasive argument for why all the political > >requirement, control, manipulation, administration, policy, > ... aspects > >can't be built around a simple technical model. The administrative > >tail seems to be wagging the dog. > > Ah, I guess I see the knot... > > Could it be that you are assuming: > > - a closed numbering plan (fixed number length) > - maybe a scenario where all RR's are held in the Tier1 nameservers? > > and think about a scheme where authorization to enter a > particular record type at the number level could be given to > different parties ? > > that would probably work, BUT - not all countries have a > fixed numbering plan - among them Germany and Austria. Coming > back to my example: > > +43 59966 is a valid number, as is +43 59966-0 (a convention to reach > +the > switchboard). > +43 58866-12345678 is valid as well, and anything in between. > > In such a situation you would typically have a delegation at > +43 59966 to point to your own ("Tier3") nameservers. That is > in fact very useful - I'd have to check but I assume that > most PBX-type delegations under +43 use that scheme. As I > mentioned, actually enlightened IP PBX manufacturers use this method. > > I assume this to be incompatible with carrier type records at > or under +43 > 59966 - no carrier fiddling in user-operated zones, please. > > -Michael > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@inode.at Mon, 11 Jul 2005 18:01:32 -0400 From: Michael Haberler Date: Mon, 11 Jul 2005 18:01:32 -0400 To: Jim Reid Subject: Re: [Enum] code and maintainence complexity of combined user/carrier ENUM proposal In-Reply-To: <6.2.1.2.2.20050711171234.04d96f90@localhost> Message-ID: <6.2.1.2.2.20050711232850.04eb9bf0@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: R At 18:25 11.07.2005, Jim Reid wrote: WRT to "table management complexity", let me reiterate: if we decide to publish the location record in the CC zone itself, there is no such thing as table management. A CC Administration decides to use this scheme, decides on location, enters the record in the cc.e164.arpa zone, DONE. Michael, I think you've overlooked something fundamental. IIUC, you're proposing that there's a "table" of operator names (or codes) immediately beneath .e164.arpa, right? How does my (Scottish) handset figure out what the names (or codes) exist for the telco operators in say Austria? Which one of not at all, since I did not propose to enter operator names or codes in the tree structure in the first place (btw since I assume the carrier subtree would be used by carriers in their routing process, I dont expect your scenario to be very likely; as mentioned, user ENUM semantics remains as-is). A carrier-of-record for a number may enter this number in appropriate carrier tree. The link between carrier-of-record and number is held in the underlying registry database, just as the right-to-use for a number needs to be asserted there in the User ENUM scenario. Wether a "POI" type record of Carrier B can be reached or not by Carrier A I expect to be covered in arrangements between A and B, and can be decided at runtime since the domainname or address of an ALG/POI is globally unique. I could imagine though that a tag in the NAPTR like ";carrier-id=XXX" might help in the process to uncouple domain names from carrier identity, if that is deemed worthwile. BTW, the idea of putting this "table" into the DNS somehow is worth considering. This could be a very elegant solution to part of the problem. However I think it would need a new RRtype, one RR per operator/telco. Doing this with TXT records would be very bad. It works for my demo - I concur in reality a new RRtype would be in order. However, since the subdomain location is a CC/NPA and not an operator choice, only one RRtype is required. I can see other nasties when these hypothetical tables got too big: TCP queries to get the whole table; buffer overflows in clients; telcos/CSPs doing a land grab to get I dont see that problem - what I'm suggesting is a single record per cc/NPA in the *cc.e164.arpa* zone, which documents the choice for location of the carrier subtree for that cc/NPA, btw without any control fight about who is entering which record into which zone. A cc/NPA decides on a location, documents this by entering the record into *its* zone, and is done. The reason why I propose that is that it maps nicely onto the per-cc/NPA authority over the zone. Therefore the client searches for that record in the cc.e164.arpa zone, not at e164.arpa. To do so, the client may determine the length of the country code, and thus the location in the tree for that record, as laid out in http://mah.priv.at/tmp/draft-haberler-carrier-enum-00.html section 4, third to fifth paragraph - alternatively by checking against the authoritative list of country codes as per ITU website. I assume that list to be at hand, and current, by any organisation suspect of delivering some sort of telephony service. Claiming inability on that front is dismissed ;) Note that the boundary case "subdomainlocation = 0" covers the "Shockey scenario", namely .carrier.e164.arpa. Be my hero in Geneva, Rich... -Michael _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Mon, 11 Jul 2005 18:01:50 -0400 From: "Michael Hammer \(mhammer\)" Date: Mon, 11 Jul 2005 18:01:50 -0400 To: "Michael Haberler" Subject: RE: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris) Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3561491@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R But, now you have partitioned the PSTN into walled gardens. It should not be a requirement for party B to opt-in to User ENUM for the call to go through. If the caller is in Carrier ENUM, the call should still go through unless party B has blocked calls from party A. Mike > -----Original Message----- > From: Michael Haberler [mailto:mah at inode.at] > Sent: Saturday, July 09, 2005 4:33 AM > To: Michael Hammer (mhammer) > Cc: enum at ietf.org > Subject: RE: Carrier ENUM Definition (was RE: [Enum] Agenda > items forIETF Paris) > > At 23:33 08.07.2005, Michael Hammer \(mhammer\) wrote: > > >Following up on the question about hiding the points of interconnect > >between two carriers: > > > >1. Does this mean that if party A has been assigned an ENUM number > >directly from a national authority and A tries to call party > B that got > >his number from a carrier X in club Y, that the ENUM query > for the SBC > >to access carrier X will be null because A is not in club Y? > > A will be able to call B if B has opted in to User ENUM. The requirement should be that an ENUM lookup will reveal B's carrier's SBC. B should not have to opt-in to User ENUM for this to work. What happened to the one lookup requirement? > > If A, a "User", looks in the carrier tree for B, he will find > X's SBC URI. > The session setup to this URI will fail though. It should not fail, unless you want to force all users to have to user carriers. Mike > >2. Should the RR identifying the SBC to access carrier X > contain both > >sip and sips URI? One for public access and one for private club > >access? If I scan the DNS would I find these URIs? > > sip or sips, they would be for "private club access". This > doesnt prevent a carrier to leave their SBC/ALG openly > accessible, but I dont expect that to happen frequently. > > You would find them in the DNS, but they will not be > particularly interesting beyond giving the SBC/ALG URI. > > -Michael > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Mon, 11 Jul 2005 18:18:43 -0400 From: "Michael Hammer \(mhammer\)" Date: Mon, 11 Jul 2005 18:18:43 -0400 To: "Jim Reid" Subject: RE: [Enum] code and maintainence complexity of combined user/carrierENUM proposal Message-ID: <072C5B76F7CEAB488172C6F64B30B5E356149F@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R I thought that the DNS allowed us to avoid tables, e.g. hosts.txt. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Jim Reid > Sent: Monday, July 11, 2005 12:26 PM > To: Michael Haberler > Cc: enum at ietf.org > Subject: Re: [Enum] code and maintainence complexity of > combined user/carrierENUM proposal > > > WRT to "table management complexity", let me reiterate: if > we decide > > to publish the location record in the CC zone itself, there > is no such > > thing as table management. A CC Administration decides to use this > > scheme, decides on location, enters the record in the cc.e164.arpa > > zone, DONE. > > Michael, I think you've overlooked something fundamental. > IIUC, you're proposing that there's a "table" of operator > names (or codes) immediately beneath .e164.arpa, > right? How does my > (Scottish) handset figure out what the names (or codes) exist > for the telco operators in say Austria? Which one of these > Austrian telcos is it supposed to prefer? How do I get my > handset to pick a new preferred partner for calls to Austria > whenever I port my number to another Scottish telco or if the > preferred telco in Austria has been renamed (or gone bust)? > > BTW, the idea of putting this "table" into the DNS somehow > is worth considering. This could be a very elegant solution > to part of the problem. However I think it would need a new > RRtype, one RR per operator/telco. Doing this with TXT > records would be very bad. > > I can see other nasties when these hypothetical tables got > too big: TCP queries to get the whole table; buffer overflows > in clients; telcos/CSPs doing a land grab to get "cute" > entries in the table; legacy clients failing to check/refresh > this table; etc, etc. > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Mon, 11 Jul 2005 18:22:26 -0400 From: lconroy Date: Mon, 11 Jul 2005 18:22:26 -0400 To: Michael Haberler Subject: Re: [Enum] code and maintainence complexity of combined user/carrier ENUM proposal In-Reply-To: <6.2.1.2.2.20050711171234.04d96f90@localhost> Message-ID: <2534ac84e1fcaf276d8485593cb13af6@insensate.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Michael, Neat solution, IMHO. Yup - a new RRtype is needed, but it's only 1 for the world (with 1 instance per cc). On 12 Jul 2005, at 00:00, Michael Haberler wrote: Note that the boundary case "subdomainlocation = 0" covers the "Shockey scenario", namely .carrier.e164.arpa. Be my hero in Geneva, Rich... Rich - now the IPO's done, how long till you retire? I'm just trying to figure if the ITU will have completed the rehash before that point. all the best, Lawrence --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@inode.at Mon, 11 Jul 2005 18:50:33 -0400 From: Michael Haberler Date: Mon, 11 Jul 2005 18:50:33 -0400 To: "Michael Hammer \(mhammer\)" Subject: RE: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris) In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3561491@xmb-rtp-20b.amer.cisco.com> Message-ID: <6.2.1.2.2.20050712000457.04e41be0@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: R At 00:01 12.07.2005, Michael Hammer \(mhammer\) wrote: But, now you have partitioned the PSTN into walled gardens. Sorry if I was unclear - you are right, that wasnt what I intended to say. regarding scenario 1 (I'm unsure what you mean by "ENUM number" in that context): a) If A just obtains a number from the NP administrator, and has NOT subcribed to any carrier for routing that number in the PSTN, then A is relegated to the User ENUM scenario - in which case A will be able to call B if B has opted in to User ENUM and A resolves B in the User ENUM tree. b) if A is serviced by a carrier, and passes calls by some way (POTS, ISDN, IP) to him for delivery, then the call will obviously succeed through direct PSTN interconnect or carriers'carrier service delivering to X - standard PSTN case. b1) if A's carrier decides to resolve B's number in the carrier tree, finds the POI information for X, and has an agreement with X, then A's carrier will be able to pass the call to X on IP. b2) If A's carrier decides to resolve B's number in the carrier tree, finds the POI information for X, and has NO agreement with X, then A's carrier will probably pass the call to X via the PSTN (again direct PSTN interconnect or carriers'carrier service delivering to X). b3) If A's carrier decides to resolve in the carrier tree and doesnt find any POI information for X (= X doesnt user the carrier ENUm tree), again A's carrier will probably pass the call to X via the PSTN as above. It should not be a requirement for party B to opt-in to User ENUM for the call to go through. If the caller is in Carrier ENUM, the call should still go through unless party B has blocked calls from party A. It isnt a requirement, sorry - I hit send too fast and hoped nobody will notice ;) ... > At 23:33 08.07.2005, Michael Hammer \(mhammer\) wrote: > > >Following up on the question about hiding the points of interconnect > >between two carriers: > > > >1. Does this mean that if party A has been assigned an ENUM number > >directly from a national authority and A tries to call party > B that got > >his number from a carrier X in club Y, that the ENUM query > for the SBC > >to access carrier X will be null because A is not in club Y? > > A will be able to call B if B has opted in to User ENUM. The requirement should be that an ENUM lookup will reveal B's carrier's SBC. B should not have to opt-in to User ENUM for this to work. What happened to the one lookup requirement? Noted - it should say: one DNS lookup per tree (carrier or user) to resolve to a NAPTR. > If A, a "User", looks in the carrier tree for B, he will find > X's SBC URI. > The session setup to this URI will fail though. It should not fail, unless you want to force all users to have to user carriers. I'm confused - are you saying that just because *user* A has some way of determining the POI of *carrier* X (servicing B) then X is *required* to accept the call from *user* A? that's not how interconnection works - I guess this is a misunderstanding. Nobody is forced to use a carrier just because he owns a E.164 number (subject to local regulatory mileage) - but it helps reachability to the non-user ENUM enabled part of the E.164 space a lot. -Michael _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@inode.at Mon, 11 Jul 2005 18:53:39 -0400 From: Michael Haberler Date: Mon, 11 Jul 2005 18:53:39 -0400 To: "Michael Hammer \(mhammer\)" Subject: RE: [Enum] code and maintainence complexity of combined user/carrierENUM proposal In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E356149F@xmb-rtp-20b.amer.cisco.com> Message-ID: <6.2.1.2.2.20050712004904.04f18f50@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: R At 00:18 12.07.2005, Michael Hammer \(mhammer\) wrote: I thought that the DNS allowed us to avoid tables, e.g. hosts.txt. such as the succesful avoidance of the root.cache file, hm ;-) no seriously, I'm not ecstatic about the table approach either, which is why I'm looking at storing that information in the DNS proper. -Michael _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lendl@nic.at Tue, 12 Jul 2005 02:24:10 -0400 From: Otmar Lendl Date: Tue, 12 Jul 2005 02:24:10 -0400 To: enum at ietf.org Subject: Re: combined User and Carrier ENUM (was RE: [Enum] Agenda items for IETF Paris) In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3561488@xmb-rtp-20b.amer.cisco.com> Message-ID: <20050712062344.GA790@nic.at> MIME-Version: 1.0 Content-Type: text/plain Status: R On 2005/07/11 23:07, "Michael Hammer (mhammer)" wrote: > Michael, > > I did not assume anything. And yes I am aware of the variable length > numbers in certain countries. Will your system work when every other 11 > digit (+1-NPA-NXX-XXXX) number is ported to a different carrier? > BTW, in the US there are 3000 plus carriers and growing. How many does > Austria have? Michael, In Michael's I-D, the domain component "carrier" is meant as the literal sequence of the ascii characters c,a,r,r,i,e and r and not as a variable for which you substitute a real-life carrier name. It could just as well be "foobar", "c" or "death-to-ss7-interconnects". There is thus still one single tree per country (or NPA), and thus still a need for a registry who runs that tree and with which every carrier needs to interact to get its numbers into carrier ENUM. The number of carriers per country is thus irrelevant for the lookup procedure. /ol -- < Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Tue, 12 Jul 2005 05:43:23 -0400 From: Jim Reid Date: Tue, 12 Jul 2005 05:43:23 -0400 To: Michael Hammer Subject: Re: combined User and Carrier ENUM (was RE: [Enum] Agenda items for IETF Paris) In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3561488@xmb-rtp-20b.amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R I suspect that there is some aspect to DNS operation that I haven't put my finger on that makes this difficult. I'm still not sure what exactly your one DNS lookup means since from what I understand several domain servers need to be queried to get a final response. Michael, you seem to be confused how DNS lookups work. I hope this explanation helps. An application makes a DNS lookup by sending a query to some local name server. This is known as the stub resolver in DNS jargon: it formats a packet, sends it and waits for a reply. That's all. The local name server -- full service resolver in DNS jargon -- sends a response back. If it can't answer from its cache, the local name server will make iterative queries to resolve the stub resolver's query. Conceptually, it does that by starting at the root and working its way down the tree. In ENUM, this would be querying the .arpa name servers, then the e164.arpa name servers and so on. This full service resolver will not go off and query other branches of the tree. That is no DNS implementation has logic which says "if the name doesn't exist under foo.bar, try resolving this in some other incantation of foo.bar or in some other domain name entirely". In other words, the full service resolver terminates the iterative lookups when it gets an answer or gives up because the remote name servers are non-responsible or unresolvable. That answer can of course be "the name/query type you looked up does not exist". Whatever result the full service resolver gets is then returned to the stub resolver that made the initial query. Of course the application could have logic that says "if there are no NAPTRs for this number in e164.arpa, try querying for them in some other domain name". If it did, that second lookup would go to the full service resolver and go through the same iterative process as before. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@inode.at Tue, 12 Jul 2005 09:50:37 -0400 From: Michael Haberler Date: Tue, 12 Jul 2005 09:50:37 -0400 To: enum at ietf.org Subject: [Enum] combined user/carrier ENUM proposal - proof of concept implementation Message-ID: <6.2.1.2.2.20050712154609.04fce1b8@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: R as announced - here is the proof-of-concept C implementation of our draft http://www.enum.at/ietf/draft-haberler-carrier-enum-00.html . Files for perusal: http://mah.priv.at/enum/dist/ The tarball is at: http://mah.priv.at/enum/c-enum-dist.tar.gz -Michael --- dist/README : Combined Carrier and User ENUM under e164.arpa ---------------------------------------------- This is my example implementation of our I-D as outlined in http://www.enum.at/ietf/draft-haberler-carrier-enum-00.html . Beyond the described table-driven method this program experimentally uses the DNS to announce the carrier subdomain location in the relevant zone itself - for now by an integer value carried in a TXT RR named 'subdomainlocation' by default. I've set up a e164.mah.priv.at 'miniworld' under e164.mah.priv.at, which is publically accessible. If you want to play with your own DNS setup: the zone files and named.conf fragment used for this are in the 'bind' subdirectory. The zones under mah.priv.at are open also for zone transfer. To compile and run the demo (see shell script demo.sh), type make demo The expected output is in 'demo.out'. The demo script executes 4 scenarios, with sample user and carrier NAPTR records; the latter's location either determined through the subdomain location table or the DNS TXT RR as described above. [c.]3.4.e164.mah.priv.at ('c' for 'carrier') [c.]1.7.5.1.e164.mah.priv.at [c.]0.1.8.7.8.e164.mah.priv.at 7.[c.]e164.mah.priv.at Installation notes ------------------ Compiles ok under Linux and cygwin32. Cygwin binary for Windows supplied, I assume you need to have cygwin32 environment set up for the DLL's to be present. I've neither tried to be most efficient, nor are error scenarios thoroughly checked - this is a proof-of-concept. An example subdomain location table is compiled in, in real use there would be some other mechanism to import the table. The only source file specific to the I-D is c-enum.c, the rest is support routines mostly for DNS. I've liberally reused code for DNS resolution from the iptel.org SIP Express Router distribution - thanks, guys. Suggestions/feedback welcome. Michael Haberler mah at inode.at 12-7-2005 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Tue, 12 Jul 2005 10:24:43 -0400 From: "Stastny Richard" Date: Tue, 12 Jul 2005 10:24:43 -0400 To: Subject: [Enum] Clarification on Carrier ENUM discussions Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C01E@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Dear all, following the current discussions on carrier ENUM, I have a serious problem with some issues raised So to clarify some issues: We have on one side User ENUM, which is used by end-users to find other end-users. We so not need to define requirements here and we do not need to discuss its purpose. On the other hand we have carrier ENUM. Carrier (or Infrastructure) ENUM is for carriers ONLY and ONLY carriers-of-record are allowed to enter information there and ONLY carriers may use the infromation, even if it may publicly available. Carier ENUM is required for carriers to announce their PoI (IP based or on the PSTN) to other carriers, with ENUM based technology, that is NAPTRs using Enumservices such as "sip", "mms:mailto" or eventually "npd:tel" To do so, different methods may be used. A. use any tree in any domain (e.g foo.bar). Carriers may do so on their own choice and are already doing so. The problem here is that many trees exists. If the carriers want to use a commonly agreed tree, they have two options: agree on any tree out of .arpa or use B. an additional (side) tree in .arpa here 3 technically equivalent options exists 1. use carrier.arpa 2. use carrier.e164.arpa 3. use carrier.c.c.e164.arpa For the avoidance of doubt, carrier could also be "c" od "foo" as Otmar pointed out and NOT the name of the carrier (the SPID) Any discussion of draft-haberler should restrict itself to the question where to put "carrier" or "c" or "foo" and how to find the proper side tree within the carriers ENUM client and NOT e.g. asking questions like: "How does my (Scottish) handset figure out what the names (or codes) exist for the telco operators in say Austria? Which one of these Austrian telcos is it supposed to prefer? How do I get my handset to pick a new preferred partner for calls to Austria whenever I port my number to another Scottish telco or if the preferred telco in Austria has been renamed (or gone bust)?" This question has nothing to do with the problem at hand not even with ENUM at all (not even in Scottland ;-) First: a handset (end-user) will never query carrier enum and even a telco querying carrier ENUM does not have to find out which telco to query or to prefer. ENU will give you this information. And a number may only be hosted by one telco at a time. -richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ppfautz@att.com Tue, 12 Jul 2005 10:33:36 -0400 From: "Pfautz, Penn L, NEO" Date: Tue, 12 Jul 2005 10:33:36 -0400 To: "Stastny Richard" Subject: RE: [Enum] Clarification on Carrier ENUM discussions Message-ID: <34DA635B184A644DA4588E260EC0A25A0AA1337A@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard: While I agree with your statement that only carriers will put information into carrier ENUM I would not want to foreclose the possibility that other non-carrier parties may be able to query it under certain circumstances. I'm not saying that this will be the common circumstance at least initially. Penn -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Stastny Richard Sent: Tuesday, July 12, 2005 10:28 AM To: enum at ietf.org Subject: [Enum] Clarification on Carrier ENUM discussions Dear all, following the current discussions on carrier ENUM, I have a serious problem with some issues raised So to clarify some issues: We have on one side User ENUM, which is used by end-users to find other end-users. We so not need to define requirements here and we do not need to discuss its purpose. On the other hand we have carrier ENUM. Carrier (or Infrastructure) ENUM is for carriers ONLY and ONLY carriers-of-record are allowed to enter information there and ONLY carriers may use the infromation, even if it may publicly available. Carier ENUM is required for carriers to announce their PoI (IP based or on the PSTN) to other carriers, with ENUM based technology, that is NAPTRs using Enumservices such as "sip", "mms:mailto" or eventually "npd:tel" To do so, different methods may be used. A. use any tree in any domain (e.g foo.bar). Carriers may do so on their own choice and are already doing so. The problem here is that many trees exists. If the carriers want to use a commonly agreed tree, they have two options: agree on any tree out of .arpa or use B. an additional (side) tree in .arpa here 3 technically equivalent options exists 1. use carrier.arpa 2. use carrier.e164.arpa 3. use carrier.c.c.e164.arpa For the avoidance of doubt, carrier could also be "c" od "foo" as Otmar pointed out and NOT the name of the carrier (the SPID) Any discussion of draft-haberler should restrict itself to the question where to put "carrier" or "c" or "foo" and how to find the proper side tree within the carriers ENUM client and NOT e.g. asking questions like: "How does my (Scottish) handset figure out what the names (or codes) exist for the telco operators in say Austria? Which one of these Austrian telcos is it supposed to prefer? How do I get my handset to pick a new preferred partner for calls to Austria whenever I port my number to another Scottish telco or if the preferred telco in Austria has been renamed (or gone bust)?" This question has nothing to do with the problem at hand not even with ENUM at all (not even in Scottland ;-) First: a handset (end-user) will never query carrier enum and even a telco querying carrier ENUM does not have to find out which telco to query or to prefer. ENU will give you this information. And a number may only be hosted by one telco at a time. -richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From rich.shockey@neustar.biz Wed, 13 Jul 2005 05:16:58 -0400 From: "Rich.shockey" Date: Wed, 13 Jul 2005 05:16:58 -0400 To: "Enum" Subject: [Enum] Re: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R +----------------------------------------------------+ Panda GateDefender has detected malicious content (Virus) in the following file: [Doll.cpl] W32/Bagle.AH.worm The file has been deleted to protect the network. 07/13/2005 09:10 +0100 www.pandasoftware.com +----------------------------------------------------+ >Lovely animals _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From dmm@1-4-5.net Wed, 13 Jul 2005 16:15:55 -0400 From: David Meyer Date: Wed, 13 Jul 2005 16:15:55 -0400 To: voipeer at lists.uoregon.edu Subject: [Enum] draft voipeer BOF agenda Message-ID: <20050713134813.GA23031@1-4-5.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary..32256.1122908375.multipart/mixed" Status: R --Boundary..32256.1122908375.multipart/mixed Content-Type: text/plain Content-Transfer-Encoding: 7bit Folks, Here's the current draft agenda for the voipeer BOF. Please note that the scheduled time is subject to change. I also have some draft materials for the BOF up on http://www.1-4-5.net/~dmm/IETF/IETF63/VOIPEER/agenda http://www.1-4-5.net/~dmm/IETF/IETF63/VOIPEER/problem_statement http://www.1-4-5.net/~dmm/IETF/IETF63/VOIPEER/problem_space As always, questions, comments, etc greatly appreciated. Thanks, Dave ---- VoIP Peering and Interconnect BOF (voipeer) THURSDAY, August 4, 2005, 1400-1630 (Afternoon Session I) ========================================================= CHAIR: David Meyer AGENDA o Administriva 5 minutes - Mailing list: majordomo at lists.uoregon.edu subscribe voipeer or visit http://darkwing.uoregon.edu/~llynch/voipeer.html - Scribe(s)? - Blue Sheets o Agenda Bashing 5 minutes Meyer o BOF Purpose and Objectives 10 minutes Meyer o Description of the Problem Space 10 minutes Meyer o SIPPING update/overview 10 minutes Camarillo o ENUM Update/Overview 10 minutes Shockey o Service Provider Perspectives 60 minutes Bill Woodcock (PCH) Martin Dolly (ATT) Jason Livingood (Comcast) Joao Damas (ISC) o Discussion 15 minutes o Next Steps 10 minutes Meyer Attachment: pgpknEJcBzVtQ.pgp Description: PGP signature _______________________________________________ enum mailing list enum at ietf.org --Boundary..32256.1122908375.multipart/mixed Content-Type: application/octet-stream; name="pgpknEJcBzVtQ.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgpknEJcBzVtQ.pgp" Content-Description: "https://www1.ietf.org/mailman/listinfo/enum" --Boundary..32256.1122908375.multipart/mixed-- From sdlind@att.com Wed, 13 Jul 2005 22:41:40 -0400 From: "Lind, Steven D, ALABS" Date: Wed, 13 Jul 2005 22:41:40 -0400 To: Subject: [Enum] draft I-D on Infrastructure ENUM Requirements Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R I've put together, from the various threads on this list as well as going through several documents, what I felt were the requirements people felt were important for infrastructure ENUM. I've gathered that into an Internet Draft which I will submit sometime tomorrow. It's too late for it to be announced for the Paris meeting, but I've posted a copy online at:   http://www.sdlind.com/draft-lind-infrastructure-enum-reqs-00.txt.   Health warning: the contents are raw and do not imply any consensus on *any* of the text.   Not to put words into Patrick's or Rich's mouths, but I think we're still at the green-lighting stage. So if there is something you feel is missing from the list, let me know. Let's wait a while before we start picking things apart. Once we have what we feel is a complete list, we can start discussing the individual items to see where we have consensus.   Steve   -------------------------------------------------------- Steven D. Lind, AT&T            Tel: 973-236-6787 180 Park Avenue, Rm. A201       Fax: 360-343-2875 Florham Park, NJ 07932          e-mail: sdlind at att.com --------------------------------------------------------   _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From rich.shockey@neustar.biz Thu, 14 Jul 2005 13:39:01 -0400 From: Richard Shockey Date: Thu, 14 Jul 2005 13:39:01 -0400 To: enum at ietf.org Subject: [Enum] Final Agenda items for IETF 63 Paris Message-ID: <6.2.1.2.2.20050712091704.04f2eeb0@wheresmymailserver.com> MIME-Version: 1.0 Content-Type: text/plain Status: R It looks like Friday AM. IETF 63 Telephone Number Mapping (ENUM) WG Agenda Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: Allison Mankin Mailing Lists: General Discussion:enum at ietf.org To Subscribe: enum-request at ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ AGENDA BASHING (5 min) 1. Review of the existing drafts - Ready to go top Last call ( 5-10 M ? ) Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-02.txt Pages : 29 Date : 2005-7-1 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is informational only, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-02.txt 2. Final disposition of IRIS EREG, hopefully to last call. ( 5 Min? ) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-00.txt 3. New/old work on enumservice registrations ( 20 M ) 3.1 Title : IANA Registration for Enumservice Voice Author(s) : R. Brandner, et al. Filename : draft-brandner-enum-voice-00.txt Pages : 12 Date : 2005-7-7 This document registers the ENUMservice ^voice^ (which has a defined sub-type ^tel^), as per the IANA registration process defined in the ENUM specification RFC3761. This service indicates that the contact held in the generated URI can be used to initiate an interactive voice (audio) call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enum-voice-00.txt 3.2 Title : IANA Registration for an Enumservice Containing Number Portability and PSTN Signaling Information Author(s) : J. Livingood, R. Shockey Filename : draft-livingood-shockey-enum-npd-00.txt Pages : 8 Date : 2005-7-8 This document registers the Enumservice "npd" and subtype "tel" using the URI scheme 'tel:' as per the IANA registration process defined in the ENUM specification, RFC 3761. This data is used to facilitate the routing of telephone calls in those countries where Number Portability exists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-livingood-shockey-enum-npd-00.txt 3.3 Title : IANA Registration for ENUMservice Mobile Webpage Author(s) : J. Ra, et al. Filename : draft-ra-shin-enum-mobileweb-00.txt Pages : Date : 2005-7-7 This document registers the ENUMservice ^mobweb^ using the URI schemes 'http:' and 'https:' as per the IANA registration process defined in the ENUM specification RFC3761. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ra-shin-enum-mobileweb-00.txt 4. ENUM Validation Issues. 3 Drafts 15 -20 4.1 ENUM Validation Architecture draft-mayrhofer-enum-validation-arch-00 Title : ENUM Validation Architecture Author(s) : A. Mayrhofer, B. Hoeneisen Filename : draft-mayrhofer-enum-validation-arch-00.txt Pages : 16 Date : 2005-7-11 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called ^validation^. This document describes validation requirements and a high level architecture for an ENUM validation infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-validation-arch-00.txt 4.2 "ENUM Validation Token Format Definition" - draft-lendl-enum-validation-token-00.txt Title : ENUM Validation Token Format Definition Author(s) : O. Lendl Filename : draft-lendl-enum-validation-token-00.txt Pages : 16 Date : 2005-7-11 An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called ^validation^. This document describes an signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lendl-enum-validation-token-00.txt 4.3 Bernie Hoeneisen http://ietf.hoeneisen.ch/draft-ietf-enum-validation-epp-00.txt http://ietf.hoeneisen.ch/draft-ietf-enum-validation-epp-00.html ################# 5. PART 2 1/2 hours. 3 Items The first order of business is to attempt to create some very basic common ground on what is the problem Carrier/Infrastructure/Private ENUM is trying to solve based on what we generally understand are the orthogonal interests of A. the E.164 number holder vs B. the carrier of record for that number. In addition try to place this problem statement in the over all context of converged carrier networks and the desire for interconnection and peering. We are NOT going to solve the Carrier ENUM definition and problem statement in Paris but there needs to be some baseline before we can generally review the drafts at hand. Steve Lind has attempted to capture some of the ongoing discussion. This was not ready before the ID cut off but anyone coming to Paris is encouraged to read and comment on this ID on the list. http://www.sdlind.com/draft-lind-infrastructure-enum-reqs-00.txt ################# Discussion of Pfautz etal drafts on Carrier ENUM - Requirements ? Title : IANA Carrier/User enumservice Registration Author(s) : P. Pfautz, et al. Filename : draft-pfautz-lind-enum-carrier-user-00.txt Pages : 10 Date : 2005-6-6 This document registers, pursuant to the guidelines in RFC 3761, tElephone NUmber Mapping (ENUM) services to allow a single registry to support end user and carrier services with independent name servers holding the terminal NAPTR (Naming Authority Pointer) records identifying the communication services for each. The to-be- registered enumservices make use of non-terminal NAPTR records and DDDS (Dynamic Delegation Discovery System) replacement to achieve this end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pfautz-lind-enum-carrier-user-00.txt "Combined User and Carrier ENUM in the e164.arpa tree" Title : Combined User and Carrier ENUM in the e164.arpa tree Author(s) : M. Haberler, R. Stastny Filename : draft-haberler-carrier-enum-00.txt Pages : 10 Date : 2005-7-11 ENUM as defined now in RFC3761 is not well suited for the purpose of interconnection by carriers, as can be seen by the use of various private tree arrangements based on ENUM mechanisms. A combined end- user and carrier ENUM tree solution would leverage the ENUM infrastructure in e164.arpa, increase resolution rates, and decrease the cost per registered telephone number. This document describes a minimally invasive scheme to provide both end-user and carrier data in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Non-Terminal NAPTR Processing: A Modest Proposal Author(s) : L. Conroy Filename : draft-conroy-enum-modestproposal-00.txt Pages : 12 Date : 2005-7-6 Recent Discussions within the IETF and in other fora have highlighted differences in interpretation of the set of standards associated with ENUM and DDDS, on which it relies. Specifically, the operation and semantics surrounding support for non-terminal NAPTRs has led to some confusion. This document is an attempt to add clarification to non- terminal NAPTR processing. In this, it clarifies RFC3403. A subsequent document will build on this one to extend RFC3761 further, permitting registration of non-terminal Enumservices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-conroy-enum-modestproposal-00.txt 6. Discussion of ENUM WG recharter ? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Thu, 14 Jul 2005 16:47:47 -0400 From: "Stastny Richard" Date: Thu, 14 Jul 2005 16:47:47 -0400 To: "Lind, Steven D, ALABS" Subject: Re: [Enum] draft I-D on Infrastructure ENUM Requirements Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C027@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Thanks Steve, for doing this job, well done. I propose this document also as input to the VoIP peering BoF -richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Lind, Steven D, ALABS Gesendet: Do 14.07.2005 04:41 An: enum at ietf.org Betreff: [Enum] draft I-D on Infrastructure ENUM Requirements I've put together, from the various threads on this list as well as going through several documents, what I felt were the requirements people felt were important for infrastructure ENUM. I've gathered that into an Internet Draft which I will submit sometime tomorrow. It's too late for it to be announced for the Paris meeting, but I've posted a copy online at: http:// www.sdlind.com/draft -lind-infrastructure-enum-reqs-00.txt. Health warning: the contents are raw and do not imply any consensus on *any* of the text. Not to put words into Patrick's or Rich's mouths, but I think we're still at the green-lighting stage. So if there is something you feel is missing from the list, let me know. Let's wait a while before we start picking things apart. Once we have what we feel is a complete list, we can start discussing the individual items to see where we have consensus. Steve -------------------------------------------------------- Steven D. Lind, AT&T Tel: 973-236-6787 180 Park Avenue, Rm. A201 Fax: 360-343-2875 Florham Park, NJ 07932 e-mail: sdlind at att.com -------------------------------------------------------- _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From james.f.baskin@verizon.com Thu, 14 Jul 2005 19:03:29 -0400 From: james.f.baskin@verizon.com Date: Thu, 14 Jul 2005 19:03:29 -0400 To: enum at ietf.org Subject: [Enum] E.164 communication assumptions/requirements Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Steve Lind and the enum wg mailing list - I don't know if the following material belongs with the requirements list Steve has compiled, but I thought it might be useful for everyone to consider these items. In the long term, these items may have little relevance, but I would like to hear reasoned discussion from anyone who thinks that they do not or should not apply in the near term. Jim Baskin = = = = = = = = = = Some E.164 assumptions/requirements/principles (concentrating on voice communication and the reasonably near future): - A significant portion of the world's population will continue to depend on PSTN-based voice telephony service available for years to come. - E.164 telephone numbers within geographic country codes will continue to be assigned by numbering administration entities authorized by the governments of those countries. The administrators will assign blocks of numbers or individual numbers to ^carriers^ or ^service providers^ for subsequent assignment to end users. Some administrators might also be given the authority to assign numbers directly to individual end users. - All E.164 numbers should be callable from the PSTN. Someone using a PSTN-connected telephone with a keypad or a rotary dial should be able to place a call to any other end user who has voice telephone service that has been assigned an E.164 number. It should not matter what underlying technology is used to provide the voice service to the called user -- wireline, wireless, satellite, VoIP, etc. - There should be no ^islands^ of E.164 numbers that are unreachable from users of other E.164 numbers. ENUM-specific assumptions/requirements/principles: - There should be no E.164 numbers that can be reached only by ENUM-enabled call originators. - An E.164 number that exists in e164.arpa should be callable with no need for an originating PSTN user or carrier to perform an ENUM query. Standard PSTN call origination should always work, although the terminating carrier may need to do an ENUM query to complete the call. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Nick.Russell@vodafone.com Fri, 15 Jul 2005 05:46:23 -0400 From: "Russell, Nick, VF UK - Technology \(TS\)" Date: Fri, 15 Jul 2005 05:46:23 -0400 To: Subject: [Enum] Comments on ID on new ENUM service "mobileweb" Message-ID: <6FC554FA1F33BE4C9AC844FC3B3B7128029911ED@UKWMXM01> MIME-Version: 1.0 Content-Type: text/plain Status: R Dear All, Having read the ID draft-ra-shin-enum-mobileweb-00 my interpretation of it is that it is used by network equipment to determine which web "protocol" (in the loosest terms) a device supports by looking up the E.164 number associated with it in the ENUM/DNS. If my assumption is wrong, please tell me. Otherwise, I see a number of scenarios where this will fail and/or not be viable, particularly in GSM/UMTS. In GSM/UMTS, the E.164 number (or the "MSISDN") is NOT associated with a device, it is associated with an IMSI (International Mobile Subscriber Identity). The IMSI is stored in the network and on the UICC (Universal Integrated Circuit Card) which has a SIM application on it. Such a chip is more commonly known as a "SIM card", and can be moved freely between different hand-sets by the user at any time they choose. This therefore allows the user to change their handset whenever they like, *without informing the network*! Such a different handset could support a different "mobileweb" sub-type e.g. if I move my SIM card from my SonyEricsson V800 to an HP iPAQ. How are such updates going to be catered for in the ENUM/DNS? Static configuration by a human will not suffice so I presume your thinking is that the ENUM/DNS could be dynamically updated when the user turns on the phone (i.e. the network detects a new handset and alters the ENUM fields appropriately). Today, operators currently cater for different devices by examining the IMEI (International Mobile Equipment Identity) when the subscriber establishes the data session (GPRS session). This IMEI value is used as a key to a look-up table to determine such things as screen size, colour depth, WAP browser capabilities (and however strict the WAP specs are, there ARE differences in implementations of WAP browsers between mobile handset manufacturers) etc. We then cache this information for the life time of the data session. This cache value is therefore dependant on the protocol layers below the IP layer. Now, from what is being proposed in the ID in question, it seems everything is going to be done at the IP layer (and above). Presuming there is some undocumented dynamic way to update the "mobileweb" service field (such as that described above), the TTL of the DNS resource records are going to have to be fairly low in order to account for the times when a subscriber changes his handset/device, as a DNS TTL can't be set to expire when the user decides to turn-off his handset. Now let's consider another service. Multi-SIM. This essentially allows subscribers to "share" an E.164 number and is achieved by the network storing the same MSISDN for a two or more IMSIs. So if there are, say, two subscribers sharing the same MSISDN but both using different handsets, and they both request a mobile web page of some sort within a few seconds of each other, one subscriber will get the correctly formatted page and the other won't. So in conclusion, I don't believe this ID serves it's intended purpose due to the two facts of: 1) DNS cache time can't be matched to a time period of the user's preferred time of using the same handset (at least, without setting a very low DNS cache time which is bad DNS design). 2) There is not always a one-to-one mapping between E.164 number and mobile device. In my mind, a better idea would be to create a whole new DDDS application (is that the right term?) that uses IMEIs as the input instead of E.164 numbers and re-write the general DNS caching rules (!) to specify lower layer protocol events as expiration time (e.g. PDP Context deactivation), rather than an actual time period (e.g. 1 minute)! ;-) Cheers, Nick Russell _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Kim.Fullbrook@o2.com Fri, 15 Jul 2005 06:49:56 -0400 From: "Fullbrook Kim \(UK\)" Date: Fri, 15 Jul 2005 06:49:56 -0400 To: Subject: RE: [Enum] Comments on ID on new ENUM service "mobileweb" Message-ID: <0CD3FFEAEC982F489F872AB8DA32D624019D3E8B@Uksthmsx012> MIME-Version: 1.0 Content-Type: text/plain Status: R Nick Russell has already commented on the proposal and I would agree with much of what he says. My view is that the proposal uses DNS technology inappropriately, is easily broken and potentially there are better solutions available, although with development work required. These comments are from the point of view of a GSM operator. Equipment may work differently in a non-GSM network. It appears that the proposal is trying to store handset information in the DNS. This is a very bad idea for a number of reasons: - There is no easy way of updating the DNS with the new or updated handset information other than by a manual process. If you're going to update it in some automated fashion then you might as well do the job properly and enhance the EIR (Equipment Identity Register) whose job it is to record equipment details - In many countries operators sell SIMs only and users put them in their handsets. How does the DNS get updated ? - Mobile operators would be unhappy about the extra work required to provision this information and keep it updated - DNS has never been intended as a "real time" store for information. Even if the DNS did get updated there would be propagation delays as is usual with DNS - Many users frequently swap their SIM card between handsets. Again there is no way of updating the DNS with this information. - As Nick has already said there are operators with a service that allows one E.164 number to be associated with multiple devices. Updating the DNS with this information is not realistic. It's not clear to me how this proposal would deal with handsets then potentially can support more than one of Wap, Web, i-mode. A better way to deal with this sort of requirement and get a standardised implementation that everyone is happy with would be to take it to 3GPP or OMA. Another opportunity is created by the recent agreement by Icann to introduce the .mobi TLD. Use of this in URIs requested by users immediately shows that they want to use mobile format web pages rather than full size PC-optimised pages. Kim Fullbrook O2 UK -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Russell, Nick, VF UK - Technology (TS) Sent: 15 July 2005 10:46 To: enum at ietf.org Subject: [Enum] Comments on ID on new ENUM service "mobileweb" Dear All, Having read the ID draft-ra-shin-enum-mobileweb-00 my interpretation of it is that it is used by network equipment to determine which web "protocol" (in the loosest terms) a device supports by looking up the E.164 number associated with it in the ENUM/DNS. If my assumption is wrong, please tell me. Otherwise, I see a number of scenarios where this will fail and/or not be viable, particularly in GSM/UMTS. In GSM/UMTS, the E.164 number (or the "MSISDN") is NOT associated with a device, it is associated with an IMSI (International Mobile Subscriber Identity). The IMSI is stored in the network and on the UICC (Universal Integrated Circuit Card) which has a SIM application on it. Such a chip is more commonly known as a "SIM card", and can be moved freely between different hand-sets by the user at any time they choose. This therefore allows the user to change their handset whenever they like, *without informing the network*! Such a different handset could support a different "mobileweb" sub-type e.g. if I move my SIM card from my SonyEricsson V800 to an HP iPAQ. How are such updates going to be catered for in the ENUM/DNS? Static configuration by a human will not suffice so I presume your thinking is that the ENUM/DNS could be dynamically updated when the user turns on the phone (i.e. the network detects a new handset and alters the ENUM fields appropriately). Today, operators currently cater for different devices by examining the IMEI (International Mobile Equipment Identity) when the subscriber establishes the data session (GPRS session). This IMEI value is used as a key to a look-up table to determine such things as screen size, colour depth, WAP browser capabilities (and however strict the WAP specs are, there ARE differences in implementations of WAP browsers between mobile handset manufacturers) etc. We then cache this information for the life time of the data session. This cache value is therefore dependant on the protocol layers below the IP layer. Now, from what is being proposed in the ID in question, it seems everything is going to be done at the IP layer (and above). Presuming there is some undocumented dynamic way to update the "mobileweb" service field (such as that described above), the TTL of the DNS resource records are going to have to be fairly low in order to account for the times when a subscriber changes his handset/device, as a DNS TTL can't be set to expire when the user decides to turn-off his handset. Now let's consider another service. Multi-SIM. This essentially allows subscribers to "share" an E.164 number and is achieved by the network storing the same MSISDN for a two or more IMSIs. So if there are, say, two subscribers sharing the same MSISDN but both using different handsets, and they both request a mobile web page of some sort within a few seconds of each other, one subscriber will get the correctly formatted page and the other won't. So in conclusion, I don't believe this ID serves it's intended purpose due to the two facts of: 1) DNS cache time can't be matched to a time period of the user's preferred time of using the same handset (at least, without setting a very low DNS cache time which is bad DNS design). 2) There is not always a one-to-one mapping between E.164 number and mobile device. In my mind, a better idea would be to create a whole new DDDS application (is that the right term?) that uses IMEIs as the input instead of E.164 numbers and re-write the general DNS caching rules (!) to specify lower layer protocol events as expiration time (e.g. PDP Context deactivation), rather than an actual time period (e.g. 1 minute)! ;-) Cheers, Nick Russell _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum ===================================================== This electronic message contains information from O2 which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. ===================================================== _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Fri, 15 Jul 2005 07:29:35 -0400 From: Jim Reid Date: Fri, 15 Jul 2005 07:29:35 -0400 To: "Fullbrook Kim \(UK\)" Subject: Re: [Enum] Comments on ID on new ENUM service "mobileweb" In-Reply-To: <0CD3FFEAEC982F489F872AB8DA32D624019D3E8B@Uksthmsx012> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R On Jul 15, 2005, at 11:49, Fullbrook Kim ((UK)) wrote: It appears that the proposal is trying to store handset information in the DNS. This is a very bad idea for a number of reasons: - There is no easy way of updating the DNS with the new or updated handset information other than by a manual process. If you're going to update it in some automated fashion then you might as well do the job properly and enhance the EIR (Equipment Identity Register) whose job it is to record equipment details Wrong. Dynamic Update has been around since 1997. See RFC2136. Clients just send updates to the master name server. This technology is at the core of how Active Directory works (albeit in a somewhat bastardised form). There is no reason for manual intervention at all. DNS zones don't have to be managed with someone's favourite screen editor and/or a bunch of shell scripts. Putting the extra data in the EIR appears to makes sense. Buy why not put the EIR in the DNS? :-) - In many countries operators sell SIMs only and users put them in their handsets. How does the DNS get updated ? The handset could have a DNS client that makes DDNS (Dynamic DNS) requests. These can even be authenticated using the identifiers on the SIM card itself. Or if we're talking about the installed base, something in the telco's network could make the Dynamic DNS update on behalf of the handset whenever a SIM is introduced to the network. - DNS has never been intended as a "real time" store for information. Even if the DNS did get updated there would be propagation delays as is usual with DNS The DNS may not have been designed as a real-time store but it can certainly function as one. Though things like propagation delays and TTL values obviously need attention. These are not insurmountable. It's a straightforward matter of engineering the DNS infrastructure for the operational requirements. Even with off-the-shelf open source BIND -- the reference DNS implementation and not the best choice for carrier-class solutions -- some TLD registries are able to offer close to real-time propagation of registration changes. It would be even easier to do this for small zones with a handful of resource records: ie one per E.164 number. And it would be even easier still with DNS server software that was designed specifically for those kinds of problems. It would be good if we could capture the requirements and then build a DNS infrastructure to match them. That would settle the discussion about whether the DNS is or isn't up to the job. - Many users frequently swap their SIM card between handsets. Again there is no way of updating the DNS with this information. Well if the handset makes a DDNS request when it's powered on or the SIM changes.... Or if the network does that for them... _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Daniel.Schoettler@iqpc.de Fri, 15 Jul 2005 07:41:22 -0400 From: "Daniel Schoettler" Date: Fri, 15 Jul 2005 07:41:22 -0400 To: Subject: [Enum] ENUM-Event Europe Frankfurt/Germany Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R dear all,   first of all, i do not want to post an event or spam this mailing list! - me an my colleagues are about to organize an event under the topic "ENUM" my company iqpc organized the ENUM summit in miami this june.   we are looking for speakers in this event from all over the world and also for vendors who are able to sponsor this event.   if someone is interested in speaking or sponsoring, please do not hesitate to contact me.   best regards   daniel  
Daniel Schöttler Business Development Manager IQPC Gesellschaft für Management Konferenzen mbH Friedrichstrasse 94 D-10117 Berlin    ) +49 30 20 91 3-275 Ê +49 30 20 91 3-210 8 mailto:daniel.schottler at iqpc.de : http://www.iqpc.com/     Wissenswertes über IQPC IQPC zeichnet sich durch die Gestaltung von exklusiven Businesskongressen, Seminaren und One-to-One-Veranstaltungen aus. Seit 1973 vertrauen hunderttausende internationale Führungskräfte unseren Events: Sie steigern ihre Wettbewerbsfähigkeit und Rentabilität durch praxisorientierte Lösungsansätze, die durch namhafte Unternehmensvertreter im Rahmen unserer Veranstaltungen vermittelt werden. Führende Experten aus Wissenschaft und Praxis teilen ihre Erfahrungen mit unseren Teilnehmern in einer exklusiven Umgebung als ideale Networking-Plattform. Aus diesem Wissenspool schöpfen unsere Teilnehmer den erfolgsentscheidenden Informationsvorsprung. Unsere Niederlassungen befinden sich in Berlin, Johannesburg, London, New Jersey, New York, Singapur, Stockholm, Sydney und Toronto. Diese internationale Präsenz verleiht unserer Vision sowohl eine "globale Perspektive" als auch die Chance zur umfassenden Informationsgewinnung im internationalen Kontext.************************************************************************ This email is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of IQPC GmbH or any of its affiliates. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you have received this email in error please notify us by telephone on +49 (0)30 20 91 30. This footnote also confirms that this email message has been checked by anti-virus software for the presence of computer virii. However, IQPC GmbH accepts no responsibility for any virus or defect that might arise from opening this e-mail or attachments. ************************************************************************ _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Fri, 15 Jul 2005 12:42:17 -0400 From: "Stastny Richard" Date: Fri, 15 Jul 2005 12:42:17 -0400 To: "Lind, Steven D, ALABS" Subject: Re: [Enum] draft I-D on Infrastructure ENUM Requirements Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C02A@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Dear all, although Steve did a tremendous job here in such a short time, IMHO one important set of requirements is still missing in draft-lind-infrastructure-enum-reqs-00.txt, namely the Enumservices required for carrier (infrastructure) ENUM. The Enumservices required for User ENUM can easily be defined: since User ENUM is an optional service where an end-user may point to basically any service or application on the Internet he wants to have associated with his E.164 number, any Enumservice pointing to a valid URI may potentially be used. The underlying basic "PSTN" service provided for this E.164 number remains untouched. Even for E.164 numbers only existing in ENUM this is not a problem, because if these numbers are dialed on the PSTN, routed to a generic gateway and no compatible service exists, the valid response will be "service not available". This may also happen on the PSTN if you are calling a fax-machine and the calling party is not a fax-machine also. This situation is different for carrier ENUM. Here a minimum set of required Enumservices needs to be defined, depending on the intended usage of carrier ENUM This intended usage needs to be defined first. The problem here is the time-frame: 1. there is an immediate short-term need for carrier ENUM to allow peering of carrier networks a. for additional services currently not supported via conventianal signalling (e.g. MMS), b. to allow additional peering via IP-based technology for certain services between carreir able to do so, c. to allow carriers to use DNS-based technology for getting information required for number portability (e.g. routing numbers). These use cases need immediate solutions and implementations. Since one cannot expect here that ALL assigned E.164 numbers will be in Carrier ENUM at this time, and the PSTN as default still exists, the basic questions to be answered here are: what is the behaviour of a client if no corresponding entry is found, and even more important: what if an entry is found and the requested service is not contained in the NAPTRs retrieved? 2. There is a mid-term need to provide IP-based peering between 1. all networks using IP technology and then eventually also 2. between PSTN-networks 3. The final solution will be that some time in the future (I do not want now to discuss when, James;-) the default PSTN interconnection will cease to exist and ALL interconnections (peerings) will be IP-based. Latest at this time all E.164 numbers must be in ENUM and also a complete set of Enumservices must be available covering all required services. Side remark: sometimes between step 2 and 3 the basic addressing (naming) scheme used for routing between IP-based networks needs to be defined, and this IMHO cannot be E.164 based, it will be domain based. So E.164 numbering will change from the main naming scheme to an additional naming scheme. As a result, issues like "number portability" and routing numbers will go away. NP will be a simple change in database and routing numbers will not be needed at all. Resumee: Requirements for Infrastructure ENUM need to define which Enumservices are required for short-term step 1 immediately, because the second step will take some time. In a second step it is necessary first to define the requirements for "VoIP" peering (I have a problem with VoIP here) and derived from this the final set of Enumservices required. I will try to give some additional comments regarding this issue in reply to draft-livingood-shockey-enum-npd-00.txt Richard Stastny ________________________________ Von: enum-bounces at ietf.org im Auftrag von Lind, Steven D, ALABS Gesendet: Do 14.07.2005 04:41 An: enum at ietf.org Betreff: [Enum] draft I-D on Infrastructure ENUM Requirements I've put together, from the various threads on this list as well as going through several documents, what I felt were the requirements people felt were important for infrastructure ENUM. I've gathered that into an Internet Draft which I will submit sometime tomorrow. It's too late for it to be announced for the Paris meeting, but I've posted a copy online at: http:// www.sdlind.com/draft -lind-infrastructure-enum-reqs-00.txt. Health warning: the contents are raw and do not imply any consensus on *any* of the text. Not to put words into Patrick's or Rich's mouths, but I think we're still at the green-lighting stage. So if there is something you feel is missing from the list, let me know. Let's wait a while before we start picking things apart. Once we have what we feel is a complete list, we can start discussing the individual items to see where we have consensus. Steve -------------------------------------------------------- Steven D. Lind, AT&T Tel: 973-236-6787 180 Park Avenue, Rm. A201 Fax: 360-343-2875 Florham Park, NJ 07932 e-mail: sdlind at att.com -------------------------------------------------------- _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Sat, 16 Jul 2005 06:25:55 -0400 From: lconroy Date: Sat, 16 Jul 2005 06:25:55 -0400 To: Jim Reid Subject: Re: [Enum] Comments on ID on new ENUM service "mobileweb" In-Reply-To: <0CD3FFEAEC982F489F872AB8DA32D624019D3E8B@Uksthmsx012> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Folks, I have (unsurprisingly) looked through this draft more than once. I still can't see where it says (or could reasonably be interpreted as suggesting) that the end device capabilities are specified. Like *ALL* Enumservices, this is a hint to the end device what they will get if they use this URL, i.e. this kind of content using this kind of web service is available. As one example use-case, this content could be associated with a given telephone number - it could be a personal web page for the subscriber whose number has an ENUM registration, provisioned and/or available via this web service. It must be me, or the stuff someone is smoking. all the best, Lawrence On 15 Jul 2005, at 12:29, Jim Reid wrote: On Jul 15, 2005, at 11:49, Fullbrook Kim ((UK)) wrote: It appears that the proposal is trying to store handset information in the DNS. This is a very bad idea for a number of reasons: - There is no easy way of updating the DNS with the new or updated handset information other than by a manual process. If you're going to update it in some automated fashion then you might as well do the job properly and enhance the EIR (Equipment Identity Register) whose job it is to record equipment details Wrong. Dynamic Update has been around since 1997. See RFC2136. Clients just send updates to the master name server. This technology is at the core of how Active Directory works (albeit in a somewhat bastardised form). There is no reason for manual intervention at all. DNS zones don't have to be managed with someone's favourite screen editor and/or a bunch of shell scripts. Putting the extra data in the EIR appears to makes sense. Buy why not put the EIR in the DNS? :-) - In many countries operators sell SIMs only and users put them in their handsets. How does the DNS get updated ? The handset could have a DNS client that makes DDNS (Dynamic DNS) requests. These can even be authenticated using the identifiers on the SIM card itself. Or if we're talking about the installed base, something in the telco's network could make the Dynamic DNS update on behalf of the handset whenever a SIM is introduced to the network. - DNS has never been intended as a "real time" store for information. Even if the DNS did get updated there would be propagation delays as is usual with DNS The DNS may not have been designed as a real-time store but it can certainly function as one. Though things like propagation delays and TTL values obviously need attention. These are not insurmountable. It's a straightforward matter of engineering the DNS infrastructure for the operational requirements. Even with off-the-shelf open source BIND -- the reference DNS implementation and not the best choice for carrier-class solutions -- some TLD registries are able to offer close to real-time propagation of registration changes. It would be even easier to do this for small zones with a handful of resource records: ie one per E.164 number. And it would be even easier still with DNS server software that was designed specifically for those kinds of problems. It would be good if we could capture the requirements and then build a DNS infrastructure to match them. That would settle the discussion about whether the DNS is or isn't up to the job. - Many users frequently swap their SIM card between handsets. Again there is no way of updating the DNS with this information. Well if the handset makes a DDNS request when it's powered on or the SIM changes.... Or if the network does that for them... _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From pk@denic.de Sun, 17 Jul 2005 13:20:09 -0400 From: Peter Koch Date: Sun, 17 Jul 2005 13:20:09 -0400 To: enum at ietf.org Subject: Re: [Enum] Comments on ID on new ENUM service "mobileweb" In-Reply-To: <0CD3FFEAEC982F489F872AB8DA32D624019D3E8B@Uksthmsx012> Message-ID: <20050717171942.GA19724@denics7.denic.de> MIME-Version: 1.0 Content-Type: text/plain Status: R Lawrence, > I have (unsurprisingly) looked through this draft more than once. > I still can't see where it says (or could reasonably be interpreted > as suggesting) that the end device capabilities are specified. the paragraph If mobile web-serivce is registered as ENUMServices in accordance with RFC4002(IANA Registration for ENUMServices web and ft), it is very hard for a mobile service provider, terminal and its user to distinguish mobile webpage from general webpage. Moreover, there is no way to discriminat e the protocol(WAP, ME or i-mode) of mobile web-service to be supported by the terminal. *can* be read to suggest that the web server determines the client's capabilities to serve the best tailored "content" or presentation form. Part of the confusion might also originate from the term "mobile service provider", which is not a mobile provider but a provider of "mobile service", where again "mobile" does not relate to mobility but to the limited display capabilities of the mobile client device. Still I'm not sure I get the proposal right; aren't there other or better ways of capability negotiation? -Peter _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From rich.shockey@neustar.biz Sun, 17 Jul 2005 13:31:23 -0400 From: Richard Shockey Date: Sun, 17 Jul 2005 13:31:23 -0400 To: enum at ietf.org Subject: [Enum] Fwd: I-D ACTION:draft-lind-infrastructure-enum-reqs-00.txt Message-ID: <6.2.1.2.2.20050715183515.05d48490@mail.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R To: i-d-announce at ietf.org From: Internet-Drafts at ietf.org Date: Fri, 15 Jul 2005 10:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 X-BeenThere: i-d-announce at ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts at ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces at ietf.org X-SongbirdInformation: support at songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: i-d-announce-bounces at ietf.org Subject: I-D ACTION:draft-lind-infrastructure-enum-reqs-00.txt X-Keywords: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Infrastructure ENUM Requirements Author(s) : S. Lind Filename : draft-lind-infrastructure-enum-reqs-00.txt Pages : 8 Date : 2005-7-15 There has been much discussion in various industries about the concept of infrastructure (or carrier) ENUM. Some of this discussion has been has been reflected within the ENUM WG mailing list and some within other organizations, including ETSI, the US ENUM Forum and the Country Code 1 ENUM LLC. While there has been consensus within some pockets of individual efforts, there has been little consensus industry-wide on even what infrastructure ENUM is, why it seems to be important, or what the requirements for implementing it are. At the request of the WG co-chairs, this document attempts to gather together the bits and pieces from those discussions (i.e., I stole the words shamelessly from the various sources) and, with an absolute minimum of editing, present them in some sort of cohesive manner that will enable enlightened discussion and hopefully achieve consensus. Some items listed below may be duplicative and suggest alternative wordings for similar and other contradictory issues. As such, this list is very raw and should not be viewed as complete, cohesive or correct. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lind-infrastructure-enum-reqs-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at 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-lind-infrastructure-enum-reqs-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 at ietf.org. In the body type: "FILE /internet-drafts/draft-lind-infrastructure-enum-reqs-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. Content-Type: text/plain Content-ID: <2005-7-15103659.I-D at ietf.org> ENCODING mime FILE /internet-drafts/draft-lind-infrastructure-enum-reqs-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Sun, 17 Jul 2005 18:04:57 -0400 From: lconroy Date: Sun, 17 Jul 2005 18:04:57 -0400 To: Peter Koch Subject: Re: [Enum] Comments on ID on new ENUM service "mobileweb" In-Reply-To: <0CD3FFEAEC982F489F872AB8DA32D624019D3E8B@Uksthmsx012> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Peter, sorry - it just hadn't occurred to me that anyone could read it that way. (I should have asked you for a cigarette in the IDN Workshop in Luxembourg - it might have helped :) Without this scheme, the Mobile Service Provider has no *easy* way to indicate the kind of mobile protocol stack needed to retrieve it, the terminal has no way to guess what kind of mobile protocol to use, and the user can't guess either (well, they can, but from experience, with the help of said Mobile Service Provider's "Help" Desk, the user will probably make the wrong guess). As for capability negotiation - hmm. W3C are perfectly correct; one could use some more or less extended negotiation technique (even using DNS queries for URNs if it looks like the negotiation might complete before the end of the universe - see that proposal in the end of RFC3403 and in RFC3404 and RFC3405). If that doesn't generate enough revenue for Mobile Service Providers, then one could always begin with SIP capability negotiation before starting all that. However... As you know, mobile phones operate over "long" pipes. Even with the good capacity of 3G, the pipes are still long, and latency is the kicker for extended negotiation. The Enumservices in this draft are designed to tell the end user (and their terminal) exactly what content is available using what mobile protocol stack//program. Negotiation is not needed, as the story is already out as soon as the terminal does the ENUM query. Hence - in answer to your questions "are there other and better ways of capability negotiation?", I guess my answers are yes and no. With these Enumservices, the user and terminal already know their capability, and the Service Provider has already said in what forms and using what protocols the content is available. There is no capability negotiation needed, which is going to be quicker than any explicit exchange. As for a "Mobile Service Provider" being a provider of "Mobile Service" - well, yes, they do and are. So? I don't think I understand the point you are making. all the best, Lawrence On 17 Jul 2005, at 18:19, Peter Koch wrote: Lawrence, I have (unsurprisingly) looked through this draft more than once. I still can't see where it says (or could reasonably be interpreted as suggesting) that the end device capabilities are specified. the paragraph If mobile web-serivce is registered as ENUMServices in accordance with RFC4002(IANA Registration for ENUMServices web and ft), it is very hard for a mobile service provider, terminal and its user to distinguish mobile webpage from general webpage. Moreover, there is no way to discriminat e the protocol(WAP, ME or i-mode) of mobile web-service to be supported by the terminal. *can* be read to suggest that the web server determines the client's capabilities to serve the best tailored "content" or presentation form. Part of the confusion might also originate from the term "mobile service provider", which is not a mobile provider but a provider of "mobile service", where again "mobile" does not relate to mobility but to the limited display capabilities of the mobile client device. Still I'm not sure I get the proposal right; aren't there other or better ways of capability negotiation? -Peter _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From rich.shockey@neustar.biz Mon, 18 Jul 2005 04:13:19 -0400 From: "Rich.shockey" Date: Mon, 18 Jul 2005 04:13:19 -0400 To: "Enum" Subject: [Enum] Re: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R +----------------------------------------------------+ Panda GateDefender has detected malicious content (Virus) in the following file: [Doll.cpl] W32/Bagle.AH.worm The file has been deleted to protect the network. 07/18/2005 08:06 +0100 www.pandasoftware.com +----------------------------------------------------+ >The snake _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Nick.Russell@vodafone.com Mon, 18 Jul 2005 04:18:06 -0400 From: "Russell, Nick, VF UK - Technology \(TS\)" Date: Mon, 18 Jul 2005 04:18:06 -0400 To: "Ray Anderson" Subject: RE: [Enum] Comments on ID on new ENUM service "mobileweb" Message-ID: <6FC554FA1F33BE4C9AC844FC3B3B712802991211@UKWMXM01> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Ray, I agree with you that IMEI can stay the same while the browser changes. Especially if the phone is just being used as a modem for a laptop, for instance. My argument was more that the IMEI would perhaps give a *better* indication than the MSISDN e.g. default browser for the phone *currently* being used by the subscriber. Cheers, Nick P.S. Another reason why WAP push is used instead of MMS, is that it's more likely to get past any MMSC "spam" filters and/or adult content filters! ;-) > -----Original Message----- > From: Ray Anderson [mailto:ray at bango.com] > Sent: 16 July 2005 17:32 > To: Russell, Nick, VF UK - Technology (TS); enum at ietf.org > Cc: tim at bango.com > Subject: Re: [Enum] Comments on ID on new ENUM service "mobileweb" > > Nick, > > Using IMEI to determine browser capabilities is not a very > common practice. > > Very few content providers know the MSISDN let alone the IMEI. > > Moreover, the browser can easily change while the IMEI stays > static (e.g. > switching from the factory shipped browser to another, or by > using a browser proxy. > > I do know that a few operators have to take a guess at the > browser / phone type, because they want to send MMS messages, > which are best optimized to target device type. > > That's also one of the main reasons why Content Providers > have given MMS a wide berth and prefer to use WAP push or > equivalents to deliver multimedia services. > > Ray > > At 10:45 15/07/2005, Russell, Nick, VF UK - Technology \(TS\) wrote: > >Today, operators currently cater for different devices by > examining the > >IMEI (International Mobile Equipment Identity) when the subscriber > >establishes the data session (GPRS session). This IMEI value > is used as > >a key to a look-up table to determine such things as screen size, > >colour depth, WAP browser capabilities (and however strict the WAP > >specs are, there ARE differences in implementations of WAP browsers > >between mobile handset manufacturers) etc. We then cache this > >information for the life time of the data session. This > cache value is > >therefore dependant on the protocol layers below the IP layer. > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Kim.Fullbrook@o2.com Mon, 18 Jul 2005 08:14:46 -0400 From: "Fullbrook Kim \(UK\)" Date: Mon, 18 Jul 2005 08:14:46 -0400 To: Subject: RE: [Enum] Comments on ID on new ENUM service "mobileweb" Message-ID: <0CD3FFEAEC982F489F872AB8DA32D624019D3F8C@Uksthmsx012> MIME-Version: 1.0 Content-Type: text/plain Status: R There is a more fundamental problem with the use of Enumservices here which Ray Anderson's note mentions in passing. The MSISDN of a mobile surfer - whether Wap, web or whatever - would not normally be made available outside an operators network. There would be significant privacy concerns about doing this. Can you imagine the implications of surfing the Net from your phone and presenting your CLI to each and every web site ? In summary I can't see how the proposal could work for web providers because the MSISDN would not be available. A better solution would be that which was sent to me in a private email "I think it is more important that we encourage web site developers to make good use of the HTTP_ACCEPT header to provide optimum experience for different devices." (There's also the possibility that I may have interpreted the proposal incorrectly. It's a confusing I-D) -----Original Message----- ===================================================== This electronic message contains information from O2 which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. ===================================================== From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Russell, Nick, VF UK - Technology (TS) Sent: 18 July 2005 09:17 To: Ray Anderson; enum at ietf.org Cc: tim at bango.com Subject: RE: [Enum] Comments on ID on new ENUM service "mobileweb" Hi Ray, I agree with you that IMEI can stay the same while the browser changes. Especially if the phone is just being used as a modem for a laptop, for instance. My argument was more that the IMEI would perhaps give a *better* indication than the MSISDN e.g. default browser for the phone *currently* being used by the subscriber. Cheers, Nick P.S. Another reason why WAP push is used instead of MMS, is that it's more likely to get past any MMSC "spam" filters and/or adult content filters! ;-) > -----Original Message----- > From: Ray Anderson [mailto:ray at bango.com] > Sent: 16 July 2005 17:32 > To: Russell, Nick, VF UK - Technology (TS); enum at ietf.org > Cc: tim at bango.com > Subject: Re: [Enum] Comments on ID on new ENUM service "mobileweb" > > Nick, > > Using IMEI to determine browser capabilities is not a very > common practice. > > Very few content providers know the MSISDN let alone the IMEI. > > Moreover, the browser can easily change while the IMEI stays > static (e.g. > switching from the factory shipped browser to another, or by > using a browser proxy. > > I do know that a few operators have to take a guess at the > browser / phone type, because they want to send MMS messages, > which are best optimized to target device type. > > That's also one of the main reasons why Content Providers > have given MMS a wide berth and prefer to use WAP push or > equivalents to deliver multimedia services. > > Ray _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ray@bango.com Mon, 18 Jul 2005 08:23:55 -0400 From: Ray Anderson Date: Mon, 18 Jul 2005 08:23:55 -0400 To: enum at ietf.org Subject: Re: [Enum] E.164 communication assumptions/requirements In-Reply-To: Message-ID: <6.1.2.0.2.20050716173430.0c44a7e0@smtp.bango.net> MIME-Version: 1.0 Content-Type: text/plain Status: R At 00:03 15/07/2005, james.f.baskin at verizon.com wrote: - All E.164 numbers should be callable from the PSTN.  Someone using a PSTN-connected telephone with a keypad or a rotary dial should be able to place a call to any other end user who has voice telephone service that has been assigned an E.164 number. It should not matter what underlying technology is used to provide the voice service to the called user -- wireline, wireless, satellite, VoIP, etc. - There should be no ^islands^ of E.164 numbers that are unreachable from users of other E.164 numbers. I don't believe the above two things are ENUM requirements. There are applications being envisaged where the E.164 number is purely used as a key to ENUM data "stored in DNS".  There is no requirement that an E.164 number has to be "callable" as far as I know, and if it had to be, those applications would have to create "callable endpoints" which might be meaningless certain applications (e.g. what is delivered to a voice caller when the E.164 number refers to a video stream or a WAP page? Ray Anderson   CEO Bango   ray at bango.com    www.bango.com Mobile: +44 7768 454545  Fax: +44 20 7692 5558  Come and see Bango at Mobile Entertainment Summit 2005,  Hilton Universal City, Los Angeles, USA   27-28 July www.ihollywoodforum.com   _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ray@bango.com Mon, 18 Jul 2005 08:23:55 -0400 From: Ray Anderson Date: Mon, 18 Jul 2005 08:23:55 -0400 To: "Russell, Nick, VF UK - Technology \(TS\)" Subject: Re: [Enum] Comments on ID on new ENUM service "mobileweb" In-Reply-To: <6FC554FA1F33BE4C9AC844FC3B3B7128029911ED@UKWMXM01> Message-ID: <6.1.2.0.2.20050716172626.02f22eb0@smtp.bango.net> MIME-Version: 1.0 Content-Type: text/plain Status: R Nick, Using IMEI to determine browser capabilities is not a very common practice. Very few content providers know the MSISDN let alone the IMEI. Moreover, the browser can easily change while the IMEI stays static (e.g. switching from the factory shipped browser to another, or by using a browser proxy. I do know that a few operators have to take a guess at the browser / phone type, because they want to send MMS messages, which are best optimized to target device type. That's also one of the main reasons why Content Providers have given MMS a wide berth and prefer to use WAP push or equivalents to deliver multimedia services. Ray At 10:45 15/07/2005, Russell, Nick, VF UK - Technology \(TS\) wrote: Today, operators currently cater for different devices by examining the IMEI (International Mobile Equipment Identity) when the subscriber establishes the data session (GPRS session). This IMEI value is used as a key to a look-up table to determine such things as screen size, colour depth, WAP browser capabilities (and however strict the WAP specs are, there ARE differences in implementations of WAP browsers between mobile handset manufacturers) etc. We then cache this information for the life time of the data session. This cache value is therefore dependant on the protocol layers below the IP layer. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ppfautz@att.com Mon, 18 Jul 2005 08:46:35 -0400 From: "Pfautz, Penn L, NEO" Date: Mon, 18 Jul 2005 08:46:35 -0400 To: "Ray Anderson" Subject: RE: [Enum] E.164 communication assumptions/requirements Message-ID: <34DA635B184A644DA4588E260EC0A25A0AAB4DAE@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Ray: We could argue about whether these are ENUM requirements.  And use of numbers within assigned E.164 country codes is largely a national matter. But at least within the United States the reachability assumption is likely to hold and use of NANP numbers for purposes such as you describe (pure DNS indexes) are likely to be discouraged by regulators.   Penn Pfautz From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Ray AndersonSent: Saturday, July 16, 2005 12:38 PMTo: james.f.baskin at verizon.com; Lind, Steven D, ALABS; enum at ietf.orgSubject: Re: [Enum] E.164 communication assumptions/requirements At 00:03 15/07/2005, james.f.baskin at verizon.com wrote: - All E.164 numbers should be callable from the PSTN.  Someoneusing a PSTN-connected telephone with a keypad or a rotary dialshould be able to place a call to any other end user who hasvoice telephone service that has been assigned an E.164 number.It should not matter what underlying technology is used to providethe voice service to the called user -- wireline, wireless,satellite, VoIP, etc.- There should be no ^islands^ of E.164 numbers that areunreachable from users of other E.164 numbers.I don't believe the above two things are ENUM requirements.There are applications being envisaged where the E.164 number is purely used as a key to ENUM data "stored in DNS".  There is no requirement that an E.164 number has to be "callable"as far as I know, and if it had to be, those applications would have to create "callable endpoints"which might be meaningless certain applications (e.g. what is delivered to a voice caller when the E.164 number refers to a video stream or a WAP page? Ray Anderson   CEO Bango   ray at bango.com    www.bango.com Mobile: +44 7768 454545  Fax: +44 20 7692 5558  Come and see Bango at Mobile Entertainment Summit 2005,  Hilton Universal City, Los Angeles, USA   27-28 July www.ihollywoodforum.com   _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Mon, 18 Jul 2005 11:19:06 -0400 From: Jim Reid Date: Mon, 18 Jul 2005 11:19:06 -0400 To: "Fullbrook Kim \(UK\)" Subject: Re: [Enum] Comments on ID on new ENUM service "mobileweb" In-Reply-To: <0CD3FFEAEC982F489F872AB8DA32D624019D3F8C@Uksthmsx012> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R On Jul 18, 2005, at 13:13, Fullbrook Kim ((UK)) wrote: Can you imagine the implications of surfing the Net from your phone and presenting your CLI to each and every web site ? No I can't. Please enlighten me. As far as I'm aware no internet websites look for CLI from their clients. Unless a client's browser disclosed that info, how could a HTTP server know if it was talking to a phone as opposed to (say) a laptop? _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Kim.Fullbrook@o2.com Mon, 18 Jul 2005 12:41:22 -0400 From: "Fullbrook Kim \(UK\)" Date: Mon, 18 Jul 2005 12:41:22 -0400 To: "Jim Reid" Subject: RE: [Enum] Comments on ID on new ENUM service "mobileweb" Message-ID: <0CD3FFEAEC982F489F872AB8DA32D624019D3FE3@Uksthmsx012> MIME-Version: 1.0 Content-Type: text/plain Status: R The point is that unless the web site receives the CLI of the phone it can't use ENUM to look up the desired details. If the web site can't use ENUM then I'm can't see the applicability of the "mobileweb" enumservice being proposed. Kim. -----Original Message----- ===================================================== This electronic message contains information from O2 which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. ===================================================== From: Jim Reid [mailto:jim at rfc1035.com] Sent: 18 July 2005 16:19 To: Fullbrook Kim (UK) Cc: enum at ietf.org Subject: Re: [Enum] Comments on ID on new ENUM service "mobileweb" On Jul 18, 2005, at 13:13, Fullbrook Kim ((UK)) wrote: > Can you imagine the implications of > surfing the Net from your phone and presenting your CLI to each and > every web site ? No I can't. Please enlighten me. As far as I'm aware no internet websites look for CLI from their clients. Unless a client's browser disclosed that info, how could a HTTP server know if it was talking to a phone as opposed to (say) a laptop? _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From pk@denic.de Mon, 18 Jul 2005 12:51:40 -0400 From: Peter Koch Date: Mon, 18 Jul 2005 12:51:40 -0400 To: enum at ietf.org Subject: Re: [Enum] Comments on ID on new ENUM service "mobileweb" In-Reply-To: <0CD3FFEAEC982F489F872AB8DA32D624019D3FE3@Uksthmsx012> Message-ID: <20050718165124.GA1981@denics7.denic.de> MIME-Version: 1.0 Content-Type: text/plain Status: R Kim, > The point is that unless the web site receives the CLI of the phone it > can't use ENUM to look up the desired details. If the web site can't use > ENUM then I'm can't see the applicability of the "mobileweb" enumservice > being proposed. are you suggesting that the web server uses ENUM as kind of "reverse mapping" to lookup the properties of the requesting client which happens to be a phone? Lawrence (thanks by the way) has already clarified that that's not the case. -Peter _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Mon, 18 Jul 2005 15:21:25 -0400 From: "Michael Hammer \(mhammer\)" Date: Mon, 18 Jul 2005 15:21:25 -0400 To: "Stastny Richard" Subject: RE: [Enum] Clarification on Carrier ENUM discussions Message-ID: <072C5B76F7CEAB488172C6F64B30B5E35E82D5@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard, I have serious problems with the statement that only carriers can discover a point of interconnect for a carrier given an E.164 number. We do not need walled ENUM gardens, and this will certainly require regulators in each country to get involved. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Stastny Richard > Sent: Tuesday, July 12, 2005 10:28 AM > To: enum at ietf.org > Subject: [Enum] Clarification on Carrier ENUM discussions > > Dear all, > > following the current discussions on carrier ENUM, I have a > serious problem with some issues raised > > So to clarify some issues: > We have on one side User ENUM, which is used by end-users to > find other end-users. We so not need to define requirements > here and we do not need to discuss its purpose. > > On the other hand we have carrier ENUM. Carrier (or > Infrastructure) ENUM is for carriers ONLY and ONLY > carriers-of-record are allowed to enter information there and > ONLY carriers may use the infromation, even if it may > publicly available. Carier ENUM is required for carriers to > announce their PoI (IP based or on the PSTN) to other > carriers, with ENUM based technology, that is NAPTRs using > Enumservices such as "sip", "mms:mailto" or eventually "npd:tel" > > To do so, different methods may be used. > > A. use any tree in any domain (e.g foo.bar). Carriers may do > so on their own choice and are already doing so. > The problem here is that many trees exists. > If the carriers want to use a commonly agreed tree, they have > two options: agree on any tree out of .arpa or use > > B. an additional (side) tree in .arpa > > here 3 technically equivalent options exists > > 1. use carrier.arpa > 2. use carrier.e164.arpa > 3. use carrier.c.c.e164.arpa > > For the avoidance of doubt, carrier could also be "c" od "foo" > as Otmar pointed out and NOT the name of the carrier (the SPID) > > Any discussion of draft-haberler should restrict itself to > the question where to put "carrier" or "c" or "foo" and how > to find the proper side tree within the carriers ENUM client > and NOT e.g. asking questions like: > > "How does my > (Scottish) handset figure out what the names (or codes) exist > for the telco operators in say Austria? Which one of these > Austrian telcos is it supposed to prefer? How do I get my > handset to pick a new preferred partner for calls to Austria > whenever I port my number to another Scottish telco or if the > preferred telco in Austria has been renamed (or gone bust)?" > > This question has nothing to do with the problem at hand not > even with ENUM at all (not even in Scottland ;-) > > First: a handset (end-user) will never query carrier enum and > even a telco querying carrier ENUM does not have to find out > which telco to query or to prefer. ENU will give you this > information. And a number may only be hosted by one telco at a time. > > -richard > > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Mon, 18 Jul 2005 15:21:28 -0400 From: "Michael Hammer \(mhammer\)" Date: Mon, 18 Jul 2005 15:21:28 -0400 To: "Michael Haberler" Subject: RE: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris) Message-ID: <072C5B76F7CEAB488172C6F64B30B5E35E82D8@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Michael, We are still not there yet. I am party A. I get an E.164 number directly from the number administrator (not through a carrier) and put it in User ENUM. My mother is party B. She gets E.164 number from a carrier who has moved her over to VoIP and puts that number in Carrier ENUM, but doesn't tell her anything about User ENUM. (She doesn't monitor ENUM WG mailer.) My mother can call me, since carrier is smart enough to look me up in User ENUM. But, they are not required to do so! So, maybe she can't call me. Can I call my mother? No. I do lookup in User ENUM and she is not there. I (according to you) may not have access to Carrier ENUM, or even if I did, sending a call to the interconnect point would be rejected because I don't have an interconnect agreement with every carrier. My only recourse is to get an E.164 number from a major carrier that likely has interconnect to my mother's carrier. The end result will be that User ENUM dies and we all have to get E.164 from and subscribe to carrier to get calls through. What good is it to be able to communicate only to the miniscule minority that knows otherwise? Mike > -----Original Message----- > From: Michael Haberler [mailto:mah at inode.at] > Sent: Monday, July 11, 2005 6:47 PM > To: Michael Hammer (mhammer) > Cc: enum at ietf.org > Subject: RE: Carrier ENUM Definition (was RE: [Enum] Agenda > items forIETF Paris) > > At 00:01 12.07.2005, Michael Hammer \(mhammer\) wrote: > > >But, now you have partitioned the PSTN into walled gardens. > > Sorry if I was unclear - you are right, that wasnt what I > intended to say. > > regarding scenario 1 (I'm unsure what you mean by "ENUM > number" in that > context): > > a) If A just obtains a number from the NP administrator, and > has NOT subcribed to any carrier for routing that number in > the PSTN, then A is relegated to the User ENUM scenario - in > which case A will be able to call B if B has opted in to User > ENUM and A resolves B in the User ENUM tree. > > b) if A is serviced by a carrier, and passes calls by some > way (POTS, ISDN, > IP) to him for delivery, then the call will obviously succeed > through direct PSTN interconnect or carriers'carrier service > delivering to X - standard PSTN case. > > b1) if A's carrier decides to resolve B's number in the > carrier tree, finds the POI information for X, and has an > agreement with X, then A's carrier will be able to pass the > call to X on IP. > > b2) If A's carrier decides to resolve B's number in the > carrier tree, finds the POI information for X, and has NO > agreement with X, then A's carrier will probably pass the > call to X via the PSTN (again direct PSTN interconnect or > carriers'carrier service delivering to X). > > b3) If A's carrier decides to resolve in the carrier tree and > doesnt find any POI information for X (= X doesnt user the > carrier ENUm tree), again A's carrier will probably pass the > call to X via the PSTN as above. > > >It should not be a requirement for party B to opt-in to User > ENUM for > >the call to go through. If the caller is in Carrier ENUM, the call > >should still go through unless party B has blocked calls > from party A. > > It isnt a requirement, sorry - I hit send too fast and hoped > nobody will notice ;) ... > > > At 23:33 08.07.2005, Michael Hammer \(mhammer\) wrote: > > > > > > >Following up on the question about hiding the points of > > > >interconnect between two carriers: > > > > > > > >1. Does this mean that if party A has been assigned an > ENUM number > > > >directly from a national authority and A tries to call party > > > B that got > > > >his number from a carrier X in club Y, that the ENUM query > > > for the SBC > > > >to access carrier X will be null because A is not in club Y? > > > > > > A will be able to call B if B has opted in to User ENUM. > > > >The requirement should be that an ENUM lookup will reveal > B's carrier's > >SBC. B should not have to opt-in to User ENUM for this to work. > > > >What happened to the one lookup requirement? > > Noted - it should say: one DNS lookup per tree (carrier or > user) to resolve to a NAPTR. > > > > If A, a "User", looks in the carrier tree for B, he will find X's > > > SBC URI. > > > The session setup to this URI will fail though. > > > >It should not fail, unless you want to force all users to > have to user > >carriers. > > I'm confused - are you saying that just because *user* A has > some way of determining the POI of *carrier* X (servicing B) > then X is *required* to accept the call from *user* A? > > that's not how interconnection works - I guess this is a > misunderstanding. > > Nobody is forced to use a carrier just because he owns a > E.164 number (subject to local regulatory mileage) - but it > helps reachability to the non-user ENUM enabled part of the > E.164 space a lot. > > -Michael > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Mon, 18 Jul 2005 15:21:31 -0400 From: "Michael Hammer \(mhammer\)" Date: Mon, 18 Jul 2005 15:21:31 -0400 To: "Otmar Lendl" Subject: RE: combined User and Carrier ENUM (was RE: [Enum] Agenda items forIETF Paris) Message-ID: <072C5B76F7CEAB488172C6F64B30B5E35E82DB@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Otmar, I understood the literal. What I don't understand is how the situation of an IP-PBX extrapolates to all types of end office switches. There seems to be an assumption that the 1,000 block or 10,000 block of numbers will be permanently assigned to the operator (IP-PBX owner), but that doesn't hold for public carriers where an end-user can change carriers. Also, if I build my own IP-PBX with one trunk and one line-side user, will I have the right by law to enter a number into the Carrier ENUM tree? How does that then affect what server the record resides on? Will we then need: x.b.p.r.e.i.r.r.a.c.e164.arpa and c.i.l.b.u.p.r.e.i.r.r.a.c.e164.arpa This seems like a slippery slope. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Otmar Lendl > Sent: Tuesday, July 12, 2005 2:24 AM > To: enum at ietf.org > Subject: Re: combined User and Carrier ENUM (was RE: [Enum] > Agenda items forIETF Paris) > > On 2005/07/11 23:07, "Michael Hammer (mhammer)" > wrote: > > Michael, > > > > I did not assume anything. And yes I am aware of the > variable length > > numbers in certain countries. Will your system work when > every other > > 11 digit (+1-NPA-NXX-XXXX) number is ported to a different carrier? > > BTW, in the US there are 3000 plus carriers and growing. How many > > does Austria have? > > Michael, > > In Michael's I-D, the domain component "carrier" is meant as > the literal sequence of the ascii characters c,a,r,r,i,e and > r and not as a variable for which you substitute a real-life > carrier name. > > It could just as well be "foobar", "c" or > "death-to-ss7-interconnects". > > There is thus still one single tree per country (or NPA), and > thus still a need for a registry who runs that tree and with > which every carrier needs to interact to get its numbers into > carrier ENUM. > > The number of carriers per country is thus irrelevant for the > lookup procedure. > > /ol > -- > < Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Mon, 18 Jul 2005 15:21:32 -0400 From: "Michael Hammer \(mhammer\)" Date: Mon, 18 Jul 2005 15:21:32 -0400 To: "Russell, Nick, VF UK - Technology \(TS\)" Subject: RE: [Enum] Comments on ID on new ENUM service "mobileweb" Message-ID: <072C5B76F7CEAB488172C6F64B30B5E35E82D6@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Nick, I'm not sure I really understand the underlying need. Even if the user has the capability, it doesn't mean he is willing to use it. SIP/SDP and SIMPLE (presence) already have mechanisms to negotiate what capabilities of a handset a user is willing to use at this instant or Notify other users of such. Just wondering if we are looking at the right tool to solve the problem. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Russell, Nick, VF UK - Technology (TS) > Sent: Friday, July 15, 2005 5:46 AM > To: enum at ietf.org > Subject: [Enum] Comments on ID on new ENUM service "mobileweb" > > Dear All, > > Having read the ID draft-ra-shin-enum-mobileweb-00 my > interpretation of it is that it is used by network equipment > to determine which web "protocol" (in the loosest terms) a > device supports by looking up the > E.164 number associated with it in the ENUM/DNS. > > If my assumption is wrong, please tell me. Otherwise, I see a > number of scenarios where this will fail and/or not be > viable, particularly in GSM/UMTS. > > In GSM/UMTS, the E.164 number (or the "MSISDN") is NOT > associated with a device, it is associated with an IMSI > (International Mobile Subscriber Identity). The IMSI is > stored in the network and on the UICC (Universal Integrated > Circuit Card) which has a SIM application on it. Such a chip > is more commonly known as a "SIM card", and can be moved > freely between different hand-sets by the user at any time > they choose. This therefore allows the user to change their > handset whenever they like, *without informing the network*! > Such a different handset could support a different > "mobileweb" sub-type e.g. if I move my SIM card from my > SonyEricsson V800 to an HP iPAQ. > > How are such updates going to be catered for in the ENUM/DNS? > Static configuration by a human will not suffice so I presume > your thinking is that the ENUM/DNS could be dynamically > updated when the user turns on the phone (i.e. the network > detects a new handset and alters the ENUM fields appropriately). > > Today, operators currently cater for different devices by > examining the IMEI (International Mobile Equipment Identity) > when the subscriber establishes the data session (GPRS > session). This IMEI value is used as a key to a look-up table > to determine such things as screen size, colour depth, WAP > browser capabilities (and however strict the WAP specs are, > there ARE differences in implementations of WAP browsers > between mobile handset manufacturers) etc. We then cache this > information for the life time of the data session. This cache > value is therefore dependant on the protocol layers below the > IP layer. > > Now, from what is being proposed in the ID in question, it > seems everything is going to be done at the IP layer (and > above). Presuming there is some undocumented dynamic way to > update the "mobileweb" service field (such as that described > above), the TTL of the DNS resource records are going to have > to be fairly low in order to account for the times when a > subscriber changes his handset/device, as a DNS TTL can't be > set to expire when the user decides to turn-off his handset. > > Now let's consider another service. Multi-SIM. This > essentially allows subscribers to "share" an E.164 number and > is achieved by the network storing the same MSISDN for a two > or more IMSIs. So if there are, say, two subscribers sharing > the same MSISDN but both using different handsets, and they > both request a mobile web page of some sort within a few > seconds of each other, one subscriber will get the correctly > formatted page and the other won't. > > So in conclusion, I don't believe this ID serves it's > intended purpose due to the two facts of: > > 1) DNS cache time can't be matched to a time period of the > user's preferred time of using the same handset (at least, > without setting a very low DNS cache time which is bad DNS design). > > 2) There is not always a one-to-one mapping between E.164 > number and mobile device. > > > In my mind, a better idea would be to create a whole new DDDS > application (is that the right term?) that uses IMEIs as the > input instead of E.164 numbers and re-write the general DNS > caching rules (!) to specify lower layer protocol events as > expiration time (e.g. PDP Context deactivation), rather than > an actual time period (e.g. 1 minute)! ;-) > > Cheers, > Nick Russell > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Mon, 18 Jul 2005 15:21:37 -0400 From: "Michael Hammer \(mhammer\)" Date: Mon, 18 Jul 2005 15:21:37 -0400 To: "Jim Reid" Subject: RE: combined User and Carrier ENUM (was RE: [Enum] Agenda items for IETF Paris) Message-ID: <072C5B76F7CEAB488172C6F64B30B5E35E82DA@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Jim, What you describe is what I understood to be the case. And if so, then I don't see any more or less queries to what I suggested versus defining an additional carrier domain. It seems that both the user and carrier have rights to submit records to be stored at the authoritative server for domain x.x.x.x.X.X.N.A.P.N.1.e164.arpa (to use a North American example). Do I understand correctly that when you say "NAPTRs" below, that more that one could be present? If so, what server is authoritative for that domain, and what stops them from hosting two records? What happens when a number is ported from one carrier to another, even using Carrier ENUM? It seems like the same exact problem exists that having a Carrier domain was seeking to somehow avoid. Mike > -----Original Message----- > From: Jim Reid [mailto:jim at rfc1035.com] > Sent: Tuesday, July 12, 2005 5:42 AM > To: Michael Hammer (mhammer) > Cc: Michael Haberler; enum at ietf.org > Subject: Re: combined User and Carrier ENUM (was RE: [Enum] > Agenda items for IETF Paris) > > > I suspect that there is some aspect to DNS operation that I haven't > > put my finger on that makes this difficult. I'm still not > sure what > > exactly your one DNS lookup means since from what I > understand several > > domain servers need to be queried to get a final response. > > Michael, you seem to be confused how DNS lookups work. I hope > this explanation helps. > > An application makes a DNS lookup by sending a query to some > local name server. This is known as the stub resolver in DNS > jargon: it formats a packet, sends it and waits for a reply. > That's all. > > The local name server -- full service resolver in DNS jargon > -- sends a response back. If it can't answer from its cache, > the local name server will make iterative queries to resolve > the stub resolver's query. > Conceptually, it does that by starting at the root and > working its way down the tree. In ENUM, this would be > querying the .arpa name servers, then the e164.arpa name > servers and so on. This full service resolver will not go off > and query other branches of the tree. That is no DNS > implementation has logic which says "if the name doesn't > exist under foo.bar, try resolving this in some other > incantation of foo.bar or in some other domain name > entirely". In other words, the full service resolver > terminates the iterative lookups when it gets an answer or > gives up because the remote name servers are non-responsible > or unresolvable. That answer can of course be "the name/query > type you looked up does not exist". Whatever result the full > service resolver gets is then returned to the stub resolver > that made the initial query. > > Of course the application could have logic that says "if > there are no NAPTRs for this number in e164.arpa, try > querying for them in some other domain name". If it did, that > second lookup would go to the full service resolver and go > through the same iterative process as before. > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Mon, 18 Jul 2005 15:32:16 -0400 From: "Stastny Richard" Date: Mon, 18 Jul 2005 15:32:16 -0400 To: "Michael Hammer \(mhammer\)" Subject: Re: [Enum] Clarification on Carrier ENUM discussions Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C032@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R >I have serious problems with the statement that only carriers can >discover a point of interconnect for a carrier given an E.164 number. In Carrier ENUM, who else? >We do not need walled ENUM gardens, and this will certainly require >regulators in each country to get involved. Who is "we"? ;-) -richard ________________________________ Von: Michael Hammer (mhammer) [mailto:mhammer at cisco.com] Gesendet: Mo 18.07.2005 21:21 An: Stastny Richard; enum at ietf.org Betreff: RE: [Enum] Clarification on Carrier ENUM discussions Richard, I have serious problems with the statement that only carriers can discover a point of interconnect for a carrier given an E.164 number. We do not need walled ENUM gardens, and this will certainly require regulators in each country to get involved. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Stastny Richard > Sent: Tuesday, July 12, 2005 10:28 AM > To: enum at ietf.org > Subject: [Enum] Clarification on Carrier ENUM discussions > > Dear all, > > following the current discussions on carrier ENUM, I have a > serious problem with some issues raised > > So to clarify some issues: > We have on one side User ENUM, which is used by end-users to > find other end-users. We so not need to define requirements > here and we do not need to discuss its purpose. > > On the other hand we have carrier ENUM. Carrier (or > Infrastructure) ENUM is for carriers ONLY and ONLY > carriers-of-record are allowed to enter information there and > ONLY carriers may use the infromation, even if it may > publicly available. Carier ENUM is required for carriers to > announce their PoI (IP based or on the PSTN) to other > carriers, with ENUM based technology, that is NAPTRs using > Enumservices such as "sip", "mms:mailto" or eventually "npd:tel" > > To do so, different methods may be used. > > A. use any tree in any domain (e.g foo.bar). Carriers may do > so on their own choice and are already doing so. > The problem here is that many trees exists. > If the carriers want to use a commonly agreed tree, they have > two options: agree on any tree out of .arpa or use > > B. an additional (side) tree in .arpa > > here 3 technically equivalent options exists > > 1. use carrier.arpa > 2. use carrier.e164.arpa > 3. use carrier.c.c.e164.arpa > > For the avoidance of doubt, carrier could also be "c" od "foo" > as Otmar pointed out and NOT the name of the carrier (the SPID) > > Any discussion of draft-haberler should restrict itself to > the question where to put "carrier" or "c" or "foo" and how > to find the proper side tree within the carriers ENUM client > and NOT e.g. asking questions like: > > "How does my > (Scottish) handset figure out what the names (or codes) exist > for the telco operators in say Austria? Which one of these > Austrian telcos is it supposed to prefer? How do I get my > handset to pick a new preferred partner for calls to Austria > whenever I port my number to another Scottish telco or if the > preferred telco in Austria has been renamed (or gone bust)?" > > This question has nothing to do with the problem at hand not > even with ENUM at all (not even in Scottland ;-) > > First: a handset (end-user) will never query carrier enum and > even a telco querying carrier ENUM does not have to find out > which telco to query or to prefer. ENU will give you this > information. And a number may only be hosted by one telco at a time. > > -richard > > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ray@bango.net Mon, 18 Jul 2005 16:35:28 -0400 From: Ray Anderson Date: Mon, 18 Jul 2005 16:35:28 -0400 To: enum at ietf.org Subject: Re: [Enum] Comments on ID on new ENUM service "mobileweb" Message-ID: <6.1.2.0.2.20050718213524.0b2fa940@smtp.bango.net> MIME-Version: 1.0 Content-Type: text/plain Status: R Just re-reading the "mobileweb" submission, and it could be read differently. Lets say you promote your phone number 44 1234 567890 to people as an access point to your business, you might also want to make the same number a short - cut to one or more web pages. (Just like Bango Numbers point to URLs) You could store the page URLs - different URLs for different browser types - in the DNS using ENUM. The idea of having a differnt URL (ENUM record) for each browser type is probably as flawed as the .MOBI idea - since HTTP_ACCEPT should be used. The idea of using ENUM / DNS to map numbers to content URLs is very reasonable. At 17:51 18/07/2005, Peter Koch wrote: Kim, > The point is that unless the web site receives the CLI of the phone it > can't use ENUM to look up the desired details. If the web site can't use > ENUM then I'm can't see the applicability of the "mobileweb" enumservice > being proposed. are you suggesting that the web server uses ENUM as kind of "reverse mapping" to lookup the properties of the requesting client which happens to be a phone? Lawrence (thanks by the way) has already clarified that that's not the case. -Peter _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum Ray Anderson T:+44 7768 454545 F:+44 20 7692 5558 ray at bango.com _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ray@bango.net Mon, 18 Jul 2005 16:36:46 -0400 From: Ray Anderson Date: Mon, 18 Jul 2005 16:36:46 -0400 To: "Pfautz, Penn L, NEO" Subject: RE: [Enum] E.164 communication assumptions/requirements Message-ID: <6.1.2.0.2.20050718213516.0b2f9eb0@smtp.bango.net> MIME-Version: 1.0 Content-Type: text/plain Status: R At 13:45 18/07/2005, Pfautz, Penn L, NEO wrote: Ray: We could argue about whether these are ENUM requirements.  And use of numbers within assigned E.164 country codes is largely a national matter. But at least within the United States the reachability assumption is likely to hold and use of NANP numbers for purposes such as you describe (pure DNS indexes) are likely to be discouraged by regulators.   Penn Pfautz I believe that some regulators will allow "free issue" of large blocks of ENUM "space" for non voice purposes I also think that the ability to "change" your ENUM DNS records is a good clue that you "own" that number, so it is possible to use ENUM as a way of cost effectively verifying who "owns" an E.164 number _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From thomas.jauch@gmail.com Mon, 18 Jul 2005 17:07:57 -0400 From: Thomas Jauch Date: Mon, 18 Jul 2005 17:07:57 -0400 To: Ray Anderson Subject: Re: [Enum] E.164 communication assumptions/requirements In-Reply-To: <6.1.2.0.2.20050718213516.0b2f9eb0@smtp.bango.net> Message-ID: <4ed6c24a0507181406440aa8b3@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Ray, Are you speaking about Public ENUM or Carrier ENUM? Don't forget the User Opt-In requirenment in Public ENUM! And how would you "verifying who "owns" an E.164 number" without a WHOIS database in place? WHOIS would be even a bigger nightmare, from a privacy point of view, than publishing name based URIs in connection with a phone number... Regards, Tom On 7/18/05, Ray Anderson wrote: > At 13:45 18/07/2005, Pfautz, Penn L, NEO wrote: > > Ray: > We could argue about whether these are ENUM requirements. And use of > numbers within assigned E.164 country codes is largely a national matter. > But at least within the United States the reachability assumption is likely > to hold and use of NANP numbers for purposes such as you describe (pure DNS > indexes) are likely to be discouraged by regulators. > > Penn Pfautz > I believe that some regulators will allow "free issue" of large blocks of > ENUM "space" for non voice purposes > > I also think that the ability to "change" your ENUM DNS records is a good > clue that you "own" that number, so > it is possible to use ENUM as a way of cost effectively verifying who > "owns" an E.164 number > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Mon, 18 Jul 2005 17:09:15 -0400 From: "Stastny Richard" Date: Mon, 18 Jul 2005 17:09:15 -0400 To: Subject: [Enum] VoIP Peering BoF - Naming and Addressing Issues Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C033@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R This is my input on the BoF session on VoIP peering and Interconnect dealing only with the first two issues on (a) Call routing and (b) ENUM and raising a third not yet mentioned issue: -Numbering, naming and addressing In my understanding the basic requirement of VoIP peering is that voice calls (and other IP communications) originating on IP and terminating on IP should stay on IP. There reason for this has been stated in VOIP peering documents many times: -better QoS -more capabilities (BB codecs, presence, IM, video, etc.) Any call going via the PSTN will loose this advantages. One (very) simple minded could ask the question: "And where is the problem?" I also can send an e-mail to anybody as long as I know his e-mail address. Currently the following "types" of "VoIP" exist (for simplicity I assume only VoIP implemented using SIP): 1. freely accessible servers (proxies) on the public Internet (ala e-mail) 2. servers on the public Internet, but requiring authentication 3. servers in private networks, accessible from the public Internet via a Session Border Controller 4. servers in private networks, accessible from the public Internet via a Session Border Controller (SBC), requiring authentication 5. servers in private networks, accessible only via SBC from other private networks, eventually via a commonly shared network. and for completeness: 6. servers in private networks only reachable via the PSTN 7. users on a PSTN network which is connected to the Internet via gateway acting as SBC. There may exist other cases and more details, especially if SIP, H323 and IMS systems are taken into account The first question that needs to be answered in a BoF session on VoIP peering is: A. which of these scenarios are in- and out-of-scope After the scenarios are defined, the next question is how to route calls between two servers. Routing of calls implies to find out in the originating network the destination network and, if there is no direct interconnection between origination network and destination network, the transit networks required to interconnect. So we are back to question A.: "Are there transit networks within the scenarios in-scope?" Routing of calls is done normally by analyzing the "public" identifier of the called party the calling party enters. It is obvious that on IP IP-based addresses and names will be used for routing, the basic question is: What are the "public" identifiers an end-user will enter? To make it simple: What identifier does one put on his business card? There are currently two choices: -E.164 numbers -sip AoR in the format sip:user at foo.bar -both If it is E.164 numbers only, these E.164 numbers are translated by some magic (e.g ENUM) to internal identifiers e.g. sip AoR to find the routing. The assignement of these E.164 is according to national rules. If it is SIP AoR, an additional question comes up: is an end-user restricted to public identifiers given out by providers such as richard.stastny AT vodafone.de or is it possible also to "port in" identifiers such as richard AT stastny.com? If it is both, the E.164 identifiers need to be mapped to SIP AoRs by some means e.g. ENUM. This ENUM cannot be USER ENUM because the Carriers services relies on this mapping, so it must be independant. For all these cases depending on the scenarios the required mappings and access to DNS and IP addresses need to be investigated and defined. Some preliminary work in this regard analyzing the possible scenarios has been done by ETSI in TS 102 055 "Infrastructure ENUM". Richard Stastny _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Mon, 18 Jul 2005 19:50:58 -0400 From: Jim Reid Date: Mon, 18 Jul 2005 19:50:58 -0400 To: Thomas Jauch Subject: Death to whois! (was Re: [Enum] E.164 communication assumptions/requirements) In-Reply-To: <6.1.2.0.2.20050718213516.0b2f9eb0@smtp.bango.net> Message-ID: <423e307ff8c45f038126acce6304cf80@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain Status: R On Jul 18, 2005, at 22:06, Thomas Jauch wrote: And how would you "verifying who "owns" an E.164 number" without a WHOIS database in place? whois is completely orthogonal to the DNS or ENUM. Please don't cross-contaminate these things. ENUM and the DNS work perfectly well without any whois service whatsoever. ENUM and the DNS do not depend on whois. And vice versa. In the context of ENUM, whois is essentially pointless. The whole concept of whois was to provide contact data for the owner of some domain. In the early days of the internet, this was used so you could *phone* someone to tell them their DNS servers were broken => they couldn't receive email. With all the spamming that goes on these days, people try to obfuscate any whois data and registries are in an arms race with spammers to keep them away from their whois databases. So at best, whois is debatable for regular domain names. For ENUM, it's pointless because the contact data is already known: the phone number. So why look for that in some whois server? The best you could hope for from an ENUM whois server is some other possibly valid contact data for a broken domain. As for verification and authentication of ENUM entries, whois data proves nothing. Unless of course it was authenticated and validated at the point where it was entered into that database. So we're back to where we started. And of course since whois and DNS are not necessarily tightly coupled, there's no guarantee that any data that's in the DNS for some zone is consistent with what's in the whois database for that zone. WHOIS would be even a bigger nightmare, from a privacy point of view, than publishing name based URIs in connection with a phone number... Indeed. This is one of the reasons why ENUM in the UK does not (and probably never will have) a whois service. Or CRISP if that ever supplants whois. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@inode.at Mon, 18 Jul 2005 20:41:31 -0400 From: Michael Haberler Date: Mon, 18 Jul 2005 20:41:31 -0400 To: Ray Anderson Subject: RE: [Enum] E.164 communication assumptions/requirements In-Reply-To: <6.1.2.0.2.20050718213516.0b2f9eb0@smtp.bango.net> Message-ID: <6.2.1.2.2.20050719023048.056e5198@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: R At 22:35 18.07.2005, Ray Anderson wrote: At 13:45 18/07/2005, Pfautz, Penn L, NEO wrote: Ray: We could argue about whether these are ENUM requirements. And use of numbers within assigned E.164 country codes is largely a national matter. But at least within the United States the reachability assumption is likely to hold and use of NANP numbers for purposes such as you describe (pure DNS indexes) are likely to be discouraged by regulators. Penn Pfautz I believe that some regulators will allow "free issue" of large blocks of ENUM "space" for non voice purposes I havent heard of regulators doing that, it might be more the other way around - a number range allocated but nobody routes it in the PSTN. That, by the way, is the case since a long time - have a look at the bottom of http://www.itu.int/itudoc/itu-t/ob-lists/icc/e164_763.pdf - the ITU has allocated whole 'country codes' (actually private network codes) for, amongst others, ATM virtual circuit addressing. No, you cant call these numbers on the PSTN, but yes, they are E.164 numbers. The 'E.164 number has to be "reachable"'' assumption is an extrapolation of experience with the subset of E.164 that is used for PSTN voice. -Michael I also think that the ability to "change" your ENUM DNS records is a good clue that you "own" that number, so it is possible to use ENUM as a way of cost effectively verifying who "owns" an E.164 number _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@inode.at Mon, 18 Jul 2005 21:01:36 -0400 From: Michael Haberler Date: Mon, 18 Jul 2005 21:01:36 -0400 To: "Michael Hammer \(mhammer\)" Subject: RE: [Enum] Clarification on Carrier ENUM discussions In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E35E82D5@xmb-rtp-20b.amer.cisco.com> Message-ID: <6.2.1.2.2.20050719024312.0490aeb0@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: R At 21:21 18.07.2005, Michael Hammer \(mhammer\) wrote: Richard, I have serious problems with the statement that only carriers can discover a point of interconnect for a carrier given an E.164 number. What Richard meant was that just because you *know* the network coordinates of POI for a number that doesnt imply that you can *force* the telco operating that POI to accept calls from, and terminate for you just because you like that to be (assuming you not having an agreement with said telco), regardless if you discover the POI coordinates through DNS, published information or social engineering. We do not need walled ENUM gardens, and this will certainly require regulators in each country to get involved. I'm a bit fuzzy on what are you're suggesting. Are you saying any URI which is entered by either User or Carrier-of-Record must be publically reachable without authentication (the latter would map to an underlying intent or agreement)? I happen own a +43 780ff number, mapped to a URI in User ENUM, and the SIP proxy for that URI accepts calls only from the PSTN->IP gateway handling that number. Am I violating some vision here? is SIP authentication a no-no or what is actually the issue? lost, -Michael _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@inode.at Mon, 18 Jul 2005 21:51:17 -0400 From: Michael Haberler Date: Mon, 18 Jul 2005 21:51:17 -0400 To: "Michael Hammer \(mhammer\)" Subject: RE: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris) In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E35E82D8@xmb-rtp-20b.amer.cisco.com> Message-ID: <6.2.1.2.2.20050719030232.048b0f90@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: R At 21:21 18.07.2005, Michael Hammer \(mhammer\) wrote: Michael, We are still not there yet. I am party A. I get an E.164 number directly from the number administrator (not through a carrier) and put it in User ENUM. did you contract a telco to route that number in the PSTN once you got it, or not? My mother is party B. She gets E.164 number from a carrier who has moved her over to VoIP and puts that number in Carrier ENUM, but doesn't tell her anything about User ENUM. (She doesn't monitor ENUM WG mailer.) My mother can call me, since carrier is smart enough to look me up in User ENUM. But, they are not required to do so! So, maybe she can't call me. Can I call my mother? No. Yes, and that is your problem, not an ENUM problem. I do lookup in User ENUM and she is not there. I (according to you) may not have access to Carrier ENUM, or even if I did, sending a call to the interconnect point would be rejected because I don't have an interconnect agreement with every carrier. yes, that's how life is for phone users - I'll have to be a customer of a telco so I can be called by the non-User-ENUM-aware population. My only recourse is to get an E.164 number from a major carrier that likely has interconnect to my mother's carrier. No, your recourse is to contract a telco to route that number in the PSTN, just like everbody else does. For your ability to be called by your mother you' or your mother likely do not care about carrier ENUM or not used by your telcos, and frankly its not your business in the first place if you are a user. Carrier ENUM or not is a carrier business decision (aka carrier opt-in). Part of the misunderstanding we have might actually be based in the historically fuzzy definition of number ownership and rights and obligations attached to it. The fuzz factor comes in in two ways a) a telco sort of "owns" a number until a user ports away b) for individually assigned numbers (as in my example +43 59966) the owner still needs to turn around and contract a telco to route it which sort of makes him the "number range holder" for a number you own - again until one ports elsewhere. The better term thus really is "carrier-of-record" which covers all cases - number issued out of a block, number ported to new carrier (of record) and individually assigned number "recorded" to be routed in the PSTN by that telco. The end result will be that User ENUM dies and we all have to get E.164 from and subscribe to carrier to get calls through. The current result is that telcos care zilch about user ENUM and deliver calls over the PSTN, which is why you are well advised to have a telco route to your number no matter how you'd obtained it, so you can be called by the 99.999999% of non-user-ENUM telephone users. The medium result might be that telcos migrate to IP interconnect but just dont give up their habits yet. Enlightened telcos might consult User ENUM, too, besides some other mechanism to drive their IP interconnect, but that doesnt make my day. The long term result might be that telcos get revenue through useful service to customers and not by charging at the termination bottleneck. Whoa.. what a concept.. Whatever the outcome, I wouldnt operate on the assumption that one can force, or shortcut that development through IETF activity. An offering which aids migration between business models might help. An approach which exclusively addresses the 0.000001% scenario is likely to be a very the long road. What good is it to be able to communicate only to the miniscule minority that knows otherwise? That is in fact an excellent question, and encapsulates the User ENUM adoption problem entirely. The fact that you own an E.164 identifier doesnt give you the right to force everbody else in the world to deliver to said identifier in a way you would like (and I would like, put the PSTN aint like email). -Michael _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ray@bango.com Tue, 19 Jul 2005 04:53:09 -0400 From: Ray Anderson Date: Tue, 19 Jul 2005 04:53:09 -0400 To: enum at ietf.org Subject: Re: [Enum] Comments on ID on new ENUM service "mobileweb" In-Reply-To: <0CD3FFEAEC982F489F872AB8DA32D624019D3FE3@Uksthmsx012> Message-ID: <6.1.2.0.2.20050718211140.0b2dcd70@smtp.bango.net> MIME-Version: 1.0 Content-Type: text/plain Status: R Just re-reading the "mobileweb" submission, and it could be read differently. Lets say you promote your phone number 44 1234 567890 to people as an access point to your business, you might also want to make the same number a short - cut to one or more web pages.   (Just like Bango Numbers point to URLs) You could store the page URLs - different URLs for different browser types - in the DNS using ENUM. The idea of having a differnt URL (ENUM record) for each browser type is probably as flawed as the .MOBI idea - since HTTP_ACCEPT should be used. The idea of using ENUM / DNS to map numbers to content URLs is very reasonable. At 17:51 18/07/2005, Peter Koch wrote: Kim, > The point is that unless the web site receives the CLI of the phone it > can't use ENUM to look up the desired details. If the web site can't use > ENUM then I'm can't see the applicability of the "mobileweb" enumservice > being proposed. are you suggesting that the web server uses ENUM as kind of "reverse mapping" to lookup the properties of the requesting client which happens to be a phone? Lawrence (thanks by the way) has already clarified that that's not the case. -Peter _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum Ray Anderson   CEO Bango   ray at bango.com    www.bango.com Mobile: +44 7768 454545  Fax: +44 20 7692 5558  Come and see Bango at Mobile Entertainment Summit 2005,  Hilton Universal City, Los Angeles, USA   27-28 July www.ihollywoodforum.com   _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ray@bango.com Tue, 19 Jul 2005 04:53:10 -0400 From: Ray Anderson Date: Tue, 19 Jul 2005 04:53:10 -0400 To: "Pfautz, Penn L, NEO" Subject: RE: [Enum] E.164 communication assumptions/requirements In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0AAB4DAE@ACCLUST02EVS1.ugd.att.com> Message-ID: <6.1.2.0.2.20050718211829.0b2dbc30@smtp.bango.net> MIME-Version: 1.0 Content-Type: text/plain Status: R At 13:45 18/07/2005, Pfautz, Penn L, NEO wrote: Ray: We could argue about whether these are ENUM requirements.  And use of numbers within assigned E.164 country codes is largely a national matter. But at least within the United States the reachability assumption is likely to hold and use of NANP numbers for purposes such as you describe (pure DNS indexes) are likely to be discouraged by regulators.   Penn Pfautz I believe that some regulators will allow "free issue" of large blocks of ENUM "space" for non voice purposes I also think that the ability to "change" your ENUM DNS records is a good clue that you "own" that number, so it is possible to use ENUM as a way of cost effectively verifying who "owns" an E.164 number _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ray@bango.net Tue, 19 Jul 2005 05:02:26 -0400 From: Ray Anderson Date: Tue, 19 Jul 2005 05:02:26 -0400 To: Thomas Jauch Subject: Re: [Enum] E.164 communication assumptions/requirements In-Reply-To: <6.1.2.0.2.20050718213516.0b2f9eb0@smtp.bango.net> Message-ID: <6.1.2.0.2.20050719095349.0b310410@smtp.bango.net> MIME-Version: 1.0 Content-Type: text/plain Status: R At 22:06 18/07/2005, Thomas Jauch wrote: Ray, Are you speaking about Public ENUM or Carrier ENUM? Don't forget the User Opt-In requirenment in Public ENUM! And how would you "verifying who "owns" an E.164 number" without a WHOIS database in place? WHOIS would be even a bigger nightmare, from a privacy point of view, than publishing name based URIs in connection with a phone number... Regards, Tom Our requirement is to be able to determine who "has control" of a "phone number". We plan to use ENUM to help us determine this by asking the user who claims to own a phone number to do something with ENUM that means that somebody who controls that bit of the E.164 numberspace has given them control over that number. So, if I claim to own +441223472778 I might be asked to change the email address in the ENUM record to banana at bango.com If I can do that, it is assumed I am "all powerful" with respect to that number. The whole ENUM project should be causing E.164 owners to put into place varying levels of verification systems that we can piggyback on top of. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From thomas.jauch@gmail.com Tue, 19 Jul 2005 05:40:17 -0400 From: Thomas Jauch Date: Tue, 19 Jul 2005 05:40:17 -0400 To: Ray Anderson Subject: Re: [Enum] E.164 communication assumptions/requirements In-Reply-To: <6.1.2.0.2.20050718213516.0b2f9eb0@smtp.bango.net> Message-ID: <4ed6c24a0507190239143ce649@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain Status: R On 7/19/05, Ray Anderson wrote: > At 22:06 18/07/2005, Thomas Jauch wrote: > >Ray, > > > >Are you speaking about Public ENUM or Carrier ENUM? Don't forget the > >User Opt-In requirenment in Public ENUM! And how would you "verifying > >who "owns" an E.164 number" without a WHOIS database in place? WHOIS > >would be even a bigger nightmare, from a privacy point of view, than > >publishing name based URIs in connection with a phone number... > > > >Regards, > > > >Tom > > Our requirement is to be able to determine who "has control" of a "phone > number". > We plan to use ENUM to help us determine this by asking the user who claims > to own > a phone number to do something with ENUM that means that somebody who controls > that bit of the E.164 numberspace has given them control over that number. > > So, if I claim to own +441223472778 I might be asked to change the email > address in the > ENUM record to banana at bango.com If I can do that, it is assumed I am "all > powerful" > with respect to that number. The whole ENUM project should be causing > E.164 owners > to put into place varying levels of verification systems that we can > piggyback on top of. > If I understand you correctly you would like to use such a method as described during a sign-up process, to make sure that the person who signs-up is the owner of the number? So you assume that every of your future customers would have choosen already an ENUM registrar, proven his identity, published at least an some sort of data into ENUM, etc. before he signs-up for your service? When would you check the change made to the endpoint in the process of signing-up? What about the TTL? Do you expect that the customer to wait until the changes are visible to you and you could confirm the ownership? If you ask for a change of the email address, would you provide an email account? What happens with the emails distributed to that address during the "ownership check"? Does your customer have to log into this new account and, after he has changed the email address back to his personal email address, forward all incoming emails to his personal email address? Aren't there other ways like sending an SMS message to the handset including a verification code, which your future customer has to enter into a form within a given time frame? Do you consider this method as not secure because a handset could have been stolen? Tom _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Tue, 19 Jul 2005 09:36:46 -0400 From: Jim Reid Date: Tue, 19 Jul 2005 09:36:46 -0400 To: "Fullbrook Kim \(UK\)" Subject: Re: [Enum] Comments on ID on new ENUM service "mobileweb" In-Reply-To: <0CD3FFEAEC982F489F872AB8DA32D624019D3FE3@Uksthmsx012> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R On Jul 18, 2005, at 17:32, Fullbrook Kim ((UK)) wrote: The point is that unless the web site receives the CLI of the phone it can't use ENUM to look up the desired details. If the web site can't use ENUM then I'm can't see the applicability of the "mobileweb" enumservice being proposed. I seem to have things back-to-front. I thought that ENUM was about mapping phone numbers to URIs and that web servers talked to clients that had IP addresses. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From philippe.fouquart@francetelecom.com Tue, 19 Jul 2005 10:38:05 -0400 From: "FOUQUART Philippe RD-CORE-ISS" Date: Tue, 19 Jul 2005 10:38:05 -0400 To: "Ray Anderson" Subject: RE: [Enum] E.164 communication assumptions/requirements Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Ray, Penn, I'm not sure you're in total disagreement :-) Even for conversational services, there may be perfectly valid reasons for not making E.164 numbers reachable (customer request, barred portions of international CCs for all kinds of reasons...) so I'm not sure that in principle an E.164 number is automatically tied with reachability. However, most national/international numbering plans are under some pressure to accommodate all sorts of new services in a space that's already assigned for the main part (and demand may exceed supply). So there has to be criteria for making sure that public resources are assigned where they're most needed, a primary requirement being that these can be reached from PSTN/PLMN. Reachability may therefore not be a prerequisite for E.164 number assignment per se, but it is often part of a sensible numbering plan management, let alone national regulatory constraints as alluded to by Penn. For the ownership of an international numbering resource, I don't believe a user or anyone can claim to be the owner of a number, but I guess that's just a point of terminology. For a short 'explanation' you may have a look at principle n°5 of E.190, which along with E.164.1 sort of governs E.164 numbering ("Assignment confers use of the resource but does not imply ownership by the assignee".) For a moooore substantial discussion you may want to try http://www.ero.dk/documentation/docs/docfiles.asp?docid=1902&frames=0. It's not new but still applies to a large extent, and I would assume this absence of ownership is pretty much a constant of the numbering regulatory regimes within the EU. Now whether we refer the "owner" or the "assignee" of the E.164 number, I don't think that impacts infrastructure/ carrier Enum. Hope this helps, Philippe Fouquart R&D/CORE/NAS +33 (0) 1 45 29 58 13 ________________________________ From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Ray Anderson Sent: Monday, July 18, 2005 10:22 PM To: Pfautz, Penn L, NEO; enum at ietf.org Subject: RE: [Enum] E.164 communication assumptions/requirements At 13:45 18/07/2005, Pfautz, Penn L, NEO wrote: Ray: We could argue about whether these are ENUM requirements. And use of numbers within assigned E.164 country codes is largely a national matter. But at least within the United States the reachability assumption is likely to hold and use of NANP numbers for purposes such as you describe (pure DNS indexes) are likely to be discouraged by regulators. Penn Pfautz I believe that some regulators will allow "free issue" of large blocks of ENUM "space" for non voice purposes I also think that the ability to "change" your ENUM DNS records is a good clue that you "own" that number, so it is possible to use ENUM as a way of cost effectively verifying who "owns" an E.164 number _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Internet-Drafts@ietf.org Tue, 19 Jul 2005 10:50:24 -0400 From: Internet-Drafts@ietf.org Date: Tue, 19 Jul 2005 10:50:24 -0400 To: i-d-announce at ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-iris-ereg-01.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R 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 : An ENUM Registry Type for the Internet Registry Information Service Author(s) : A. Newton Filename : draft-ietf-enum-iris-ereg-01.txt Pages : 52 Date : 2005-7-19 This document describes an IRIS registry schema for registered ENUM information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by ENUM registries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-iris-ereg-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at 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-iris-ereg-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-iris-ereg-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Tue, 19 Jul 2005 10:54:46 -0400 From: "Stastny Richard" Date: Tue, 19 Jul 2005 10:54:46 -0400 To: "Thomas Jauch" Subject: Re: [Enum] E.164 communication assumptions/requirements Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C038@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R I am not quite sure where this discussion is leading to? We are discussing here carrier ENUM. Valdiation in User ENUM has been discussed and solved years ago, there are commercial implementations out. -richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Thomas Jauch Gesendet: Di 19.07.2005 11:39 An: Ray Anderson Cc: enum at ietf.org; tim at bango.com Betreff: Re: [Enum] E.164 communication assumptions/requirements On 7/19/05, Ray Anderson wrote: > At 22:06 18/07/2005, Thomas Jauch wrote: > >Ray, > > > >Are you speaking about Public ENUM or Carrier ENUM? Don't forget the > >User Opt-In requirenment in Public ENUM! And how would you "verifying > >who "owns" an E.164 number" without a WHOIS database in place? WHOIS > >would be even a bigger nightmare, from a privacy point of view, than > >publishing name based URIs in connection with a phone number... > > > >Regards, > > > >Tom > > Our requirement is to be able to determine who "has control" of a "phone > number". > We plan to use ENUM to help us determine this by asking the user who claims > to own > a phone number to do something with ENUM that means that somebody who controls > that bit of the E.164 numberspace has given them control over that number. > > So, if I claim to own +441223472778 I might be asked to change the email > address in the > ENUM record to banana at bango.com If I can do that, it is assumed I am "all > powerful" > with respect to that number. The whole ENUM project should be causing > E.164 owners > to put into place varying levels of verification systems that we can > piggyback on top of. > If I understand you correctly you would like to use such a method as described during a sign-up process, to make sure that the person who signs-up is the owner of the number? So you assume that every of your future customers would have choosen already an ENUM registrar, proven his identity, published at least an some sort of data into ENUM, etc. before he signs-up for your service? When would you check the change made to the endpoint in the process of signing-up? What about the TTL? Do you expect that the customer to wait until the changes are visible to you and you could confirm the ownership? If you ask for a change of the email address, would you provide an email account? What happens with the emails distributed to that address during the "ownership check"? Does your customer have to log into this new account and, after he has changed the email address back to his personal email address, forward all incoming emails to his personal email address? Aren't there other ways like sending an SMS message to the handset including a verification code, which your future customer has to enter into a form within a given time frame? Do you consider this method as not secure because a handset could have been stolen? Tom _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Tue, 19 Jul 2005 11:32:06 -0400 From: "Peter Williams" Date: Tue, 19 Jul 2005 11:32:06 -0400 To: "'Ray Anderson'" Subject: RE: [Enum] E.164 communication assumptions/requirements In-Reply-To: <6.1.2.0.2.20050719095349.0b310410@smtp.bango.net> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R > > Our requirement is to be able to determine who "has control" of a "phone > number". > We plan to use ENUM to help us determine this by asking the user who > claims > to own > a phone number to do something with ENUM that means that somebody who > controls > that bit of the E.164 numberspace has given them control over that number. Its more the other way around: which carrier of record, or which contracted telco for an individual number assignment, is held responsible for administering and managing the network when delivering the less well known AND MANDATORY services for a PSTN-connected number. Track-and-trace: relaying data, usually stored vs. real-time, on called and calling parties, usually to police investigators Interception: realtime relaying of the bit stream to the monitoring switch node for that telco Denial: intercept switching/reachability at the incoming interconnection point between carriers. (e.g. stop detonation based on cell phone call trigger) Let's remember that, in the US, carriers are audited and fined if their infrastructure and management controls are unable to meet the standards for delivering the above PSTN-related services. Passing the audit (and avoiding the sanctions) comes down to deploying business controls that guarantee the timeliness aspects of the routing/switching database management, from subscription through provisioning to publication. For track-and-trace, carriers generally only work with other regulated (i.e. audited) carriers as their own effectiveness when performing their obligations generally depends on the quality of the carriers with whom they have interconnect agreements. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Tue, 19 Jul 2005 11:45:41 -0400 From: "Stastny Richard" Date: Tue, 19 Jul 2005 11:45:41 -0400 To: "FOUQUART Philippe RD-CORE-ISS" Subject: Re: [Enum] E.164 communication assumptions/requirements Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C03B@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Philippe, thanks for pointing out again that nobody "owns" a E.164 number (I gave up already ;-) the correct term is Right-of-Use (RoU), which is always used in our national ENUM documents. >Now whether we refer the "owner" or the "assignee" of the E.164 number, >I don't think that impacts infrastructure/ carrier Enum. Yes and no ;-) Both User ENUM and Infrastructure/Carrier ENUM use the DNS and use domain names related to E.164 numbers, and because of this these domains are a bit different to "normal" domains, there are more like "sponsored" domains. In User ENUM the domain name holder can only be the end-user having the RoU; and only during the time he has the RoU. Note: Number Portability is NA in User ENUM because the RoU does not change. The End-user is directly responsible for the contents of the domainn In Carrier ENUM the domain name holder can only be the Carrier-of-Record (see a previous posting that for the time beeing this definition is a national matter) Note: Therefore Number Portability IS an issue in Carrier ENUM, because the Carrier-of-Record and therefore the domain Name Holder changes. In Carrier ENUM the end-user is only indirectly via the current Carrier-of-record responsible for the content of the domain -richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von FOUQUART Philippe RD-CORE-ISS Gesendet: Di 19.07.2005 16:34 An: Ray Anderson; Pfautz, Penn L, NEO Cc: enum at ietf.org Betreff: RE: [Enum] E.164 communication assumptions/requirements Ray, Penn, I'm not sure you're in total disagreement :-) Even for conversational services, there may be perfectly valid reasons for not making E.164 numbers reachable (customer request, barred portions of international CCs for all kinds of reasons...) so I'm not sure that in principle an E.164 number is automatically tied with reachability. However, most national/international numbering plans are under some pressure to accommodate all sorts of new services in a space that's already assigned for the main part (and demand may exceed supply). So there has to be criteria for making sure that public resources are assigned where they're most needed, a primary requirement being that these can be reached from PSTN/PLMN. Reachability may therefore not be a prerequisite for E.164 number assignment per se, but it is often part of a sensible numbering plan management, let alone national regulatory constraints as alluded to by Penn. For the ownership of an international numbering resource, I don't believe a user or anyone can claim to be the owner of a number, but I guess that's just a point of terminology. For a short 'explanation' you may have a look at principle n°5 of E.190, which along with E.164.1 sort of governs E.164 numbering ("Assignment confers use of the resource but does not imply ownership by the assignee".) For a moooore substantial discussion you may want to try http://www.ero.dk/documentation/docs/docfiles.asp?docid=1902&frames=0. It's not new but still applies to a large extent, and I would assume this absence of ownership is pretty much a constant of the numbering regulatory regimes within the EU. Now whether we refer the "owner" or the "assignee" of the E.164 number, I don't think that impacts infrastructure/ carrier Enum. Hope this helps, Philippe Fouquart R&D/CORE/NAS +33 (0) 1 45 29 58 13 ________________________________ From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Ray Anderson Sent: Monday, July 18, 2005 10:22 PM To: Pfautz, Penn L, NEO; enum at ietf.org Subject: RE: [Enum] E.164 communication assumptions/requirements At 13:45 18/07/2005, Pfautz, Penn L, NEO wrote: Ray: We could argue about whether these are ENUM requirements. And use of numbers within assigned E.164 country codes is largely a national matter. But at least within the United States the reachability assumption is likely to hold and use of NANP numbers for purposes such as you describe (pure DNS indexes) are likely to be discouraged by regulators. Penn Pfautz I believe that some regulators will allow "free issue" of large blocks of ENUM "space" for non voice purposes I also think that the ability to "change" your ENUM DNS records is a good clue that you "own" that number, so it is possible to use ENUM as a way of cost effectively verifying who "owns" an E.164 number _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From rich.shockey@neustar.biz Tue, 19 Jul 2005 12:20:07 -0400 From: Richard Shockey Date: Tue, 19 Jul 2005 12:20:07 -0400 To: enum at ietf.org Subject: Question: [Enum] I-D ACTION:draft-ietf-enum-iris-ereg-01.txt In-Reply-To: Message-ID: <6.2.1.2.2.20050719121348.0589dc20@mail.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Andy ..what changes have you made in this version? 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 : An ENUM Registry Type for the Internet Registry Information Service Author(s) : A. Newton Filename : draft-ietf-enum-iris-ereg-01.txt Pages : 52 Date : 2005-7-19 This document describes an IRIS registry schema for registered ENUM information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by ENUM registries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-iris-ereg-01.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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From rich.shockey@neustar.biz Tue, 19 Jul 2005 12:20:18 -0400 From: Richard Shockey Date: Tue, 19 Jul 2005 12:20:18 -0400 To: Jim Reid Subject: Re: Death to whois! (was Re: [Enum] E.164 communication assumptions/requirements) In-Reply-To: <6.1.2.0.2.20050718213516.0b2f9eb0@smtp.bango.net> Message-ID: <6.2.1.2.2.20050719121552.05802580@mail.songbird.com> MIME-Version: 1.0 Content-Type: text/plain Status: R At 07:50 PM 7/18/2005, Jim Reid wrote: On Jul 18, 2005, at 22:06, Thomas Jauch wrote: And how would you "verifying who "owns" an E.164 number" without a WHOIS database in place? whois is completely orthogonal to the DNS or ENUM. Please don't cross-contaminate these things. ENUM and the DNS work perfectly well without any whois service whatsoever. ENUM and the DNS do not depend on whois. And vice versa. In the context of ENUM, whois is essentially pointless. not really .. The whole concept of whois was to provide contact data for the owner of some domain. In the early days of the internet, this was used so you could *phone* someone to tell them their DNS servers were broken => they couldn't receive email. With all the spamming that goes on these days, people try to obfuscate any whois data and registries are in an arms race with spammers to keep them away from their whois databases. So at best, whois is debatable for regular domain names. For ENUM, it's pointless because the contact data is already known: the phone number. So why look for that in some whois server? The best you could hope for from an ENUM whois server is some other possibly valid contact data for a broken domain. There may be all sorts of requirements from regulatory authorities for which a ENUM Contact-Database based on ..IRIS perhaps will be useful. In fact the US ENUM forum is going to specify the use if IRIS-EREG in its architecture. Which is one reason I want to bring the latest version to Last Call ASAP. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From andy@hxr.us Tue, 19 Jul 2005 14:13:14 -0400 From: Andrew Newton Date: Tue, 19 Jul 2005 14:13:14 -0400 To: Richard Shockey Subject: Re: Death to whois! (was Re: [Enum] E.164 communication assumptions/requirements) In-Reply-To: <6.1.2.0.2.20050718213516.0b2f9eb0@smtp.bango.net> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R On Jul 19, 2005, at 12:19 PM, Richard Shockey wrote: Which is one reason I want to bring the latest version to Last Call ASAP. It has been submitted, and I think is ready for wglc. -andy _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From andy@hxr.us Tue, 19 Jul 2005 14:29:34 -0400 From: Andrew Newton Date: Tue, 19 Jul 2005 14:29:34 -0400 To: Richard Shockey Subject: Re: Question: [Enum] I-D ACTION:draft-ietf-enum-iris-ereg-01.txt In-Reply-To: Message-ID: <67A05EF7-C259-47FF-894C-882240C1B53A@hxr.us> MIME-Version: 1.0 Content-Type: text/plain Status: R On Jul 19, 2005, at 12:14 PM, Richard Shockey wrote: Andy ..what changes have you made in this version? Most of the changes were to correct inconsistent terminology. Things like changing AuthenticationAuthority to ValidationAuthority, etc.. etc... The biggest change is that the various types of contacts were normalized in the schema and are now allowed on any result that represents a real-world organization. There was a request to add a search for finding ENUMs by partial E. 164 number, but I did not include it in the draft because I did not understand its semantics and could not get clarification before the cut-off date. I also don't consider this to be a big deal. -andy _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From bhoeneis@switch.ch Wed, 20 Jul 2005 08:09:24 -0400 From: Bernie Hoeneisen Date: Wed, 20 Jul 2005 08:09:24 -0400 To: enum at ietf.org Subject: Re: Death to whois! (was Re: [Enum] E.164 communication assumptions/requirements) In-Reply-To: <6.1.2.0.2.20050718213516.0b2f9eb0@smtp.bango.net> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R On Tue, 19 Jul 2005, Richard Shockey wrote: There may be all sorts of requirements from regulatory authorities for which a ENUM Contact-Database based on ..IRIS perhaps will be useful. In fact the US ENUM forum is going to specify the use if IRIS-EREG in its architecture. Which is one reason I want to bring the latest version to Last Call ASAP. What kind of requirements have been set by the US authoities? Is this an IRIS service which can be accessed by everybody, or can only a restricted user group access such data, e.g. law enforcement staff? cheers, Bernie _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From bhoeneis@switch.ch Wed, 20 Jul 2005 08:18:12 -0400 From: Bernie Hoeneisen Date: Wed, 20 Jul 2005 08:18:12 -0400 To: Stastny Richard Subject: Re: [Enum] E.164 communication assumptions/requirements In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C038@oefeg-s04.oefeg.loc> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R On Tue, 19 Jul 2005, Stastny Richard wrote: Valdiation in User ENUM has been discussed and solved years ago, Validation is solved in User ENUM? I'd say at most part of it... cheers, Bernie _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ppfautz@att.com Wed, 20 Jul 2005 08:23:35 -0400 From: "Pfautz, Penn L, NEO" Date: Wed, 20 Jul 2005 08:23:35 -0400 To: "Bernie Hoeneisen" Subject: RE: Death to whois! (was Re: [Enum] E.164 communicationassumptions/requirements) Message-ID: <34DA635B184A644DA4588E260EC0A25A0AB25D2F@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Bernie: The US authorities have yet to formally set any requirements in detail except to offer a set of principles, including protection of user privacy, that must be met before the USG would request delegation of 1.e164.arpa. With this in mind the US ENUM Forum has proposed and the CC 1 ENUM LLC adopted the view that a normal whois is inappropriate for ENUM. Instead, the plan is to do something called "contactinfo", which, unless the number assignee specifically chose to make their contact information available (it's been pointed out some business might want to do so), would not. Instead, contact info of the Registrar would be provided and the Registrar would be expected to act as a pass thru to get info to the assignee or appropriate technical contact (e.g. the appropriate Tier 2 provider) in the case of troubleshooting or other legitimate need. The thick registry model is planned and would contain number assignee info but this would not be generally available. Presumably law enforcement could get this upon presentation of proper court authorization. Penn -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Bernie Hoeneisen Sent: Wednesday, July 20, 2005 8:06 AM To: enum at ietf.org Subject: Re: Death to whois! (was Re: [Enum] E.164 communicationassumptions/requirements) On Tue, 19 Jul 2005, Richard Shockey wrote: > There may be all sorts of requirements from regulatory authorities for which > a ENUM Contact-Database based on ..IRIS perhaps will be useful. In fact the > US ENUM forum is going to specify the use if IRIS-EREG in its architecture. > Which is one reason I want to bring the latest version to Last Call ASAP. What kind of requirements have been set by the US authoities? Is this an IRIS service which can be accessed by everybody, or can only a restricted user group access such data, e.g. law enforcement staff? cheers, Bernie _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From philippe.fouquart@francetelecom.com Wed, 20 Jul 2005 09:10:13 -0400 From: "FOUQUART Philippe RD-CORE-ISS" Date: Wed, 20 Jul 2005 09:10:13 -0400 To: "Stastny Richard" Subject: RE: [Enum] E.164 communication assumptions/requirements Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R > From: Stastny Richard > > Now whether we refer the "owner" or the "assignee" of the E.164 number, > > I don't think that impacts infrastructure/ carrier Enum. > > Yes and no ;- [...] Richard, Thanks for the clarification, I agree, I think :-) What I meant was that I'm not sure the notion of owner or that of assignee would be the appropriate one to determine what you refer to as the Carrier-of-record. There are countries (one that I know of at least...) where strictly speaking NP does not affect E.164 numbering assignment whereas as you point out it should impact your 'Carrier-of-record'. Having said that, since NP comes in a number of different flavours, as a work-method requirement if you like, the solution that the WG can come up with should be kept as generic as possible in this department. Anything that would venture into NP national specifics would be better dealt with 'locally' IMO. And I'm not sure we want to get into some Enum administration model thing again :-) Regards, Philippe Fouquart R&D/CORE/NAS +33 (0) 1 45 29 58 13 -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] Sent: Tuesday, July 19, 2005 5:49 PM To: FOUQUART Philippe RD-CORE-ISS Cc: enum at ietf.org Subject: Re: [Enum] E.164 communication assumptions/requirements Philippe, thanks for pointing out again that nobody "owns" a E.164 number (I gave up already ;-) the correct term is Right-of-Use (RoU), which is always used in our national ENUM documents. >Now whether we refer the "owner" or the "assignee" of the E.164 number, >I don't think that impacts infrastructure/ carrier Enum. Yes and no ;-) Both User ENUM and Infrastructure/Carrier ENUM use the DNS and use domain names related to E.164 numbers, and because of this these domains are a bit different to "normal" domains, there are more like "sponsored" domains. In User ENUM the domain name holder can only be the end-user having the RoU; and only during the time he has the RoU. Note: Number Portability is NA in User ENUM because the RoU does not change. The End-user is directly responsible for the contents of the domainn In Carrier ENUM the domain name holder can only be the Carrier-of-Record (see a previous posting that for the time beeing this definition is a national matter) Note: Therefore Number Portability IS an issue in Carrier ENUM, because the Carrier-of-Record and therefore the domain Name Holder changes. In Carrier ENUM the end-user is only indirectly via the current Carrier-of-record responsible for the content of the domain -richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Wed, 20 Jul 2005 09:27:13 -0400 From: "Michael Hammer \(mhammer\)" Date: Wed, 20 Jul 2005 09:27:13 -0400 To: "Stastny Richard" Subject: RE: [Enum] Clarification on Carrier ENUM discussions Message-ID: <072C5B76F7CEAB488172C6F64B30B5E35E8680@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard, If any user can not find a carrier point of interconnect from Carrier ENUM, then where else? > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] > Sent: Monday, July 18, 2005 3:34 PM > To: Michael Hammer (mhammer); enum at ietf.org > Subject: Re: [Enum] Clarification on Carrier ENUM discussions > > >I have serious problems with the statement that only carriers can > >discover a point of interconnect for a carrier given an E.164 number. > > In Carrier ENUM, who else? > > >We do not need walled ENUM gardens, and this will certainly require > >regulators in each country to get involved. > > Who is "we"? ;-) I think it was Metcalfe's Law that said that the value of the network was the square of the number of users that can interconnect. The PSTN has great value because any E.164 number can call any other E.164 number. The value of the Internet is great because one public IP address can reach another. Look at instant messaging. Everyone agrees that having non-interoperable islands is not good. Thus efforts to provide for interoperability. Look at cellular networks. Without wide geographic coverage enabled by the possibility to roam, the value was limited. VoIP and ENUM will have value if it enables anyone to reach anyone else. We is anyone who wants to maximize the value of the network by making it easier to reach one another. Early in US telephone history there were many telephone companies, but because you could only call someone connected to the same company, there was not general reachability. The government stepped in and created one phone company and gave it a monopoly. Let's not repeat history. Note, I don't expect monopolies to be created, but the lawyers will fix what the technicians fail to accomplish. Do you want that? If the above does not describe you, who are you looking out for? Mike > > -richard > > ________________________________ > > Von: Michael Hammer (mhammer) [mailto:mhammer at cisco.com] > Gesendet: Mo 18.07.2005 21:21 > An: Stastny Richard; enum at ietf.org > Betreff: RE: [Enum] Clarification on Carrier ENUM discussions > > > > Richard, > > I have serious problems with the statement that only carriers > can discover a point of interconnect for a carrier given an > E.164 number. > We do not need walled ENUM gardens, and this will certainly > require regulators in each country to get involved. > > Mike > > > > -----Original Message----- > > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] > On Behalf > > Of Stastny Richard > > Sent: Tuesday, July 12, 2005 10:28 AM > > To: enum at ietf.org > > Subject: [Enum] Clarification on Carrier ENUM discussions > > > > Dear all, > > > > following the current discussions on carrier ENUM, I have a serious > > problem with some issues raised > > > > So to clarify some issues: > > We have on one side User ENUM, which is used by end-users to find > > other end-users. We so not need to define requirements here > and we do > > not need to discuss its purpose. > > > > On the other hand we have carrier ENUM. Carrier (or > > Infrastructure) ENUM is for carriers ONLY and ONLY > carriers-of-record > > are allowed to enter information there and ONLY carriers > may use the > > infromation, even if it may publicly available. Carier ENUM is > > required for carriers to announce their PoI (IP based or on > the PSTN) > > to other carriers, with ENUM based technology, that is NAPTRs using > > Enumservices such as "sip", "mms:mailto" or eventually "npd:tel" > > > > To do so, different methods may be used. > > > > A. use any tree in any domain (e.g foo.bar). Carriers may do so on > > their own choice and are already doing so. > > The problem here is that many trees exists. > > If the carriers want to use a commonly agreed tree, they have two > > options: agree on any tree out of .arpa or use > > > > B. an additional (side) tree in .arpa > > > > here 3 technically equivalent options exists > > > > 1. use carrier.arpa > > 2. use carrier.e164.arpa > > 3. use carrier.c.c.e164.arpa > > > > For the avoidance of doubt, carrier could also be "c" od "foo" > > as Otmar pointed out and NOT the name of the carrier (the SPID) > > > > Any discussion of draft-haberler should restrict itself to the > > question where to put "carrier" or "c" or "foo" and how to find the > > proper side tree within the carriers ENUM client and NOT > e.g. asking > > questions like: > > > > "How does my > > (Scottish) handset figure out what the names (or codes) > exist for the > > telco operators in say Austria? Which one of these Austrian > telcos is > > it supposed to prefer? How do I get my handset to pick a > new preferred > > partner for calls to Austria whenever I port my number to another > > Scottish telco or if the preferred telco in Austria has > been renamed > > (or gone bust)?" > > > > This question has nothing to do with the problem at hand > not even with > > ENUM at all (not even in Scottland ;-) > > > > First: a handset (end-user) will never query carrier enum > and even a > > telco querying carrier ENUM does not have to find out which > telco to > > query or to prefer. ENU will give you this information. And > a number > > may only be hosted by one telco at a time. > > > > -richard > > > > > > > > _______________________________________________ > > enum mailing list > > enum at ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Wed, 20 Jul 2005 12:09:48 -0400 From: "Stastny Richard" Date: Wed, 20 Jul 2005 12:09:48 -0400 To: "Bernie Hoeneisen" Subject: Re: [Enum] E.164 communication assumptions/requirements Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C03E@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R >> Valdiation in User ENUM has been discussed and solved >> years ago, >Validation is solved in User ENUM? I'd say at most part of it... Agreed, most if the problems are solved, at least one can subscribe to ENUM. I have to admit we are still not able to subscribe whales and also global warming is not not completely solved yet ;-) -richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From dmm@1-4-5.net Wed, 20 Jul 2005 18:26:48 -0400 From: David Meyer Date: Wed, 20 Jul 2005 18:26:48 -0400 To: voipeer at lists.uoregon.edu Subject: [Enum] [voipeer] updated voipeer BOF agenda for IETF 63 Message-ID: <20050720220833.GA23928@1-4-5.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary..32256.1122908376.multipart/mixed" Status: R --Boundary..32256.1122908376.multipart/mixed Content-Type: text/plain Content-Transfer-Encoding: 7bit VoIP Peering and Interconnect BOF (voipeer) THURSDAY, August 4, 1400-1630 (Afternoon Session I) =================================================== CHAIR: David Meyer AGENDA o Administriva 0 minutes - Mailing list: majordomo at lists.uoregon.edu subscribe voipeer or visit http://darkwing.uoregon.edu/~llynch/voipeer.html - Scribe(s)? - Blue Sheets o Agenda Bashing 0 minutes Meyer o Puropse and Objectives + Overview 10 minutes Meyer o SIPPING update/overview 10 minutes Camarillo o ENUM Update/Overview 10 minutes Shockey o SIP Forum Tech WG IP PBX to SP Interconnect Update 5 minutes Mahy o Issues in Numbering, Naming and Addressing 10 minutes Stastny o Service Provider Perspectives 40 minutes Bill Woodcock (PCH) Martin Dolly (ATT) Jason Livingood (Comcast) Joao Damas (ISC) o Discussion 50 minutes Meyer/All o Next Steps 15 minutes Meyer Attachment: pgpXkwSvTmLXc.pgp Description: PGP signature _______________________________________________ enum mailing list enum at ietf.org --Boundary..32256.1122908376.multipart/mixed Content-Type: application/octet-stream; name="pgpXkwSvTmLXc.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgpXkwSvTmLXc.pgp" Content-Description: "https://www1.ietf.org/mailman/listinfo/enum" --Boundary..32256.1122908376.multipart/mixed-- From richard@shockey.us Wed, 20 Jul 2005 21:39:22 -0400 From: Richard Shockey Date: Wed, 20 Jul 2005 21:39:22 -0400 To: enum at ietf.org Subject: [Enum] A shameless plug for my new job. Message-ID: <42DEFCA4.9000801@shockey.us> MIME-Version: 1.0 Content-Type: text/plain Status: R NO I have not left NeuStar. For quite some time I've been extremely interested in technical issues surrounding how IP-PBX's and Service Provider can interconnect. The SIP Forum http://www.sipforum.com/ has established a working group charged with: This task group will produce one or more SIP Forum recommendations that define a common set of implementation rules for implementers who desire to interface an IP PBX with a SIP-enabled service provider. The recommendation(s) will specify which standards must be supported, provide precise guidance in the areas where the standards leave multiple options, supplement functionality gaps in existing protocols, and identify a baseline set of features that should be common to an IP PBX to service provider interface. Such guidelines will not preclude the implementation of additional SIP functionality and primitives that do not conflict with the common implementation rules of the recommendation(s). For purposes of this task group a SIP-enabled IP PBX is defined as a private, multi-user communications system that supports a clearly-defined baseline set of SIP standards along with other (optional) protocols. At a high level, the interface to the service provider utilizes a combination of SIP signaling and media transport using RTP. The interface to end-users of the IP PBX can be SIP or any other protocol capable of establishing a voice session (such as SCCP, H.323, directly connected analog “black phone”, etc.) While vendor implementation choices vary (i.e. the PBX may be comprised of multiple servers and SIP endpoints), the SIP signaling exchanged with a service provider must be traceable to a single account identity, which may be a separate identity from users of the PBX. In this respect, the PBX is to be viewed logically as a single SIP user agent for the purposes of the interface specification. This does not preclude, however, the capability for media to be exchanged directly between the service provider and PBX-controlled IP endpoints such as IP phones and media terminal adaptors. ########## I will be chairing this effort. I believe its important and ultimately relevant to what the ENUM WG wants to accomplish over time. The reason the SIP Forum is dealing with this issue is that SIPPING determined that such an activity is out of scope for an IETF working group and better handled in a industry working forum. ########### This preliminary charter will change but I believe it is important work that may of you may be interested in. Information on the WG list is avaiable below. Particpitation in this WG will be under the same general terms and conditions that the ITEF operates under though the SIP Forum Intellectual policy has yet to be firmly estabilshed. Send mail to: techwg at sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg -- 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lendl@nic.at Thu, 21 Jul 2005 09:07:08 -0400 From: Otmar Lendl Date: Thu, 21 Jul 2005 09:07:08 -0400 To: enum at ietf.org Subject: Re: Question: [Enum] I-D ACTION:draft-ietf-enum-iris-ereg-01.txt In-Reply-To: Message-ID: <20050721130640.GA13475@nic.at> MIME-Version: 1.0 Content-Type: text/plain Status: R On 2005/07/19 20:07, Andrew Newton wrote: > > The biggest change is that the various types of contacts were > normalized in the schema and are now allowed on any result that > represents a real-world organization. I've just read the document and here are some comments: * Terminology. You use "ENUM" as a shortcut for what is usually called "ENUM domain". For me, the single word "ENUM" stands for the overall standard (as defined in RFC3761). Perhaps this shortening is inevitable (just as "static IP address" is often shortened to just "static IP"), but I'm uncomfortable to legitimize such language via official documents. Btw, what *is* the official explanation of the word ENUM? (other than just being a word play on "electronic numbering"?) * Domain vs. Number As long as there is a 1:1 mapping between domains and numbers this is just a question about syntax, but fuer the Austrian ENUM registry we decided to use the E.164 number as the primary data object and not the resulting domain. Rationale: The number is much better suited for human reading than ENUM domains, so we prefer to have numbers in logs, error- messages and protocol fields. Furthermore, when expanding the registry to cover more than just ENUM dns (e.g. more generic number assignment, E-911, NP) it becomes even more natural to deal with numbers and not with domains. * Domain status: How would you map the cases "domain marked for deletion" and "deleted and in grace period" to your choices? Does "assignedAndOnHold" mean that the delegation is active or not? * Contact schema: Your contact schema seems to be rather close to the dreg contact from RFC 3982. What is the rationale to duplicate the definition vs. including the dreg schema? Is your contact obejct compatible to the EPP contact object? (I haven't checked this one.) What about reusing the schema from the EPP rfcs? [side comment: the +43 live ENUM registry uses a different contact schema to be compatible with the Austrian phonebook.] * Host schema: Same as for contact. * I'm not sure if I got this right: The entityName attribute of registrationAuthority or validationAuthority acts as the unique identifier of said entity in the context of that registry? E.g. the EPP clID [i.e. the Registrar-ID] should be put into that field? * Your ValidationResult is very close to the Validation Token I describe in draft-lendl-enum-validation-token-00. It contains the same basic fields and just omits the digital signature and the optional owner date. /ol -- < Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jaap@NLnetLabs.nl Thu, 21 Jul 2005 09:49:14 -0400 From: Jaap Akkerhuis Date: Thu, 21 Jul 2005 09:49:14 -0400 To: Otmar Lendl Subject: Re: Question: [Enum] I-D ACTION:draft-ietf-enum-iris-ereg-01.txt In-Reply-To: Message-ID: <20050721154850.4fc0509b.jaap@NLnetLabs.nl> MIME-Version: 1.0 Content-Type: text/plain Status: R On Thu, 21 Jul 2005 15:06:40 +0200 Otmar Lendl wrote: > > Btw, what *is* the official explanation of the word ENUM? > (other than just being a word play on "electronic numbering"?) I've been told that it comes from the C language keyword "enum". there was a trend to call ietf-WGs to well known UNIX terms such as "cat", "malloc", "rtfm". jaap _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Thu, 21 Jul 2005 13:00:17 -0400 From: "Stastny Richard" Date: Thu, 21 Jul 2005 13:00:17 -0400 To: "Richard Shockey" Subject: Re: [Enum] A shameless plug for my new job. Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C043@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R >I believe its important and ultimately relevant to what the ENUM WG >wants to accomplish over time. Hm? I always thought ENUM was for DIRECT peering between PBX Why do I need a suddenly a SIP Service provider in between? Just for my information, some other minor questions: How does this relate to the work of SIPConnect? >In this respect, the PBX is to >be viewed logically as a single SIP user agent for the purposes of the >interface specification. So it is a B2BUA? I miss the 3-letter word SBC in your text ;-) BTW, what is the opinion of Henry to the scope of this group? regards -richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Richard Shockey Gesendet: Do 21.07.2005 03:38 An: enum at ietf.org Betreff: [Enum] A shameless plug for my new job. NO I have not left NeuStar. For quite some time I've been extremely interested in technical issues surrounding how IP-PBX's and Service Provider can interconnect. The SIP Forum http://www.sipforum.com/ has established a working group charged with: This task group will produce one or more SIP Forum recommendations that define a common set of implementation rules for implementers who desire to interface an IP PBX with a SIP-enabled service provider. The recommendation(s) will specify which standards must be supported, provide precise guidance in the areas where the standards leave multiple options, supplement functionality gaps in existing protocols, and identify a baseline set of features that should be common to an IP PBX to service provider interface. Such guidelines will not preclude the implementation of additional SIP functionality and primitives that do not conflict with the common implementation rules of the recommendation(s). For purposes of this task group a SIP-enabled IP PBX is defined as a private, multi-user communications system that supports a clearly-defined baseline set of SIP standards along with other (optional) protocols. At a high level, the interface to the service provider utilizes a combination of SIP signaling and media transport using RTP. The interface to end-users of the IP PBX can be SIP or any other protocol capable of establishing a voice session (such as SCCP, H.323, directly connected analog "black phone", etc.) While vendor implementation choices vary (i.e. the PBX may be comprised of multiple servers and SIP endpoints), the SIP signaling exchanged with a service provider must be traceable to a single account identity, which may be a separate identity from users of the PBX. In this respect, the PBX is to be viewed logically as a single SIP user agent for the purposes of the interface specification. This does not preclude, however, the capability for media to be exchanged directly between the service provider and PBX-controlled IP endpoints such as IP phones and media terminal adaptors. ########## I will be chairing this effort. I believe its important and ultimately relevant to what the ENUM WG wants to accomplish over time. The reason the SIP Forum is dealing with this issue is that SIPPING determined that such an activity is out of scope for an IETF working group and better handled in a industry working forum. ########### This preliminary charter will change but I believe it is important work that may of you may be interested in. Information on the WG list is avaiable below. Particpitation in this WG will be under the same general terms and conditions that the ITEF operates under though the SIP Forum Intellectual policy has yet to be firmly estabilshed. Send mail to: techwg at sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Thu, 21 Jul 2005 13:47:53 -0400 From: "Stastny Richard" Date: Thu, 21 Jul 2005 13:47:53 -0400 To: "Michael Hammer \(mhammer\)" Subject: Re: [Enum] Clarification on Carrier ENUM discussions Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C044@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Michael, In most of my presentations I gave on ENUM the last two years I pointed out that the major problem of ENUM is to overcome Metcalfe's Law. So much for that.;-) >If any user can not find a carrier point of interconnect from Carrier >ENUM, then where else? only another Carrier, and if you monitor the current discussion, only Carriers that have an bi-lateral interconnect agreement with this carrier. A user can never use a PoI of a carrier. The term PoI is derived from TDM (PSTN) interconnect, and here PoI is a synonym for Network-Network Interface (NNI). In PSTN Interconnect, a user is ALWAYS connected via a User-Network-Interface (UNI) and NEVER can access (per definition) a NNI. What we have here is a clash of cultures: User ENUM is desigend along the lines of the end-to-end Internet model To use User ENUM, you need to get a public SIP URI from your service provider (or you provide it by yourself - e.g. a company PBX) - like e-mail Carrier ENUM is designed along the lines of PSTN interconnect, Carriers have networks and interconnect with each other, either via the Internet or via direct connections. You as a user connect to the connect via a "UNI" to one service provider and the service provider has to find out a way to connect you to the service provider of the called user. How he is doing this is not your problem. The next two or so years we will see a battle between these two approaches - I have no idea who will win. It will basically be decided by the end-users: do they want to be on their own or do they want to have the comfort of a service provider and pay for this. The trend currently goes in direction of the PSTN interconnect model: even the SIP Forum is changing focus, just read the "shameless" e-mail from Rich Shockey: the new task group will specify a UNI. -richard ________________________________ Von: Michael Hammer (mhammer) [mailto:mhammer at cisco.com] Gesendet: Mi 20.07.2005 15:27 An: Stastny Richard; enum at ietf.org Betreff: RE: [Enum] Clarification on Carrier ENUM discussions Richard, If any user can not find a carrier point of interconnect from Carrier ENUM, then where else? > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] > Sent: Monday, July 18, 2005 3:34 PM > To: Michael Hammer (mhammer); enum at ietf.org > Subject: Re: [Enum] Clarification on Carrier ENUM discussions > > >I have serious problems with the statement that only carriers can > >discover a point of interconnect for a carrier given an E.164 number. > > In Carrier ENUM, who else? > > >We do not need walled ENUM gardens, and this will certainly require > >regulators in each country to get involved. > > Who is "we"? ;-) I think it was Metcalfe's Law that said that the value of the network was the square of the number of users that can interconnect. The PSTN has great value because any E.164 number can call any other E.164 number. The value of the Internet is great because one public IP address can reach another. Look at instant messaging. Everyone agrees that having non-interoperable islands is not good. Thus efforts to provide for interoperability. Look at cellular networks. Without wide geographic coverage enabled by the possibility to roam, the value was limited. VoIP and ENUM will have value if it enables anyone to reach anyone else. We is anyone who wants to maximize the value of the network by making it easier to reach one another. Early in US telephone history there were many telephone companies, but because you could only call someone connected to the same company, there was not general reachability. The government stepped in and created one phone company and gave it a monopoly. Let's not repeat history. Note, I don't expect monopolies to be created, but the lawyers will fix what the technicians fail to accomplish. Do you want that? If the above does not describe you, who are you looking out for? Mike > > -richard > > ________________________________ > > Von: Michael Hammer (mhammer) [mailto:mhammer at cisco.com] > Gesendet: Mo 18.07.2005 21:21 > An: Stastny Richard; enum at ietf.org > Betreff: RE: [Enum] Clarification on Carrier ENUM discussions > > > > Richard, > > I have serious problems with the statement that only carriers > can discover a point of interconnect for a carrier given an > E.164 number. > We do not need walled ENUM gardens, and this will certainly > require regulators in each country to get involved. > > Mike > > > > -----Original Message----- > > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] > On Behalf > > Of Stastny Richard > > Sent: Tuesday, July 12, 2005 10:28 AM > > To: enum at ietf.org > > Subject: [Enum] Clarification on Carrier ENUM discussions > > > > Dear all, > > > > following the current discussions on carrier ENUM, I have a serious > > problem with some issues raised > > > > So to clarify some issues: > > We have on one side User ENUM, which is used by end-users to find > > other end-users. We so not need to define requirements here > and we do > > not need to discuss its purpose. > > > > On the other hand we have carrier ENUM. Carrier (or > > Infrastructure) ENUM is for carriers ONLY and ONLY > carriers-of-record > > are allowed to enter information there and ONLY carriers > may use the > > infromation, even if it may publicly available. Carier ENUM is > > required for carriers to announce their PoI (IP based or on > the PSTN) > > to other carriers, with ENUM based technology, that is NAPTRs using > > Enumservices such as "sip", "mms:mailto" or eventually "npd:tel" > > > > To do so, different methods may be used. > > > > A. use any tree in any domain (e.g foo.bar). Carriers may do so on > > their own choice and are already doing so. > > The problem here is that many trees exists. > > If the carriers want to use a commonly agreed tree, they have two > > options: agree on any tree out of .arpa or use > > > > B. an additional (side) tree in .arpa > > > > here 3 technically equivalent options exists > > > > 1. use carrier.arpa > > 2. use carrier.e164.arpa > > 3. use carrier.c.c.e164.arpa > > > > For the avoidance of doubt, carrier could also be "c" od "foo" > > as Otmar pointed out and NOT the name of the carrier (the SPID) > > > > Any discussion of draft-haberler should restrict itself to the > > question where to put "carrier" or "c" or "foo" and how to find the > > proper side tree within the carriers ENUM client and NOT > e.g. asking > > questions like: > > > > "How does my > > (Scottish) handset figure out what the names (or codes) > exist for the > > telco operators in say Austria? Which one of these Austrian > telcos is > > it supposed to prefer? How do I get my handset to pick a > new preferred > > partner for calls to Austria whenever I port my number to another > > Scottish telco or if the preferred telco in Austria has > been renamed > > (or gone bust)?" > > > > This question has nothing to do with the problem at hand > not even with > > ENUM at all (not even in Scottland ;-) > > > > First: a handset (end-user) will never query carrier enum > and even a > > telco querying carrier ENUM does not have to find out which > telco to > > query or to prefer. ENU will give you this information. And > a number > > may only be hosted by one telco at a time. > > > > -richard > > > > > > > > _______________________________________________ > > enum mailing list > > enum at ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ppfautz@att.com Thu, 21 Jul 2005 13:52:09 -0400 From: "Pfautz, Penn L, NEO" Date: Thu, 21 Jul 2005 13:52:09 -0400 To: "Stastny Richard" Subject: RE: [Enum] Clarification on Carrier ENUM discussions Message-ID: <34DA635B184A644DA4588E260EC0A25A0AB55801@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Status: R -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Stastny Richard Sent: Thursday, July 21, 2005 1:51 PM To: Michael Hammer (mhammer); enum at ietf.org Subject: Re: [Enum] Clarification on Carrier ENUM discussions A user can never use a PoI of a carrier. >>>never say never.... _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 22 Jul 2005 10:14:39 -0400 From: Richard Shockey Date: Fri, 22 Jul 2005 10:14:39 -0400 To: Stastny Richard Subject: Re: [Enum] A shameless plug for my new job. In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C043@oefeg-s04.oefeg.loc> Message-ID: <42E0FF27.4030907@shockey.us> MIME-Version: 1.0 Content-Type: text/plain Status: R Stastny Richard wrote: I believe its important and ultimately relevant to what the ENUM WG wants to accomplish over time. Hm? I always thought ENUM was for DIRECT peering between PBX Why do I need a suddenly a SIP Service provider in between? Well again this topic is rather orthogonal to ENUM but obviously for a considerable time most endpoints will continue to be on the PSTN and many enterprises etc would like to trunk their calls via sip directly to a SP for PSTN termination.. Just for my information, some other minor questions: How does this relate to the work of SIPConnect? It is the formal continuation of the SIPConnect work Its the SIP trunking issue. In this respect, the PBX is to be viewed logically as a single SIP user agent for the purposes of the interface specification. So it is a B2BUA? not necessiarily I miss the 3-letter word SBC in your text ;-) it was deliberate :-) BTW, what is the opinion of Henry to the scope of this group? regards -richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Richard Shockey Gesendet: Do 21.07.2005 03:38 An: enum at ietf.org Betreff: [Enum] A shameless plug for my new job. NO I have not left NeuStar. For quite some time I've been extremely interested in technical issues surrounding how IP-PBX's and Service Provider can interconnect. The SIP Forum http://www.sipforum.com/ has established a working group charged with: This task group will produce one or more SIP Forum recommendations that define a common set of implementation rules for implementers who desire to interface an IP PBX with a SIP-enabled service provider. The recommendation(s) will specify which standards must be supported, provide precise guidance in the areas where the standards leave multiple options, supplement functionality gaps in existing protocols, and identify a baseline set of features that should be common to an IP PBX to service provider interface. Such guidelines will not preclude the implementation of additional SIP functionality and primitives that do not conflict with the common implementation rules of the recommendation(s). For purposes of this task group a SIP-enabled IP PBX is defined as a private, multi-user communications system that supports a clearly-defined baseline set of SIP standards along with other (optional) protocols. At a high level, the interface to the service provider utilizes a combination of SIP signaling and media transport using RTP. The interface to end-users of the IP PBX can be SIP or any other protocol capable of establishing a voice session (such as SCCP, H.323, directly connected analog "black phone", etc.) While vendor implementation choices vary (i.e. the PBX may be comprised of multiple servers and SIP endpoints), the SIP signaling exchanged with a service provider must be traceable to a single account identity, which may be a separate identity from users of the PBX. In this respect, the PBX is to be viewed logically as a single SIP user agent for the purposes of the interface specification. This does not preclude, however, the capability for media to be exchanged directly between the service provider and PBX-controlled IP endpoints such as IP phones and media terminal adaptors. ########## I will be chairing this effort. I believe its important and ultimately relevant to what the ENUM WG wants to accomplish over time. The reason the SIP Forum is dealing with this issue is that SIPPING determined that such an activity is out of scope for an IETF working group and better handled in a industry working forum. ########### This preliminary charter will change but I believe it is important work that may of you may be interested in. Information on the WG list is avaiable below. Particpitation in this WG will be under the same general terms and conditions that the ITEF operates under though the SIP Forum Intellectual policy has yet to be firmly estabilshed. Send mail to: techwg at sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg -- 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 at 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Fri, 22 Jul 2005 10:31:20 -0400 From: "Stastny Richard" Date: Fri, 22 Jul 2005 10:31:20 -0400 To: "Richard Shockey" Subject: Re: [Enum] A shameless plug for my new job. Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C04A@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Thanks for the clarification. So the group is defining an UNI Are there any plans to set up a similar group to define a NNI (PoI) or real VoIP Peering between Service Providers? -richard ________________________________ Von: Richard Shockey [mailto:richard at shockey.us] Gesendet: Fr 22.07.2005 16:13 An: Stastny Richard Cc: enum at ietf.org; henry at sinnreich.net Betreff: Re: [Enum] A shameless plug for my new job. Stastny Richard wrote: >>I believe its important and ultimately relevant to what the ENUM WG >>wants to accomplish over time. >> >> > >Hm? > >I always thought ENUM was for DIRECT peering between PBX >Why do I need a suddenly a SIP Service provider in between? > > Well again this topic is rather orthogonal to ENUM but obviously for a considerable time most endpoints will continue to be on the PSTN and many enterprises etc would like to trunk their calls via sip directly to a SP for PSTN termination.. > >Just for my information, some other minor questions: > >How does this relate to the work of SIPConnect? > > It is the formal continuation of the SIPConnect work Its the SIP trunking issue. > > > >>In this respect, the PBX is to >>be viewed logically as a single SIP user agent for the purposes of the >>interface specification. >> >> > >So it is a B2BUA? > > not necessiarily >I miss the 3-letter word SBC in your text ;-) > > it was deliberate :-) >BTW, what is the opinion of Henry to the scope of this group? > >regards > >-richard > > >________________________________ > >Von: enum-bounces at ietf.org im Auftrag von Richard Shockey >Gesendet: Do 21.07.2005 03:38 >An: enum at ietf.org >Betreff: [Enum] A shameless plug for my new job. > > > >NO I have not left NeuStar. > >For quite some time I've been extremely interested in technical issues >surrounding how IP-PBX's and Service Provider can interconnect. > >The SIP Forum > >http://www.sipforum.com/ > >has established a working group charged with: > >This task group will produce one or more SIP Forum recommendations that >define a common set of implementation rules for implementers who desire >to interface an IP PBX with a SIP-enabled service provider. The >recommendation(s) will specify which standards must be supported, >provide precise guidance in the areas where the standards leave multiple >options, supplement functionality gaps in existing protocols, and >identify a baseline set of features that should be common to an IP PBX >to service provider interface. Such guidelines will not preclude the >implementation of additional SIP functionality and primitives that do >not conflict with the common implementation rules of the recommendation(s). > >For purposes of this task group a SIP-enabled IP PBX is defined as a >private, multi-user communications system that supports a >clearly-defined baseline set of SIP standards along with other >(optional) protocols. At a high level, the interface to the service >provider utilizes a combination of SIP signaling and media transport >using RTP. The interface to end-users of the IP PBX can be SIP or any >other protocol capable of establishing a voice session (such as SCCP, >H.323, directly connected analog "black phone", etc.) While vendor >implementation choices vary (i.e. the PBX may be comprised of multiple >servers and SIP endpoints), the SIP signaling exchanged with a service >provider must be traceable to a single account identity, which may be a >separate identity from users of the PBX. In this respect, the PBX is to >be viewed logically as a single SIP user agent for the purposes of the >interface specification. This does not preclude, however, the capability >for media to be exchanged directly between the service provider and >PBX-controlled IP endpoints such as IP phones and media terminal adaptors. > >########## > >I will be chairing this effort. > >I believe its important and ultimately relevant to what the ENUM WG >wants to accomplish over time. > >The reason the SIP Forum is dealing with this issue is that SIPPING >determined that such an activity is out of scope for an IETF working >group and better handled in a industry working forum. > >########### > >This preliminary charter will change but I believe it is important work >that may of you may be interested in. Information on the WG list is >avaiable below. Particpitation in this WG will be under the same general >terms and conditions that the ITEF operates under though the SIP Forum >Intellectual policy has yet to be firmly estabilshed. > >Send mail to: techwg at sipforum.org >Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg > > > >-- > > > >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 at 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Fri, 22 Jul 2005 11:05:54 -0400 From: "Stastny Richard" Date: Fri, 22 Jul 2005 11:05:54 -0400 To: "Richard Shockey" Subject: RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C04B@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Dear all, although I did not receive (yet) any response to my e-mail below, I want to comment on the mentioned draft: I have a question to the following paragraph: "The following Enumservice is registered with this document: "npd" to indicate number portability data. The purpose of this Enumservice is to describe information about telephone numbers which cannot be used on the public Internet or a private/peered Internet Protocol (IP) network. Thus, these are numbers which are only reachable via the traditional Public Switched Telephone Network (PSTN)." The second sentence seems to imply that ONLY ported numbers will be used with the Enumservice "npd". The example 4.2 indicates that also non-ported numbers may be used. The third sentence is simply not true: I myself have ported numbers that can be reached on the public Internet via SIP URIs. IMHO there is a more in-depth analysis required how this Enumservice is used, what it implies and with which other Enumservices it can be used togother There is also a need to consolidate the different Enumservices using the tel URI and their use in User and Carrier ENUM. Also the usage of crosspointers (entries in User ENUM pointing to Carrier ENUM and vice versa) with tel URIs is necessary. One example is the usage of ENUM-only numbers existing only in User ENUM (e.g. +43780 and +87810). Here a pointer in Carrier ENUM may be useful to point from Carrier ENUM to User ENUM. Such a number may have a routing number , but this routing numbers are only of national significance and cannot be used in a global system. There is also missing a note that with this Enumservice the tel URI MUST always contain the same number then the AUS. regards -richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Stastny Richard Gesendet: So 10.07.2005 14:51 An: Richard Shockey; enum at ietf.org Betreff: Re: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Dear all, especially Allison Mankin, I consider this I-D very interesting, because I also proposed in the past to use the parameters defined in draft-ietf-iptel-tel-np-06.txt e.g. ";rn=" within ENUM, but did not bring this forward because of reason stated below. Before I comment on this draft and raise some questions, I would like to get some principle statements from our esteemed AD Allison if this draft is within the scope of IETF and ENUM WG. The rationale for this question is the following: The intended use of the Enumservice "npd:tel" is primarily for carriers, because only carriers my interpret and use the "rn= parameter. Routing numbers MUST NEVER be used by end-users. During the discussion Lawrence Conroy and I had with Ted Hardie and Allison Mankin in Geneva in May regarding the I-D draft-ietf-enum-msg-04.txt, especially about Enumservice "mms:mailto", I mentioned the fact that this Enumservice MAY also be used by carriers. Allison did not like this statement at all and said ENUM and Enumservices to-be-defined are ONLY for end-user usage. I only got over this hurdle by confirming that "mms:mailto" is ALSO useful for end-users. Therefore I want to have a clear statement from the responsible AD if an Enumservice for carrier use ONLY is within the scope of ENUM WG, before I waste my time in discussing this I-D on the list. Richard Stastny ________________________________ Von: enum-bounces at ietf.org im Auftrag von Richard Shockey Gesendet: Fr 08.07.2005 22:52 An: enum at ietf.org Betreff: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt >To: i-d-announce at ietf.org >From: Internet-Drafts at ietf.org >Date: Fri, 08 Jul 2005 15:50:01 -0400 >X-Spam-Score: 0.4 (/) >X-Scan-Signature: 73734d43604d52d23b3eba644a169745 >X-BeenThere: i-d-announce at ietf.org >X-Mailman-Version: 2.1.5 >Reply-To: internet-drafts at ietf.org >List-Id: i-d-announce.ietf.org >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >Sender: i-d-announce-bounces at ietf.org >X-SongbirdInformation: support at songbird.com for more information >X-Songbird: Found to be clean >X-Songbird-From: i-d-announce-bounces at ietf.org >Subject: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt >X-Keywords: > > > > >X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA11687 > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : IANA Registration for an Enumservice > Containing Number Portability and PSTN > Signaling Information > Author(s) : J. Livingood, R. Shockey > Filename : draft-livingood-shockey-enum-npd-00.txt > Pages : 8 > Date : 2005-7-8 > > This document registers the Enumservice "npd" and subtype "tel" using > the URI scheme 'tel:' as per the IANA registration process defined in > the ENUM specification, RFC 3761. This data is used to facilitate > the routing of telephone calls in those countries where Number > Portability exists. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-livingood-shockey-enum-npd-00.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request at 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-livingood-shockey-enum-npd-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 at ietf.org. >In the body type: > "FILE /internet-drafts/draft-livingood-shockey-enum-npd-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. > >Content-Type: text/plain >Content-ID: <2005-7-8104034.I-D at ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-livingood-shockey-enum-npd-00.txt > > > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce at ietf.org >https://www1.ietf.org/mailman/listinfo/i-d-announce >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 22 Jul 2005 12:01:59 -0400 From: Richard Shockey Date: Fri, 22 Jul 2005 12:01:59 -0400 To: enum at ietf.org Subject: [Enum] Required reading for IETF Paris Message-ID: <42E11861.8090402@shockey.us> MIME-Version: 1.0 Content-Type: text/plain Status: R Ths Systems Standards Stockholm Syndrome http://www.bcr.com/bcrmag/2005/07/p62.php -- 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Fri, 22 Jul 2005 12:16:37 -0400 From: "Stastny Richard" Date: Fri, 22 Jul 2005 12:16:37 -0400 To: "Richard Shockey" Subject: RE: [Enum] Required reading for IETF Paris Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C04D@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Not to forget: http://www.bcr.com/bcrmag/2005/06/p18.php IMS 101: What you Need to Know Maybe it will be very useful to crosspost this to Voipeer and Sipping ;-) -richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Richard Shockey Gesendet: Fr 22.07.2005 18:01 An: enum at ietf.org Betreff: [Enum] Required reading for IETF Paris Ths Systems Standards Stockholm Syndrome http://www.bcr.com/bcrmag/2005/07/p62.php -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 22 Jul 2005 12:47:02 -0400 From: Richard Shockey Date: Fri, 22 Jul 2005 12:47:02 -0400 To: Stastny Richard Subject: Re: [Enum] Required reading for IETF Paris In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C04D@oefeg-s04.oefeg.loc> Message-ID: <42E122F2.5060102@shockey.us> MIME-Version: 1.0 Content-Type: text/plain Status: R Stastny Richard wrote: Not to forget: http://www.bcr.com/bcrmag/2005/06/p18.php IMS 101: What you Need to Know Maybe it will be very useful to crosspost this to Voipeer and Sipping ;-) dont forget IETF Discuss :-) -richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Richard Shockey Gesendet: Fr 22.07.2005 18:01 An: enum at ietf.org Betreff: [Enum] Required reading for IETF Paris Ths Systems Standards Stockholm Syndrome http://www.bcr.com/bcrmag/2005/07/p62.php -- 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Fri, 22 Jul 2005 12:49:45 -0400 From: Richard Shockey Date: Fri, 22 Jul 2005 12:49:45 -0400 To: Stastny Richard Subject: Re: [Enum] A shameless plug for my new job. In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C04A@oefeg-s04.oefeg.loc> Message-ID: <42E1239B.2040504@shockey.us> MIME-Version: 1.0 Content-Type: text/plain Status: R Stastny Richard wrote: Thanks for the clarification. So the group is defining an UNI precicely .. Are there any plans to set up a similar group to define a NNI (PoI) or real VoIP Peering between Service Providers? not in SIPForum .. ATIS in the US is starting to "talk". I'm sure we're going to hear more about this at the voipeer BOF on thursday. -richard ________________________________ Von: Richard Shockey [mailto:richard at shockey.us] Gesendet: Fr 22.07.2005 16:13 An: Stastny Richard Cc: enum at ietf.org; henry at sinnreich.net Betreff: Re: [Enum] A shameless plug for my new job. Stastny Richard wrote: I believe its important and ultimately relevant to what the ENUM WG wants to accomplish over time. 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From andy@hxr.us Fri, 22 Jul 2005 13:37:25 -0400 From: Andrew Newton Date: Fri, 22 Jul 2005 13:37:25 -0400 To: Otmar Lendl Subject: Re: Question: [Enum] I-D ACTION:draft-ietf-enum-iris-ereg-01.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Otmar, Thanks for your comments. My response is in-line: On Jul 21, 2005, at 9:06 AM, Otmar Lendl wrote: * Terminology. You use "ENUM" as a shortcut for what is usually called "ENUM domain". For me, the single word "ENUM" stands for the overall standard (as defined in RFC3761). Perhaps this shortening is inevitable (just as "static IP address" is often shortened to just "static IP"), but I'm uncomfortable to legitimize such language via official documents. This is covered in section 2. However, I have no trouble changing the terminology throughout the document, especially if you think it provides better clarity and readability. Btw, what *is* the official explanation of the word ENUM? (other than just being a word play on "electronic numbering"?) Good question. * Domain vs. Number As long as there is a 1:1 mapping between domains and numbers this is just a question about syntax, but fuer the Austrian ENUM registry we decided to use the E.164 number as the primary data object and not the resulting domain. Rationale: The number is much better suited for human reading than ENUM domains, so we prefer to have numbers in logs, error- messages and protocol fields. Furthermore, when expanding the registry to cover more than just ENUM dns (e.g. more generic number assignment, E-911, NP) it becomes even more natural to deal with numbers and not with domains. The reason for the current model is, as you stated, the 1:1 mapping between domain and numbers. Splitting the two out may add extra complexity, but your rationale has merit. So I guess the big question here is "Do we think this will be used beyond ENUM?" If so, then I think this change is in order. * Domain status: How would you map the cases "domain marked for deletion" and "deleted and in grace period" to your choices? Does "assignedAndOnHold" mean that the delegation is active or not? Confusing, isn't it? This uses the 3982 status values, but perhaps it should be refined (in both places). The status values of and should be independent so they can be combined in the necessary ways. I've known about this problem, and I don't know why I didn't fix it. * Contact schema: Your contact schema seems to be rather close to the dreg contact from RFC 3982. What is the rationale to duplicate the definition vs. including the dreg schema? Is your contact obejct compatible to the EPP contact object? (I haven't checked this one.) What about reusing the schema from the EPP rfcs? The rationale for making it separate is to allow this specification to be modified separately of DREG and EPP (not all registries that use EPP use IRIS and vice versa). If you look at AREG, you'll notice this is true. [side comment: the +43 live ENUM registry uses a different contact schema to be compatible with the Austrian phonebook.] If you provide the details, I can change the schema to be compatible if you would like. Again, this is the reason why it is separate from DREG. * Host schema: Same as for contact. * I'm not sure if I got this right: The entityName attribute of registrationAuthority or validationAuthority acts as the unique identifier of said entity in the context of that registry? E.g. the EPP clID [i.e. the Registrar-ID] should be put into that field? The entity name needs to be unique with in its entity class of the registry (if it is not temporary). Otherwise, it can be what you want it to be. This is so clients can properly reference the object. * Your ValidationResult is very close to the Validation Token I describe in draft-lendl-enum-validation-token-00. It contains the same basic fields and just omits the digital signature and the optional owner date. I did not include the digital signature because I was uncertain of its application and thought it was only relevant in authentication during provisioning. But I could be convinced otherwise. What is the owner date? Is that the created date? -andy _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Rich.Shockey@neustar.biz Fri, 22 Jul 2005 14:46:27 -0400 From: Richard Shockey Date: Fri, 22 Jul 2005 14:46:27 -0400 To: Stastny Richard Subject: Re: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C04B@oefeg-s04.oefeg.loc> Message-ID: <42E13EED.80006@neustar.biz> MIME-Version: 1.0 Content-Type: text/plain Status: R Stastny Richard wrote: Dear all, although I did not receive (yet) any response to my e-mail below, I want to comment on the mentioned draft: I have a question to the following paragraph: "The following Enumservice is registered with this document: "npd" to indicate number portability data. The purpose of this Enumservice is to describe information about telephone numbers which cannot be used on the public Internet or a private/peered Internet Protocol (IP) network. Thus, these are numbers which are only reachable via the traditional Public Switched Telephone Network (PSTN)." The second sentence seems to imply that ONLY ported numbers will be used with the Enumservice "npd". The example 4.2 indicates that also non-ported numbers may be used. That is not true. The ENUM serive npd indicated number portability data that may be associated with any telephone number. The examples in the textare quite clear that the information relates to both Ported and NonPorted numbers. 4.1 Example of a Ported Telephone Number $ORIGIN 3.1.8.7.1.8.9.5.1.2.1.e164.arpa. NAPTR 10 100 "u" "E2U+npd:tel" "!^.*$!tel:+1-215-981-7813;rn=+1-215-981-7600;npdi!" In this example, a Routing Number (rn) and a Number Portability Dip Indicator (npdi) are used as shown in draft-ietf-iptel-tel-np-06.txt [10] (Internet-Draft New Parameters for the "tel" URI to Support Number Portability, draft-ietf-iptel-tel-np-06.txt [10]). The ‘npdi’ field is included in order to prevent subsequent lookups in legacy- style PSTN databases. 4.2 Example of a Non-Ported Telephone Number $ORIGIN 3.1.8.7.1.8.9.5.1.2.1.e164.arpa. NAPTR 10 100 "u" "E2U+npd:tel" "!^.*$!tel:+1-215-981-7813;npdi!" I have had a private request to consider an alternative formation of th e URI. as in The modification is to define a new enumservice field. E2U+npd:sip with the URI defined something like this. NAPTR 10 10 "u" "E2U+npd:sip" "!^.*$!sip:+15714345651 at mg4.mso.net;rn=+15712768933;npdi!" the rationale for this is that many gateways dont know what tel URI's are. The third sentence is simply not true: I myself have ported numbers that can be reached on the public Internet via SIP URIs. A fair criticism a better wording might have been. "Thus, this information is only useful in a national specific context within the traditional Public Switched Telephone Network (PSTN)." IMHO there is a more in-depth analysis required how this Enumservice is used, what it implies and with which other Enumservices it can be used togother There is also a need to consolidate the different Enumservices using the tel URI and their use in User and Carrier ENUM. Also the usage of crosspointers (entries in User ENUM pointing to Carrier ENUM and vice versa) with tel URIs is necessary. For what purpose? One example is the usage of ENUM-only numbers existing only in User ENUM (e.g. +43780 and +87810). Here a pointer in Carrier ENUM may be useful to point from Carrier ENUM to User ENUM. Such a number may have a routing number , but this routing numbers are only of national significance and cannot be used in a global system. There is also missing a note that with this Enumservice the tel URI MUST always contain the same number then the AUS. regards -richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Stastny Richard Gesendet: So 10.07.2005 14:51 An: Richard Shockey; enum at ietf.org Betreff: Re: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Dear all, especially Allison Mankin, I consider this I-D very interesting, because I also proposed in the past to use the parameters defined in draft-ietf-iptel-tel-np-06.txt e.g. ";rn=" within ENUM, but did not bring this forward because of reason stated below. Before I comment on this draft and raise some questions, I would like to get some principle statements from our esteemed AD Allison if this draft is within the scope of IETF and ENUM WG. The rationale for this question is the following: The intended use of the Enumservice "npd:tel" is primarily for carriers, because only carriers my interpret and use the "rn= parameter. Routing numbers MUST NEVER be used by end-users. During the discussion Lawrence Conroy and I had with Ted Hardie and Allison Mankin in Geneva in May regarding the I-D draft-ietf-enum-msg-04.txt, especially about Enumservice "mms:mailto", I mentioned the fact that this Enumservice MAY also be used by carriers. Allison did not like this statement at all and said ENUM and Enumservices to-be-defined are ONLY for end-user usage. I only got over this hurdle by confirming that "mms:mailto" is ALSO useful for end-users. Therefore I want to have a clear statement from the responsible AD if an Enumservice for carrier use ONLY is within the scope of ENUM WG, before I waste my time in discussing this I-D on the list. Richard Stastny -- 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Fri, 22 Jul 2005 16:37:09 -0400 From: "Michael Hammer \(mhammer\)" Date: Fri, 22 Jul 2005 16:37:09 -0400 To: "Michael Haberler" Subject: RE: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris) Message-ID: <072C5B76F7CEAB488172C6F64B30B5E35E8CB4@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Inline. > -----Original Message----- > From: Michael Haberler [mailto:mah at inode.at] > Sent: Monday, July 18, 2005 9:50 PM > To: Michael Hammer (mhammer) > Cc: enum at ietf.org > Subject: RE: Carrier ENUM Definition (was RE: [Enum] Agenda > items forIETF Paris) > > At 21:21 18.07.2005, Michael Hammer \(mhammer\) wrote: > > >Michael, > > > >We are still not there yet. > > > >I am party A. I get an E.164 number directly from the number > >administrator (not through a carrier) and put it in User ENUM. > > did you contract a telco to route that number in the PSTN > once you got it, or not? This number could have been set aside as a VoIP number, thus the PSTN would route a call to a PSTN gateway that should look it up in User ENUM and could route over the Internet to me. Of course there is no regulation requiring them to do so. But, if they didn't you would find such numbers useless, begging the question of why a national public resource is wasted. The caller has contracted with the carrier to deliver the call, so why should the carrier not attempt to deliver it? > >My mother is party B. She gets E.164 number from a carrier who has > >moved her over to VoIP and puts that number in Carrier ENUM, > but doesn't > >tell her anything about User ENUM. (She doesn't monitor ENUM WG > >mailer.) > > > >My mother can call me, since carrier is smart enough to look me up in > >User ENUM. But, they are not required to do so! So, maybe she can't > >call me. > > > >Can I call my mother? No. > > Yes, and that is your problem, not an ENUM problem. It is an ENUM problem if a carrier point of interconnect address is not available. It is a SIP problem once I have an IP address to route the call to. > >I do lookup in User ENUM and she is not > >there. > >I (according to you) may not have access to Carrier ENUM, or > >even if I did, sending a call to the interconnect point would be > >rejected because I don't have an interconnect agreement with every > >carrier. > > yes, that's how life is for phone users - I'll have to be a > customer of a > telco so I can be called by the non-User-ENUM-aware population. You've turned the problem around. Please stick with the given scenario. My mother, party B, ie the called party IS a carrier customer. And I as the caller am both User ENUM and Carrier ENUM aware. So, why wouldn't the carrier deliver the service to my mother that she is paying for? > >My only recourse is to get an E.164 number from a major > >carrier that likely has interconnect to my mother's carrier. > > No, your recourse is to contract a telco to route that number > in the PSTN, But, I don't want to route the call through the PSTN at all, I want to route the call through the Internet to the carrier VoIP network serving (supposedly) my mother! > just like everybody else does. For your ability to be called > by your mother > you' or your mother likely do not care about carrier ENUM or > not used by > your telcos, and frankly its not your business in the first > place if you > are a user. Carrier ENUM or not is a carrier business > decision (aka carrier > opt-in). How is opt-in by carriers going to be any better than opt-in by users? Sounds like a repeat of the same issues. If ENUM is to supplant LNP, then the same characteristic must exist of having wide visibility of what number belongs to what carrier. > Part of the misunderstanding we have might actually be based in the > historically fuzzy definition of number ownership and rights and > obligations attached to it. The fuzz factor comes in in two > ways a) a telco > sort of "owns" a number until a user ports away b) for individually > assigned numbers (as in my example +43 59966) the owner still > needs to turn > around and contract a telco to route it which sort of makes > him the "number > range holder" for a number you own - again until one ports > elsewhere. The > better term thus really is "carrier-of-record" which covers > all cases - > number issued out of a block, number ported to new carrier > (of record) and > individually assigned number "recorded" to be routed in the > PSTN by that telco. So really the carrier owns the number, not the end-user. > >The end result will be that User ENUM dies and we all have > to get E.164 > >from and subscribe to carrier to get calls through. > > The current result is that telcos care zilch about user ENUM > and deliver > calls over the PSTN, which is why you are well advised to > have a telco > route to your number no matter how you'd obtained it, so you > can be called > by the 99.999999% of non-user-ENUM telephone users. > > The medium result might be that telcos migrate to IP > interconnect but just > dont give up their habits yet. Enlightened telcos might > consult User ENUM, > too, besides some other mechanism to drive their IP > interconnect, but that > doesnt make my day. > > The long term result might be that telcos get revenue through useful > service to customers and not by charging at the termination > bottleneck. > Whoa.. what a concept.. Now you are getting the idea. But, your arguments are for retaining the status quo with all its regulations and tariffs. > > Whatever the outcome, I wouldnt operate on the assumption > that one can > force, or shortcut that development through IETF activity. An > offering > which aids migration between business models might help. An > approach which > exclusively addresses the 0.000001% scenario is likely to be > a very the > long road. It is only that percent if you preclude that as a viable option from the start. Mike > >What good is it to > >be able to communicate only to the miniscule minority that knows > >otherwise? > > That is in fact an excellent question, and encapsulates the User ENUM > adoption problem entirely. > > The fact that you own an E.164 identifier doesnt give you the > right to > force everbody else in the world to deliver to said > identifier in a way you > would like (and I would like, put the PSTN aint like email). > > -Michael > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Fri, 22 Jul 2005 16:37:22 -0400 From: "Michael Hammer \(mhammer\)" Date: Fri, 22 Jul 2005 16:37:22 -0400 To: "Stastny Richard" Subject: RE: [Enum] E.164 communication assumptions/requirements Message-ID: <072C5B76F7CEAB488172C6F64B30B5E35E8CB1@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard, A conclusion from your statements below is that if the number was assigned by the national numbering authority to the carrier, and not directly to the end-user, then that number can not be in User ENUM, only in Carrier ENUM. Was that really the intent? Since there seems to be no mechanisms to synchronize what is going on in User ENUM from Carrier ENUM, then I would also conclude that no E.164 number can appear in both User ENUM and Carrier ENUM at the same time. Otherwise, we get from queries to both that E.164 number belongs to both parties X and Y at the same time, i.e. calls based on each terminate to different places. Is that correct? I think I am missing something here. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Stastny Richard > Sent: Tuesday, July 19, 2005 11:49 AM > To: FOUQUART Philippe RD-CORE-ISS > Cc: enum at ietf.org > Subject: Re: [Enum] E.164 communication assumptions/requirements > > Philippe, > > thanks for pointing out again that nobody "owns" a E.164 > number (I gave up already ;-) the correct term is > Right-of-Use (RoU), which is always used in our national ENUM > documents. > > >Now whether we refer the "owner" or the "assignee" of the > E.164 number, > >I don't think that impacts infrastructure/ carrier Enum. > > Yes and no ;-) > > Both User ENUM and Infrastructure/Carrier ENUM use the DNS > and use domain names related to E.164 numbers, and because of > this these domains are a bit different to "normal" domains, > there are more like "sponsored" domains. > > In User ENUM the domain name holder can only be the end-user > having the RoU; and only during the time he has the RoU. > Note: Number Portability is NA in User ENUM because the RoU > does not change. > The End-user is directly responsible for the contents of the domainn > > In Carrier ENUM the domain name holder can only be the > Carrier-of-Record (see a previous posting that for the time > beeing this definition is a national matter) > Note: Therefore Number Portability IS an issue in Carrier > ENUM, because the Carrier-of-Record and therefore the domain > Name Holder changes. > In Carrier ENUM the end-user is only indirectly via the > current Carrier-of-record responsible for the content of the domain > > -richard > > > > ________________________________ > > Von: enum-bounces at ietf.org im Auftrag von FOUQUART Philippe > RD-CORE-ISS > Gesendet: Di 19.07.2005 16:34 > An: Ray Anderson; Pfautz, Penn L, NEO > Cc: enum at ietf.org > Betreff: RE: [Enum] E.164 communication assumptions/requirements > > > > Ray, Penn, > > I'm not sure you're in total disagreement :-) Even for > conversational services, there may be perfectly valid reasons > for not making E.164 numbers reachable (customer request, > barred portions of international CCs for all kinds of > reasons...) so I'm not sure that in principle an E.164 number > is automatically tied with reachability. > However, most national/international numbering plans are > under some pressure to accommodate all sorts of new services > in a space that's already assigned for the main part (and > demand may exceed supply). So there has to be criteria for > making sure that public resources are assigned where they're > most needed, a primary requirement being that these can be > reached from PSTN/PLMN. Reachability may therefore not be a > prerequisite for E.164 number assignment per se, but it is > often part of a sensible numbering plan management, let alone > national regulatory constraints as alluded to by Penn. > > For the ownership of an international numbering resource, I > don't believe a user or anyone can claim to be the owner of a > number, but I guess that's just a point of terminology. For a > short 'explanation' you may have a look at principle n°5 of > E.190, which along with E.164.1 sort of governs E.164 > numbering ("Assignment confers use of the resource but does > not imply ownership by the assignee".) For a moooore > substantial discussion you may want to try > http://www.ero.dk/documentation/docs/docfiles.asp?docid=1902&f > rames=0. It's not new but still applies to a large extent, > and I would assume this absence of ownership is pretty much a > constant of the numbering regulatory regimes within the EU. > Now whether we refer the "owner" or the "assignee" of the > E.164 number, I don't think that impacts infrastructure/ > carrier Enum. > > Hope this helps, > > Philippe Fouquart > R&D/CORE/NAS > +33 (0) 1 45 29 58 13 > > > > ________________________________ > > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Ray Anderson > Sent: Monday, July 18, 2005 10:22 PM > To: Pfautz, Penn L, NEO; enum at ietf.org > Subject: RE: [Enum] E.164 communication assumptions/requirements > > > At 13:45 18/07/2005, Pfautz, Penn L, NEO wrote: > > > Ray: > We could argue about whether these are ENUM > requirements. And use of numbers within assigned E.164 > country codes is largely a national matter. But at least > within the United States the reachability assumption is > likely to hold and use of NANP numbers for purposes such as > you describe (pure DNS indexes) are likely to be discouraged > by regulators. > > Penn Pfautz > > > I believe that some regulators will allow "free issue" of > large blocks of ENUM "space" for non voice purposes > > I also think that the ability to "change" your ENUM DNS > records is a good clue that you "own" that number, so it is > possible to use ENUM as a way of cost effectively verifying > who "owns" an E.164 number > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Fri, 22 Jul 2005 16:37:23 -0400 From: "Michael Hammer \(mhammer\)" Date: Fri, 22 Jul 2005 16:37:23 -0400 To: "Stastny Richard" Subject: RE: [Enum] VoIP Peering BoF - Naming and Addressing Issues Message-ID: <072C5B76F7CEAB488172C6F64B30B5E35E8CB2@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard, Could you clarify what you mean by "transit networks"? Are these data transport only networks, or do you mean to include networks that require transport and application layer functions to setup data network paths? That would be an interesting discussion point. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Stastny Richard > Sent: Monday, July 18, 2005 5:13 PM > To: voipeer at lists.uoregon.edu > Cc: enum at ietf.org > Subject: [Enum] VoIP Peering BoF - Naming and Addressing Issues > > This is my input on the BoF session on VoIP peering and > Interconnect dealing only with the first two issues on > (a) Call routing and > (b) ENUM and raising a third not yet mentioned issue: > > -Numbering, naming and addressing > > In my understanding the basic requirement of VoIP peering is > that voice calls (and other IP communications) originating on > IP and terminating on IP should stay on IP. There reason for > this has been stated in VOIP peering documents many times: > -better QoS > -more capabilities (BB codecs, presence, IM, video, etc.) > > Any call going via the PSTN will loose this advantages. > One (very) simple minded could ask the question: "And where > is the problem?" I also can send an e-mail to anybody as long > as I know his e-mail address. > > Currently the following "types" of "VoIP" exist (for > simplicity I assume only VoIP implemented using SIP): > > 1. freely accessible servers (proxies) on the public Internet > (ala e-mail) > > 2. servers on the public Internet, but requiring authentication > > 3. servers in private networks, accessible from the public > Internet via a Session Border Controller > > 4. servers in private networks, accessible from the public > Internet via a Session Border Controller (SBC), requiring > authentication > > 5. servers in private networks, accessible only via SBC from > other private networks, eventually via a commonly shared network. > > and for completeness: > > 6. servers in private networks only reachable via the PSTN > > 7. users on a PSTN network which is connected to the Internet > via gateway acting as SBC. > > There may exist other cases and more details, especially if > SIP, H323 and IMS systems are taken into account > > The first question that needs to be answered in a BoF session > on VoIP peering is: > > A. which of these scenarios are in- and out-of-scope > > After the scenarios are defined, the next question is how to > route calls between two servers. > > Routing of calls implies to find out in the originating > network the destination network and, if there is no direct > interconnection between origination network and destination > network, the transit networks required to interconnect. > > So we are back to question A.: "Are there transit networks > within the scenarios in-scope?" > > Routing of calls is done normally by analyzing the "public" > identifier of the called party the calling party enters. > > It is obvious that on IP IP-based addresses and names will be > used for routing, the basic question is: > > What are the "public" identifiers an end-user will enter? > > To make it simple: What identifier does one put on his business card? > > There are currently two choices: > -E.164 numbers > -sip AoR in the format sip:user at foo.bar > -both > > If it is E.164 numbers only, these E.164 numbers are > translated by some magic (e.g ENUM) to internal identifiers > e.g. sip AoR to find the routing. The assignement of these > E.164 is according to national rules. > > If it is SIP AoR, an additional question comes up: is an > end-user restricted to public identifiers given out by > providers such as richard.stastny AT vodafone.de > > or is it possible also to "port in" > identifiers such as richard AT stastny.com? > > If it is both, the E.164 identifiers need to be mapped to SIP > AoRs by some means e.g. ENUM. This ENUM cannot be USER ENUM > because the Carriers services relies on this mapping, so it > must be independant. > > For all these cases depending on the scenarios the required > mappings and access to DNS and IP addresses need to be > investigated and defined. > > Some preliminary work in this regard analyzing the possible > scenarios has been done by ETSI in TS 102 055 "Infrastructure ENUM". > > Richard Stastny > > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Fri, 22 Jul 2005 16:37:24 -0400 From: "Michael Hammer \(mhammer\)" Date: Fri, 22 Jul 2005 16:37:24 -0400 To: "Michael Haberler" Subject: RE: [Enum] Clarification on Carrier ENUM discussions Message-ID: <072C5B76F7CEAB488172C6F64B30B5E35E8CB0@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Michael, My vision is to leave a wide range of options open to users, enterprises, and carriers; and not arbitrarily shut down any possibilities via an RFC. I also want to try and keep the discovery of an address to which requests can be made (calls can be routed) and the actual operation of the service (ie SIP mechanisms) as distinct as possible. I as a user or some enterprise for that matter may wish to communicate to any other user or enterprise, that might just happen to use a carrier. It should not be a requirement that I involve a second carrier, if: 1) the carrier serving the terminating user/enterprise as a part of service agreement with that user is willing to accept calls from anywhere. 2) the carrier serving the terminating user could also direct the caller to an IVR that offers to setup a business relationship with that user (ie acquire a customer) that enables the caller to complete calls to the terminating party without originally coming from another service provider. So, my basic problem is that you are trying to do service control in Carrier ENUM instead of simply providing the addresses that let the SIP gateways implement whatever service they want. If you send an INVITE to a gateway, and I recognize that you are not a carrier with whom I have an SLA, then it is possible to provide a 300 redirection to an appropriate handler server. That is a SIP not an ENUM issue. Second, I don't think security through obscurity works long-term, so trying to make public DNS private for Carrier ENUM may not be the best route to go. It may be faster (and less prone to DOS bottlenecking) to provide a response, than attempt to authenticate the DNS requestor. These are some fine lines as to where certain services are performed. Views may vary. I am just trying to provide alternate views to avoid any group-think on this subject. Not being an ENUM insider, more attuned to SIP, I hoped to raise the question about where in these ENUM/SIP transaction flows should a call really be rejected. Hopefully, we make progress in understanding alternative views. Mike > -----Original Message----- > From: Michael Haberler [mailto:mah at inode.at] > Sent: Monday, July 18, 2005 9:00 PM > To: Michael Hammer (mhammer); Stastny Richard; enum at ietf.org > Subject: RE: [Enum] Clarification on Carrier ENUM discussions > > At 21:21 18.07.2005, Michael Hammer \(mhammer\) wrote: > > >Richard, > > > >I have serious problems with the statement that only carriers can > >discover a point of interconnect for a carrier given an E.164 number. > > What Richard meant was that just because you *know* the > network coordinates of POI for a number that doesnt imply > that you can *force* the telco operating that POI to accept > calls from, and terminate for you just because you like that > to be (assuming you not having an agreement with said telco), > regardless if you discover the POI coordinates through DNS, > published information or social engineering. > > >We do not need walled ENUM gardens, and this will certainly require > >regulators in each country to get involved. > > I'm a bit fuzzy on what are you're suggesting. > > Are you saying any URI which is entered by either User or > Carrier-of-Record must be publically reachable without > authentication (the latter would map to an underlying intent > or agreement)? > > I happen own a +43 780ff number, mapped to a URI in User > ENUM, and the SIP proxy for that URI accepts calls only from > the PSTN->IP gateway handling that number. > > Am I violating some vision here? is SIP authentication a > no-no or what is actually the issue? > > lost, > > -Michael > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Sat, 23 Jul 2005 08:10:22 -0400 From: lconroy Date: Sat, 23 Jul 2005 08:10:22 -0400 To: Richard Shockey Subject: Re: [Enum] Final Agenda items for IETF 63 Paris In-Reply-To: <6.2.1.2.2.20050712091704.04f2eeb0@wheresmymailserver.com> Message-ID: <94163E36-068E-4267-8201-3F62EACCD00E@insensate.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi Folks, In case no-one noticed, the mobileweb draft has been updated to "draft-ra-shin-enum-mobileweb-01.txt". This draft is covered in section 3.3 of the Agenda. I would suggest that folk look at the new version BEFORE the ENUM meeting - the changes are editorial rather than technical, but given how some people seem to have interpreted the -00 version so far, perhaps this one will clarify things and avoid unnecessary flights of fancy. I would also advise folk to look at the "modest proposal" draft, but as it seems vanishingly unlikely that there will be time to cover that in the meeting, questions/comments to the list would be appreciated. all the best, Lawrence On 14 Jul 2005, at 18:38, Richard Shockey wrote: It looks like Friday AM. Or, from the content to be covered, all day Friday (and most of the night) IETF 63 Telephone Number Mapping (ENUM) WG Agenda 0. AGENDA BASHING (5 min) 1. Review of the existing drafts - Ready to go top Last call ( 5-10 M ? ) Title : ENUM Implementation Issues and Experiences 2. Final disposition of IRIS EREG, hopefully to last call. ( 5 Min? ) 3. New/old work on enumservice registrations ( 20 M ) 3.1 Title : IANA Registration for Enumservice Voice 3.2 Title : IANA Registration for an Enumservice Containing Number Portability and PSTN Signaling Information 3.3 Title : IANA Registration for ENUMservice Mobile Webpage 4. ENUM Validation Issues. 3 Drafts 15-20 4.1 ENUM Validation Architecture draft-mayrhofer-enum- validation-arch-00 4.2 "ENUM Validation Token Format Definition" - draft-lendl-enum- validation-token-00.txt 4.3 EPP Validation Extension ################# 5. PART 2 1/2 hours. 3 Items 30 minutes - Ha Ha Ha! http://www.sdlind.com/draft-lind-infrastructure-enum-reqs-00.txt http://www.ietf.org/internet-drafts/draft-pfautz-lind-enum- carrier-user-00.txt http://www.ietf.org/internet-drafts/draft-haberler-carrier- enum-00.txt ...and finally, my modest proposal to clarify RFC3403 http://www.ietf.org/internet-drafts/draft-conroy-enum- modestproposal-00.txt 6. Discussion of ENUM WG recharter ? One assumes that this is for Friday night between 23:00 and 00:00. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From henry@sinnreich.net Sat, 23 Jul 2005 08:20:25 -0400 From: henry@sinnreich.net Date: Sat, 23 Jul 2005 08:20:25 -0400 To: "'Stastny Richard'" Subject: RE: [Enum] A shameless plug for my new job. In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C043@oefeg-s04.oefeg.loc> Message-ID: <200507220333.XAA16002@ietf.org> MIME-Version: 1.0 Content-Type: text/plain Status: R >BTW, what is the opinion of Henry to the scope of this group? I agree with Richard Stastny that no carrier is required for IP PBX IP-IP interconnect, but a _community of cooperating registrars_ is necessary. The scope of the WG could well be working all this out. Thanks, Henry -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] Sent: Thursday, July 21, 2005 12:03 PM To: Richard Shockey; enum at ietf.org; henry at sinnreich.net Subject: Re: [Enum] A shameless plug for my new job. >I believe its important and ultimately relevant to what the ENUM WG >wants to accomplish over time. Hm? I always thought ENUM was for DIRECT peering between PBX Why do I need a suddenly a SIP Service provider in between? Just for my information, some other minor questions: How does this relate to the work of SIPConnect? >In this respect, the PBX is to >be viewed logically as a single SIP user agent for the purposes of the >interface specification. BTW, what is the opinion of Henry to the scope of this group? I miss the 3-letter word SBC in your text ;-) BTW, what is the opinion of Henry to the scope of this group? regards -richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Richard Shockey Gesendet: Do 21.07.2005 03:38 An: enum at ietf.org Betreff: [Enum] A shameless plug for my new job. NO I have not left NeuStar. For quite some time I've been extremely interested in technical issues surrounding how IP-PBX's and Service Provider can interconnect. The SIP Forum http://www.sipforum.com/ has established a working group charged with: This task group will produce one or more SIP Forum recommendations that define a common set of implementation rules for implementers who desire to interface an IP PBX with a SIP-enabled service provider. The recommendation(s) will specify which standards must be supported, provide precise guidance in the areas where the standards leave multiple options, supplement functionality gaps in existing protocols, and identify a baseline set of features that should be common to an IP PBX to service provider interface. Such guidelines will not preclude the implementation of additional SIP functionality and primitives that do not conflict with the common implementation rules of the recommendation(s). For purposes of this task group a SIP-enabled IP PBX is defined as a private, multi-user communications system that supports a clearly-defined baseline set of SIP standards along with other (optional) protocols. At a high level, the interface to the service provider utilizes a combination of SIP signaling and media transport using RTP. The interface to end-users of the IP PBX can be SIP or any other protocol capable of establishing a voice session (such as SCCP, H.323, directly connected analog "black phone", etc.) While vendor implementation choices vary (i.e. the PBX may be comprised of multiple servers and SIP endpoints), the SIP signaling exchanged with a service provider must be traceable to a single account identity, which may be a separate identity from users of the PBX. In this respect, the PBX is to be viewed logically as a single SIP user agent for the purposes of the interface specification. This does not preclude, however, the capability for media to be exchanged directly between the service provider and PBX-controlled IP endpoints such as IP phones and media terminal adaptors. ########## I will be chairing this effort. I believe its important and ultimately relevant to what the ENUM WG wants to accomplish over time. The reason the SIP Forum is dealing with this issue is that SIPPING determined that such an activity is out of scope for an IETF working group and better handled in a industry working forum. ########### This preliminary charter will change but I believe it is important work that may of you may be interested in. Information on the WG list is avaiable below. Particpitation in this WG will be under the same general terms and conditions that the ITEF operates under though the SIP Forum Intellectual policy has yet to be firmly estabilshed. Send mail to: techwg at sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Sat, 23 Jul 2005 13:30:56 -0400 From: "Peter Williams" Date: Sat, 23 Jul 2005 13:30:56 -0400 To: ray at bango.net Subject: Re: [Enum] E.164 communication assumptions/requirements In-Reply-To: <6.1.2.0.2.20050719095349.0b310410@smtp.bango.net> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R It will be intresting to see if this "third party reliance" (aka piggybacking) security practice is ever authorized, in reality. The last 3 INTERNET infrastructures I worked in all denied this obvious practice. Once the infastructure player operates a branded (audited) process, the company will generally want any other companies who benefit from it to be paying for those reliance benefits....and come under the terms and conditions rules, etc. If we look at other examples of switched online identity databases wth federated trust models and multi-provider interconnect practices: (a) VISA will NOT let you use its accurate numbering, subscriber identification, privilege assignment, and switched trust system (VisaNet) as a way of verifying personal identity. That is, you cannot take a 1c visa purchase from a cardholder peter williams, and then claim you verified me as peter williams, with a 100k credit worthiness. (b) VeriSign will NOT let you rely on a SSL merchant cert, and then issue you own cert to that website operator - claiming "well VeriSign issued a cert, having done due dligence concerning the right-to-use rules (ENUM query on a E.164 registry, DNS registration, usb.org registration, IANA/DARPA MIB schema organizations...), and therefore "i have verified that "peter.com is clearly peter.com" when listing said "verified" name in my own _reissued_ (i.e. non-VeriSign) cert. (c) On the other hand, a variety of the practice is EXACTLY what many value added PSP providers do (in unauthorized fashion, generally) - relying on the email, paging company, or ISP provider's account management controls to boot up their own, independent trust model. We all respond to a email ping, and authenticate thereby to a new web site account. That is the website app relies on a third parties account accuracy representations when verifyng a new consumer's identity (i.e. those of the email service provider) when superimposing its own account susbcription/provisioning/publication processes. So, if I claim to own +441223472778 I might be asked to change the email address in the ENUM record to banana at bango.com If I can do that, it is assumed I am "all powerful" with respect to that number. The whole ENUM project should be causing E.164 owners to put into place varying levels of verification systems that we can piggyback on top of. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Mon, 25 Jul 2005 06:02:15 -0400 From: "Stastny Richard" Date: Mon, 25 Jul 2005 06:02:15 -0400 To: "Michael Hammer \(mhammer\)" Subject: RE: [Enum] E.164 communication assumptions/requirements Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C051@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Michael, >A conclusion from your statements below is that if the number was assigned by the national numbering authority to the >carrier, and not directly to the end-user, then that number can not be in User ENUM, only in Carrier ENUM. Was that >really the intent? I think you have a serious misunderstanding on (User) ENUM: In User ENUM an end-user may enter all numbers he has the right-to-use (and also provided the number range is open for ENUM with the national nubering scheme. In Austria end-users may enter all national numbers except value-added numbers (0900) and non-E164 numbers (logically), if he proves that he has the right-to-use this number. >Since there seems to be no mechanisms to synchronize what is going on in User ENUM from Carrier ENUM, then I would >also conclude that no E.164 number can appear in both User ENUM and Carrier ENUM at the same time. Otherwise, we >get from queries to both that E.164 number belongs to both parties X and Y at the same time, i.e. calls based on each >terminate to different places. Is that correct? No. As Rich Shockey and I pointed out many times, User ENUM and Carrier ENUM are completely independant (orthogonal) from each other. User ENUM is for End-users (both originating AND terminating) and Carrier ENUM is for Carriers. So the same number may (and will) show up in both User and Carrier ENUM. The end-user queries User ENUM, the Carrier queries Carrier ENUM. A Carrier MAY query User ENUM on behalf of the user in addition, if the user wants so (opt-in) and the carrier is providing this service. It is correct that in this case the call may terminatate in different places if the user chooses so. This is always the case for normal geographic numbers in user ENUM without Carrier ENUM -richard ________________________________ Von: Michael Hammer (mhammer) [mailto:mhammer at cisco.com] Gesendet: Fr 22.07.2005 22:36 An: Stastny Richard; FOUQUART Philippe RD-CORE-ISS Cc: enum at ietf.org Betreff: RE: [Enum] E.164 communication assumptions/requirements Richard, A conclusion from your statements below is that if the number was assigned by the national numbering authority to the carrier, and not directly to the end-user, then that number can not be in User ENUM, only in Carrier ENUM. Was that really the intent? Since there seems to be no mechanisms to synchronize what is going on in User ENUM from Carrier ENUM, then I would also conclude that no E.164 number can appear in both User ENUM and Carrier ENUM at the same time. Otherwise, we get from queries to both that E.164 number belongs to both parties X and Y at the same time, i.e. calls based on each terminate to different places. Is that correct? I think I am missing something here. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Stastny Richard > Sent: Tuesday, July 19, 2005 11:49 AM > To: FOUQUART Philippe RD-CORE-ISS > Cc: enum at ietf.org > Subject: Re: [Enum] E.164 communication assumptions/requirements > > Philippe, > > thanks for pointing out again that nobody "owns" a E.164 > number (I gave up already ;-) the correct term is > Right-of-Use (RoU), which is always used in our national ENUM > documents. > > >Now whether we refer the "owner" or the "assignee" of the > E.164 number, > >I don't think that impacts infrastructure/ carrier Enum. > > Yes and no ;-) > > Both User ENUM and Infrastructure/Carrier ENUM use the DNS > and use domain names related to E.164 numbers, and because of > this these domains are a bit different to "normal" domains, > there are more like "sponsored" domains. > > In User ENUM the domain name holder can only be the end-user > having the RoU; and only during the time he has the RoU. > Note: Number Portability is NA in User ENUM because the RoU > does not change. > The End-user is directly responsible for the contents of the domainn > > In Carrier ENUM the domain name holder can only be the > Carrier-of-Record (see a previous posting that for the time > beeing this definition is a national matter) > Note: Therefore Number Portability IS an issue in Carrier > ENUM, because the Carrier-of-Record and therefore the domain > Name Holder changes. > In Carrier ENUM the end-user is only indirectly via the > current Carrier-of-record responsible for the content of the domain > > -richard > > > > ________________________________ > > Von: enum-bounces at ietf.org im Auftrag von FOUQUART Philippe > RD-CORE-ISS > Gesendet: Di 19.07.2005 16:34 > An: Ray Anderson; Pfautz, Penn L, NEO > Cc: enum at ietf.org > Betreff: RE: [Enum] E.164 communication assumptions/requirements > > > > Ray, Penn, > > I'm not sure you're in total disagreement :-) Even for > conversational services, there may be perfectly valid reasons > for not making E.164 numbers reachable (customer request, > barred portions of international CCs for all kinds of > reasons...) so I'm not sure that in principle an E.164 number > is automatically tied with reachability. > However, most national/international numbering plans are > under some pressure to accommodate all sorts of new services > in a space that's already assigned for the main part (and > demand may exceed supply). So there has to be criteria for > making sure that public resources are assigned where they're > most needed, a primary requirement being that these can be > reached from PSTN/PLMN. Reachability may therefore not be a > prerequisite for E.164 number assignment per se, but it is > often part of a sensible numbering plan management, let alone > national regulatory constraints as alluded to by Penn. > > For the ownership of an international numbering resource, I > don't believe a user or anyone can claim to be the owner of a > number, but I guess that's just a point of terminology. For a > short 'explanation' you may have a look at principle n°5 of > E.190, which along with E.164.1 sort of governs E.164 > numbering ("Assignment confers use of the resource but does > not imply ownership by the assignee".) For a moooore > substantial discussion you may want to try > http://www.ero.dk/documentation/docs/docfiles.asp?docid=1902&f > rames=0. It's not new but still applies to a large extent, > and I would assume this absence of ownership is pretty much a > constant of the numbering regulatory regimes within the EU. > Now whether we refer the "owner" or the "assignee" of the > E.164 number, I don't think that impacts infrastructure/ > carrier Enum. > > Hope this helps, > > Philippe Fouquart > R&D/CORE/NAS > +33 (0) 1 45 29 58 13 > > > > ________________________________ > > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Ray Anderson > Sent: Monday, July 18, 2005 10:22 PM > To: Pfautz, Penn L, NEO; enum at ietf.org > Subject: RE: [Enum] E.164 communication assumptions/requirements > > > At 13:45 18/07/2005, Pfautz, Penn L, NEO wrote: > > > Ray: > We could argue about whether these are ENUM > requirements. And use of numbers within assigned E.164 > country codes is largely a national matter. But at least > within the United States the reachability assumption is > likely to hold and use of NANP numbers for purposes such as > you describe (pure DNS indexes) are likely to be discouraged > by regulators. > > Penn Pfautz > > > I believe that some regulators will allow "free issue" of > large blocks of ENUM "space" for non voice purposes > > I also think that the ability to "change" your ENUM DNS > records is a good clue that you "own" that number, so it is > possible to use ENUM as a way of cost effectively verifying > who "owns" an E.164 number > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Mon, 25 Jul 2005 06:19:59 -0400 From: "Stastny Richard" Date: Mon, 25 Jul 2005 06:19:59 -0400 To: "Richard Shockey" Subject: Re: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C052@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Rich, One comment first I basically like the idea of a generic tel Enumservice, whatever it is called. but I do not have thought through all implications Maybe we can discuss this in Paris (we have a whole week ;-) To your remarks: >That is not true. The ENUM serive npd indicated number portability data >that may be associated with any telephone number. >The examples in the textare quite clear that the information relates to >both Ported and NonPorted numbers. Thats what I said: Still, the sentence: "The purpose of this Enumservice is to describe information about telephone numbers which cannot be used on the public Internet or a private/peered Internet Protocol (IP) network. " is unclear (or wrong, because you can use proted numbers on the Public Internet (I do) >The modification is to define a new enumservice field. >E2U+npd:sip >with the URI defined something like this. >NAPTR 10 10 "u" "E2U+npd:sip" >"!^.*$!sip:+15714345651 at mg4.mso.net;rn=+15712768933;npdi!" >the rationale for this is that many gateways dont know what tel URI's are. Now I am completely lost. I tought the "npd" was a generic Enumservice giving the "rn" to be used (in the national network), but the gateway to user is your choice. One may even query this information from the PSTN via a IN-mediation device. Now you introduce a specific "transit" gateway. BTW: your example URI should be: sip:+15714345651;rn=+15712768933;npdi at mg4.mso.net >For what purpose? For this: > >One example is the usage of ENUM-only numbers existing only >in User ENUM (e.g. +43780 and +87810). Here a pointer in >Carrier ENUM may be useful to point from Carrier ENUM to >User ENUM. Such a number may have a routing number , but >this routing numbers are only of national significance and cannot >be used in a global system. > >There is also missing a note that with this Enumservice the tel URI >MUST always contain the same number then the AUS. ________________________________ Von: Richard Shockey [mailto:Rich.Shockey at neustar.biz] Gesendet: Fr 22.07.2005 20:46 An: Stastny Richard Cc: Richard Shockey; enum at ietf.org Betreff: Re: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Stastny Richard wrote: >Dear all, > >although I did not receive (yet) any response to my e-mail below, >I want to comment on the mentioned draft: > >I have a question to the following paragraph: > >"The following Enumservice is registered with this document: "npd" to > indicate number portability data. The purpose of this Enumservice is > to describe information about telephone numbers which cannot be used > on the public Internet or a private/peered Internet Protocol (IP) > network. Thus, these are numbers which are only reachable via the > traditional Public Switched Telephone Network (PSTN)." > >The second sentence seems to imply that ONLY ported numbers >will be used with the Enumservice "npd". The example 4.2 indicates >that also non-ported numbers may be used. > > That is not true. The ENUM serive npd indicated number portability data that may be associated with any telephone number. The examples in the textare quite clear that the information relates to both Ported and NonPorted numbers. 4.1 Example of a Ported Telephone Number $ORIGIN 3.1.8.7.1.8.9.5.1.2.1.e164.arpa. NAPTR 10 100 "u" "E2U+npd:tel" "!^.*$!tel:+1-215-981-7813;rn=+1-215-981-7600;npdi!" In this example, a Routing Number (rn) and a Number Portability Dip Indicator (npdi) are used as shown in draft-ietf-iptel-tel-np-06.txt [10] (Internet-Draft New Parameters for the "tel" URI to Support Number Portability, draft-ietf-iptel-tel-np-06.txt [10]). The 'npdi' field is included in order to prevent subsequent lookups in legacy- style PSTN databases. 4.2 Example of a Non-Ported Telephone Number $ORIGIN 3.1.8.7.1.8.9.5.1.2.1.e164.arpa. NAPTR 10 100 "u" "E2U+npd:tel" "!^.*$!tel:+1-215-981-7813;npdi!" I have had a private request to consider an alternative formation of th e URI. as in The modification is to define a new enumservice field. E2U+npd:sip with the URI defined something like this. NAPTR 10 10 "u" "E2U+npd:sip" "!^.*$!sip:+15714345651 at mg4.mso.net;rn=+15712768933;npdi!" the rationale for this is that many gateways dont know what tel URI's are. > >The third sentence is simply not true: I myself have ported numbers >that can be reached on the public Internet via SIP URIs. > > A fair criticism a better wording might have been. "Thus, this information is only useful in a national specific context within the traditional Public Switched Telephone Network (PSTN)." > >IMHO there is a more in-depth analysis required how this >Enumservice is used, what it implies and with which other >Enumservices it can be used togother > >There is also a need to consolidate the different Enumservices >using the tel URI and their use in User and Carrier ENUM. >Also the usage of crosspointers (entries in User ENUM pointing >to Carrier ENUM and vice versa) with tel URIs is necessary. > > For what purpose? > >One example is the usage of ENUM-only numbers existing only >in User ENUM (e.g. +43780 and +87810). Here a pointer in >Carrier ENUM may be useful to point from Carrier ENUM to >User ENUM. Such a number may have a routing number , but >this routing numbers are only of national significance and cannot >be used in a global system. > >There is also missing a note that with this Enumservice the tel URI >MUST always contain the same number then the AUS. > >regards > >-richard > >________________________________ > >Von: enum-bounces at ietf.org im Auftrag von Stastny Richard >Gesendet: So 10.07.2005 14:51 >An: Richard Shockey; enum at ietf.org >Betreff: Re: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt > > > >Dear all, especially Allison Mankin, > >I consider this I-D very interesting, because I also proposed in the past to use the >parameters defined in draft-ietf-iptel-tel-np-06.txt e.g. ";rn=" within ENUM, >but did not bring this forward because of reason stated below. > >Before I comment on this draft and raise some questions, I would like to >get some principle statements from our esteemed AD Allison if this draft >is within the scope of IETF and ENUM WG. > >The rationale for this question is the following: > >The intended use of the Enumservice "npd:tel" is primarily for >carriers, because only carriers my interpret and use the "rn= parameter. > >Routing numbers MUST NEVER be used by end-users. > >During the discussion Lawrence Conroy and I had with Ted Hardie >and Allison Mankin in Geneva in May regarding the I-D draft-ietf-enum-msg-04.txt, >especially about Enumservice "mms:mailto", I mentioned the fact that >this Enumservice MAY also be used by carriers. > >Allison did not like this statement at all and said ENUM and >Enumservices to-be-defined are ONLY for end-user usage. I only >got over this hurdle by confirming that "mms:mailto" is ALSO >useful for end-users. > >Therefore I want to have a clear statement from the responsible AD >if an Enumservice for carrier use ONLY is within the scope of ENUM WG, >before I waste my time in discussing this I-D on the list. > >Richard Stastny > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ray@bango.net Mon, 25 Jul 2005 07:55:20 -0400 From: Ray Anderson Date: Mon, 25 Jul 2005 07:55:20 -0400 To: enum at ietf.org Subject: [Enum] COMMENTS on draft-ra-shin-enum-mobileweb-01.txt Message-ID: <6.1.2.0.2.20050725124718.0333ece0@pop3.btconnect.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Here are my top level comments: The idea here seems to be to provide "clues" about the services available at an ENUM addressible site so that a device or user that could make use of those clues could provide a better service to the end user. The aims are good, but acfetr careful consideration I believe that this proposal is wrong in its approach, and also wrong as an ENUMservice. I recommend the authors get involved in the Mobile Web Initiative. http://www.w3.org/2005/MWI/ (1) Wrong Approach The W3C is currently engaged on a Mobile Web Initiative which is working hard to ensure that web sites can give an improved experience to mobile users. Currently most web sites are optimized to big screen users with a "PC environment (keyboard, distraction level etc.). There are many parts to this, not least of which is that the web site can use information presented by the end user device (HTTP_ACCEPT among others) to determine how best to deliver a good experience to users. In addition, the site can redirect to alternative services that might help, if teh device has certain characteristics. Therefore, the idea of tagging a site with different URL's that are selected between by the client device or the user should not be necessary, and in fact is more limited because the hosting site should be able to evolve and adapt its capabilities much faster than the client device. There are many reasons why one URL for content promotion / bookmarking / passing on is a good thing. Thats probably why the .MOBI TLD met with so much derision, and was rejected by W3C, 3GPP, and content providers. (2) Wrong as an ENUM service If the ENUM service approach (not withstanding the above) was to be useful, then surely it should be available across all domains, not just those in e164.arpa, for example in www.neustar.biz so that devices accessing those domains can also provide more appropriate URL's depending on the support for WAP, ME, iMode, xHTML, VoiceXML, Flash, etc. In that case, the extra "clues" should become a general DNS facility, otherwise only sites accessed by enum URL's could provide the ease of use. In that case I assume there is some other working group that should look at the proposal. At 13:09 23/07/2005, lconroy wrote: Hi Folks, In case no-one noticed, the mobileweb draft has been updated to "draft-ra-shin-enum-mobileweb-01.txt". This draft is covered in section 3.3 of the Agenda. I would suggest that folk look at the new version BEFORE the ENUM meeting - the changes are editorial rather than technical, but given how some people seem to have interpreted the -00 version so far, perhaps this one will clarify things and avoid unnecessary flights of fancy. I would also advise folk to look at the "modest proposal" draft, but as it seems vanishingly unlikely that there will be time to cover that in the meeting, questions/comments to the list would be appreciated. all the best, Lawrence _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ray@bango.net Mon, 25 Jul 2005 08:26:08 -0400 From: Ray Anderson Date: Mon, 25 Jul 2005 08:26:08 -0400 To: lconroy Subject: [Enum] COMMENTS on draft-ra-shin-enum-mobileweb-01.txt In-Reply-To: <6.2.1.2.2.20050712091704.04f2eeb0@wheresmymailserver.com> Message-ID: <6.1.2.0.2.20050725112408.0334d250@smtp.bango.net> MIME-Version: 1.0 Content-Type: text/plain Status: R Here are my top level comments: The idea here seems to be to provide "clues" about the services available at an ENUM addressible site so that a device or user that could make use of those clues could provide a better service to the end user. The aims are good, but acfetr careful consideration I believe that this proposal is wrong in its approach, and also wrong as an ENUMservice. I recommend the authors get involved in the Mobile Web Initiative. http://www.w3.org/2005/MWI/ (1) Wrong Approach The W3C is currently engaged on a Mobile Web Initiative which is working hard to ensure that web sites can give an improved experience to mobile users. Currently most web sites are optimized to big screen users with a "PC environment (keyboard, distraction level etc.). There are many parts to this, not least of which is that the web site can use information presented by the end user device (HTTP_ACCEPT among others) to determine how best to deliver a good experience to users. In addition, the site can redirect to alternative services that might help, if teh device has certain characteristics. Therefore, the idea of tagging a site with different URL's that are selected between by the client device or the user should not be necessary, and in fact is more limited because the hosting site should be able to evolve and adapt its capabilities much faster than the client device. There are many reasons why one URL for content promotion / bookmarking / passing on is a good thing. Thats probably why the .MOBI TLD met with so much derision, and was rejected by W3C, 3GPP, and content providers. (2) Wrong as an ENUM service If the ENUM service approach (not withstanding the above) was to be useful, then surely it should be available across all domains, not just those in e164.arpa, for example in www.neustar.biz so that devices accessing those domains can also provide more appropriate URL's depending on the support for WAP, ME, iMode, xHTML, VoiceXML, Flash, etc. In that case, the extra "clues" should become a general DNS facility, otherwise only sites accessed by enum URL's could provide the ease of use. In that case I assume there is some other working group that should look at the proposal. At 13:09 23/07/2005, lconroy wrote: Hi Folks, In case no-one noticed, the mobileweb draft has been updated to "draft-ra-shin-enum-mobileweb-01.txt". This draft is covered in section 3.3 of the Agenda. I would suggest that folk look at the new version BEFORE the ENUM meeting - the changes are editorial rather than technical, but given how some people seem to have interpreted the -00 version so far, perhaps this one will clarify things and avoid unnecessary flights of fancy. I would also advise folk to look at the "modest proposal" draft, but as it seems vanishingly unlikely that there will be time to cover that in the meeting, questions/comments to the list would be appreciated. all the best, Lawrence _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ray@bango.net Mon, 25 Jul 2005 09:10:13 -0400 From: Ray Anderson Date: Mon, 25 Jul 2005 09:10:13 -0400 To: enum at ietf.org Subject: Re: [Enum] E.164 communication assumptions/requirements Message-ID: <6.1.2.0.2.20050725140613.03300c70@smtp.bango.net> MIME-Version: 1.0 Content-Type: text/plain Status: R And two more examples where piggy-backing is used extensively: (1) You send a text message, containing a pass-code to a user, and piggyback on the fact that a Mobile Operator only shows it only to that subscriber (2) Mobile network operators do a 1p transaction on a credit card and use it to validate that an over 18 year old person has therefore authorised that phone to be used to see "adult only" content. In a nutshell, we want to only issue a Bango Number (a number from our proprietary database) to somebody who "owns" the equivalent phone number. We can't use text or voice messages, because the number might not support either. So, we plan to piggy-back on ENUM - relying on teh fact that if somebody can "fiddle" with teh ENUM DNS records, they have a lot of power over that number, so we give them teh Bango Number. At 18:30 23/07/2005, Peter Williams wrote: It will be intresting to see if this "third party reliance" (aka piggybacking) security practice is ever authorized, in reality. The last 3 INTERNET infrastructures I worked in all denied this obvious practice. Once the infastructure player operates a branded (audited) process, the company will generally want any other companies who benefit from it to be paying for those reliance benefits....and come under the terms and conditions rules, etc. If we look at other examples of switched online identity databases wth federated trust models and multi-provider interconnect practices: (a) VISA will NOT let you use its accurate numbering, subscriber identification, privilege assignment, and switched trust system (VisaNet) as a way of verifying personal identity. That is, you cannot take a 1c visa purchase from a cardholder peter williams, and then claim you verified me as peter williams, with a 100k credit worthiness. (b) VeriSign will NOT let you rely on a SSL merchant cert, and then issue you own cert to that website operator - claiming "well VeriSign issued a cert, having done due dligence concerning the right-to-use rules (ENUM query on a E.164 registry, DNS registration, usb.org registration, IANA/DARPA MIB schema organizations...), and therefore "i have verified that "peter.com is clearly peter.com" when listing said "verified" name in my own _reissued_ (i.e. non-VeriSign) cert. (c) On the other hand, a variety of the practice is EXACTLY what many value added PSP providers do (in unauthorized fashion, generally) - relying on the email, paging company, or ISP provider's account management controls to boot up their own, independent trust model. We all respond to a email ping, and authenticate thereby to a new web site account. That is the website app relies on a third parties account accuracy representations when verifyng a new consumer's identity (i.e. those of the email service provider) when superimposing its own account susbcription/provisioning/publication processes. So, if I claim to own +441223472778 I might be asked to change the email address in the ENUM record to banana at bango.com If I can do that, it is assumed I am "all powerful" with respect to that number. The whole ENUM project should be causing E.164 owners to put into place varying levels of verification systems that we can piggyback on top of. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum Ray Anderson T:+44 7768 454545 F:+44 20 7692 5558 ray at bango.com _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Mon, 25 Jul 2005 09:20:40 -0400 From: "Michael Hammer \(mhammer\)" Date: Mon, 25 Jul 2005 09:20:40 -0400 To: "Richard Shockey" Subject: RE: [Enum] A shameless plug for my new job. Message-ID: <072C5B76F7CEAB488172C6F64B30B5E35E8DE0@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R NNI and UNI, although work on the latter is just getting started. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Richard Shockey > Sent: Friday, July 22, 2005 12:50 PM > To: Stastny Richard > Cc: enum at ietf.org; henry at sinnreich.net > Subject: Re: [Enum] A shameless plug for my new job. > > Stastny Richard wrote: > > >Thanks for the clarification. > > > >So the group is defining an UNI > > > > > precicely .. > > > > >Are there any plans to set up a similar group to define a > NNI (PoI) or > >real VoIP Peering between Service Providers? > > > > > not in SIPForum .. ATIS in the US is starting to "talk". I'm > sure we're going to hear more about this at the voipeer BOF > on thursday. > > > > >-richard > > > >________________________________ > > > >Von: Richard Shockey [mailto:richard at shockey.us] > >Gesendet: Fr 22.07.2005 16:13 > >An: Stastny Richard > >Cc: enum at ietf.org; henry at sinnreich.net > >Betreff: Re: [Enum] A shameless plug for my new job. > > > > > > > >Stastny Richard wrote: > > > > > > > >>>I believe its important and ultimately relevant to what > the ENUM WG > >>>wants to accomplish over time. > >>> > >>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > 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 at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Mon, 25 Jul 2005 09:26:28 -0400 From: "Michael Hammer \(mhammer\)" Date: Mon, 25 Jul 2005 09:26:28 -0400 To: "Stastny Richard" Subject: RE: [Enum] Clarification on Carrier ENUM discussions Message-ID: <072C5B76F7CEAB488172C6F64B30B5E35E8DE5@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Inline. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] > Sent: Thursday, July 21, 2005 1:51 PM > To: Michael Hammer (mhammer); enum at ietf.org > Subject: Re: [Enum] Clarification on Carrier ENUM discussions > > Michael, > > In most of my presentations I gave on ENUM the last two years > I pointed out that the major problem of ENUM is to overcome > Metcalfe's Law. So much for that.;-) ENUM supports realization of Metcalfe's Law by increasing the number of people that can interconnect. > > >If any user can not find a carrier point of interconnect > from Carrier > >ENUM, then where else? > > only another Carrier, and if you monitor the current > discussion, only Carriers that have an bi-lateral > interconnect agreement with this carrier. > > A user can never use a PoI of a carrier. The term PoI is > derived from TDM (PSTN) interconnect, and here PoI is a > synonym for Network-Network Interface (NNI). In PSTN > Interconnect, a user is ALWAYS connected via a User-Network-Interface > (UNI) and NEVER can access (per definition) a NNI. Maybe I am being too liberal with the term POI. For me, NNI and UNI are points of interconnect. With that definition there is no reason to exclude interconnection from enterprise service providers or home networks. That might resolve the apparent disconnect we have. Mike > > What we have here is a clash of cultures: > > User ENUM is desigend along the lines of the end-to-end > Internet model To use User ENUM, you need to get a public SIP > URI from your service provider (or you provide it by yourself > - e.g. a company PBX) - like e-mail > > Carrier ENUM is designed along the lines of PSTN > interconnect, Carriers have networks and interconnect with > each other, either via the Internet or via direct > connections. You as a user connect to the connect via a "UNI" > to one service provider and the service provider has to find > out a way to connect you to the service provider of the > called user. How he is doing this is not your problem. > > The next two or so years we will see a battle between these > two approaches - I have no idea who will win. It will > basically be decided by the end-users: do they want to be on > their own or do they want to have the comfort of a service > provider and pay for this. > > The trend currently goes in direction of the PSTN interconnect > model: even the SIP Forum is changing focus, just read the > "shameless" e-mail from Rich Shockey: > > the new task group will specify a UNI. > > -richard > > > ________________________________ > > Von: Michael Hammer (mhammer) [mailto:mhammer at cisco.com] > Gesendet: Mi 20.07.2005 15:27 > An: Stastny Richard; enum at ietf.org > Betreff: RE: [Enum] Clarification on Carrier ENUM discussions > > > > Richard, > > If any user can not find a carrier point of interconnect from > Carrier ENUM, then where else? > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] > > Sent: Monday, July 18, 2005 3:34 PM > > To: Michael Hammer (mhammer); enum at ietf.org > > Subject: Re: [Enum] Clarification on Carrier ENUM discussions > > > > >I have serious problems with the statement that only carriers can > > >discover a point of interconnect for a carrier given an > E.164 number. > > > > In Carrier ENUM, who else? > > > > >We do not need walled ENUM gardens, and this will > certainly require > > >regulators in each country to get involved. > > > > Who is "we"? ;-) > > I think it was Metcalfe's Law that said that the value of the > network was the square of the number of users that can > interconnect. The PSTN has great value because any E.164 > number can call any other E.164 number. The value of the > Internet is great because one public IP address can reach > another. Look at instant messaging. Everyone agrees that > having non-interoperable islands is not good. Thus efforts > to provide for interoperability. Look at cellular networks. > Without wide geographic coverage enabled by the possibility > to roam, the value was limited. VoIP and ENUM will have > value if it enables anyone to reach anyone else. We is > anyone who wants to maximize the value of the network by > making it easier to reach one another. > > Early in US telephone history there were many telephone > companies, but because you could only call someone connected > to the same company, there was not general reachability. The > government stepped in and created one phone company and gave > it a monopoly. Let's not repeat history. Note, I don't > expect monopolies to be created, but the lawyers will fix > what the technicians fail to accomplish. Do you want that? > > If the above does not describe you, who are you looking out for? > > Mike > > > > > -richard > > > > ________________________________ > > > > Von: Michael Hammer (mhammer) [mailto:mhammer at cisco.com] > > Gesendet: Mo 18.07.2005 21:21 > > An: Stastny Richard; enum at ietf.org > > Betreff: RE: [Enum] Clarification on Carrier ENUM discussions > > > > > > > > Richard, > > > > I have serious problems with the statement that only carriers can > > discover a point of interconnect for a carrier given an > > E.164 number. > > We do not need walled ENUM gardens, and this will certainly require > > regulators in each country to get involved. > > > > Mike > > > > > > > -----Original Message----- > > > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] > > On Behalf > > > Of Stastny Richard > > > Sent: Tuesday, July 12, 2005 10:28 AM > > > To: enum at ietf.org > > > Subject: [Enum] Clarification on Carrier ENUM discussions > > > > > > Dear all, > > > > > > following the current discussions on carrier ENUM, I have > a serious > > > problem with some issues raised > > > > > > So to clarify some issues: > > > We have on one side User ENUM, which is used by end-users to find > > > other end-users. We so not need to define requirements here > > and we do > > > not need to discuss its purpose. > > > > > > On the other hand we have carrier ENUM. Carrier (or > > > Infrastructure) ENUM is for carriers ONLY and ONLY > > carriers-of-record > > > are allowed to enter information there and ONLY carriers > > may use the > > > infromation, even if it may publicly available. Carier ENUM is > > > required for carriers to announce their PoI (IP based or on > > the PSTN) > > > to other carriers, with ENUM based technology, that is > NAPTRs using > > > Enumservices such as "sip", "mms:mailto" or eventually "npd:tel" > > > > > > To do so, different methods may be used. > > > > > > A. use any tree in any domain (e.g foo.bar). Carriers may > do so on > > > their own choice and are already doing so. > > > The problem here is that many trees exists. > > > If the carriers want to use a commonly agreed tree, they have two > > > options: agree on any tree out of .arpa or use > > > > > > B. an additional (side) tree in .arpa > > > > > > here 3 technically equivalent options exists > > > > > > 1. use carrier.arpa > > > 2. use carrier.e164.arpa > > > 3. use carrier.c.c.e164.arpa > > > > > > For the avoidance of doubt, carrier could also be "c" od "foo" > > > as Otmar pointed out and NOT the name of the carrier (the SPID) > > > > > > Any discussion of draft-haberler should restrict itself to the > > > question where to put "carrier" or "c" or "foo" and how > to find the > > > proper side tree within the carriers ENUM client and NOT > > e.g. asking > > > questions like: > > > > > > "How does my > > > (Scottish) handset figure out what the names (or codes) > > exist for the > > > telco operators in say Austria? Which one of these Austrian > > telcos is > > > it supposed to prefer? How do I get my handset to pick a > > new preferred > > > partner for calls to Austria whenever I port my number to another > > > Scottish telco or if the preferred telco in Austria has > > been renamed > > > (or gone bust)?" > > > > > > This question has nothing to do with the problem at hand > > not even with > > > ENUM at all (not even in Scottland ;-) > > > > > > First: a handset (end-user) will never query carrier enum > > and even a > > > telco querying carrier ENUM does not have to find out which > > telco to > > > query or to prefer. ENU will give you this information. And > > a number > > > may only be hosted by one telco at a time. > > > > > > -richard > > > > > > > > > > > > _______________________________________________ > > > enum mailing list > > > enum at ietf.org > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Mon, 25 Jul 2005 09:55:28 -0400 From: Richard Shockey Date: Mon, 25 Jul 2005 09:55:28 -0400 To: enum at ietf.org Subject: [Enum] [Fwd: IESG response to appeal regarding draft-ietf-lemonade-mms-mapping-04] Message-ID: <42E4EF32.4080909@shockey.us> MIME-Version: 1.0 Content-Type: text/plain Status: R -------- Original Message -------- Subject: IESG response to appeal regarding draft-ietf-lemonade-mms-mapping-04 Date: Fri, 22 Jul 2005 18:14:06 -0400 From: IESG Secretary To: IETF Announcement list CC: lemonade at ietf.org The IESG has reviewed John Klensin's appeal against the approval of draft-ietf-lemonade-mms-mapping-04.txt (see http://www.ietf.org/IESG/APPEALS/klensin-appeal-lemonade-mms-mapping.txt for the full text of the appeal). Note that the Area Director principally concerned, Ted Hardie, gave technical input during the IESG discussion of the appeal, but recused himself from the approval of this response. After analysis, the IESG withdraws its approval of draft-ietf-lemonade-mms-mapping-04.txt as Proposed Standard and invites the lemonade WG to act on the following points. 1. The IESG agrees that the technical updates between the -02 and -04 versions of draft-ietf-lemonade-mms-mapping were significant enough to warrant re-review by the working group. It therefore asks the working group to review the changes between -02 and -04; if the WG is satisfied that the changes are within its intent, it should so inform the IESG. If not, it should produce a draft that restores its original intent, and so inform the IESG. When the draft is updated, the IESG will restart the review process at IETF Last Call. 2. We note that the Resent-Count header is not mentioned in the IANA Considerations. While RFC 3864 would allow it to be registered independently, based on the OMA documents, it would be valuable to include a note in the IANA Considerations indicating what registration class (Permanent or Provisional) would be sought for and stating that the registration would be accomplished by reference to those documents. Having the registration request be concurrent with or precede the approval of the revised draft would also be valuable. 3. The appeal challenges the legitimacy of a gateway standard mandating certain mappings to and from X- headers. In one place, the draft states: ...Such systems should be aware that X-headers might be removed during transit through Internet MTAs. It is not the IETF's business that the external MMS specification makes use of X- headers in a way that the IETF mail standards do not. Additionally, given the ambiguous status of X- headers due to the discrepancy between RFC 822 and RFC 2822, the WG was placed in a difficult situation. Mail gateways have to satisfy pragmatic as well as formal requirements. The IESG therefore believes that it was within the WG's scope to specify mappings to and from X- headers, as long as it is clear that they are not part of the RFC 2822 standard format and that their treatment by Internet MTAs cannot be relied on. We now believe that the above sentence describing permitted Internet MTA behavior is not sufficiently prominent in the draft, and we request that the working group expand and strengthen it or otherwise remedy the problem, unless the WG decides for other reasons to remove the X- header mappings. If the X- header mappings are retained, they are also candidates for provisional registration under RFC 3864 and should be noted as such in the IANA Considerations. 4. The appeal raises a number of other technical points that were not, as far as we know, raised during WG discussion, WG Last Call, or IETF Last Call. Some of them were raised by John Klensin in a review carried out for the General AD during IESG evaluation. We believe that if they had been raised earlier, they might have affected the document content. But this in itself does not automatically mean the IESG was wrong to approve the document at the Proposed Standard level. However, since the WG will be reconsidering the draft, if the WG wishes to make additional changes based on its review of John's technical concerns, it should do so, and inform the IESG when consensus within the WG has been reached so that a new cycle of IETF review can be initiated. 5. John's appeal raised the question of whether the working group had an adequate opportunity to review the comments raised by his review. The IESG believes that as we continue to encourage cross-area and cross-working-group review, the issue of how to make sure review comments are seen by the right people and handled in an open manner will continue to become more important. We would like to work with the community on guidelines for reviewers, ADs and working groups on how to handle these review comments. In summary, the IESG - withdraws its approval of draft-ietf-lemonade-mms-mapping-04.txt as Proposed Standard - requests the lemonade WG to review and confirm or withdraw the changes between the -02 and -04 versions - notes that the lemonade WG is free to consider other technical comments included in the appeal - requests the lemonade WG to improve the text about MTA treatment of X- headers, if these mappings are retained - requests the lemonade WG to complete the IANA Considerations as necessary, considering RFC 3864 - requests the lemonade WG to provide an updated version of the draft that reflects WG consensus, for renewed IETF Last Call and IESG review. _______________________________________________ IETF-Announce mailing list IETF-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Mon, 25 Jul 2005 09:56:55 -0400 From: "Michael Hammer \(mhammer\)" Date: Mon, 25 Jul 2005 09:56:55 -0400 To: "Stastny Richard" Subject: RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Message-ID: <072C5B76F7CEAB488172C6F64B30B5E35E8E0B@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard and Richard, All E.164 numbers in ENUM are effectively ported, so I don't understand why the npd needs to be an ENUM service rather than just an attribute of the tel ENUM service. This is not to say that the result returned does not have the npdi, rn, cic or other tel parameters provided. Second, IP-based softswitches can do routing based on such information in the IP domain, so such information is not only of use to PSTN-based switches (during the migration from PSTN to IP-based). Third, since number portability is essentially performed by service providers, is the scope of this limited only to Carrier ENUM? Number portability is a PSTN routing database mechanism. If ENUM is done right, then when the TDM PSTN as we know it disappears, so should number portability. Porting a number in the IP domain ought to be simply an ENUM re-registration. A single ENUM dip should be needed, not an ENUM and an NP dip. Some of the crufty PSTN mechanisms will fade away, no? Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Stastny Richard > Sent: Monday, July 25, 2005 6:23 AM > To: Richard Shockey > Cc: enum at ietf.org > Subject: Re: [Enum] Fwd: I-D > ACTION:draft-livingood-shockey-enum-npd-00.txt > > Rich, > > One comment first > I basically like the idea of a generic tel Enumservice, > whatever it is called. but I do not have thought through all > implications Maybe we can discuss this in Paris (we have a > whole week ;-) > > To your remarks: > > >That is not true. The ENUM serive npd indicated number > portability data > >that may be associated with any telephone number. > > >The examples in the textare quite clear that the information > relates to > >both Ported and NonPorted numbers. > > Thats what I said: > > Still, the sentence: > > "The purpose of this Enumservice is > to describe information about telephone numbers which cannot > be used on the public Internet or a private/peered Internet > Protocol (IP) network. " > > is unclear (or wrong, because you can use proted numbers on > the Public Internet (I do) > > >The modification is to define a new enumservice field. > >E2U+npd:sip > >with the URI defined something like this. > > >NAPTR 10 10 "u" "E2U+npd:sip" > >"!^.*$!sip:+15714345651 at mg4.mso.net;rn=+15712768933;npdi!" > > >the rationale for this is that many gateways dont know what > tel URI's are. > > Now I am completely lost. I tought the "npd" was a generic > Enumservice giving the "rn" to be used (in the national > network), but the gateway to user is your choice. One may > even query this information from the PSTN via a IN-mediation > device. Now you introduce a specific "transit" gateway. > > BTW: your example URI should be: > sip:+15714345651;rn=+15712768933;npdi at mg4.mso.net > > > >For what purpose? > > For this: > > > > >One example is the usage of ENUM-only numbers existing only in User > >ENUM (e.g. +43780 and +87810). Here a pointer in Carrier ENUM may be > >useful to point from Carrier ENUM to User ENUM. Such a > number may have > >a routing number , but this routing numbers are only of national > >significance and cannot be used in a global system. > > > >There is also missing a note that with this Enumservice the tel URI > >MUST always contain the same number then the AUS. > > > > ________________________________ > > Von: Richard Shockey [mailto:Rich.Shockey at neustar.biz] > Gesendet: Fr 22.07.2005 20:46 > An: Stastny Richard > Cc: Richard Shockey; enum at ietf.org > Betreff: Re: [Enum] Fwd: I-D > ACTION:draft-livingood-shockey-enum-npd-00.txt > > > > Stastny Richard wrote: > > >Dear all, > > > >although I did not receive (yet) any response to my e-mail below, I > >want to comment on the mentioned draft: > > > >I have a question to the following paragraph: > > > >"The following Enumservice is registered with this document: "npd" to > > indicate number portability data. The purpose of this > Enumservice is > > to describe information about telephone numbers which > cannot be used > > on the public Internet or a private/peered Internet Protocol (IP) > > network. Thus, these are numbers which are only reachable via the > > traditional Public Switched Telephone Network (PSTN)." > > > >The second sentence seems to imply that ONLY ported numbers will be > >used with the Enumservice "npd". The example 4.2 indicates that also > >non-ported numbers may be used. > > > > > That is not true. The ENUM serive npd indicated number > portability data that may be associated with any telephone number. > > The examples in the textare quite clear that the information > relates to both Ported and NonPorted numbers. > > 4.1 Example of a Ported Telephone Number > > $ORIGIN 3.1.8.7.1.8.9.5.1.2.1.e164.arpa. > > NAPTR 10 100 "u" "E2U+npd:tel" > > "!^.*$!tel:+1-215-981-7813;rn=+1-215-981-7600;npdi!" > > > In this example, a Routing Number (rn) and a Number Portability Dip > > Indicator (npdi) are used as shown in draft-ietf-iptel-tel-np-06.txt > > [10] (Internet-Draft New Parameters for the "tel" URI to Support > > Number Portability, draft-ietf-iptel-tel-np-06.txt [10]). The 'npdi' > > field is included in order to prevent subsequent lookups in legacy- > > style PSTN databases. > > 4.2 Example of a Non-Ported Telephone Number > > $ORIGIN 3.1.8.7.1.8.9.5.1.2.1.e164.arpa. > > NAPTR 10 100 "u" "E2U+npd:tel" > > "!^.*$!tel:+1-215-981-7813;npdi!" > > I have had a private request to consider an alternative > formation of th e URI. > > as in > > The modification is to define a new enumservice field. > > E2U+npd:sip > > with the URI defined something like this. > > NAPTR 10 10 "u" "E2U+npd:sip" > "!^.*$!sip:+15714345651 at mg4.mso.net;rn=+15712768933;npdi!" > > the rationale for this is that many gateways dont know what > tel URI's are. > > > > >The third sentence is simply not true: I myself have ported numbers > >that can be reached on the public Internet via SIP URIs. > > > > > A fair criticism a better wording might have been. > > "Thus, this information is only useful in a national specific > context within the traditional Public Switched Telephone > Network (PSTN)." > > > > > >IMHO there is a more in-depth analysis required how this > Enumservice is > >used, what it implies and with which other Enumservices it > can be used > >togother > > > >There is also a need to consolidate the different Enumservices using > >the tel URI and their use in User and Carrier ENUM. > >Also the usage of crosspointers (entries in User ENUM pointing to > >Carrier ENUM and vice versa) with tel URIs is necessary. > > > > > For what purpose? > > > > >One example is the usage of ENUM-only numbers existing only in User > >ENUM (e.g. +43780 and +87810). Here a pointer in Carrier ENUM may be > >useful to point from Carrier ENUM to User ENUM. Such a > number may have > >a routing number , but this routing numbers are only of national > >significance and cannot be used in a global system. > > > >There is also missing a note that with this Enumservice the tel URI > >MUST always contain the same number then the AUS. > > > >regards > > > >-richard > > > >________________________________ > > > >Von: enum-bounces at ietf.org im Auftrag von Stastny Richard > >Gesendet: So 10.07.2005 14:51 > >An: Richard Shockey; enum at ietf.org > >Betreff: Re: [Enum] Fwd: I-D > >ACTION:draft-livingood-shockey-enum-npd-00.txt > > > > > > > >Dear all, especially Allison Mankin, > > > >I consider this I-D very interesting, because I also proposed in the > >past to use the parameters defined in draft-ietf-iptel-tel-np-06.txt > >e.g. ";rn=" within ENUM, but did not bring this forward > because of reason stated below. > > > >Before I comment on this draft and raise some questions, I > would like > >to get some principle statements from our esteemed AD > Allison if this > >draft is within the scope of IETF and ENUM WG. > > > >The rationale for this question is the following: > > > >The intended use of the Enumservice "npd:tel" is primarily for > >carriers, because only carriers my interpret and use the > "rn= parameter. > > > >Routing numbers MUST NEVER be used by end-users. > > > >During the discussion Lawrence Conroy and I had with Ted Hardie and > >Allison Mankin in Geneva in May regarding the I-D > >draft-ietf-enum-msg-04.txt, especially about Enumservice > "mms:mailto", > >I mentioned the fact that this Enumservice MAY also be used > by carriers. > > > >Allison did not like this statement at all and said ENUM and > >Enumservices to-be-defined are ONLY for end-user usage. I > only got over > >this hurdle by confirming that "mms:mailto" is ALSO useful for > >end-users. > > > >Therefore I want to have a clear statement from the > responsible AD if > >an Enumservice for carrier use ONLY is within the scope of ENUM WG, > >before I waste my time in discussing this I-D on the list. > > > >Richard Stastny > > > > -- > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > 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 at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Klaus.Nieminen@ficora.fi Mon, 25 Jul 2005 09:57:08 -0400 From: "Nieminen Klaus" Date: Mon, 25 Jul 2005 09:57:08 -0400 To: Subject: RE: [Enum] Clarification on Carrier ENUM discussions Message-ID: <07BC6C0D40216E44A34BE6701694FE860186262B@POSTI.laru.local> MIME-Version: 1.0 Content-Type: text/plain Status: R Michael and all, Reading rather many emaíls about this issue, I wanted to ask one question: Is there any need, why we should now define, who can or can't access carrier's POI? In http://www.sdlind.com/draft-lind-infrastructure-enum-reqs-00.txt (2.2 Architecture Requirements ) it is mentioned that it should: > provide information on how to route a service to a point of > carrier interconnection or ALG as expressed as a URI. For > privacy and or network security reasons this information may_ > need to be restricted to service providers and not generally > available to end users. [editor's note: some have argued that > they might provide a carrier record that generally points to a > public interconnection point, but would provide pointers to > specific interconnection points for specific interconnecting > network providers.] I believe that this could be a good requirement. Of course, we may need to consider the availability of that information, but we cannot force all carriers to open their POIs just because of our carrier-ENUM draft/RFC... End-users and the market situation may do this, but should not we left that open? BTW: of course also I would be happy to see the following ;-) > The long term result might be that telcos get revenue through useful > service to customers and not by charging at the termination > bottleneck. > Whoa.. what a concept.. regards, - Klaus - Finnish Communications Regulatory Authority www: http://www.ficora.fi _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Mon, 25 Jul 2005 10:02:19 -0400 From: "Michael Hammer \(mhammer\)" Date: Mon, 25 Jul 2005 10:02:19 -0400 To: "Nieminen Klaus" Subject: RE: [Enum] Clarification on Carrier ENUM discussions Message-ID: <072C5B76F7CEAB488172C6F64B30B5E35E8E15@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Klaus, I would be happy if the RFCs leave it up to the owners of the E.164 number ranges the decision as to whether to advertize or not advertize such points of interconnect. That is an implementation/operational decision for which the protocol work should allow both closed and open options to exist. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Nieminen Klaus > Sent: Monday, July 25, 2005 9:57 AM > To: enum at ietf.org > Subject: RE: [Enum] Clarification on Carrier ENUM discussions > > Michael and all, > > Reading rather many emaíls about this issue, I wanted to ask > one question: > > Is there any need, why we should now define, who can or can't > access carrier's POI? In > http://www.sdlind.com/draft-lind-infrastructure-enum-reqs-00.t > xt (2.2 Architecture Requirements ) it is mentioned that it should: > > > provide information on how to route a service to a point of carrier > > interconnection or ALG as expressed as a URI. For privacy and or > > network security reasons this information may_ need to be > restricted > > to service providers and not generally available to end users. > > [editor's note: some have argued that they might provide a carrier > > record that generally points to a public interconnection point, but > > would provide pointers to specific interconnection points > for specific > > interconnecting network providers.] > > I believe that this could be a good requirement. Of course, > we may need to consider the availability of that information, > but we cannot force all carriers to open their POIs just > because of our carrier-ENUM draft/RFC... End-users and the > market situation may do this, but should not we left that open? > > BTW: of course also I would be happy to see the following ;-) > > > The long term result might be that telcos get revenue > through useful > > service to customers and not by charging at the termination > > bottleneck. > > Whoa.. what a concept.. > > regards, > > - Klaus - > > Finnish Communications Regulatory Authority > www: http://www.ficora.fi > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From dmm@1-4-5.net Mon, 25 Jul 2005 10:24:08 -0400 From: David Meyer Date: Mon, 25 Jul 2005 10:24:08 -0400 To: agenda at ietf.org Subject: [Enum] updated voipeer BOF agenda for IETF 63 Message-ID: <20050725142353.GC12372@1-4-5.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary..32256.1122908376.multipart/mixed" Status: R --Boundary..32256.1122908376.multipart/mixed Content-Type: text/plain Content-Transfer-Encoding: 7bit See also http://www.1-4-5.net/~dmm/IETF/IETF63/VOIPEER/agenda http://www.1-4-5.net/~dmm/IETF/IETF63/VOIPEER/problem_statement http://www.1-4-5.net/~dmm/IETF/IETF63/VOIPEER/problem_space Thanks, Dave [sorry about the wide cc:...please excuse any duplicates] --- VoIP Peering and Interconnect BOF (voipeer) THURSDAY, August 4, 1400-1630 (Afternoon Session I) =================================================== CHAIR: David Meyer AGENDA o Administriva 0 minutes - Mailing list: majordomo at lists.uoregon.edu subscribe voipeer or visit http://darkwing.uoregon.edu/~llynch/voipeer.html - Scribe(s)? - Blue Sheets o Agenda Bashing 0 minutes Meyer o Puropse and Objectives + Overview 10 minutes Meyer o SIPPING update/overview 10 minutes Camarillo o ENUM Update/Overview 10 minutes Shockey o SIP Forum Tech WG IP PBX to SP Interconnect Update 5 minutes Mahy o Issues in Numbering, Naming and Addressing 10 minutes Stastny o Service Provider Perspectives 50 minutes Bill Woodcock (PCH) Alan Duric (Telio) Martin Dolly (ATT) Jason Livingood (Comcast) Joao Damas (ISC) o Discussion 40 minutes Meyer/All o Next Steps 15 minutes Meyer Attachment: pgpaGWRMbkfcc.pgp Description: PGP signature _______________________________________________ enum mailing list enum at ietf.org --Boundary..32256.1122908376.multipart/mixed Content-Type: application/octet-stream; name="pgpaGWRMbkfcc.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgpaGWRMbkfcc.pgp" Content-Description: "https://www1.ietf.org/mailman/listinfo/enum" --Boundary..32256.1122908376.multipart/mixed-- From dmm@1-4-5.net Mon, 25 Jul 2005 11:05:07 -0400 From: David Meyer Date: Mon, 25 Jul 2005 11:05:07 -0400 To: agenda at ietf.org Subject: [Enum] (updated) updated voipeer BOF agenda for IETF 63 In-Reply-To: <20050725142353.GC12372@1-4-5.net> Message-ID: <20050725150451.GA14880@1-4-5.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary..32256.1122908376.multipart/mixed" Status: R --Boundary..32256.1122908376.multipart/mixed Content-Type: text/plain Content-Transfer-Encoding: 7bit Folks, First, sorry about the agenda flux, and the attendant email load (seems that every time I update the agenda I get a flurry new requests). In any event, the most up to date agenda is included below. In addition, some folks have asked for a pointer to the BOF proposal, which can be found here: http://www.1-4-5.net/~dmm/IETF/IETF63/VOIPEER/voipeer.bof.proposal Please see also: http://www.1-4-5.net/~dmm/IETF/IETF63/VOIPEER/agenda http://www.1-4-5.net/~dmm/IETF/IETF63/VOIPEER/problem_statement http://www.1-4-5.net/~dmm/IETF/IETF63/VOIPEER/problem_space Thanks, Dave --- VoIP Peering and Interconnect BOF (voipeer) THURSDAY, August 4, 1400-1630 (Afternoon Session I) =================================================== CHAIR: David Meyer AGENDA o Administriva 0 minutes - Mailing list: majordomo at lists.uoregon.edu subscribe voipeer or visit http://darkwing.uoregon.edu/~llynch/voipeer.html - Scribe(s)? - Blue Sheets o Agenda Bashing 0 minutes Meyer o Puropse and Objectives + Overview 10 minutes Meyer o SIPPING update/overview 10 minutes Camarillo o ENUM Update/Overview 5 minutes Shockey o SIP Forum Tech WG IP PBX to SP Interconnect Update 5 minutes Mahy o Issues in Numbering, Naming and Addressing 10 minutes Stastny o Service Provider Perspectives 60 minutes Bill Woodcock (PCH) Alan Duric (Telio) Martin Dolly (ATT) Jason Livingood (Comcast) Joao Damas (ISC) Sohel Khan (Sprint) o Discussion 40 minutes Meyer/All o Next Steps 10 minutes Meyer Attachment: pgpsxYFGlCIUZ.pgp Description: PGP signature _______________________________________________ enum mailing list enum at ietf.org --Boundary..32256.1122908376.multipart/mixed Content-Type: application/octet-stream; name="pgpsxYFGlCIUZ.pgp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pgpsxYFGlCIUZ.pgp" Content-Description: "https://www1.ietf.org/mailman/listinfo/enum" --Boundary..32256.1122908376.multipart/mixed-- From Richard.Stastny@oefeg.at Mon, 25 Jul 2005 11:08:02 -0400 From: "Stastny Richard" Date: Mon, 25 Jul 2005 11:08:02 -0400 To: "Michael Hammer \(mhammer\)" Subject: Re: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C053@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Mike wrote: >All E.164 numbers in ENUM are effectively ported, so I don't understand >why the npd needs to be an ENUM service rather than just an attribute of >the tel ENUM service. This is not to say that the result returned does >not have the npdi, rn, cic or other tel parameters provided. Since e talk here about USER ENUM and Carrier ENUM, could you PLEASE state what ENUM you are talking about. In User ENUM it is meaningless if a number is ported or not, because the holder of the domain is the end-user having the right to use the number and this user does not change if the number is ported In Carrier ENUM the holder of the domain has to change if the number is ported. What is the tel ENUM services? There is none currently defined. >Second, IP-based softswitches can do routing based on such information >in the IP domain, so such information is not only of use to PSTN-based >switches (during the migration from PSTN to IP-based). No, routing numbers are only meaningfull on the PSTN and also here only in a national context. On IP you need an additional information, e.g. instead of a tel URI with a rn also a sip URI with a domain name. >Third, since number portability is essentially performed by service >providers, is the scope of this limited only to Carrier ENUM? YES. I said it many times already that a user cannot access routing numbers, so putting rn in User ENUM is not useful. >Number portability is a PSTN routing database mechanism. If ENUM is >done right, then when the TDM PSTN as we know it disappears, so should >number portability. Porting a number in the IP domain ought to be >simply an ENUM re-registration. A single ENUM dip should be needed, not >an ENUM and an NP dip. Some of the crufty PSTN mechanisms will fade >away, no? Maybe, maybe not >Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Stastny Richard > Sent: Monday, July 25, 2005 6:23 AM > To: Richard Shockey > Cc: enum at ietf.org > Subject: Re: [Enum] Fwd: I-D > ACTION:draft-livingood-shockey-enum-npd-00.txt > > Rich, > > One comment first > I basically like the idea of a generic tel Enumservice, > whatever it is called. but I do not have thought through all > implications Maybe we can discuss this in Paris (we have a > whole week ;-) > > To your remarks: > > >That is not true. The ENUM serive npd indicated number > portability data > >that may be associated with any telephone number. > > >The examples in the textare quite clear that the information > relates to > >both Ported and NonPorted numbers. > > Thats what I said: > > Still, the sentence: > > "The purpose of this Enumservice is > to describe information about telephone numbers which cannot > be used on the public Internet or a private/peered Internet > Protocol (IP) network. " > > is unclear (or wrong, because you can use proted numbers on > the Public Internet (I do) > > >The modification is to define a new enumservice field. > >E2U+npd:sip > >with the URI defined something like this. > > >NAPTR 10 10 "u" "E2U+npd:sip" > >"!^.*$!sip:+15714345651 at mg4.mso.net;rn=+15712768933;npdi!" > > >the rationale for this is that many gateways dont know what > tel URI's are. > > Now I am completely lost. I tought the "npd" was a generic > Enumservice giving the "rn" to be used (in the national > network), but the gateway to user is your choice. One may > even query this information from the PSTN via a IN-mediation > device. Now you introduce a specific "transit" gateway. > > BTW: your example URI should be: > sip:+15714345651;rn=+15712768933;npdi at mg4.mso.net > > > >For what purpose? > > For this: > > > > >One example is the usage of ENUM-only numbers existing only in User > >ENUM (e.g. +43780 and +87810). Here a pointer in Carrier ENUM may be > >useful to point from Carrier ENUM to User ENUM. Such a > number may have > >a routing number , but this routing numbers are only of national > >significance and cannot be used in a global system. > > > >There is also missing a note that with this Enumservice the tel URI > >MUST always contain the same number then the AUS. > > > > ________________________________ > > Von: Richard Shockey [mailto:Rich.Shockey at neustar.biz] > Gesendet: Fr 22.07.2005 20:46 > An: Stastny Richard > Cc: Richard Shockey; enum at ietf.org > Betreff: Re: [Enum] Fwd: I-D > ACTION:draft-livingood-shockey-enum-npd-00.txt > > > > Stastny Richard wrote: > > >Dear all, > > > >although I did not receive (yet) any response to my e-mail below, I > >want to comment on the mentioned draft: > > > >I have a question to the following paragraph: > > > >"The following Enumservice is registered with this document: "npd" to > > indicate number portability data. The purpose of this > Enumservice is > > to describe information about telephone numbers which > cannot be used > > on the public Internet or a private/peered Internet Protocol (IP) > > network. Thus, these are numbers which are only reachable via the > > traditional Public Switched Telephone Network (PSTN)." > > > >The second sentence seems to imply that ONLY ported numbers will be > >used with the Enumservice "npd". The example 4.2 indicates that also > >non-ported numbers may be used. > > > > > That is not true. The ENUM serive npd indicated number > portability data that may be associated with any telephone number. > > The examples in the textare quite clear that the information > relates to both Ported and NonPorted numbers. > > 4.1 Example of a Ported Telephone Number > > $ORIGIN 3.1.8.7.1.8.9.5.1.2.1.e164.arpa. > > NAPTR 10 100 "u" "E2U+npd:tel" > > "!^.*$!tel:+1-215-981-7813;rn=+1-215-981-7600;npdi!" > > > In this example, a Routing Number (rn) and a Number Portability Dip > > Indicator (npdi) are used as shown in draft-ietf-iptel-tel-np-06.txt > > [10] (Internet-Draft New Parameters for the "tel" URI to Support > > Number Portability, draft-ietf-iptel-tel-np-06.txt [10]). The 'npdi' > > field is included in order to prevent subsequent lookups in legacy- > > style PSTN databases. > > 4.2 Example of a Non-Ported Telephone Number > > $ORIGIN 3.1.8.7.1.8.9.5.1.2.1.e164.arpa. > > NAPTR 10 100 "u" "E2U+npd:tel" > > "!^.*$!tel:+1-215-981-7813;npdi!" > > I have had a private request to consider an alternative > formation of th e URI. > > as in > > The modification is to define a new enumservice field. > > E2U+npd:sip > > with the URI defined something like this. > > NAPTR 10 10 "u" "E2U+npd:sip" > "!^.*$!sip:+15714345651 at mg4.mso.net;rn=+15712768933;npdi!" > > the rationale for this is that many gateways dont know what > tel URI's are. > > > > >The third sentence is simply not true: I myself have ported numbers > >that can be reached on the public Internet via SIP URIs. > > > > > A fair criticism a better wording might have been. > > "Thus, this information is only useful in a national specific > context within the traditional Public Switched Telephone > Network (PSTN)." > > > > > >IMHO there is a more in-depth analysis required how this > Enumservice is > >used, what it implies and with which other Enumservices it > can be used > >togother > > > >There is also a need to consolidate the different Enumservices using > >the tel URI and their use in User and Carrier ENUM. > >Also the usage of crosspointers (entries in User ENUM pointing to > >Carrier ENUM and vice versa) with tel URIs is necessary. > > > > > For what purpose? > > > > >One example is the usage of ENUM-only numbers existing only in User > >ENUM (e.g. +43780 and +87810). Here a pointer in Carrier ENUM may be > >useful to point from Carrier ENUM to User ENUM. Such a > number may have > >a routing number , but this routing numbers are only of national > >significance and cannot be used in a global system. > > > >There is also missing a note that with this Enumservice the tel URI > >MUST always contain the same number then the AUS. > > > >regards > > > >-richard > > > >________________________________ > > > >Von: enum-bounces at ietf.org im Auftrag von Stastny Richard > >Gesendet: So 10.07.2005 14:51 > >An: Richard Shockey; enum at ietf.org > >Betreff: Re: [Enum] Fwd: I-D > >ACTION:draft-livingood-shockey-enum-npd-00.txt > > > > > > > >Dear all, especially Allison Mankin, > > > >I consider this I-D very interesting, because I also proposed in the > >past to use the parameters defined in draft-ietf-iptel-tel-np-06.txt > >e.g. ";rn=" within ENUM, but did not bring this forward > because of reason stated below. > > > >Before I comment on this draft and raise some questions, I > would like > >to get some principle statements from our esteemed AD > Allison if this > >draft is within the scope of IETF and ENUM WG. > > > >The rationale for this question is the following: > > > >The intended use of the Enumservice "npd:tel" is primarily for > >carriers, because only carriers my interpret and use the > "rn= parameter. > > > >Routing numbers MUST NEVER be used by end-users. > > > >During the discussion Lawrence Conroy and I had with Ted Hardie and > >Allison Mankin in Geneva in May regarding the I-D > >draft-ietf-enum-msg-04.txt, especially about Enumservice > "mms:mailto", > >I mentioned the fact that this Enumservice MAY also be used > by carriers. > > > >Allison did not like this statement at all and said ENUM and > >Enumservices to-be-defined are ONLY for end-user usage. I > only got over > >this hurdle by confirming that "mms:mailto" is ALSO useful for > >end-users. > > > >Therefore I want to have a clear statement from the > responsible AD if > >an Enumservice for carrier use ONLY is within the scope of ENUM WG, > >before I waste my time in discussing this I-D on the list. > > > >Richard Stastny > > > > -- > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > 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 at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Mon, 25 Jul 2005 11:19:41 -0400 From: Richard Shockey Date: Mon, 25 Jul 2005 11:19:41 -0400 To: Stastny Richard Subject: Re: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C052@oefeg-s04.oefeg.loc> Message-ID: <42E502FD.7020007@shockey.us> MIME-Version: 1.0 Content-Type: text/plain Status: R Stastny Richard wrote: Rich, One comment first I basically like the idea of a generic tel Enumservice, whatever it is called. but I do not have thought through all implications Maybe we can discuss this in Paris (we have a whole week ;-) We've gone back and forward on this .. this draft does not require a generic tel. The service field is what it is. To your remarks: Thats what I said: Still, the sentence: "The purpose of this Enumservice is to describe information about telephone numbers which cannot be used on the public Internet or a private/peered Internet Protocol (IP) network. " I still dont get the problem routing numbers have no signinicance on IP Networks... this is a clarity issue. is unclear (or wrong, because you can use proted numbers on the Public Internet (I do) Did you see my reply ..I conceded this point. "Thus, this information is only useful in a national specific context within the traditional Public Switched Telephone Network (PSTN)." The modification is to define a new enumservice field. E2U+npd:sip with the URI defined something like this. NAPTR 10 10 "u" "E2U+npd:sip" "!^.*$!sip:+15714345651 at mg4.mso.net;rn=+15712768933;npdi!" the rationale for this is that many gateways dont know what tel URI's are. Now I am completely lost. I tought the "npd" was a generic Enumservice giving the "rn" to be used (in the national network), but the gateway to user is your choice. The operators choice. This draft is meant for use only within the context of a Carrier ENUM service and more specifically in North America this data would never be globally visable.In other national jurisdictions it might be but not in NA. One may even query this information from the PSTN via a IN-mediation device. Now you introduce a specific "transit" gateway. BTW: your example URI should be: sip:+15714345651;rn=+15712768933;npdi at mg4.mso.net no the original was correct. This is not a SIP URI. For what purpose? F 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Mon, 25 Jul 2005 11:39:21 -0400 From: "Stastny Richard" Date: Mon, 25 Jul 2005 11:39:21 -0400 To: "Richard Shockey" Subject: Re: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C055@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Rich wrote: >Did you see my reply ..I conceded this point. >"Thus, this information is only useful in a national specific context >within the traditional Public Switched Telephone Network (PSTN)." Scusi, I saw it the first time, but I missed it when I wrote the reply >The operators choice. This draft is meant for use only within the >context of a Carrier ENUM service and more specifically in North America >this data would never be globally visable.In other national >jurisdictions it might be but not in NA. They are globally visible, but not usable >>BTW: your example URI should be: >>sip:+15714345651;rn=+15712768933;npdi at mg4.mso.net >> >no the original was correct. This is not a SIP URI. IMHO the correct version is sip:+15714345651;rn=+15712768933;npdi at mg4.mso.net; user=phone To be continued in another post -richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Mon, 25 Jul 2005 11:53:39 -0400 From: Richard Shockey Date: Mon, 25 Jul 2005 11:53:39 -0400 To: "Michael Hammer (mhammer)" Subject: Re: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E35E8E0B@xmb-rtp-20b.amer.cisco.com> Message-ID: <42E50AA9.1030101@shockey.us> MIME-Version: 1.0 Content-Type: text/plain Status: R Michael Hammer (mhammer) wrote: Richard and Richard, All E.164 numbers in ENUM are effectively ported, you cannot completely draw that conclusion over time. Policy over number allocation isues are under serious discussion which might change that statement ..though for the indefinate future it is reasonable to assume that most VoIP numbers will be ported or pooled. so I don't understand why the npd needs to be an ENUM service rather than just an attribute of the tel ENUM service. This is not to say that the result returned does not have the npdi, rn, cic or other tel parameters provided. Enhancing the search pattern the resolver uses to find the appropriate NAPTR record. Yes it could use a pure E2U+tel but I think this is better and there are logical arguments for seperating values out such as if you wanted to add CNAM. Unlike some in this WG I have never had an objection to granular "hints" as to the service or information contained in a NAPTR record. More information is better than less. Second, IP-based softswitches can do routing based on such information in the IP domain, so such information is not only of use to PSTN-based switches (during the migration from PSTN to IP-based). Yes .. you can make some interesting trunking decisions based on the NPA-NXX of a particular LRN if you can aquire that information at point of session origination vs N-1. Third, since number portability is essentially performed by service providers, is the scope of this limited only to Carrier ENUM? Yes ..that should be self evident by now but as Richard points out this is a national specific issue. And as I spefically said before North American LNP data cannot be openly distributed. The context of the query in the US and Canada would certainly be some form of closed network or internal network databases that have DNS query response capability. BTW this would certainly work in a SIP redirect context as well. Number portability is a PSTN routing database mechanism. If ENUM is done right, and IF you get significant consumer and enterprise OP-IN ... lots of big IF's here then when the TDM PSTN as we know it disappears, so should number portability. Yes in the long run we are all dead. Porting a number in the IP domain ought to be simply an ENUM re-registration. Correct ... IF the PSTN disapears. but I'm not holding my breath for that to happen anytime soon or ending world hunger, rediscovering cold fusion, fixing the US trade decifit...etc A single ENUM dip should be needed, not an ENUM and an NP dip. Some of the crufty PSTN mechanisms will fade away, no? Yes and we'll all join hands and sing Kumbayaa, but until that time of perfect Nirvana, spiritual harmony and bliss arrives we'll just have to plug along trying to solve the simple practial problems of interworking IP and PSTN networks. Mike -- 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Mon, 25 Jul 2005 12:20:45 -0400 From: "Stastny Richard" Date: Mon, 25 Jul 2005 12:20:45 -0400 To: "Richard Shockey" Subject: [Enum] Generic Enumservices required? Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C054@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R All, In my last post below I talked about "generic" Enumservices here a more detailed explanation what I mean with this: User ENUM is an additional service to an existing service on the PSTN (with the exception of ENUM-only numbers), where an end-user may define additional services linked to this E.164 numbers on the Internet To point to this services the end-user is using URIs, but these URIs alone are not sufficient. So Enumservices are used for two purposes: 1. to allow clients to find out the application needed without the need to evaluate the regexp (a requirement from Patrik) 2. to provide additional information about the application needed if the same URI is used e.g. for email:mailto; sms:mailto, mms:mailto, ifax:mailto fax:tel; sms:tel; mms:tel, voice:tel; video:tel, etc: Carrier ENUM is an additional service (at least at the moment) carriers may use to point to the destination NETWORK if they host the E.164 number for the end-user. The npd:tel Enumservice is typically such a generic Enumservice: the information is not even contained in the tel URI, it is in the "rn" parameter. and the "rn" parameter is basically giving the destination network, and not the services which are connected with the E.164 number. So in Carrier ENUM a carrier may provide the following information: a generic information (also sip is a "generic information) npd:tel and rn for ported numbers npd:tel without rn (not ported) in addition the entry in cariier ENUM may point with sip either to a SBC or to a gateway to the PSTN using sip with rn is IMHO not useful, because a carrier would either point to his own gateway or just use npd.tel. As I already explained, an enum:tel would be useful to point from carríer ENUM to User ENUM for ENUM-only numbers (they do not belong to any carrier) npd:tel (or something similar) would be useful for User ENUM to add the information that the number is also existing on the PSTN (this would replace voice:tel) -richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Stastny Richard Gesendet: Mo 25.07.2005 12:23 An: Richard Shockey Cc: enum at ietf.org Betreff: Re: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Rich, One comment first I basically like the idea of a generic tel Enumservice, whatever it is called. but I do not have thought through all implications Maybe we can discuss this in Paris (we have a whole week ;-) To your remarks: >That is not true. The ENUM serive npd indicated number portability data >that may be associated with any telephone number. >The examples in the textare quite clear that the information relates to >both Ported and NonPorted numbers. Thats what I said: Still, the sentence: "The purpose of this Enumservice is to describe information about telephone numbers which cannot be used on the public Internet or a private/peered Internet Protocol (IP) network. " is unclear (or wrong, because you can use proted numbers on the Public Internet (I do) >The modification is to define a new enumservice field. >E2U+npd:sip >with the URI defined something like this. >NAPTR 10 10 "u" "E2U+npd:sip" >"!^.*$!sip:+15714345651 at mg4.mso.net;rn=+15712768933;npdi!" >the rationale for this is that many gateways dont know what tel URI's are. Now I am completely lost. I tought the "npd" was a generic Enumservice giving the "rn" to be used (in the national network), but the gateway to user is your choice. One may even query this information from the PSTN via a IN-mediation device. Now you introduce a specific "transit" gateway. BTW: your example URI should be: sip:+15714345651;rn=+15712768933;npdi at mg4.mso.net >For what purpose? For this: > >One example is the usage of ENUM-only numbers existing only >in User ENUM (e.g. +43780 and +87810). Here a pointer in >Carrier ENUM may be useful to point from Carrier ENUM to >User ENUM. Such a number may have a routing number , but >this routing numbers are only of national significance and cannot >be used in a global system. > >There is also missing a note that with this Enumservice the tel URI >MUST always contain the same number then the AUS. ________________________________ Von: Richard Shockey [mailto:Rich.Shockey at neustar.biz] Gesendet: Fr 22.07.2005 20:46 An: Stastny Richard Cc: Richard Shockey; enum at ietf.org Betreff: Re: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Stastny Richard wrote: >Dear all, > >although I did not receive (yet) any response to my e-mail below, >I want to comment on the mentioned draft: > >I have a question to the following paragraph: > >"The following Enumservice is registered with this document: "npd" to > indicate number portability data. The purpose of this Enumservice is > to describe information about telephone numbers which cannot be used > on the public Internet or a private/peered Internet Protocol (IP) > network. Thus, these are numbers which are only reachable via the > traditional Public Switched Telephone Network (PSTN)." > >The second sentence seems to imply that ONLY ported numbers >will be used with the Enumservice "npd". The example 4.2 indicates >that also non-ported numbers may be used. > > That is not true. The ENUM serive npd indicated number portability data that may be associated with any telephone number. The examples in the textare quite clear that the information relates to both Ported and NonPorted numbers. 4.1 Example of a Ported Telephone Number $ORIGIN 3.1.8.7.1.8.9.5.1.2.1.e164.arpa. NAPTR 10 100 "u" "E2U+npd:tel" "!^.*$!tel:+1-215-981-7813;rn=+1-215-981-7600;npdi!" In this example, a Routing Number (rn) and a Number Portability Dip Indicator (npdi) are used as shown in draft-ietf-iptel-tel-np-06.txt [10] (Internet-Draft New Parameters for the "tel" URI to Support Number Portability, draft-ietf-iptel-tel-np-06.txt [10]). The 'npdi' field is included in order to prevent subsequent lookups in legacy- style PSTN databases. 4.2 Example of a Non-Ported Telephone Number $ORIGIN 3.1.8.7.1.8.9.5.1.2.1.e164.arpa. NAPTR 10 100 "u" "E2U+npd:tel" "!^.*$!tel:+1-215-981-7813;npdi!" I have had a private request to consider an alternative formation of th e URI. as in The modification is to define a new enumservice field. E2U+npd:sip with the URI defined something like this. NAPTR 10 10 "u" "E2U+npd:sip" "!^.*$!sip:+15714345651 at mg4.mso.net;rn=+15712768933;npdi!" the rationale for this is that many gateways dont know what tel URI's are. > >The third sentence is simply not true: I myself have ported numbers >that can be reached on the public Internet via SIP URIs. > > A fair criticism a better wording might have been. "Thus, this information is only useful in a national specific context within the traditional Public Switched Telephone Network (PSTN)." > >IMHO there is a more in-depth analysis required how this >Enumservice is used, what it implies and with which other >Enumservices it can be used togother > >There is also a need to consolidate the different Enumservices >using the tel URI and their use in User and Carrier ENUM. >Also the usage of crosspointers (entries in User ENUM pointing >to Carrier ENUM and vice versa) with tel URIs is necessary. > > For what purpose? > >One example is the usage of ENUM-only numbers existing only >in User ENUM (e.g. +43780 and +87810). Here a pointer in >Carrier ENUM may be useful to point from Carrier ENUM to >User ENUM. Such a number may have a routing number , but >this routing numbers are only of national significance and cannot >be used in a global system. > >There is also missing a note that with this Enumservice the tel URI >MUST always contain the same number then the AUS. > >regards > >-richard > >________________________________ > >Von: enum-bounces at ietf.org im Auftrag von Stastny Richard >Gesendet: So 10.07.2005 14:51 >An: Richard Shockey; enum at ietf.org >Betreff: Re: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt > > > >Dear all, especially Allison Mankin, > >I consider this I-D very interesting, because I also proposed in the past to use the >parameters defined in draft-ietf-iptel-tel-np-06.txt e.g. ";rn=" within ENUM, >but did not bring this forward because of reason stated below. > >Before I comment on this draft and raise some questions, I would like to >get some principle statements from our esteemed AD Allison if this draft >is within the scope of IETF and ENUM WG. > >The rationale for this question is the following: > >The intended use of the Enumservice "npd:tel" is primarily for >carriers, because only carriers my interpret and use the "rn= parameter. > >Routing numbers MUST NEVER be used by end-users. > >During the discussion Lawrence Conroy and I had with Ted Hardie >and Allison Mankin in Geneva in May regarding the I-D draft-ietf-enum-msg-04.txt, >especially about Enumservice "mms:mailto", I mentioned the fact that >this Enumservice MAY also be used by carriers. > >Allison did not like this statement at all and said ENUM and >Enumservices to-be-defined are ONLY for end-user usage. I only >got over this hurdle by confirming that "mms:mailto" is ALSO >useful for end-users. > >Therefore I want to have a clear statement from the responsible AD >if an Enumservice for carrier use ONLY is within the scope of ENUM WG, >before I waste my time in discussing this I-D on the list. > >Richard Stastny > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Mon, 25 Jul 2005 12:45:34 -0400 From: "Michael Hammer \(mhammer\)" Date: Mon, 25 Jul 2005 12:45:34 -0400 To: "Stastny Richard" Subject: RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Message-ID: <072C5B76F7CEAB488172C6F64B30B5E35E8ECE@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard, I did not write the draft, nor the email that started this, so as my later comment noted, it was not clear what ENUM the original email referred to. Inline. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] > Sent: Monday, July 25, 2005 11:11 AM > To: Michael Hammer (mhammer); Richard Shockey > Cc: enum at ietf.org > Subject: Re: [Enum] Fwd: I-D > ACTION:draft-livingood-shockey-enum-npd-00.txt > > Mike wrote: > > >All E.164 numbers in ENUM are effectively ported, so I don't > understand > >why the npd needs to be an ENUM service rather than just an > attribute > >of the tel ENUM service. This is not to say that the result > returned > >does not have the npdi, rn, cic or other tel parameters provided. > > Since e talk here about USER ENUM and Carrier ENUM, could you > PLEASE state what ENUM you are talking about. > In User ENUM it is meaningless if a number is ported or not, > because the holder of the domain is the end-user having the > right to use the number and this user does not change if the > number is ported This begs the question. If I have the right to use an E.164 number and therefore can register it in User ENUM, can I not register it even when I have a PSTN phone along with other IP-based services? This would suggest that I could put in a tel URI in the NAPTR, no? > In Carrier ENUM the holder of the domain has to change if the > number is ported. Call it porting if you like, but do you use the ENUM registration process or the Number Portability process to make the change in the Carrier ENUM registry? > What is the tel ENUM services? There is none currently defined. I have heard discussion of putting tel URIs in NAPTR records (maybe that was on IPTEL list). Perhaps, I am using wrong terminology. What do you call such NAPTRs? Perhaps, also defining such is still work in progress. I found all the SIP+E2U versus E2U+SIP IANA registration mixup confusing. > >Second, IP-based softswitches can do routing based on such > information > >in the IP domain, so such information is not only of use to > PSTN-based > >switches (during the migration from PSTN to IP-based). > > No, routing numbers are only meaningfull on the PSTN and also > here only in a national context. Given the +CCxxxxx digits the national context can be known. While it is meanful to determine which switch or gateway the rn= digits are homed to, that does not mean that one needs to route to the nearest PSTN GW to get the call to that switch. If an SP has many PSTN GWs, it may be cost-effective to route to that rn= value through one PSTN GW versus another. Are there any assumptions being made here? > On IP you need an additional information, e.g. instead of a > tel URI with a rn also a sip URI with a domain name. Some have suggested that having tel instead of sip URI leaves the IP-domain more flexibility in how to route. > >Third, since number portability is essentially performed by service > >providers, is the scope of this limited only to Carrier ENUM? > > YES. I said it many times already that a user cannot access > routing numbers, so putting rn in User ENUM is not useful. The original email did not specify Carrier ENUM. Mike > >Number portability is a PSTN routing database mechanism. If ENUM is > >done right, then when the TDM PSTN as we know it disappears, > so should > >number portability. Porting a number in the IP domain ought to be > >simply an ENUM re-registration. A single ENUM dip should be needed, > >not an ENUM and an NP dip. Some of the crufty PSTN mechanisms will > >fade away, no? > > Maybe, maybe not > > >Mike > > > > -----Original Message----- > > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] > On Behalf > > Of Stastny Richard > > Sent: Monday, July 25, 2005 6:23 AM > > To: Richard Shockey > > Cc: enum at ietf.org > > Subject: Re: [Enum] Fwd: I-D > > ACTION:draft-livingood-shockey-enum-npd-00.txt > > > > Rich, > > > > One comment first > > I basically like the idea of a generic tel Enumservice, > whatever it is > > called. but I do not have thought through all implications Maybe we > > can discuss this in Paris (we have a whole week ;-) > > > > To your remarks: > > > > >That is not true. The ENUM serive npd indicated number > > portability data > > >that may be associated with any telephone number. > > > > >The examples in the textare quite clear that the information > > relates to > > >both Ported and NonPorted numbers. > > > > Thats what I said: > > > > Still, the sentence: > > > > "The purpose of this Enumservice is > > to describe information about telephone numbers which > cannot be used > > on the public Internet or a private/peered Internet Protocol (IP) > > network. " > > > > is unclear (or wrong, because you can use proted numbers on > the Public > > Internet (I do) > > > > >The modification is to define a new enumservice field. > > >E2U+npd:sip > > >with the URI defined something like this. > > > > >NAPTR 10 10 "u" "E2U+npd:sip" > > >"!^.*$!sip:+15714345651 at mg4.mso.net;rn=+15712768933;npdi!" > > > > >the rationale for this is that many gateways dont know what > > tel URI's are. > > > > Now I am completely lost. I tought the "npd" was a generic > Enumservice > > giving the "rn" to be used (in the national network), but > the gateway > > to user is your choice. One may even query this information > from the > > PSTN via a IN-mediation device. Now you introduce a > specific "transit" > > gateway. > > > > BTW: your example URI should be: > > sip:+15714345651;rn=+15712768933;npdi at mg4.mso.net > > > > > > >For what purpose? > > > > For this: > > > > > > > >One example is the usage of ENUM-only numbers existing > only in User > > >ENUM (e.g. +43780 and +87810). Here a pointer in Carrier > ENUM may be > > >useful to point from Carrier ENUM to User ENUM. Such a > > number may have > > >a routing number , but this routing numbers are only of national > > >significance and cannot be used in a global system. > > > > > >There is also missing a note that with this Enumservice > the tel URI > > >MUST always contain the same number then the AUS. > > > > > > > > ________________________________ > > > > Von: Richard Shockey [mailto:Rich.Shockey at neustar.biz] > > Gesendet: Fr 22.07.2005 20:46 > > An: Stastny Richard > > Cc: Richard Shockey; enum at ietf.org > > Betreff: Re: [Enum] Fwd: I-D > > ACTION:draft-livingood-shockey-enum-npd-00.txt > > > > > > > > Stastny Richard wrote: > > > > >Dear all, > > > > > >although I did not receive (yet) any response to my e-mail > below, I > > >want to comment on the mentioned draft: > > > > > >I have a question to the following paragraph: > > > > > >"The following Enumservice is registered with this > document: "npd" to > > > indicate number portability data. The purpose of this > > Enumservice is > > > to describe information about telephone numbers which > > cannot be used > > > on the public Internet or a private/peered Internet > Protocol (IP) > > > network. Thus, these are numbers which are only > reachable via the > > > traditional Public Switched Telephone Network (PSTN)." > > > > > >The second sentence seems to imply that ONLY ported > numbers will be > > >used with the Enumservice "npd". The example 4.2 indicates > that also > > >non-ported numbers may be used. > > > > > > > > That is not true. The ENUM serive npd indicated number portability > > data that may be associated with any telephone number. > > > > The examples in the textare quite clear that the > information relates > > to both Ported and NonPorted numbers. > > > > 4.1 Example of a Ported Telephone Number > > > > $ORIGIN 3.1.8.7.1.8.9.5.1.2.1.e164.arpa. > > > > NAPTR 10 100 "u" "E2U+npd:tel" > > > > "!^.*$!tel:+1-215-981-7813;rn=+1-215-981-7600;npdi!" > > > > > > In this example, a Routing Number (rn) and a Number Portability Dip > > > > Indicator (npdi) are used as shown in draft-ietf-iptel-tel-np-06.txt > > > > [10] (Internet-Draft New Parameters for the "tel" URI to Support > > > > Number Portability, draft-ietf-iptel-tel-np-06.txt [10]). The 'npdi' > > > > field is included in order to prevent subsequent lookups in legacy- > > > > style PSTN databases. > > > > 4.2 Example of a Non-Ported Telephone Number > > > > $ORIGIN 3.1.8.7.1.8.9.5.1.2.1.e164.arpa. > > > > NAPTR 10 100 "u" "E2U+npd:tel" > > > > "!^.*$!tel:+1-215-981-7813;npdi!" > > > > I have had a private request to consider an alternative > formation of > > th e URI. > > > > as in > > > > The modification is to define a new enumservice field. > > > > E2U+npd:sip > > > > with the URI defined something like this. > > > > NAPTR 10 10 "u" "E2U+npd:sip" > > "!^.*$!sip:+15714345651 at mg4.mso.net;rn=+15712768933;npdi!" > > > > the rationale for this is that many gateways dont know what > tel URI's > > are. > > > > > > > >The third sentence is simply not true: I myself have > ported numbers > > >that can be reached on the public Internet via SIP URIs. > > > > > > > > A fair criticism a better wording might have been. > > > > "Thus, this information is only useful in a national > specific context > > within the traditional Public Switched Telephone Network (PSTN)." > > > > > > > > > >IMHO there is a more in-depth analysis required how this > > Enumservice is > > >used, what it implies and with which other Enumservices it > > can be used > > >togother > > > > > >There is also a need to consolidate the different > Enumservices using > > >the tel URI and their use in User and Carrier ENUM. > > >Also the usage of crosspointers (entries in User ENUM pointing to > > >Carrier ENUM and vice versa) with tel URIs is necessary. > > > > > > > > For what purpose? > > > > > > > >One example is the usage of ENUM-only numbers existing > only in User > > >ENUM (e.g. +43780 and +87810). Here a pointer in Carrier > ENUM may be > > >useful to point from Carrier ENUM to User ENUM. Such a > > number may have > > >a routing number , but this routing numbers are only of national > > >significance and cannot be used in a global system. > > > > > >There is also missing a note that with this Enumservice > the tel URI > > >MUST always contain the same number then the AUS. > > > > > >regards > > > > > >-richard > > > > > >________________________________ > > > > > >Von: enum-bounces at ietf.org im Auftrag von Stastny Richard > > >Gesendet: So 10.07.2005 14:51 > > >An: Richard Shockey; enum at ietf.org > > >Betreff: Re: [Enum] Fwd: I-D > > >ACTION:draft-livingood-shockey-enum-npd-00.txt > > > > > > > > > > > >Dear all, especially Allison Mankin, > > > > > >I consider this I-D very interesting, because I also > proposed in the > > >past to use the parameters defined in > draft-ietf-iptel-tel-np-06.txt > > >e.g. ";rn=" within ENUM, but did not bring this forward > > because of reason stated below. > > > > > >Before I comment on this draft and raise some questions, I > > would like > > >to get some principle statements from our esteemed AD > > Allison if this > > >draft is within the scope of IETF and ENUM WG. > > > > > >The rationale for this question is the following: > > > > > >The intended use of the Enumservice "npd:tel" is primarily for > > >carriers, because only carriers my interpret and use the > > "rn= parameter. > > > > > >Routing numbers MUST NEVER be used by end-users. > > > > > >During the discussion Lawrence Conroy and I had with Ted > Hardie and > > >Allison Mankin in Geneva in May regarding the I-D > > >draft-ietf-enum-msg-04.txt, especially about Enumservice > > "mms:mailto", > > >I mentioned the fact that this Enumservice MAY also be used > > by carriers. > > > > > >Allison did not like this statement at all and said ENUM and > > >Enumservices to-be-defined are ONLY for end-user usage. I > > only got over > > >this hurdle by confirming that "mms:mailto" is ALSO useful for > > >end-users. > > > > > >Therefore I want to have a clear statement from the > > responsible AD if > > >an Enumservice for carrier use ONLY is within the scope of > ENUM WG, > > >before I waste my time in discussing this I-D on the list. > > > > > >Richard Stastny > > > > > > > -- > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > 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 at ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Mon, 25 Jul 2005 12:58:27 -0400 From: "Michael Hammer \(mhammer\)" Date: Mon, 25 Jul 2005 12:58:27 -0400 To: "Richard Shockey" Subject: RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Message-ID: <072C5B76F7CEAB488172C6F64B30B5E35E8ED5@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard, I suspect that some 20 years in the future we will have something called the PSTN, but it will not look anything like the TDM network. My only goal here is to not assume that the number portability databases and processes will automatically become the ENUM databases and processes. As a result, I start with the assumption that number portability is purely a TDM mechanism that affect routing in the TDM domain. But, then acknowledge that certain information may bleed over and be acted on in the IP domain. But, there have been others that have suggested that somehow the ENUM registration change needs to be dependent on the number portability change, and I don't think that is necessary. If ENUM can do it in one day, while NP takes several weeks, no sense in anchoring ENUM down. Mike > -----Original Message----- > From: Richard Shockey [mailto:richard at shockey.us] > Sent: Monday, July 25, 2005 11:52 AM > To: Michael Hammer (mhammer) > Cc: Stastny Richard; Richard Shockey; enum at ietf.org > Subject: Re: [Enum] Fwd: I-D > ACTION:draft-livingood-shockey-enum-npd-00.txt > > Michael Hammer (mhammer) wrote: > > >Richard and Richard, > > > >All E.164 numbers in ENUM are effectively ported, > > > you cannot completely draw that conclusion over time. Policy > over number allocation isues are under serious discussion > which might change that statement ..though for the indefinate > future it is reasonable to assume that most VoIP numbers will > be ported or pooled. > > > so I don't understand > >why the npd needs to be an ENUM service rather than just an > attribute > >of the tel ENUM service. This is not to say that the result > returned > >does not have the npdi, rn, cic or other tel parameters provided. > > > > > Enhancing the search pattern the resolver uses to find the > appropriate NAPTR record. Yes it could use a pure E2U+tel but > I think this is better and there are logical arguments for > seperating values out such as if you wanted to add CNAM. > > Unlike some in this WG I have never had an objection to > granular "hints" > as to the service or information contained in a NAPTR record. > > More information is better than less. > > >Second, IP-based softswitches can do routing based on such > information > >in the IP domain, so such information is not only of use to > PSTN-based > >switches (during the migration from PSTN to IP-based). > > > > > Yes .. you can make some interesting trunking decisions based > on the NPA-NXX of a particular LRN if you can aquire that > information at point of session origination vs N-1. > > >Third, since number portability is essentially performed by service > >providers, is the scope of this limited only to Carrier ENUM? > > > > > Yes ..that should be self evident by now but as Richard > points out this is a national specific issue. And as I > spefically said before North American LNP data cannot be > openly distributed. The context of the query in the US and > Canada would certainly be some form of closed network or > internal network databases that have DNS query response capability. > > BTW this would certainly work in a SIP redirect context as well. > > >Number portability is a PSTN routing database mechanism. If ENUM is > >done right, > > > and IF you get significant consumer and enterprise OP-IN ... > lots of big IF's here > > > then when the TDM PSTN as we know it disappears, so should number > >portability. > > > Yes in the long run we are all dead. > > > Porting a number in the IP domain ought to be simply an ENUM > >re-registration. > > > Correct ... IF the PSTN disapears. but I'm not holding my > breath for that to happen anytime soon or ending world > hunger, rediscovering cold fusion, fixing the US trade decifit...etc > > > A single ENUM dip should be needed, not an ENUM and an NP > dip. Some > >of the crufty PSTN mechanisms will fade away, no? > > > > > Yes and we'll all join hands and sing Kumbayaa, but until > that time of perfect Nirvana, spiritual harmony and bliss > arrives we'll just have to plug along trying to solve the > simple practial problems of interworking IP and PSTN networks. > > >Mike > > > > > > > > -- > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Mon, 25 Jul 2005 15:46:15 -0400 From: "Stastny Richard" Date: Mon, 25 Jul 2005 15:46:15 -0400 To: "Michael Hammer \(mhammer\)" Subject: Re: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C057@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Mike wrote: >This begs the question. If I have the right to use an E.164 number and >therefore can register it in User ENUM, can I not register it even when >I have a PSTN phone along with other IP-based services? This would >suggest that I could put in a tel URI in the NAPTR, no? This is a very valid point, and needs some explanation, because there is some history involved Originally this was not considered necessary, because any entry in User ENUM requires that the E.164 number exists (is assigned to an end-user) and is IN SERVICE. The last point is a validation requirement. So a number within a block assigned to a carrier and not in service cannot be in User ENUM. So putting a tel URI with the same number would give no additional information. Nevertheless, a voice:tel Enumservice is proposed (and in discussion for now already 3 years), to be used to point to another E.164 number on the PSTN e.g. if you try a sip URI and it does not work, you may try my mobile number.This voice:tel is implemented in Austria (it is defined by ETSI) and ALSO used be some end-users (e.g. companies to exactly do what you suggest, namely to indicate that the same number is existing on the PSTN also. The reason for this is because in the meantime so-called ENUM-only numbers which do not exist on the PSTN are also in use. When I say do not exist this does not mean they are not routed. This numbers are routed to gateways from the PSTN to IP, so if you route such calls from the Internet to the PSTN you would finally end up on the Internet again. Having this in mind, an indication that the number also exists REALLY on the PSTN would make sense now. If this is finally voice:tel or ndp:tel is a somewhat philosophical question discussed within ENUM WG since years. One should only keep in mind that also some other proposals exist using the tel: URI. One is video:tel. Here the issue is not so clear, because here at least two standards exist, one for ISDN video and one for 3G video. In addition there exists the proposal for enum:tel. This enum service would allow to point to another number in ENUM. One use case would be that you have eg 3 E.164 numbers in ENUM and point two of them to the third and maintain your real ENUM entries only in onel place. The other use case would be to cross-point to an ENUM-only number from a carrier ENUM tree. ENUM-only numbers cannot be hosted in Carrier ENUM by definition, because the number exists only in User ENUM and the information there is authoritative. So some infromation is necessary in Carrier ENUM to indicate this fact. The easiest would be to put in one wildcard record for the whole number range. There is also a proposal to use enum:tel with special parameters giving the apex of the carreir tree in the tel: URI instead of the non-terminal NAPTRs in Tier 1 -richard PS: additional answers in separate postings _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Jason_Livingood@cable.comcast.com Mon, 25 Jul 2005 15:50:57 -0400 From: "Livingood, Jason" Date: Mon, 25 Jul 2005 15:50:57 -0400 To: "Michael Hammer \(mhammer\)" Subject: RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73FF014A@PACDCEXCMB01.cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Replies inline below. > I suspect that some 20 years in the future we will have > something called the PSTN, but it will not look anything like > the TDM network. My only goal here is to not assume that the > number portability databases and processes will automatically > become the ENUM databases and processes. > As a result, I start with the assumption that number > portability is purely a TDM mechanism that affect routing in > the TDM domain. But, then acknowledge that certain > information may bleed over and be acted on in the IP domain. This is probably a fair assumption to make. However, simply because the endpoints may not be IP-based, does not mean that the data/addressing cannot be queried for over IP or that such data can be distributed via IP networks. The motivation on my part grew out of a desire to consolidate both on-net and off-net TN lookups into a single DNS query that hits my ENUM server. Some vendors are (creatively) starting to propose methods of doing so (to carriers at least) that are vendor-specific (aka proprietary). As a service provider, I have an interest in trying to standardize this so that I have more potential software providers to choose from, more competition, innovation, etc. I then have a open standards-based method for querying for any addressing info associated with both on-net and off-net TNs (not-IP-based, or not IP-based that I can route to), as well as distributing such data around my IP network, etc. since it all uses DNS and ENUM. > But, there have been others that have suggested that somehow > the ENUM registration change needs to be dependent on the > number portability change, and I don't think that is > necessary. If ENUM can do it in one day, while NP takes > several weeks, no sense in anchoring ENUM down. This should not in any way slow down or conflict with various national NP processes. Jason Livingood _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Mon, 25 Jul 2005 16:06:48 -0400 From: "Stastny Richard" Date: Mon, 25 Jul 2005 16:06:48 -0400 To: "Michael Hammer \(mhammer\)" Subject: Re: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C058@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Mike wrote: >> In Carrier ENUM the holder of the domain has to change if the >> number is ported. >Call it porting if you like, but do you use the ENUM registration >process or the Number Portability process to make the change in the >Carrier ENUM registry? It is not decided yet how this works in practice This is the discussion about the so-called carrier-of-record, and will be defined nationally It is my private opinion that basically no validation is necessary if a carrier says he is hosting the number. Why should he cheat? In User ENUM it is commonly agreed that the best validation method is that the carrier hosting the number is approving that the end-user has the right to use this number. Now if the carrier wants to do the same in carrier ENUM why not trust him now? What would be the incentive to enter number in Carrier ENUM he is not hosting? the calls would be routed to him and what then? Carrier ENUMs already implemented use this trust principle Of course if a process for NP is in place and Carrier ENUM is implemented in or near e164.arpa, the existing mechanism could be used to include Carrier ENUM also. >> What is the tel ENUM services? There is none currently defined. >I have heard discussion of putting tel URIs in NAPTR records (maybe that >was on IPTEL list). Perhaps, I am using wrong terminology. What do you >call such NAPTRs? Perhaps, also defining such is still work in >progress. I found all the SIP+E2U versus E2U+SIP IANA registration >mixup confusing. As I stated in my previous posting, there are many Enumservices using tel: URI already. in addition there is fax:tel, mms:tel, sms:tel, etc Yes, it is confusing and you are not alone ;-) > >> No, routing numbers are only meaningfull on the PSTN and also >> here only in a national context. >Given the +CCxxxxx digits the national context can be known. While it >is meanful to determine which switch or gateway the rn= digits are homed >to, that does not mean that one needs to route to the nearest PSTN GW to >get the call to that switch. If an SP has many PSTN GWs, it may be >cost-effective to route to that rn= value through one PSTN GW versus >another. Are there any assumptions being made here? You may route such a call to any PSTN-GW, but then the rn info is meaningless, so you could as well remove it. Only if you route it to a PSTN GW in the country, an then you just save the GW another NP dip. As Rich pointed out this is basically for the US and here everything is national anyway ;-) The real benefit of this Enumservice is IMHO that you may no use Carrier ENUM as the real NP Database by querying the DB also from the PSTN via an IN SCP-mediation -richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Mon, 25 Jul 2005 16:28:52 -0400 From: "Michael Hammer \(mhammer\)" Date: Mon, 25 Jul 2005 16:28:52 -0400 To: "Stastny Richard" Subject: RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Message-ID: <072C5B76F7CEAB488172C6F64B30B5E35E8FCE@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Some comments inline. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] > Sent: Monday, July 25, 2005 4:10 PM > To: Michael Hammer (mhammer); Richard Shockey > Cc: enum at ietf.org > Subject: Re: [Enum] Fwd: I-D > ACTION:draft-livingood-shockey-enum-npd-00.txt > > Mike wrote: > > >> In Carrier ENUM the holder of the domain has to change if > the number > >> is ported. > > >Call it porting if you like, but do you use the ENUM registration > >process or the Number Portability process to make the change in the > >Carrier ENUM registry? > > It is not decided yet how this works in practice > > This is the discussion about the so-called carrier-of-record, > and will be defined nationally > > It is my private opinion that basically no validation is > necessary if a carrier says he is hosting the number. Why > should he cheat? Ummm... Add 10 second post-dial delay then onward route? Then advertize your network's quick setup. :) Just being cynical. > > In User ENUM it is commonly agreed that the best validation > method is that the carrier hosting the number is approving > that the end-user has the right to use this number. > > Now if the carrier wants to do the same in carrier ENUM why > not trust him now? > What would be the incentive to enter number in Carrier ENUM > he is not hosting? > the calls would be routed to him and what then? > > Carrier ENUMs already implemented use this trust principle > > Of course if a process for NP is in place and Carrier ENUM is > implemented in or near e164.arpa, the existing mechanism > could be used to include Carrier ENUM also. > > >> What is the tel ENUM services? There is none currently defined. > > >I have heard discussion of putting tel URIs in NAPTR records (maybe > >that was on IPTEL list). Perhaps, I am using wrong > terminology. What > >do you call such NAPTRs? Perhaps, also defining such is > still work in > >progress. I found all the SIP+E2U versus E2U+SIP IANA registration > >mixup confusing. > > As I stated in my previous posting, there are many > Enumservices using tel: URI already. in addition there is > fax:tel, mms:tel, sms:tel, etc > > Yes, it is confusing and you are not alone ;-) > > > > > >> No, routing numbers are only meaningfull on the PSTN and also here > >> only in a national context. > > >Given the +CCxxxxx digits the national context can be known. > While it > >is meanful to determine which switch or gateway the rn= digits are > >homed to, that does not mean that one needs to route to the nearest > >PSTN GW to get the call to that switch. If an SP has many > PSTN GWs, it > >may be cost-effective to route to that rn= value through one PSTN GW > >versus another. Are there any assumptions being made here? > > You may route such a call to any PSTN-GW, but then the rn > info is meaningless, so you could as well remove it. The PSTN GW can interwork this information into the appropriate ISUP parameter. > Only if you route it to a PSTN GW in the country, an then you > just save the GW another NP dip. Exactly. > As Rich pointed out this is basically for the US and here > everything is national anyway ;-) > > The real benefit of this Enumservice is IMHO that you may no > use Carrier ENUM as the real NP Database by querying the DB > also from the PSTN via an IN SCP-mediation Yes, the ENUM can *now* replace the current NP database system. Mike > -richard > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From richard@shockey.us Mon, 25 Jul 2005 16:48:02 -0400 From: Richard Shockey Date: Mon, 25 Jul 2005 16:48:02 -0400 To: "Michael Hammer (mhammer)" Subject: Re: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E35E8FCE@xmb-rtp-20b.amer.cisco.com> Message-ID: <42E54FE3.9050209@shockey.us> MIME-Version: 1.0 Content-Type: text/plain Status: R Michael Hammer (mhammer) wrote: As Rich pointed out this is basically for the US and here everything is national anyway ;-) The real benefit of this Enumservice is IMHO that you may no use Carrier ENUM as the real NP Database by querying the DB also from the PSTN via an IN SCP-mediation Yes, the ENUM can *now* replace the current NP database system. Ah ...well.. no. You cant replace the NPAC ..but you can provide service providers some new options on how to use it. -- 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Mon, 25 Jul 2005 17:12:22 -0400 From: "Michael Hammer \(mhammer\)" Date: Mon, 25 Jul 2005 17:12:22 -0400 To: "Richard Shockey" Subject: RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Message-ID: <072C5B76F7CEAB488172C6F64B30B5E35E8FFD@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Oh, I was trying to clarify whether "you may *no* use Carrier ENUM" was "not" or "now" in my over-eager response. I am hoping that ENUM works faster than the current NP. It seems to be taking weeks for my home number under the old system. We shouldn't just put lipstick on an old system. Mike > -----Original Message----- > From: Richard Shockey [mailto:richard at shockey.us] > Sent: Monday, July 25, 2005 4:48 PM > To: Michael Hammer (mhammer) > Cc: Stastny Richard; enum at ietf.org > Subject: Re: [Enum] Fwd: I-D > ACTION:draft-livingood-shockey-enum-npd-00.txt > > Michael Hammer (mhammer) wrote: > > >>As Rich pointed out this is basically for the US and here > everything > >>is national anyway ;-) > >> > >>The real benefit of this Enumservice is IMHO that you may no use > >>Carrier ENUM as the real NP Database by querying the DB > also from the > >>PSTN via an IN SCP-mediation > >> > >> > > > >Yes, the ENUM can *now* replace the current NP database system. > > > > > > Ah ...well.. no. You cant replace the NPAC ..but you > can provide service providers some new options on how to use it. > > -- > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lconroy@insensate.co.uk Mon, 25 Jul 2005 18:03:50 -0400 From: lconroy Date: Mon, 25 Jul 2005 18:03:50 -0400 To: Richard Shockey Subject: Re: [Enum] [Fwd: IESG response to appeal regarding draft-ietf-lemonade-mms-mapping-04] In-Reply-To: <42E4EF32.4080909@shockey.us> Message-ID: <46FCEAFE-C4AA-4AE0-BE2A-B7290FADB9E0@insensate.co.uk> MIME-Version: 1.0 Content-Type: text/plain Status: R Super. If anyone intends to use the Msg draft, you may note that the reference to the now dis-approved "Lemonade" MMS mapping draft was introduced in response to IESG request. The Msg draft is technically complete and sits in the RFC-ED "output hopper" merely awaits disposition of what I still believe should be an informational rather than a normative reference. In short, I cannot imagine any further change to the Msg draft - it's ready for RFPs. Enjoy Paris, folks. atb, Lawrence On 25 Jul 2005, at 14:54, Richard Shockey wrote: -------- Original Message -------- Subject: IESG response to appeal regarding draft-ietf-lemonade- mms-mapping-04 Date: Fri, 22 Jul 2005 18:14:06 -0400 From: IESG Secretary To: IETF Announcement list CC: lemonade at ietf.org The IESG has reviewed John Klensin's appeal against the approval of draft-ietf-lemonade-mms-mapping-04.txt (see http://www.ietf.org/IESG/APPEALS/klensin-appeal-lemonade-mms- mapping.txt for the full text of the appeal). Note that the Area Director principally concerned, Ted Hardie, gave technical input during the IESG discussion of the appeal, but recused himself from the approval of this response. After analysis, the IESG withdraws its approval of draft-ietf- lemonade-mms-mapping-04.txt as Proposed Standard and invites the lemonade WG to act on the following points. 1. The IESG agrees that the technical updates between the -02 and -04 versions of draft-ietf-lemonade-mms-mapping were significant enough to warrant re-review by the working group. It therefore asks the working group to review the changes between -02 and -04; if the WG is satisfied that the changes are within its intent, it should so inform the IESG. If not, it should produce a draft that restores its original intent, and so inform the IESG. When the draft is updated, the IESG will restart the review process at IETF Last Call. 2. We note that the Resent-Count header is not mentioned in the IANA Considerations. While RFC 3864 would allow it to be registered independently, based on the OMA documents, it would be valuable to include a note in the IANA Considerations indicating what registration class (Permanent or Provisional) would be sought for and stating that the registration would be accomplished by reference to those documents. Having the registration request be concurrent with or precede the approval of the revised draft would also be valuable. 3. The appeal challenges the legitimacy of a gateway standard mandating certain mappings to and from X- headers. In one place, the draft states: ...Such systems should be aware that X-headers might be removed during transit through Internet MTAs. It is not the IETF's business that the external MMS specification makes use of X- headers in a way that the IETF mail standards do not. Additionally, given the ambiguous status of X- headers due to the discrepancy between RFC 822 and RFC 2822, the WG was placed in a difficult situation. Mail gateways have to satisfy pragmatic as well as formal requirements. The IESG therefore believes that it was within the WG's scope to specify mappings to and from X- headers, as long as it is clear that they are not part of the RFC 2822 standard format and that their treatment by Internet MTAs cannot be relied on. We now believe that the above sentence describing permitted Internet MTA behavior is not sufficiently prominent in the draft, and we request that the working group expand and strengthen it or otherwise remedy the problem, unless the WG decides for other reasons to remove the X- header mappings. If the X- header mappings are retained, they are also candidates for provisional registration under RFC 3864 and should be noted as such in the IANA Considerations. 4. The appeal raises a number of other technical points that were not, as far as we know, raised during WG discussion, WG Last Call, or IETF Last Call. Some of them were raised by John Klensin in a review carried out for the General AD during IESG evaluation. We believe that if they had been raised earlier, they might have affected the document content. But this in itself does not automatically mean the IESG was wrong to approve the document at the Proposed Standard level. However, since the WG will be reconsidering the draft, if the WG wishes to make additional changes based on its review of John's technical concerns, it should do so, and inform the IESG when consensus within the WG has been reached so that a new cycle of IETF review can be initiated. 5. John's appeal raised the question of whether the working group had an adequate opportunity to review the comments raised by his review. The IESG believes that as we continue to encourage cross-area and cross-working-group review, the issue of how to make sure review comments are seen by the right people and handled in an open manner will continue to become more important. We would like to work with the community on guidelines for reviewers, ADs and working groups on how to handle these review comments. In summary, the IESG - withdraws its approval of draft-ietf-lemonade-mms-mapping-04.txt as Proposed Standard - requests the lemonade WG to review and confirm or withdraw the changes between the -02 and -04 versions - notes that the lemonade WG is free to consider other technical comments included in the appeal - requests the lemonade WG to improve the text about MTA treatment of X- headers, if these mappings are retained - requests the lemonade WG to complete the IANA Considerations as necessary, considering RFC 3864 - requests the lemonade WG to provide an updated version of the draft that reflects WG consensus, for renewed IETF Last Call and IESG review. _______________________________________________ IETF-Announce mailing list IETF-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From arnold@ligtvoet.org Mon, 25 Jul 2005 18:17:43 -0400 From: Arnold Ligtvoet Date: Mon, 25 Jul 2005 18:17:43 -0400 To: enum at ietf.org Subject: [Enum] Enum and Bind? Message-ID: <42E564FD.5040107@ligtvoet.org> MIME-Version: 1.0 Content-Type: text/plain Status: R Hi, Fairly new to the list. I'm not sure if this question fits here, but I'm a bit lost. I'm trying to build an example country wide ENUM database with several operators. The main basic works with records like: *.5.7.3.7.5.4.4.e164.lleto.lan. 15 IN NAPTR 100 10 "u" "E2U+sip" "!^\\+(.*)$!sip:\\1 at example_a.co.uk!" . All phone numbers in the +44573750000 range (to +44573759999) should be matched and the output will be sip:4457365xxxx at example_a.co.uk. This part works. I then came to the part where a user ports to a different operator. I still have the before mentioned block at operator example_a, howver +44573751111 is now ported out of the block to example_b. I tried entering : 1.1.1.1.5.7.3.7.5.4.4.e164.lleto.lan. 15 IN NAPTR 100 10 "u" "E2U+sip" "!^\\+(.*)$!sip:\\1 at example_b.co.uk!" . When I reload Bind the block of numbers does not work anymore. The single number at example_b works. I tried changing the order (mention the single host first then the block), but to no avail. How would I solve this. I'm presuming I'm not the first to run into this...? Thanks for any input! Regards, Arnold. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From arnold@ligtvoet.org Mon, 25 Jul 2005 19:00:16 -0400 From: Arnold Ligtvoet Date: Mon, 25 Jul 2005 19:00:16 -0400 To: enum at ietf.org Subject: Re: [Enum] Enum and Bind? Message-ID: <42E56EF7.9000908@ligtvoet.org> MIME-Version: 1.0 Content-Type: text/plain Status: R Derrick D. Daugherty wrote: hmm, your two examples look ok but my first guess was the missing terminating . on your entry. The last "." is actually on the next line in my email. mabye check the bind logs to make sure it's ok when loading the zone and noticed the changes... The syslog gives me no errors and the zone loads. also dig -t axfr e164.lleto.lan @yourNS Tried that and it gave me: *.2.1.7.2.6.1.4.4.e164.lleto.lan. 15 IN NAPTR 100 10 "u" "E2U+sip" "!^\\+(.*)$!sip:\\1 at example_c.co.uk!" . *.8.4.4.0.7.4.4.e164.lleto.lan. 604800 IN NAPTR 100 10 "u" "E2U+sip" "!^\\+(.*)$!sip:\\1 at example_a.co.uk!" . 8.4.4.0.8.4.4.0.7.4.4.e164.lleto.lan. 604800 IN NAPTR 100 10 "u" "E2U+sip" "!^\\+(.*)$!sip:\\1 at axample_b.co.uk!" . and it should return all entries provided you allow transfers to that client. iirc axfr's will also xfer the errors so you should be able to see if the records look wrong. Records look fine, no errors reported. i'm doing these sort of wildcard matches and more-specific matches and it works as expected. bind8 and 9. it should work so my guess is syntax mishap in the zone file. The example_c lookup works fine, the specific telephone number does so as well. The block +4470448xxxx does not work at all (except for the specific number at example_b). Probably I'm missing something small and stupid here. Thanks for your help. Regards, Arnold Ligtvoet. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From arnold@ligtvoet.org Mon, 25 Jul 2005 19:19:38 -0400 From: Arnold Ligtvoet Date: Mon, 25 Jul 2005 19:19:38 -0400 To: enum at ietf.org Subject: Re: [Enum] Enum and Bind? In-Reply-To: <42E56EF7.9000908@ligtvoet.org> Message-ID: <42E5737D.9080302@ligtvoet.org> MIME-Version: 1.0 Content-Type: text/plain Status: R Peter Koch wrote: *.8.4.4.0.7.4.4.e164.lleto.lan. 604800 IN NAPTR 100 10 "u" "E2U+sip" "!^\\+(.*)$!sip:\\1 at example_a.co.uk!" . 8.4.4.0.8.4.4.0.7.4.4.e164.lleto.lan. 604800 IN NAPTR 100 10 "u" "E2U+sip" "!^\\+(.*)$!sip:\\1 at axample_b.co.uk!" . are you aware that the second RR will effectively make the wildcard *not* work for anything below (and including) 0.8.4.4.0.7.4.4.e164.lleto.lan. ? Nope I'm not. I'm trying to figure out how I should enter this in valid 'DNS speak' coming from a telecoms background. Any tips/pointers on how to solve this are very welcome. Thanks, Arnold. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Mon, 25 Jul 2005 20:22:34 -0400 From: "Michael Hammer \(mhammer\)" Date: Mon, 25 Jul 2005 20:22:34 -0400 To: "Livingood, Jason" Subject: RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Message-ID: <072C5B76F7CEAB488172C6F64B30B5E35E9073@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Agree completely. I think I hinted at the idea that the E.164 number could terminate in either the IP domain or TDM domain and still be included in ENUM. My concern about tying too tightly to NP was when I heard suggestion in other fora that ENUM add things like CLLI codes and other TDM elements, as well as anchoring ENUM to NP administrative processes. I may have misunderstood what was proposed, but it seemed headed in the wrong direction. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Livingood, Jason > Sent: Monday, July 25, 2005 3:50 PM > To: Michael Hammer (mhammer); Richard Shockey > Cc: enum at ietf.org; Stastny Richard > Subject: RE: [Enum] Fwd: I-D > ACTION:draft-livingood-shockey-enum-npd-00.txt > > Replies inline below. > > > I suspect that some 20 years in the future we will have something > > called the PSTN, but it will not look anything like the TDM > network. > > My only goal here is to not assume that the number portability > > databases and processes will automatically become the ENUM > databases > > and processes. > > As a result, I start with the assumption that number portability is > > purely a TDM mechanism that affect routing in the TDM domain. But, > > then acknowledge that certain information may bleed over > and be acted > > on in the IP domain. > > This is probably a fair assumption to make. However, simply > because the endpoints may not be IP-based, does not mean that > the data/addressing cannot be queried for over IP or that > such data can be distributed via IP networks. > > The motivation on my part grew out of a desire to consolidate > both on-net and off-net TN lookups into a single DNS query > that hits my ENUM server. Some vendors are (creatively) > starting to propose methods of doing so (to carriers at > least) that are vendor-specific (aka proprietary). As a > service provider, I have an interest in trying to standardize > this so that I have more potential software providers to > choose from, more competition, innovation, etc. I then have > a open standards-based method for querying for any addressing > info associated with both on-net and off-net TNs > (not-IP-based, or not IP-based that I can route to), as well > as distributing such data around my IP network, etc. since it > all uses DNS and ENUM. > > > But, there have been others that have suggested that > somehow the ENUM > > registration change needs to be dependent on the number portability > > change, and I don't think that is necessary. If ENUM can > do it in one > > day, while NP takes several weeks, no sense in anchoring ENUM down. > > This should not in any way slow down or conflict with various > national NP processes. > > Jason Livingood > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jmce@nortel.com Mon, 25 Jul 2005 23:45:18 -0400 From: "James McEachern" Date: Mon, 25 Jul 2005 23:45:18 -0400 To: "Stastny Richard" Subject: RE: [Enum] E.164 communication assumptions/requirements Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Stastny Richard wrote: >The end-user queries User ENUM, the Carrier queries Carrier ENUM. > >A Carrier MAY query User ENUM on behalf of the user in addition, if the >user wants so (opt-in) and the carrier is providing this service. If the Carrier queries Carrier ENUM (and retrieves the POI for that number), and then also queries User ENUM (and receives the URI for the users mobile phone), what should the Carrier do (and why)? If the User ENUM query returns a phone number in another country, what should the carrier do? And finally, if the User ENUM query returns a link to a web page, what should the Carrier do? Jim _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jmce@nortel.com Mon, 25 Jul 2005 23:46:13 -0400 From: "James McEachern" Date: Mon, 25 Jul 2005 23:46:13 -0400 To: "Michael Hammer \(mhammer\)" Subject: RE: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETFParis) Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Michael Hammer wrote: >You've turned the problem around. Please stick with the given scenario. >My mother, party B, ie the called party IS a carrier customer. And I as >the caller am both User ENUM and Carrier ENUM aware. So, why wouldn't >the carrier deliver the service to my mother that she is paying for? The question is, exactly what is your mother paying for? You imply that she is paying to receive all calls targeted to her phone number, without any restrictions. But this is not the case. If you phone your mother from a pay phone (they still do exist) without depositing the required change, the call will not be completed - though your mother may be given the option of paying on your behalf. How is your scenario different? Jim _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jmce@nortel.com Tue, 26 Jul 2005 00:58:40 -0400 From: "James McEachern" Date: Tue, 26 Jul 2005 00:58:40 -0400 To: "Michael Haberler" Subject: RE: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris) Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Michael Haberler wrote: >Enlightened telcos might consult User ENUM too... I'm curious about your rationale for this statement, given that the purpose of User ENUM is to allow end users to directly contact other end users, bypassing the carrier completely. Jim _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lendl@nic.at Tue, 26 Jul 2005 03:47:47 -0400 From: Otmar Lendl Date: Tue, 26 Jul 2005 03:47:47 -0400 To: enum at ietf.org Subject: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris) In-Reply-To: Message-ID: <20050726074724.GA662@nic.at> MIME-Version: 1.0 Content-Type: text/plain Status: R On 2005/07/26 06:07, James McEachern wrote: > > Michael Haberler wrote: > > >Enlightened telcos might consult User ENUM too... > > I'm curious about your rationale for this statement, given that the > purpose of User ENUM is to allow end users to directly contact other > end users, bypassing the carrier completely. > Of course it is best for the originating user to bypass all carriers, but once the call has been handed to a telco, the following rationale applies: Delivering the call to another telco costs termination fees, direct delivery to the enduser over IP is basically for free. Example in the Austrian context: If telco A can use User-ENUM to avoid the normal PoI for a call to a Hutchison 3G mobile, it saves about 20 cent/min on interconnection fees. I understand that the US settlement regime is quite different to the European one, thus the motivations might be different on the western shores of the atlantic. /ol -- < Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From clive@demon.net Tue, 26 Jul 2005 03:57:55 -0400 From: "Clive D.W. Feather" Date: Tue, 26 Jul 2005 03:57:55 -0400 To: Michael Haberler Subject: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris) In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E35E82D8@xmb-rtp-20b.amer.cisco.com> Message-ID: <20050726075745.GB92268@finch-staff-1.thus.net> MIME-Version: 1.0 Content-Type: text/plain Status: R Michael Haberler said [in a different order]: > The fact that you own an E.164 identifier doesnt give you the right to > force everbody else in the world to deliver to said identifier in a way you > would like (and I would like, put the PSTN aint like email). Exactly. This is, in fact, no different to the Internet world. >> I am party A. I get an E.164 number directly from the number >> administrator (not through a carrier) and put it in User ENUM. > did you contract a telco to route that number in the PSTN once you got it, > or not? I am party A. I get a block of IP addresses from RIPE and a domain name from Nominet, and I put them in the DNS. However, unless I contract with an ISP to route those addresses to and from the rest of the Internet, I'm stuck. >> My mother is party B. She gets E.164 number from a carrier who has >> moved her over to VoIP and puts that number in Carrier ENUM, but doesn't >> tell her anything about User ENUM. (She doesn't monitor ENUM WG >> mailer.) My mother is party B. She gets her IP address and domain name from her ISP. >> My mother can call me, since carrier is smart enough to look me up in >> User ENUM. But, they are not required to do so! So, maybe she can't >> call me. >> >> Can I call my mother? No. Can my mother and I email each other? No. > Yes, and that is your problem, not an ENUM problem. Exactly. -- 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ray@bango.net Tue, 26 Jul 2005 04:23:01 -0400 From: Ray Anderson Date: Tue, 26 Jul 2005 04:23:01 -0400 To: "Michael Hammer \(mhammer\)" Subject: RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E35E9073@xmb-rtp-20b.amer.cisco.com> Message-ID: <6.1.2.0.2.20050726091905.03f35650@smtp.bango.net> MIME-Version: 1.0 Content-Type: text/plain Status: R At 01:22 26/07/2005, Michael Hammer \(mhammer\) wrote: Agree completely. I think I hinted at the idea that the E.164 number could terminate in either the IP domain or TDM domain and still be included in ENUM. Just for clarity, there will be ENUM's (E.164 numbers) that DO NOT terminate in either IP or TDM domains. They are used purely for "non-voice" purposes, and allocated by an E.164 "delegator" for such purposes. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From clive@demon.net Tue, 26 Jul 2005 05:16:24 -0400 From: "Clive D.W. Feather" Date: Tue, 26 Jul 2005 05:16:24 -0400 To: "Michael Hammer (mhammer)" Subject: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris) In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E35E8CB4@xmb-rtp-20b.amer.cisco.com> Message-ID: <20050726091520.GD92268@finch-staff-1.thus.net> MIME-Version: 1.0 Content-Type: text/plain Status: R Michael Hammer (mhammer) said: >> did you contract a telco to route that number in the PSTN >> once you got it, or not? > > This number could have been set aside as a VoIP number, thus the PSTN > would route a call to a PSTN gateway that should look it up in User ENUM > and could route over the Internet to me. Of course there is no > regulation requiring them to do so. But, if they didn't you would find > such numbers useless, begging the question of why a national public > resource is wasted. The caller has contracted with the carrier to > deliver the call, so why should the carrier not attempt to deliver it? Because they have no path to do so. For many years, my telco wouldn't deliver calls to various country codes because they didn't have interconnection agreements. In the UK, Directory Enquiries is a competitive service using the (non-E.164) number range 118000 to 118999. My carrier, however, will only connect me to exactly two of those numbers; they haven't bothered to set up an interconnection agreement with the operators of the other 998. In both cases, "contracted with" is JUST PLAIN WRONG - the contract excludes numbers not reachable for such reasons. [Most UK numbers are reachable from one another because BT has a regulatory obligation to provide both interconnect and transit to all comers. However, some combinations don't work because the originating carrier isn't willing to charge a high enough call cost to cover the transit and termination fees involved.] > You've turned the problem around. Please stick with the given scenario. > My mother, party B, ie the called party IS a carrier customer. And I as > the caller am both User ENUM and Carrier ENUM aware. Do you have a call termination agreement with either your mother's telco, or with a telco who does and who is willing to provide transit? If not, then it's *YOUR* fault, not anyone else's. > So, why wouldn't > the carrier deliver the service to my mother that she is paying for? She may need to re-read her contract. >> No, your recourse is to contract a telco to route that number >> in the PSTN, > But, I don't want to route the call through the PSTN at all, I want to > route the call through the Internet to the carrier VoIP network serving > (supposedly) my mother! That carrier network has costs. How are you proposing they be paid, and by whom? -- 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Robert.Shaw@itu.int Tue, 26 Jul 2005 07:24:26 -0400 From: Robert.Shaw@itu.int Date: Tue, 26 Jul 2005 07:24:26 -0400 To: Subject: RE: [Enum] Required reading for IETF Paris Message-ID: <2ECA12DF5FCB7948A1CD9047C3DAF3DCA5210C@MAILBOX1.blue.itu.ch> MIME-Version: 1.0 Content-Type: text/plain Status: R and not to forget either... http://www.bcr.com/bcrmag/2005/06/p08.php rs > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Stastny Richard > Sent: 22 July 2005 18:16 > To: Richard Shockey; enum at ietf.org > Subject: RE: [Enum] Required reading for IETF Paris > > Not to forget: > > http://www.bcr.com/bcrmag/2005/06/p18.php > > IMS 101: What you Need to Know > > Maybe it will be very useful to crosspost this to Voipeer and > Sipping ;-) > > -richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ppfautz@att.com Tue, 26 Jul 2005 07:55:22 -0400 From: "Pfautz, Penn L, NEO" Date: Tue, 26 Jul 2005 07:55:22 -0400 To: "James McEachern" Subject: RE: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETFParis) Message-ID: <34DA635B184A644DA4588E260EC0A25A0ABC9EC8@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Carriers have been know to want to bypass each other when the compensation rules of the PSTN make it advantageous... -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of James McEachern Sent: Tuesday, July 26, 2005 12:58 AM To: Michael Haberler Cc: enum at ietf.org Subject: RE: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETFParis) Michael Haberler wrote: >Enlightened telcos might consult User ENUM too... I'm curious about your rationale for this statement, given that the purpose of User ENUM is to allow end users to directly contact other end users, bypassing the carrier completely. Jim _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ray@bango.com Tue, 26 Jul 2005 08:04:58 -0400 From: Ray Anderson Date: Tue, 26 Jul 2005 08:04:58 -0400 To: "Peter Williams" Message-ID: <6.1.2.0.2.20050725140216.03302620@smtp.bango.net> MIME-Version: 1.0 Content-Type: text/plain Status: R And two more examples where piggy-backing is used extensively: (1) You send a text message, containing a pass-code to a user, and piggyback on the fact that a Mobile Operator only shows it only to that subscriber (2) Mobile network operators do a 1p transaction on a credit card and use it to validate that an over 18 year old person has therefore authorised that phone to be used to see "adult only" content. In a nutshell, we want to only issue a Bango Number (a number from our proprietary database) to somebody who "owns" the equivalent phone number.  We can't use text or voice messages, because the number might not support either.  So, we plan to piggy-back on ENUM - relying on teh fact that if somebody can "fiddle" with teh ENUM DNS records, they have a lot of power over that number, so we give them teh Bango Number. At 18:30 23/07/2005, Peter Williams wrote: It will be intresting to see if this "third party reliance" (aka piggybacking) security practice is ever authorized, in reality. The last 3 INTERNET infrastructures I worked in all denied this obvious practice. Once the infastructure player operates a branded (audited) process, the company will generally want any other companies who benefit from it to be paying for those reliance benefits....and come under the terms and conditions rules, etc. If we look at other examples of switched online identity databases wth federated trust models and multi-provider interconnect practices: (a) VISA will NOT let you use its accurate numbering, subscriber identification, privilege assignment, and switched trust system (VisaNet) as a way of verifying personal identity. That is, you cannot take a 1c visa purchase from a cardholder peter williams, and then claim you verified me as peter williams, with a 100k credit worthiness. (b) VeriSign will NOT let you rely on a SSL merchant cert, and then issue you own cert to that website operator - claiming "well VeriSign issued a cert, having done due dligence concerning the right-to-use rules (ENUM query on a E.164 registry, DNS registration, usb.org registration, IANA/DARPA MIB schema organizations...), and therefore "i have verified that "peter.com is clearly peter.com" when listing said "verified" name in my own _reissued_ (i.e. non-VeriSign) cert. (c) On the other hand, a variety of the practice is EXACTLY what many value added PSP providers do (in unauthorized fashion, generally) -  relying on the  email, paging company, or ISP provider's account management controls to boot up their own, independent trust model. We all respond to a email ping, and authenticate thereby to a new web site account. That is the website app relies on a third parties account accuracy representations when verifyng a new consumer's identity (i.e. those of the email service provider) when superimposing its own account susbcription/provisioning/publication processes. So, if I claim to own +441223472778 I might be asked to change the email address in the ENUM record to banana at bango.com   If I can do that, it is assumed I am "all powerful" with respect to that number.  The whole ENUM project should be causing E.164 owners to put into place varying levels of verification systems that we can piggyback on top of. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum Ray Anderson   CEO Bango   ray at bango.com    www.bango.com Mobile: +44 7768 454545  Fax: +44 20 7692 5558  Come and see Bango at Mobile Entertainment Summit 2005,  Hilton Universal City, Los Angeles, USA   27-28 July www.ihollywoodforum.com   _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Jason_Livingood@cable.comcast.com Tue, 26 Jul 2005 09:00:26 -0400 From: "Livingood, Jason" Date: Tue, 26 Jul 2005 09:00:26 -0400 To: "Ray Anderson" Subject: RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73FF0166@PACDCEXCMB01.cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Understood and acknowledged. I will figure out an appropriate way to note this in a subsequent draft of this I-D. Jason > -----Original Message----- > From: Ray Anderson [mailto:ray at bango.net] > Sent: Tuesday, July 26, 2005 4:22 AM > To: Michael Hammer (mhammer); Livingood, Jason; Richard Shockey > Cc: enum at ietf.org; Stastny Richard > Subject: RE: [Enum] Fwd: I-D > ACTION:draft-livingood-shockey-enum-npd-00.txt > > At 01:22 26/07/2005, Michael Hammer \(mhammer\) wrote: > >Agree completely. I think I hinted at the idea that the > E.164 number > >could terminate in either the IP domain or TDM domain and still be > >included in ENUM. > > Just for clarity, there will be ENUM's (E.164 numbers) that > DO NOT terminate in either IP or TDM domains. They are used > purely for "non-voice" purposes, and allocated by an E.164 > "delegator" for such purposes. > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Tue, 26 Jul 2005 10:13:52 -0400 From: "Michael Hammer \(mhammer\)" Date: Tue, 26 Jul 2005 10:13:52 -0400 To: "Ray Anderson" Subject: RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Message-ID: <072C5B76F7CEAB488172C6F64B30B5E366872D@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Ray, Although voice is a first killer app, it is not the last, so I understand the "non-voice" part of your comment. Could you elaborate on the "non-IP" part? Mike > -----Original Message----- > From: Ray Anderson [mailto:ray at bango.net] > Sent: Tuesday, July 26, 2005 4:22 AM > To: Michael Hammer (mhammer); Livingood, Jason; Richard Shockey > Cc: enum at ietf.org; Stastny Richard > Subject: RE: [Enum] Fwd: I-D > ACTION:draft-livingood-shockey-enum-npd-00.txt > > At 01:22 26/07/2005, Michael Hammer \(mhammer\) wrote: > >Agree completely. I think I hinted at the idea that the > E.164 number > >could terminate in either the IP domain or TDM domain and still be > >included in ENUM. > > Just for clarity, there will be ENUM's (E.164 numbers) that > DO NOT terminate in either IP or TDM domains. They are used > purely for "non-voice" purposes, and allocated by an E.164 > "delegator" for such purposes. > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Tue, 26 Jul 2005 10:52:46 -0400 From: "Michael Hammer \(mhammer\)" Date: Tue, 26 Jul 2005 10:52:46 -0400 To: "Clive D.W. Feather" Subject: RE: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris) Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3668758@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Clive, You have made some assumptions about what my mother's contract says and about what business relationship I might have with the terminating telco my mother uses. Let's say for arguments sake, that I do have a business relationship with them, or that my mother's contract says that they will terminate calls from the wild wild Internet. Let's say that the terminating carrier has a nice IVR system that will take credit or debit card input to complete the call. Could they not sell calling cards at the local convenience store to recent immigrants with no credit history, that can use them on an IP pay-phone connected only to the local ISP to provide Internet access? Do you still feel it necessary to prohibit a carrier from including public interconnect points in Carrier ENUM and allowing public access to Carrier ENUM? I don't think it right to shut down possibilities, just because it doesn't match a particular business model you have in mind. So, please keep the call control and business aspects orthogonal to the ENUM capabilities. Mike > -----Original Message----- > From: Clive D.W. Feather [mailto:clive at demon.net] > Sent: Tuesday, July 26, 2005 5:15 AM > To: Michael Hammer (mhammer) > Cc: Michael Haberler; enum at ietf.org > Subject: Re: Carrier ENUM Definition (was RE: [Enum] Agenda > items forIETF Paris) > > Michael Hammer (mhammer) said: > >> did you contract a telco to route that number in the PSTN once you > >> got it, or not? > > > > This number could have been set aside as a VoIP number, > thus the PSTN > > would route a call to a PSTN gateway that should look it up in User > > ENUM and could route over the Internet to me. Of course > there is no > > regulation requiring them to do so. But, if they didn't you would > > find such numbers useless, begging the question of why a national > > public resource is wasted. The caller has contracted with > the carrier > > to deliver the call, so why should the carrier not attempt > to deliver it? > > Because they have no path to do so. > > For many years, my telco wouldn't deliver calls to various > country codes because they didn't have interconnection agreements. > > In the UK, Directory Enquiries is a competitive service using > the (non-E.164) number range 118000 to 118999. My carrier, > however, will only connect me to exactly two of those > numbers; they haven't bothered to set up an interconnection > agreement with the operators of the other 998. > > In both cases, "contracted with" is JUST PLAIN WRONG - the > contract excludes numbers not reachable for such reasons. > > [Most UK numbers are reachable from one another because BT > has a regulatory obligation to provide both interconnect and > transit to all comers. However, some combinations don't work > because the originating carrier isn't willing to charge a > high enough call cost to cover the transit and termination > fees involved.] > > > You've turned the problem around. Please stick with the > given scenario. > > My mother, party B, ie the called party IS a carrier > customer. And I > > as the caller am both User ENUM and Carrier ENUM aware. > > Do you have a call termination agreement with either your > mother's telco, or with a telco who does and who is willing > to provide transit? If not, then it's *YOUR* fault, not anyone else's. > > > So, why wouldn't > > the carrier deliver the service to my mother that she is paying for? > > She may need to re-read her contract. > > >> No, your recourse is to contract a telco to route that > number in the > >> PSTN, > > But, I don't want to route the call through the PSTN at > all, I want to > > route the call through the Internet to the carrier VoIP network > > serving > > (supposedly) my mother! > > That carrier network has costs. How are you proposing they be > paid, and by whom? > > -- > 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Paul.Rosbotham@cwmsg.cwplc.com Tue, 26 Jul 2005 11:18:58 -0400 From: "Rosbotham, Paul" Date: Tue, 26 Jul 2005 11:18:58 -0400 To: "Michael Hammer \(mhammer\)" Subject: RE: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETFParis) Message-ID: <9322B78036E1534A99B0BC51DEB0F9D601725639@GBCWSWIEM002.ad.plc.cwintra.com> MIME-Version: 1.0 Content-Type: text/plain Status: R >You have made some assumptions about what my mother's contract says and >about what business relationship I might have with the terminating telco >my mother uses. Let's say for arguments sake, that I do have a business >relationship with them, or that my mother's contract says that they will >terminate calls from the wild wild Internet. Let's say that the >terminating carrier has a nice IVR system that will take credit or debit >card input to complete the call. Could they not sell calling cards at >the local convenience store to recent immigrants with no credit history, >that can use them on an IP pay-phone connected only to the local ISP to >provide Internet access? In the UK, several carriers are considering such an approach, but such functionality would reside in *user* ENUM, not carrier. If that proposal does go ahead - and it's still in the early stages of debate at present - the concept would be that if the user hadn't made a user-ENUM entry, then the carrier (of record) could put an entry in advertising the gateway to terminate the call onto their network. Of course, if the user wished to put an entry into user-ENUM, this would over-ride the carrier entry which would be removed. >Do you still feel it necessary to prohibit a carrier from including >public interconnect points in Carrier ENUM and allowing public access to >Carrier ENUM? Carrier-ENUM, at least as I envisage it, is about advertising NNIs for the usage of carriers. It's not about advertising UNIs for customers to break-in from the internet. Given the scope of carrier-ENUM hasn't yet been buttoned down, others may have differing views. >I don't think it right to shut down possibilities, just because it >doesn't match a particular business model you have in mind. So, please >keep the call control and business aspects orthogonal to the ENUM >capabilities. I wouldn't like to be perceived as arbitarily trying to close options down, but as a stake in the ground, if anyone that I don't have a contractual relationship with tries to route a call to an NNI into my network, the call will be failed. No termination fee, no call routed. Regards Paul -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of Michael Hammer (mhammer) Sent: Tuesday, July 26, 2005 3:52 PM To: Clive D.W. Feather Cc: enum at ietf.org Subject: RE: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETFParis) Clive, You have made some assumptions about what my mother's contract says and about what business relationship I might have with the terminating telco my mother uses. Let's say for arguments sake, that I do have a business relationship with them, or that my mother's contract says that they will terminate calls from the wild wild Internet. Let's say that the terminating carrier has a nice IVR system that will take credit or debit card input to complete the call. Could they not sell calling cards at the local convenience store to recent immigrants with no credit history, that can use them on an IP pay-phone connected only to the local ISP to provide Internet access? Do you still feel it necessary to prohibit a carrier from including public interconnect points in Carrier ENUM and allowing public access to Carrier ENUM? I don't think it right to shut down possibilities, just because it doesn't match a particular business model you have in mind. So, please keep the call control and business aspects orthogonal to the ENUM capabilities. Mike This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lendl@nic.at Tue, 26 Jul 2005 11:46:22 -0400 From: Otmar Lendl Date: Tue, 26 Jul 2005 11:46:22 -0400 To: enum at ietf.org Subject: Re: Question: [Enum] I-D ACTION:draft-ietf-enum-iris-ereg-01.txt In-Reply-To: Message-ID: <20050726154610.GB662@nic.at> MIME-Version: 1.0 Content-Type: text/plain Status: R Andrew, On 2005/07/22 19:07, Andrew Newton wrote: > On Jul 21, 2005, at 9:06 AM, Otmar Lendl wrote: > >* Terminology. You use "ENUM" as a shortcut for what is usually > > called "ENUM domain". For me, the single word "ENUM" stands for the > > overall standard (as defined in RFC3761). > > > > Perhaps this shortening is inevitable (just as "static IP address" is > > often shortened to just "static IP"), but I'm uncomfortable to > > legitimize such language via official documents. > > This is covered in section 2. However, I have no trouble changing > the terminology throughout the document, especially if you think it > provides better clarity and readability. I saw the explanation, but I'm not sure if the working group as a whole feed comfortable with that terminology. We prefer to write "ENUM domain". enum query /response > >* Domain vs. Number > > The reason for the current model is, as you stated, the 1:1 mapping > between domain and numbers. Splitting the two out may add extra > complexity, but your rationale has merit. So I guess the big question > here is "Do we think this will be used beyond ENUM?" If so, then I > think this change is in order. Looking at the other threads on this list shows that Carrier ENUM does indeed have the potential to carry NP information. Once this information is not only published via ENUM but also via SS7 IN dips it makes more sense to use the number as the main object and not the ENUM domain. Another question is whether this IRIS scheme could be useful for current E.164 related databases like * white pages * line information databases * the current NP database * telco internal provisioning systems One question to consider here as well is how this affects the dynamic server discovery according to RFC3958. > >* Domain status: > > > > How would you map the cases "domain marked for deletion" and > > "deleted and in grace period" to your choices? > > > > Does "assignedAndOnHold" mean that the delegation is active or not? > > Confusing, isn't it? This uses the 3982 status values, but perhaps > it should be refined (in both places). The status values of > and should be independent so they can be combined > in the necessary ways. > > I've known about this problem, and I don't know why I didn't fix it. We (the Austria ENUM registry) use independent flags. We have one for the DNS visibility. One for "locked". One for "delete pending". > >* Contact schema: > > > > Your contact schema seems to be rather close to the dreg contact > > from RFC 3982. What is the rationale to duplicate the definition > > vs. including the dreg schema? > > > [side comment: the +43 live ENUM registry uses a different contact > > schema to be compatible with the Austrian phonebook.] > > If you provide the details, I can change the schema to be compatible > if you would like. Again, this is the reason why it is separate from > DREG. The main difference is that we split up the address and the name field into its components. We separate commonName into firstname/lastname/title address into streetname/streetnumber/appartment [This is needed for E.115 compatibility.] We have the added field "commercialregisternumber", you have "sip". On our side, "type" is handled differently XML-wise but allows for the same "person", "organization" and "role" classification. As mentioned before, our main focus was compatibility with the Austrian phonebook and not existing Internet whois-style databases. I'll attach our XML schema file. The contact object in DREG is certainly inspired by what's currently in use in gTLD and ccTLD registries. For ENUM, I recommend you also take a closer look to what you local white pages databases use, because those will be used for validation purposes. After all, if some day the ENUM registry is also used as the generic number allocation database, it will have to be compatible to a) old carrier provisioning systems and b) the national white pages data format. Have you checked what kind of fields they use in the US? > >* Your ValidationResult is very close to the Validation Token I > > describe in draft-lendl-enum-validation-token-00. > > > > It contains the same basic fields and just omits the digital > > signature and the optional owner date. > > I did not include the digital signature because I was uncertain of > its application and thought it was only relevant in authentication > during provisioning. But I could be convinced otherwise. You're right that the main point of the signature is during the provisioning process. For the purposes of auditing the whole validation scheme we consider it helpful that those signatures can be retrieved and checked ex post. We don't do IRIS right now. In our case the token can be retrieved from the registry with the EPP info command. > What is the owner date? Is that the created date? That should have been 'data'. Sorry. Our Token can contain a copy of a "contact" object or some other data related to the validation procedure. The idea here is that the validator checked the identity of the owner of the number and includes those results in the token such that the digital signature covers that information as well. (That can be name/address in the form of a contact structure, but may as well be an IMSI in a GSM/3GPP context.) We expect that some innovative solution will emerge in terms of number assignement. e.g. other forms of chip-cards (similar to those used in access-control applications), perhaps credit cards, biometric information, ... This "tokendata" XML element gives us the flexibility to add support for such methods without changing the main XML schema of our registry interface. Thus the registry only touches the data within the main Token structure (containing the same fields as your ValidationEvent) and treats the signature (after checking) and the rest of the Token as opaque XML document. Conceptually the contact infomation in the token is different from the domain owner object which the registrar sends to the registry. The former is written by the validator and specifies the ownership of a number whereas the later comes from the registrar and can be used for directories like the phonebook. For typical User ENUM and existing E.164 numbers, no registrar-defined owner contact is needed. For ENUM-only number ranges like +43 780 the contact information in the Token acts as the definite source of information on who owns the number. That e.g. does not need to be a full name/address set, an email address is sufficient for us. /ol -- < Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer > Extensible Provisioning Protocol v1.0 enum.at contact provisioning schema. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From KMcCandless@verisign.com Tue, 26 Jul 2005 11:53:28 -0400 From: "McCandless, Kevin" Date: Tue, 26 Jul 2005 11:53:28 -0400 To: "Michael Hammer \(mhammer\)" Subject: RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R The NPD is authoritative and therefore the source for routing on ported numbers. This information can be replicated in the IP space but needs to be synchronized to the one in the TDM side ie the NPAC. -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Michael Hammer (mhammer) Sent: Monday, July 25, 2005 7:22 PM To: Livingood, Jason; Richard Shockey Cc: enum at ietf.org; Stastny Richard Subject: RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Agree completely. I think I hinted at the idea that the E.164 number could terminate in either the IP domain or TDM domain and still be included in ENUM. My concern about tying too tightly to NP was when I heard suggestion in other fora that ENUM add things like CLLI codes and other TDM elements, as well as anchoring ENUM to NP administrative processes. I may have misunderstood what was proposed, but it seemed headed in the wrong direction. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Livingood, Jason > Sent: Monday, July 25, 2005 3:50 PM > To: Michael Hammer (mhammer); Richard Shockey > Cc: enum at ietf.org; Stastny Richard > Subject: RE: [Enum] Fwd: I-D > ACTION:draft-livingood-shockey-enum-npd-00.txt > > Replies inline below. > > > I suspect that some 20 years in the future we will have something > > called the PSTN, but it will not look anything like the TDM > network. > > My only goal here is to not assume that the number portability > > databases and processes will automatically become the ENUM > databases > > and processes. > > As a result, I start with the assumption that number portability is > > purely a TDM mechanism that affect routing in the TDM domain. But, > > then acknowledge that certain information may bleed over > and be acted > > on in the IP domain. > > This is probably a fair assumption to make. However, simply > because the endpoints may not be IP-based, does not mean that > the data/addressing cannot be queried for over IP or that > such data can be distributed via IP networks. > > The motivation on my part grew out of a desire to consolidate > both on-net and off-net TN lookups into a single DNS query > that hits my ENUM server. Some vendors are (creatively) > starting to propose methods of doing so (to carriers at > least) that are vendor-specific (aka proprietary). As a > service provider, I have an interest in trying to standardize > this so that I have more potential software providers to > choose from, more competition, innovation, etc. I then have > a open standards-based method for querying for any addressing > info associated with both on-net and off-net TNs > (not-IP-based, or not IP-based that I can route to), as well > as distributing such data around my IP network, etc. since it > all uses DNS and ENUM. > > > But, there have been others that have suggested that > somehow the ENUM > > registration change needs to be dependent on the number portability > > change, and I don't think that is necessary. If ENUM can > do it in one > > day, while NP takes several weeks, no sense in anchoring ENUM down. > > This should not in any way slow down or conflict with various > national NP processes. > > Jason Livingood > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lendl@nic.at Tue, 26 Jul 2005 11:59:31 -0400 From: Otmar Lendl Date: Tue, 26 Jul 2005 11:59:31 -0400 To: enum at ietf.org Subject: Re: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris) In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3668758@xmb-rtp-20b.amer.cisco.com> Message-ID: <20050726155923.GC662@nic.at> MIME-Version: 1.0 Content-Type: text/plain Status: R On 2005/07/26 16:07, "Michael Hammer (mhammer)" wrote: > > Do you still feel it necessary to prohibit a carrier from including > public interconnect points in Carrier ENUM and allowing public access to > Carrier ENUM? > I wouldn't prohibit carriers from having public interconnect points and listing them in Carrier ENUM. I can't recall anybody here advocating such a prohibition. But I wouldn't require them to do so, either. The current assumptions in User ENUM basically mandate this which is one reason why carriers don't adopt ENUM. (The other one is the end-user opt-in requirement.) /ol -- < Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Tue, 26 Jul 2005 12:16:43 -0400 From: "Michael Hammer \(mhammer\)" Date: Tue, 26 Jul 2005 12:16:43 -0400 To: "Otmar Lendl" Subject: RE: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETFParis) Message-ID: <072C5B76F7CEAB488172C6F64B30B5E36687B3@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Agreed. I'm not advocating a requirement to do so. Just trying to keep options open until this is better understood by all. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Otmar Lendl > Sent: Tuesday, July 26, 2005 11:59 AM > To: enum at ietf.org > Subject: Re: Carrier ENUM Definition (was RE: [Enum] Agenda > items forIETFParis) > > On 2005/07/26 16:07, "Michael Hammer (mhammer)" > wrote: > > > > Do you still feel it necessary to prohibit a carrier from including > > public interconnect points in Carrier ENUM and allowing > public access > > to Carrier ENUM? > > > > I wouldn't prohibit carriers from having public interconnect > points and listing them in Carrier ENUM. I can't recall > anybody here advocating such a prohibition. > > But I wouldn't require them to do so, either. The current > assumptions in User ENUM basically mandate this which is one > reason why carriers don't adopt ENUM. (The other one is the > end-user opt-in requirement.) > > /ol > -- > < Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Tue, 26 Jul 2005 12:23:14 -0400 From: "Stastny Richard" Date: Tue, 26 Jul 2005 12:23:14 -0400 To: "Ray Anderson" Subject: Re: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C05C@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Ray wrote: >Just for clarity, there will be ENUM's (E.164 numbers) that DO NOT >terminate in either IP or TDM domains. They are used purely for >"non-voice" purposes, and allocated by an E.164 "delegator" for >such purposes. Just for my personal enlightment, could you please give me some examples of these numbers and also expalin what a "delegator" is? -richard ________________________________ Von: Ray Anderson [mailto:ray at bango.net] Gesendet: Di 26.07.2005 10:21 An: Michael Hammer (mhammer); Livingood, Jason; Richard Shockey Cc: enum at ietf.org; Stastny Richard Betreff: RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt At 01:22 26/07/2005, Michael Hammer \(mhammer\) wrote: >Agree completely. I think I hinted at the idea that the E.164 number >could terminate in either the IP domain or TDM domain and still be >included in ENUM. Just for clarity, there will be ENUM's (E.164 numbers) that DO NOT terminate in either IP or TDM domains. They are used purely for "non-voice" purposes, and allocated by an E.164 "delegator" for such purposes. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Tue, 26 Jul 2005 12:56:17 -0400 From: "Stastny Richard" Date: Tue, 26 Jul 2005 12:56:17 -0400 To: "James McEachern" Subject: Re: [Enum] E.164 communication assumptions/requirements Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C05D@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R James, let me first start with a practical example: Assume I have an Intertex IX67 at home (or a Snom phone) which is capable of querying User ENUM on his own. I enter now a E.164 number and I want to make a voice call. The IX67 find a sip URI in ENUM and the call is set up. Done If the IX67 does not find an entry; it forward the call to a Carrier I have a contract with and this carrier is now querying Carrier ENUM If it find an entry. done. if not the call is routed to the PSTN In both cases I may or may not be charged by the carrier. Now assume I do not have a IX67, I just have a Sipura TA and a normal phone. In this case the call is directly handled by the carrier. The cariier is only quierying Carrier ENUM by default. I may now have a contract with the carrier that the carrier is querying User ENUM FIRST on my behalf. He may charge me $5 a month for this service, but he does not charge me for the call. The rest is as above. rest inline: >>The end-user queries User ENUM, the Carrier queries Carrier ENUM. >>A Carrier MAY query User ENUM on behalf of the user in addition, if the >>user wants so (opt-in) and the carrier is providing this service. >If the Carrier queries Carrier ENUM (and retrieves the POI for that number), >and then also queries User ENUM (and receives the URI for the users mobile phone), >what should the Carrier do (and why)? The feasable agreement would be as described above that always User ENUM is queried first, In this case the Carrier ENUM entry would never be seen >If the User ENUM query returns a phone number in another country, what should the carrier do? This is a good point and it is not completely solved in User ENUM. Since User ENUM is also calling user opt-in, it is basically the decision of the calling user if a PSTN number is accessed at all Remember: if you dial a E.164 number and the number is not contained in ENUM, you need to have a carrier avaiable to provide you a GW to the PSTN to complete the call and you will be charged anyway. The problem is as you point out: you may dial a national number and the User ENUM query returns an international number: Do you forward this number now also to the carrier or not. The basic question here is the (undefined) user interface: do you get a warning that the call may be more expensive? In the above case you mention IMHO there has to be a prior agreement between user and carrier how the procedure should be in such cases. BTW: we had this problem in implementing the generic gateways for calls to ENUM-only numbers from the PSTN. Since the call on the PSTN is only charged to the gateway, there is no way to recover the additional charges from the calling party if an ENUM entry contains a tel URI to a PSTN number. The solution was that this calls are not completed with announcement: service not provided. It is strongle recommended to users of ENUM-only numbers to provide a sip URI in any case. >And finally, if the User ENUM query returns a link to a web page, what should the Carrier do? Nothing. the user requested a voice call, so he may either look up carrier ENUM or if this also does not work: "Service not available.", same if you see an ifax:mailto Have you ever had a meaningful conversation with a fax machine on the PSTN? ;-) Jim _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ray@bango.net Tue, 26 Jul 2005 13:43:01 -0400 From: Ray Anderson Date: Tue, 26 Jul 2005 13:43:01 -0400 To: "Michael Hammer \(mhammer\)" Subject: RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E366872D@xmb-rtp-20b.amer.cisco.com> Message-ID: <6.1.2.0.2.20050726153844.0b4f6a20@smtp.bango.net> MIME-Version: 1.0 Content-Type: text/plain Status: R An example might be Mobile TV. A Broadcaster might make a number point to a URL that in turn contains information that causes the terminal to connect to a video-stream which might be coming over DVB or DAB. Would that be a suitable example? At 15:13 26/07/2005, Michael Hammer \(mhammer\) wrote: Ray, Although voice is a first killer app, it is not the last, so I understand the "non-voice" part of your comment. Could you elaborate on the "non-IP" part? Mike > > Just for clarity, there will be ENUM's (E.164 numbers) that > DO NOT terminate in either IP or TDM domains. They are used > purely for "non-voice" purposes, and allocated by an E.164 > "delegator" for such purposes. > Ray Anderson T:+44 7768 454545 F:+44 20 7692 5558 ray at bango.com _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Tue, 26 Jul 2005 14:37:52 -0400 From: "Michael Hammer \(mhammer\)" Date: Tue, 26 Jul 2005 14:37:52 -0400 To: "Ray Anderson" Subject: RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3668855@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R That gives me an idea of what you meant. But, note that these do involve interaction channels that do involve the PSTN and GSM networks, and may be adapted to ride over IP networks. Mike > -----Original Message----- > From: Ray Anderson [mailto:ray at bango.net] > Sent: Tuesday, July 26, 2005 12:59 PM > To: Michael Hammer (mhammer); Ray Anderson; Livingood, Jason; > Richard Shockey > Cc: enum at ietf.org; Stastny Richard > Subject: RE: [Enum] Fwd: I-D > ACTION:draft-livingood-shockey-enum-npd-00.txt > > > An example might be Mobile TV. A Broadcaster might make a > number point to a URL that in turn contains information that > causes the terminal to connect to a video-stream > which might be coming over DVB or DAB. Would that be a > suitable example? > > At 15:13 26/07/2005, Michael Hammer \(mhammer\) wrote: > >Ray, > > > >Although voice is a first killer app, it is not the last, so I > >understand the "non-voice" part of your comment. Could you > elaborate > >on the "non-IP" part? > > > >Mike > > > > > > > > Just for clarity, there will be ENUM's (E.164 numbers) > that DO NOT > > > terminate in either IP or TDM domains. They are used purely for > > > "non-voice" purposes, and allocated by an E.164 > "delegator" for such > > > purposes. > > > > > > Ray Anderson T:+44 7768 454545 F:+44 20 7692 5558 > ray at bango.com > > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Rich.Shockey@neustar.biz Tue, 26 Jul 2005 14:40:52 -0400 From: Richard Shockey Date: Tue, 26 Jul 2005 14:40:52 -0400 To: Ray Anderson Subject: Re: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E366872D@xmb-rtp-20b.amer.cisco.com> Message-ID: <42E68362.505@neustar.biz> MIME-Version: 1.0 Content-Type: text/plain Status: R Ray Anderson wrote: An example might be Mobile TV. A Broadcaster might make a number point to a URL that in turn contains information that causes the terminal to connect to a video-stream which might be coming over DVB or DAB. Would that be a suitable example? In fact it is and it reminded me that the wireless carriers in the US have a thing called Common Short Codes that are dialable only from mobile operators phones for things like voting for American Idol etc. These 5 digit codes are not E.164 but are "dialable" from any wireless handset. The "delegator" in this case is the US wireless industry association ..CTIA. At 15:13 26/07/2005, Michael Hammer \(mhammer\) wrote: Ray, Although voice is a first killer app, it is not the last, so I understand the "non-voice" part of your comment. Could you elaborate on the "non-IP" part? Mike > > Just for clarity, there will be ENUM's (E.164 numbers) that > DO NOT terminate in either IP or TDM domains. They are used > purely for "non-voice" purposes, and allocated by an E.164 > "delegator" for such purposes. > Ray Anderson T:+44 7768 454545 F:+44 20 7692 5558 ray at bango.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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Tue, 26 Jul 2005 14:58:20 -0400 From: "Michael Hammer \(mhammer\)" Date: Tue, 26 Jul 2005 14:58:20 -0400 To: "McCandless, Kevin" Subject: RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3668866@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Kevin, "needs to be synchronized" Could you elaborate on what this requirement means? For example. Let's say I contract with a VoIP provider to port my number to them as my service provider. Let's say also for argument's sake that I have a WiFi-based phone as well as the old analog phone connected to the PTT. Can the VoIP provider register my number into Carrier ENUM immediately and have calls from other VoIP callers directed to my WiFi phone immediately, along with all its features, without waiting on the PSTN bureaucracy to provision the number as ported in the TDM network? (Note I recognize that TDM callers will be delayed and calls may still route to my old phone.) I suspect I won't like the answer, but it might make glaringly obvious how much room for improvement there may be to this porting process. Wonder if we can get it down to less than one day (Web time). Mike > -----Original Message----- > From: McCandless, Kevin [mailto:KMcCandless at verisign.com] > Sent: Tuesday, July 26, 2005 11:53 AM > To: Michael Hammer (mhammer); Livingood, Jason; Richard Shockey > Cc: enum at ietf.org; Stastny Richard > Subject: RE: [Enum] Fwd: I-D > ACTION:draft-livingood-shockey-enum-npd-00.txt > > The NPD is authoritative and therefore the source for routing > on ported numbers. This information can be replicated in the > IP space but needs to be synchronized to the one in the TDM > side ie the NPAC. > > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Michael Hammer (mhammer) > Sent: Monday, July 25, 2005 7:22 PM > To: Livingood, Jason; Richard Shockey > Cc: enum at ietf.org; Stastny Richard > Subject: RE: [Enum] Fwd: I-D > ACTION:draft-livingood-shockey-enum-npd-00.txt > > Agree completely. I think I hinted at the idea that the > E.164 number could terminate in either the IP domain or TDM > domain and still be included in ENUM. > > My concern about tying too tightly to NP was when I heard > suggestion in other fora that ENUM add things like CLLI codes > and other TDM elements, as well as anchoring ENUM to NP > administrative processes. I may have misunderstood what was > proposed, but it seemed headed in the wrong direction. > > Mike > > > > -----Original Message----- > > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] > On Behalf > > Of Livingood, Jason > > Sent: Monday, July 25, 2005 3:50 PM > > To: Michael Hammer (mhammer); Richard Shockey > > Cc: enum at ietf.org; Stastny Richard > > Subject: RE: [Enum] Fwd: I-D > > ACTION:draft-livingood-shockey-enum-npd-00.txt > > > > Replies inline below. > > > > > I suspect that some 20 years in the future we will have something > > > called the PSTN, but it will not look anything like the TDM > > network. > > > My only goal here is to not assume that the number portability > > > databases and processes will automatically become the ENUM > > databases > > > and processes. > > > As a result, I start with the assumption that number > portability is > > > purely a TDM mechanism that affect routing in the TDM > domain. But, > > > then acknowledge that certain information may bleed over > > and be acted > > > on in the IP domain. > > > > This is probably a fair assumption to make. However, > simply because > > the endpoints may not be IP-based, does not mean that the > > data/addressing cannot be queried for over IP or that such > data can be > > distributed via IP networks. > > > > The motivation on my part grew out of a desire to consolidate both > > on-net and off-net TN lookups into a single DNS query that hits my > > ENUM server. Some vendors are (creatively) starting to propose > > methods of doing so (to carriers at > > least) that are vendor-specific (aka proprietary). As a service > > provider, I have an interest in trying to standardize this > so that I > > have more potential software providers to choose from, more > > competition, innovation, etc. I then have a open standards-based > > method for querying for any addressing info associated with both > > on-net and off-net TNs (not-IP-based, or not IP-based that > I can route > > to), as well as distributing such data around my IP network, etc. > > since it all uses DNS and ENUM. > > > > > But, there have been others that have suggested that > > somehow the ENUM > > > registration change needs to be dependent on the number > portability > > > change, and I don't think that is necessary. If ENUM can > > do it in one > > > day, while NP takes several weeks, no sense in anchoring > ENUM down. > > > > This should not in any way slow down or conflict with > various national > > NP processes. > > > > Jason Livingood > > > > _______________________________________________ > > enum mailing list > > enum at ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From KMcCandless@verisign.com Tue, 26 Jul 2005 16:15:34 -0400 From: "McCandless, Kevin" Date: Tue, 26 Jul 2005 16:15:34 -0400 To: "Michael Hammer \(mhammer\)" Subject: RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Mike comments in line -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer at cisco.com] Sent: Tuesday, July 26, 2005 1:58 PM To: McCandless, Kevin; Livingood, Jason; Richard Shockey Cc: enum at ietf.org; Stastny Richard Subject: RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Kevin, "needs to be synchronized" Could you elaborate on what this requirement means? Yes, if NP records are placed into other databases, ENUM, then those records need to be synchronized, updated, when changes are made in the NPAC associated with the TN. If not, then you will have NP data in ENUM that are no longer valid. The authoritative source is still the NPAC for all ported numbers, (US specific in this discussion). For example. Let's say I contract with a VoIP provider to port my number to them as my service provider. Let's say also for argument's sake that I have a WiFi-based phone as well as the old analog phone connected to the PTT. Can the VoIP provider register my number into Carrier ENUM immediately and have calls from other VoIP callers directed to my WiFi phone immediately, along with all its features, without waiting on the PSTN bureaucracy to provision the number as ported in the TDM network? Yes, but if the call originates from the PSTN then you still have the time frames for processing a ported number. But for on Net to on Net calls you should not have any delay, theoretically ;-) In reality, 99% of VoIP originated calls are dumped onto the PSTN (US again). Ooops I suspect I won't like the answer, but it might make glaringly obvious how much room for improvement there may be to this porting process. Wonder if we can get it down to less than one day (Web time). Mike > -----Original Message----- > From: McCandless, Kevin [mailto:KMcCandless at verisign.com] > Sent: Tuesday, July 26, 2005 11:53 AM > To: Michael Hammer (mhammer); Livingood, Jason; Richard Shockey > Cc: enum at ietf.org; Stastny Richard > Subject: RE: [Enum] Fwd: I-D > ACTION:draft-livingood-shockey-enum-npd-00.txt > > The NPD is authoritative and therefore the source for routing > on ported numbers. This information can be replicated in the > IP space but needs to be synchronized to the one in the TDM > side ie the NPAC. > > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of Michael Hammer (mhammer) > Sent: Monday, July 25, 2005 7:22 PM > To: Livingood, Jason; Richard Shockey > Cc: enum at ietf.org; Stastny Richard > Subject: RE: [Enum] Fwd: I-D > ACTION:draft-livingood-shockey-enum-npd-00.txt > > Agree completely. I think I hinted at the idea that the > E.164 number could terminate in either the IP domain or TDM > domain and still be included in ENUM. > > My concern about tying too tightly to NP was when I heard > suggestion in other fora that ENUM add things like CLLI codes > and other TDM elements, as well as anchoring ENUM to NP > administrative processes. I may have misunderstood what was > proposed, but it seemed headed in the wrong direction. > > Mike > > > > -----Original Message----- > > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] > On Behalf > > Of Livingood, Jason > > Sent: Monday, July 25, 2005 3:50 PM > > To: Michael Hammer (mhammer); Richard Shockey > > Cc: enum at ietf.org; Stastny Richard > > Subject: RE: [Enum] Fwd: I-D > > ACTION:draft-livingood-shockey-enum-npd-00.txt > > > > Replies inline below. > > > > > I suspect that some 20 years in the future we will have something > > > called the PSTN, but it will not look anything like the TDM > > network. > > > My only goal here is to not assume that the number portability > > > databases and processes will automatically become the ENUM > > databases > > > and processes. > > > As a result, I start with the assumption that number > portability is > > > purely a TDM mechanism that affect routing in the TDM > domain. But, > > > then acknowledge that certain information may bleed over > > and be acted > > > on in the IP domain. > > > > This is probably a fair assumption to make. However, > simply because > > the endpoints may not be IP-based, does not mean that the > > data/addressing cannot be queried for over IP or that such > data can be > > distributed via IP networks. > > > > The motivation on my part grew out of a desire to consolidate both > > on-net and off-net TN lookups into a single DNS query that hits my > > ENUM server. Some vendors are (creatively) starting to propose > > methods of doing so (to carriers at > > least) that are vendor-specific (aka proprietary). As a service > > provider, I have an interest in trying to standardize this > so that I > > have more potential software providers to choose from, more > > competition, innovation, etc. I then have a open standards-based > > method for querying for any addressing info associated with both > > on-net and off-net TNs (not-IP-based, or not IP-based that > I can route > > to), as well as distributing such data around my IP network, etc. > > since it all uses DNS and ENUM. > > > > > But, there have been others that have suggested that > > somehow the ENUM > > > registration change needs to be dependent on the number > portability > > > change, and I don't think that is necessary. If ENUM can > > do it in one > > > day, while NP takes several weeks, no sense in anchoring > ENUM down. > > > > This should not in any way slow down or conflict with > various national > > NP processes. > > > > Jason Livingood > > > > _______________________________________________ > > enum mailing list > > enum at ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jmce@nortel.com Tue, 26 Jul 2005 21:27:51 -0400 From: "James McEachern" Date: Tue, 26 Jul 2005 21:27:51 -0400 To: "Stastny Richard" Subject: RE: [Enum] E.164 communication assumptions/requirements Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Richard, Thanks for the clarification - it clears up a couple of questions that have been confusing me for a while now. So if I understand correctly, a carrier should never query User ENUM unless the originating user has explicitly asked the carrier to do the query on his behalf, and has also provided guidance on what to do in various situations (for example if the query returns a phone number in another country, or a "900" number). Jim > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] > Sent: Tuesday, July 26, 2005 1:00 PM > To: McEachern, James [CAR:5N00:EXCH] > Cc: enum at ietf.org > Subject: Re: [Enum] E.164 communication assumptions/requirements > > James, > > let me first start with a practical example: > Assume I have an Intertex IX67 at home (or a Snom phone) > which is capable of querying User ENUM on his own. > > I enter now a E.164 number and I want to make a voice call. > The IX67 find a sip URI in ENUM and the call is set up. Done > > If the IX67 does not find an entry; it forward the call to a Carrier > I have a contract with and this carrier is now querying Carrier ENUM > If it find an entry. done. if not the call is routed to the PSTN > In both cases I may or may not be charged by the carrier. > > Now assume I do not have a IX67, I just have a Sipura TA and > a normal phone. In this case the call is directly handled by the > carrier. The cariier is only quierying Carrier ENUM by default. > > I may now have a contract with the carrier that the carrier is querying > User ENUM FIRST on my behalf. He may charge me $5 a month for > this service, but he does not charge me for the call. The rest is as > above. > > rest inline: > > >>The end-user queries User ENUM, the Carrier queries Carrier ENUM. > >>A Carrier MAY query User ENUM on behalf of the user in addition, if the > >>user wants so (opt-in) and the carrier is providing this service. > > >If the Carrier queries Carrier ENUM (and retrieves the POI for that > number), > >and then also queries User ENUM (and receives the URI for the users > mobile phone), > >what should the Carrier do (and why)? > > The feasable agreement would be as described above that always User ENUM > is queried > first, In this case the Carrier ENUM entry would never be seen > > >If the User ENUM query returns a phone number in another country, what > should the carrier do? > > This is a good point and it is not completely solved in User ENUM. Since > User ENUM is also > calling user opt-in, it is basically the decision of the calling user if > a PSTN number is accessed at all > > Remember: if you dial a E.164 number and the number is not contained in > ENUM, you need > to have a carrier avaiable to provide you a GW to the PSTN to complete > the call and you will > be charged anyway. The problem is as you point out: you may dial a > national number > and the User ENUM query returns an international number: Do you forward > this number > now also to the carrier or not. The basic question here is the (undefined) > user interface: > do you get a warning that the call may be more expensive? > > In the above case you mention IMHO there has to be a prior agreement > between user > and carrier how the procedure should be in such cases. > > BTW: we had this problem in implementing the generic gateways for calls > to ENUM-only > numbers from the PSTN. Since the call on the PSTN is only charged to the > gateway, there > is no way to recover the additional charges from the calling party if an > ENUM entry > contains a tel URI to a PSTN number. The solution was that this calls are > not completed > with announcement: service not provided. It is strongle recommended to > users of > ENUM-only numbers to provide a sip URI in any case. > > >And finally, if the User ENUM query returns a link to a web page, what > should the Carrier do? > > Nothing. the user requested a voice call, so he may either look up > carrier ENUM or if this also > does not work: "Service not available.", same if you see an ifax:mailto > Have you ever had a meaningful conversation with a fax machine on the > PSTN? ;-) > > Jim > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@inode.at Wed, 27 Jul 2005 03:25:15 -0400 From: Michael Haberler Date: Wed, 27 Jul 2005 03:25:15 -0400 To: "McCandless, Kevin" Subject: RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt In-Reply-To: Message-ID: <6.2.1.2.2.20050727071234.052df798@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: R At 17:53 26.07.2005, McCandless, Kevin wrote: The NPD is authoritative and therefore the source for routing on ported numbers. This information can be replicated in the IP space but needs to be synchronized to the one in the TDM side ie the NPAC. If an NPD exists. If - like over here in the fixed network - the NP process uses onward routing and just local information exchange & keeping by donor and recipient carrier, a Carrier ENUM register will eventually become the defacto NPD. -Michael _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ppfautz@att.com Wed, 27 Jul 2005 08:09:37 -0400 From: "Pfautz, Penn L, NEO" Date: Wed, 27 Jul 2005 08:09:37 -0400 To: "James McEachern" Subject: RE: [Enum] E.164 communication assumptions/requirements Message-ID: <34DA635B184A644DA4588E260EC0A25A0ABFA991@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Status: R I would disagree that a carrier can't query user ENUM without explicit consent of the originating caller. But if a carrier uses the results and the results are funky in the ways suggested than I would expect the carrier to eat any added cost *unless* they have some specific terms of agreement with the originator. Realistically, carriers are not stupid (well not entirely :-)) and would distinguish between a SIP URL that would allow them to terminate a call bypassing the circuit switched network and a redirecting tel URL that would be a scam. -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of James McEachern Sent: Tuesday, July 26, 2005 9:27 PM To: Stastny Richard Cc: enum at ietf.org Subject: RE: [Enum] E.164 communication assumptions/requirements Richard, Thanks for the clarification - it clears up a couple of questions that have been confusing me for a while now. So if I understand correctly, a carrier should never query User ENUM unless the originating user has explicitly asked the carrier to do the query on his behalf, and has also provided guidance on what to do in various situations (for example if the query returns a phone number in another country, or a "900" number). Jim > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] > Sent: Tuesday, July 26, 2005 1:00 PM > To: McEachern, James [CAR:5N00:EXCH] > Cc: enum at ietf.org > Subject: Re: [Enum] E.164 communication assumptions/requirements > > James, > > let me first start with a practical example: > Assume I have an Intertex IX67 at home (or a Snom phone) > which is capable of querying User ENUM on his own. > > I enter now a E.164 number and I want to make a voice call. > The IX67 find a sip URI in ENUM and the call is set up. Done > > If the IX67 does not find an entry; it forward the call to a Carrier > I have a contract with and this carrier is now querying Carrier ENUM > If it find an entry. done. if not the call is routed to the PSTN > In both cases I may or may not be charged by the carrier. > > Now assume I do not have a IX67, I just have a Sipura TA and > a normal phone. In this case the call is directly handled by the > carrier. The cariier is only quierying Carrier ENUM by default. > > I may now have a contract with the carrier that the carrier is querying > User ENUM FIRST on my behalf. He may charge me $5 a month for > this service, but he does not charge me for the call. The rest is as > above. > > rest inline: > > >>The end-user queries User ENUM, the Carrier queries Carrier ENUM. > >>A Carrier MAY query User ENUM on behalf of the user in addition, if the > >>user wants so (opt-in) and the carrier is providing this service. > > >If the Carrier queries Carrier ENUM (and retrieves the POI for that > number), > >and then also queries User ENUM (and receives the URI for the users > mobile phone), > >what should the Carrier do (and why)? > > The feasable agreement would be as described above that always User ENUM > is queried > first, In this case the Carrier ENUM entry would never be seen > > >If the User ENUM query returns a phone number in another country, what > should the carrier do? > > This is a good point and it is not completely solved in User ENUM. Since > User ENUM is also > calling user opt-in, it is basically the decision of the calling user if > a PSTN number is accessed at all > > Remember: if you dial a E.164 number and the number is not contained in > ENUM, you need > to have a carrier avaiable to provide you a GW to the PSTN to complete > the call and you will > be charged anyway. The problem is as you point out: you may dial a > national number > and the User ENUM query returns an international number: Do you forward > this number > now also to the carrier or not. The basic question here is the (undefined) > user interface: > do you get a warning that the call may be more expensive? > > In the above case you mention IMHO there has to be a prior agreement > between user > and carrier how the procedure should be in such cases. > > BTW: we had this problem in implementing the generic gateways for calls > to ENUM-only > numbers from the PSTN. Since the call on the PSTN is only charged to the > gateway, there > is no way to recover the additional charges from the calling party if an > ENUM entry > contains a tel URI to a PSTN number. The solution was that this calls are > not completed > with announcement: service not provided. It is strongle recommended to > users of > ENUM-only numbers to provide a sip URI in any case. > > >And finally, if the User ENUM query returns a link to a web page, what > should the Carrier do? > > Nothing. the user requested a voice call, so he may either look up > carrier ENUM or if this also > does not work: "Service not available.", same if you see an ifax:mailto > Have you ever had a meaningful conversation with a fax machine on the > PSTN? ;-) > > Jim > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From KMcCandless@verisign.com Wed, 27 Jul 2005 08:55:29 -0400 From: "McCandless, Kevin" Date: Wed, 27 Jul 2005 08:55:29 -0400 To: "Michael Haberler" Subject: RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R That might work in your neck of the woods but not over here. -----Original Message----- From: Michael Haberler [mailto:mah at inode.at] Sent: Wednesday, July 27, 2005 12:19 AM To: McCandless, Kevin Cc: enum at ietf.org Subject: RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt At 17:53 26.07.2005, McCandless, Kevin wrote: >The NPD is authoritative and therefore the source for routing on ported >numbers. This information can be replicated in the IP space but needs >to be synchronized to the one in the TDM side ie the NPAC. If an NPD exists. If - like over here in the fixed network - the NP process uses onward routing and just local information exchange & keeping by donor and recipient carrier, a Carrier ENUM register will eventually become the defacto NPD. -Michael _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Wed, 27 Jul 2005 15:37:24 -0400 From: "Stastny Richard" Date: Wed, 27 Jul 2005 15:37:24 -0400 To: "chenhui" Subject: Re: [Enum] E.164 communication assumptions/requirements Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C060@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Chenhui wrote: >I have some items need to be confirmed: >1. Users can decide by themselves to register the ENUM information into User ENUM or Carrier ENUM Yes for User ENUM, No for Carrier ENUM - here the Carreir decides >2. User ENUM is separated with Carrier ENUM. Yes >3. There may be same ENUM numbers recorded in User ENUM and Carrier ENUM, but the NAPTR records are different, for example, I have "SIP" record in >User ENUM and "tel" record in Carrier ENUM. Yes -richard >Thanks. >Chenhui _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Wed, 27 Jul 2005 16:16:21 -0400 From: "Stastny Richard" Date: Wed, 27 Jul 2005 16:16:21 -0400 To: "Pfautz, Penn L, NEO" Subject: Re: [Enum] E.164 communication assumptions/requirements Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C062@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Penn, James, >So if I understand correctly, a carrier should never query User ENUM >unless the originating user has explicitly asked the carrier to do the >query on his behalf, and has also provided guidance on what to do in >various situations (for example if the query returns a phone number in >another country, or a "900" number). Yes Penn, please re-read the historic "Final Report on ENUM" of the US ITAC-T SGA Ad-Hoc, Juli 2001, which was the basis of the US ENUM Forum It clearly states (I think in section 3.4) that User ENUM is opt-in BOTH for the CALLING and the called user. So the opt-in (consent) of the subscriber is necessary to query User ENUM Now there IS an interesting issue related to ENUM-only numbers ENUM-only numbers cannot be in carrier ENUM per se because there is no hosting carrier. A carrier could pretend to be stupid and route all calls to the PSTN and charge for them. Now with these numbers there is no obligation for an originating network on the PSTN to a specific gateway, so the originating network may directly route the call to his own gateway. This is the whole idea of such numbers. Therefore a carreir on IP also could be "clever", pretend to be a gateway, query User ENUM, and route the call directly (charging for it or not) This does not require opt-in by the calling user !!! The originating carrier may have a list of all such numbers; or, for convenience, carrier ENUM may contain a hint! This is the proposed "enum:tel" Enumservice. -richard ________________________________ Von: Pfautz, Penn L, NEO [mailto:ppfautz at att.com] Gesendet: Mi 27.07.2005 14:09 An: James McEachern; Stastny Richard Cc: enum at ietf.org Betreff: RE: [Enum] E.164 communication assumptions/requirements I would disagree that a carrier can't query user ENUM without explicit consent of the originating caller. But if a carrier uses the results and the results are funky in the ways suggested than I would expect the carrier to eat any added cost *unless* they have some specific terms of agreement with the originator. Realistically, carriers are not stupid (well not entirely :-)) and would distinguish between a SIP URL that would allow them to terminate a call bypassing the circuit switched network and a redirecting tel URL that would be a scam. -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of James McEachern Sent: Tuesday, July 26, 2005 9:27 PM To: Stastny Richard Cc: enum at ietf.org Subject: RE: [Enum] E.164 communication assumptions/requirements Richard, Thanks for the clarification - it clears up a couple of questions that have been confusing me for a while now. So if I understand correctly, a carrier should never query User ENUM unless the originating user has explicitly asked the carrier to do the query on his behalf, and has also provided guidance on what to do in various situations (for example if the query returns a phone number in another country, or a "900" number). Jim > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] > Sent: Tuesday, July 26, 2005 1:00 PM > To: McEachern, James [CAR:5N00:EXCH] > Cc: enum at ietf.org > Subject: Re: [Enum] E.164 communication assumptions/requirements > > James, > > let me first start with a practical example: > Assume I have an Intertex IX67 at home (or a Snom phone) > which is capable of querying User ENUM on his own. > > I enter now a E.164 number and I want to make a voice call. > The IX67 find a sip URI in ENUM and the call is set up. Done > > If the IX67 does not find an entry; it forward the call to a Carrier > I have a contract with and this carrier is now querying Carrier ENUM > If it find an entry. done. if not the call is routed to the PSTN > In both cases I may or may not be charged by the carrier. > > Now assume I do not have a IX67, I just have a Sipura TA and > a normal phone. In this case the call is directly handled by the > carrier. The cariier is only quierying Carrier ENUM by default. > > I may now have a contract with the carrier that the carrier is querying > User ENUM FIRST on my behalf. He may charge me $5 a month for > this service, but he does not charge me for the call. The rest is as > above. > > rest inline: > > >>The end-user queries User ENUM, the Carrier queries Carrier ENUM. > >>A Carrier MAY query User ENUM on behalf of the user in addition, if the > >>user wants so (opt-in) and the carrier is providing this service. > > >If the Carrier queries Carrier ENUM (and retrieves the POI for that > number), > >and then also queries User ENUM (and receives the URI for the users > mobile phone), > >what should the Carrier do (and why)? > > The feasable agreement would be as described above that always User ENUM > is queried > first, In this case the Carrier ENUM entry would never be seen > > >If the User ENUM query returns a phone number in another country, what > should the carrier do? > > This is a good point and it is not completely solved in User ENUM. Since > User ENUM is also > calling user opt-in, it is basically the decision of the calling user if > a PSTN number is accessed at all > > Remember: if you dial a E.164 number and the number is not contained in > ENUM, you need > to have a carrier avaiable to provide you a GW to the PSTN to complete > the call and you will > be charged anyway. The problem is as you point out: you may dial a > national number > and the User ENUM query returns an international number: Do you forward > this number > now also to the carrier or not. The basic question here is the (undefined) > user interface: > do you get a warning that the call may be more expensive? > > In the above case you mention IMHO there has to be a prior agreement > between user > and carrier how the procedure should be in such cases. > > BTW: we had this problem in implementing the generic gateways for calls > to ENUM-only > numbers from the PSTN. Since the call on the PSTN is only charged to the > gateway, there > is no way to recover the additional charges from the calling party if an > ENUM entry > contains a tel URI to a PSTN number. The solution was that this calls are > not completed > with announcement: service not provided. It is strongle recommended to > users of > ENUM-only numbers to provide a sip URI in any case. > > >And finally, if the User ENUM query returns a link to a web page, what > should the Carrier do? > > Nothing. the user requested a voice call, so he may either look up > carrier ENUM or if this also > does not work: "Service not available.", same if you see an ifax:mailto > Have you ever had a meaningful conversation with a fax machine on the > PSTN? ;-) > > Jim > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ppfautz@att.com Wed, 27 Jul 2005 16:26:30 -0400 From: "Pfautz, Penn L, NEO" Date: Wed, 27 Jul 2005 16:26:30 -0400 To: "Stastny Richard" Subject: RE: [Enum] E.164 communication assumptions/requirements Message-ID: <34DA635B184A644DA4588E260EC0A25A0ABFB2F0@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard: The ITAC report was not as you interpret it. Opt-in for the calling entity means there is no duty to query or to use the result if the query is made. The originator in this clause was NOT restricted to be the end user but could be the calling user's carrier. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] Sent: Wednesday, July 27, 2005 4:20 PM To: Pfautz, Penn L, NEO; James McEachern Cc: enum at ietf.org Subject: Re: [Enum] E.164 communication assumptions/requirements Penn, James, >So if I understand correctly, a carrier should never query User ENUM >unless the originating user has explicitly asked the carrier to do the >query on his behalf, and has also provided guidance on what to do in >various situations (for example if the query returns a phone number in >another country, or a "900" number). Yes Penn, please re-read the historic "Final Report on ENUM" of the US ITAC-T SGA Ad-Hoc, Juli 2001, which was the basis of the US ENUM Forum It clearly states (I think in section 3.4) that User ENUM is opt-in BOTH for the CALLING and the called user. So the opt-in (consent) of the subscriber is necessary to query User ENUM Now there IS an interesting issue related to ENUM-only numbers ENUM-only numbers cannot be in carrier ENUM per se because there is no hosting carrier. A carrier could pretend to be stupid and route all calls to the PSTN and charge for them. Now with these numbers there is no obligation for an originating network on the PSTN to a specific gateway, so the originating network may directly route the call to his own gateway. This is the whole idea of such numbers. Therefore a carreir on IP also could be "clever", pretend to be a gateway, query User ENUM, and route the call directly (charging for it or not) This does not require opt-in by the calling user !!! The originating carrier may have a list of all such numbers; or, for convenience, carrier ENUM may contain a hint! This is the proposed "enum:tel" Enumservice. -richard ________________________________ Von: Pfautz, Penn L, NEO [mailto:ppfautz at att.com] Gesendet: Mi 27.07.2005 14:09 An: James McEachern; Stastny Richard Cc: enum at ietf.org Betreff: RE: [Enum] E.164 communication assumptions/requirements I would disagree that a carrier can't query user ENUM without explicit consent of the originating caller. But if a carrier uses the results and the results are funky in the ways suggested than I would expect the carrier to eat any added cost *unless* they have some specific terms of agreement with the originator. Realistically, carriers are not stupid (well not entirely :-)) and would distinguish between a SIP URL that would allow them to terminate a call bypassing the circuit switched network and a redirecting tel URL that would be a scam. -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of James McEachern Sent: Tuesday, July 26, 2005 9:27 PM To: Stastny Richard Cc: enum at ietf.org Subject: RE: [Enum] E.164 communication assumptions/requirements Richard, Thanks for the clarification - it clears up a couple of questions that have been confusing me for a while now. So if I understand correctly, a carrier should never query User ENUM unless the originating user has explicitly asked the carrier to do the query on his behalf, and has also provided guidance on what to do in various situations (for example if the query returns a phone number in another country, or a "900" number). Jim > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] > Sent: Tuesday, July 26, 2005 1:00 PM > To: McEachern, James [CAR:5N00:EXCH] > Cc: enum at ietf.org > Subject: Re: [Enum] E.164 communication assumptions/requirements > > James, > > let me first start with a practical example: > Assume I have an Intertex IX67 at home (or a Snom phone) > which is capable of querying User ENUM on his own. > > I enter now a E.164 number and I want to make a voice call. > The IX67 find a sip URI in ENUM and the call is set up. Done > > If the IX67 does not find an entry; it forward the call to a Carrier > I have a contract with and this carrier is now querying Carrier ENUM > If it find an entry. done. if not the call is routed to the PSTN > In both cases I may or may not be charged by the carrier. > > Now assume I do not have a IX67, I just have a Sipura TA and > a normal phone. In this case the call is directly handled by the > carrier. The cariier is only quierying Carrier ENUM by default. > > I may now have a contract with the carrier that the carrier is querying > User ENUM FIRST on my behalf. He may charge me $5 a month for > this service, but he does not charge me for the call. The rest is as > above. > > rest inline: > > >>The end-user queries User ENUM, the Carrier queries Carrier ENUM. > >>A Carrier MAY query User ENUM on behalf of the user in addition, if the > >>user wants so (opt-in) and the carrier is providing this service. > > >If the Carrier queries Carrier ENUM (and retrieves the POI for that > number), > >and then also queries User ENUM (and receives the URI for the users > mobile phone), > >what should the Carrier do (and why)? > > The feasable agreement would be as described above that always User ENUM > is queried > first, In this case the Carrier ENUM entry would never be seen > > >If the User ENUM query returns a phone number in another country, what > should the carrier do? > > This is a good point and it is not completely solved in User ENUM. Since > User ENUM is also > calling user opt-in, it is basically the decision of the calling user if > a PSTN number is accessed at all > > Remember: if you dial a E.164 number and the number is not contained in > ENUM, you need > to have a carrier avaiable to provide you a GW to the PSTN to complete > the call and you will > be charged anyway. The problem is as you point out: you may dial a > national number > and the User ENUM query returns an international number: Do you forward > this number > now also to the carrier or not. The basic question here is the (undefined) > user interface: > do you get a warning that the call may be more expensive? > > In the above case you mention IMHO there has to be a prior agreement > between user > and carrier how the procedure should be in such cases. > > BTW: we had this problem in implementing the generic gateways for calls > to ENUM-only > numbers from the PSTN. Since the call on the PSTN is only charged to the > gateway, there > is no way to recover the additional charges from the calling party if an > ENUM entry > contains a tel URI to a PSTN number. The solution was that this calls are > not completed > with announcement: service not provided. It is strongle recommended to > users of > ENUM-only numbers to provide a sip URI in any case. > > >And finally, if the User ENUM query returns a link to a web page, what > should the Carrier do? > > Nothing. the user requested a voice call, so he may either look up > carrier ENUM or if this also > does not work: "Service not available.", same if you see an ifax:mailto > Have you ever had a meaningful conversation with a fax machine on the > PSTN? ;-) > > Jim > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Wed, 27 Jul 2005 16:53:22 -0400 From: "Stastny Richard" Date: Wed, 27 Jul 2005 16:53:22 -0400 To: "Pfautz, Penn L, NEO" Subject: Re: [Enum] E.164 communication assumptions/requirements Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C063@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Penn, if you say so. Nevertheless, do not forget that with ENUM calls may terminate on the PSTN and also on IP (via ENUM) Do you think the carrier may decide without the user consent where to terminate the call? -richard ------------------------------------------------------------------------ Richard: The ITAC report was not as you interpret it. Opt-in for the calling entity means there is no duty to query or to use the result if the query is made. The originator in this clause was NOT restricted to be the end user but could be the calling user's carrier. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny at oefeg.at ] Sent: Wednesday, July 27, 2005 4:20 PM To: Pfautz, Penn L, NEO; James McEachern Cc: enum at ietf.org Subject: Re: [Enum] E.164 communication assumptions/requirements Penn, James, >So if I understand correctly, a carrier should never query User ENUM >unless the originating user has explicitly asked the carrier to do the >query on his behalf, and has also provided guidance on what to do in >various situations (for example if the query returns a phone number in >another country, or a "900" number). Yes Penn, please re-read the historic "Final Report on ENUM" of the US ITAC-T SGA Ad-Hoc, Juli 2001, which was the basis of the US ENUM Forum It clearly states (I think in section 3.4) that User ENUM is opt-in BOTH for the CALLING and the called user. So the opt-in (consent) of the subscriber is necessary to query User ENUM Now there IS an interesting issue related to ENUM-only numbers ENUM-only numbers cannot be in carrier ENUM per se because there is no hosting carrier. A carrier could pretend to be stupid and route all calls to the PSTN and charge for them. Now with these numbers there is no obligation for an originating network on the PSTN to a specific gateway, so the originating network may directly route the call to his own gateway. This is the whole idea of such numbers. Therefore a carreir on IP also could be "clever", pretend to be a gateway, query User ENUM, and route the call directly (charging for it or not) This does not require opt-in by the calling user !!! The originating carrier may have a list of all such numbers; or, for convenience, carrier ENUM may contain a hint! This is the proposed "enum:tel" Enumservice. -richard ________________________________ Von: Pfautz, Penn L, NEO [mailto:ppfautz at att.com ] Gesendet: Mi 27.07.2005 14:09 An: James McEachern; Stastny Richard Cc: enum at ietf.org Betreff: RE: [Enum] E.164 communication assumptions/requirements I would disagree that a carrier can't query user ENUM without explicit consent of the originating caller. But if a carrier uses the results and the results are funky in the ways suggested than I would expect the carrier to eat any added cost *unless* they have some specific terms of agreement with the originator. Realistically, carriers are not stupid (well not entirely :-)) and would distinguish between a SIP URL that would allow them to terminate a call bypassing the circuit switched network and a redirecting tel URL that would be a scam. -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org ] On Behalf Of James McEachern Sent: Tuesday, July 26, 2005 9:27 PM To: Stastny Richard Cc: enum at ietf.org Subject: RE: [Enum] E.164 communication assumptions/requirements Richard, Thanks for the clarification - it clears up a couple of questions that have been confusing me for a while now. So if I understand correctly, a carrier should never query User ENUM unless the originating user has explicitly asked the carrier to do the query on his behalf, and has also provided guidance on what to do in various situations (for example if the query returns a phone number in another country, or a "900" number). Jim > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny at oefeg.at ] > Sent: Tuesday, July 26, 2005 1:00 PM > To: McEachern, James [CAR:5N00:EXCH] > Cc: enum at ietf.org > Subject: Re: [Enum] E.164 communication assumptions/requirements > > James, > > let me first start with a practical example: > Assume I have an Intertex IX67 at home (or a Snom phone) > which is capable of querying User ENUM on his own. > > I enter now a E.164 number and I want to make a voice call. > The IX67 find a sip URI in ENUM and the call is set up. Done > > If the IX67 does not find an entry; it forward the call to a Carrier > I have a contract with and this carrier is now querying Carrier ENUM > If it find an entry. done. if not the call is routed to the PSTN > In both cases I may or may not be charged by the carrier. > > Now assume I do not have a IX67, I just have a Sipura TA and > a normal phone. In this case the call is directly handled by the > carrier. The cariier is only quierying Carrier ENUM by default. > > I may now have a contract with the carrier that the carrier is querying > User ENUM FIRST on my behalf. He may charge me $5 a month for > this service, but he does not charge me for the call. The rest is as > above. > > rest inline: > > >>The end-user queries User ENUM, the Carrier queries Carrier ENUM. > >>A Carrier MAY query User ENUM on behalf of the user in addition, if the > >>user wants so (opt-in) and the carrier is providing this service. > > >If the Carrier queries Carrier ENUM (and retrieves the POI for that > number), > >and then also queries User ENUM (and receives the URI for the users > mobile phone), > >what should the Carrier do (and why)? > > The feasable agreement would be as described above that always User ENUM > is queried > first, In this case the Carrier ENUM entry would never be seen > > >If the User ENUM query returns a phone number in another country, what > should the carrier do? > > This is a good point and it is not completely solved in User ENUM. Since > User ENUM is also > calling user opt-in, it is basically the decision of the calling user if > a PSTN number is accessed at all > > Remember: if you dial a E.164 number and the number is not contained in > ENUM, you need > to have a carrier avaiable to provide you a GW to the PSTN to complete > the call and you will > be charged anyway. The problem is as you point out: you may dial a > national number > and the User ENUM query returns an international number: Do you forward > this number > now also to the carrier or not. The basic question here is the (undefined) > user interface: > do you get a warning that the call may be more expensive? > > In the above case you mention IMHO there has to be a prior agreement > between user > and carrier how the procedure should be in such cases. > > BTW: we had this problem in implementing the generic gateways for calls > to ENUM-only > numbers from the PSTN. Since the call on the PSTN is only charged to the > gateway, there > is no way to recover the additional charges from the calling party if an > ENUM entry > contains a tel URI to a PSTN number. The solution was that this calls are > not completed > with announcement: service not provided. It is strongle recommended to > users of > ENUM-only numbers to provide a sip URI in any case. > > >And finally, if the User ENUM query returns a link to a web page, what > should the Carrier do? > > Nothing. the user requested a voice call, so he may either look up > carrier ENUM or if this also > does not work: "Service not available.", same if you see an ifax:mailto > Have you ever had a meaningful conversation with a fax machine on the > PSTN? ;-) > > Jim > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ppfautz@att.com Wed, 27 Jul 2005 17:36:10 -0400 From: "Pfautz, Penn L, NEO" Date: Wed, 27 Jul 2005 17:36:10 -0400 To: "Stastny Richard" Subject: RE: [Enum] E.164 communication assumptions/requirements Message-ID: <34DA635B184A644DA4588E260EC0A25A0ABFB446@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Richard, I think the carrier can make that decision in the absence of some other restriction. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] Sent: Wednesday, July 27, 2005 4:57 PM To: Pfautz, Penn L, NEO; James McEachern Cc: enum at ietf.org Subject: Re: [Enum] E.164 communication assumptions/requirements Penn, if you say so. Nevertheless, do not forget that with ENUM calls may terminate on the PSTN and also on IP (via ENUM) Do you think the carrier may decide without the user consent where to terminate the call? -richard ------------------------------------------------------------------------ Richard: The ITAC report was not as you interpret it. Opt-in for the calling entity means there is no duty to query or to use the result if the query is made. The originator in this clause was NOT restricted to be the end user but could be the calling user's carrier. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny at oefeg.at ] Sent: Wednesday, July 27, 2005 4:20 PM To: Pfautz, Penn L, NEO; James McEachern Cc: enum at ietf.org Subject: Re: [Enum] E.164 communication assumptions/requirements Penn, James, >So if I understand correctly, a carrier should never query User ENUM >unless the originating user has explicitly asked the carrier to do the >query on his behalf, and has also provided guidance on what to do in >various situations (for example if the query returns a phone number in >another country, or a "900" number). Yes Penn, please re-read the historic "Final Report on ENUM" of the US ITAC-T SGA Ad-Hoc, Juli 2001, which was the basis of the US ENUM Forum It clearly states (I think in section 3.4) that User ENUM is opt-in BOTH for the CALLING and the called user. So the opt-in (consent) of the subscriber is necessary to query User ENUM Now there IS an interesting issue related to ENUM-only numbers ENUM-only numbers cannot be in carrier ENUM per se because there is no hosting carrier. A carrier could pretend to be stupid and route all calls to the PSTN and charge for them. Now with these numbers there is no obligation for an originating network on the PSTN to a specific gateway, so the originating network may directly route the call to his own gateway. This is the whole idea of such numbers. Therefore a carreir on IP also could be "clever", pretend to be a gateway, query User ENUM, and route the call directly (charging for it or not) This does not require opt-in by the calling user !!! The originating carrier may have a list of all such numbers; or, for convenience, carrier ENUM may contain a hint! This is the proposed "enum:tel" Enumservice. -richard ________________________________ Von: Pfautz, Penn L, NEO [mailto:ppfautz at att.com ] Gesendet: Mi 27.07.2005 14:09 An: James McEachern; Stastny Richard Cc: enum at ietf.org Betreff: RE: [Enum] E.164 communication assumptions/requirements I would disagree that a carrier can't query user ENUM without explicit consent of the originating caller. But if a carrier uses the results and the results are funky in the ways suggested than I would expect the carrier to eat any added cost *unless* they have some specific terms of agreement with the originator. Realistically, carriers are not stupid (well not entirely :-)) and would distinguish between a SIP URL that would allow them to terminate a call bypassing the circuit switched network and a redirecting tel URL that would be a scam. -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org ] On Behalf Of James McEachern Sent: Tuesday, July 26, 2005 9:27 PM To: Stastny Richard Cc: enum at ietf.org Subject: RE: [Enum] E.164 communication assumptions/requirements Richard, Thanks for the clarification - it clears up a couple of questions that have been confusing me for a while now. So if I understand correctly, a carrier should never query User ENUM unless the originating user has explicitly asked the carrier to do the query on his behalf, and has also provided guidance on what to do in various situations (for example if the query returns a phone number in another country, or a "900" number). Jim > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny at oefeg.at ] > Sent: Tuesday, July 26, 2005 1:00 PM > To: McEachern, James [CAR:5N00:EXCH] > Cc: enum at ietf.org > Subject: Re: [Enum] E.164 communication assumptions/requirements > > James, > > let me first start with a practical example: > Assume I have an Intertex IX67 at home (or a Snom phone) > which is capable of querying User ENUM on his own. > > I enter now a E.164 number and I want to make a voice call. > The IX67 find a sip URI in ENUM and the call is set up. Done > > If the IX67 does not find an entry; it forward the call to a Carrier > I have a contract with and this carrier is now querying Carrier ENUM > If it find an entry. done. if not the call is routed to the PSTN > In both cases I may or may not be charged by the carrier. > > Now assume I do not have a IX67, I just have a Sipura TA and > a normal phone. In this case the call is directly handled by the > carrier. The cariier is only quierying Carrier ENUM by default. > > I may now have a contract with the carrier that the carrier is querying > User ENUM FIRST on my behalf. He may charge me $5 a month for > this service, but he does not charge me for the call. The rest is as > above. > > rest inline: > > >>The end-user queries User ENUM, the Carrier queries Carrier ENUM. > >>A Carrier MAY query User ENUM on behalf of the user in addition, if the > >>user wants so (opt-in) and the carrier is providing this service. > > >If the Carrier queries Carrier ENUM (and retrieves the POI for that > number), > >and then also queries User ENUM (and receives the URI for the users > mobile phone), > >what should the Carrier do (and why)? > > The feasable agreement would be as described above that always User ENUM > is queried > first, In this case the Carrier ENUM entry would never be seen > > >If the User ENUM query returns a phone number in another country, what > should the carrier do? > > This is a good point and it is not completely solved in User ENUM. Since > User ENUM is also > calling user opt-in, it is basically the decision of the calling user if > a PSTN number is accessed at all > > Remember: if you dial a E.164 number and the number is not contained in > ENUM, you need > to have a carrier avaiable to provide you a GW to the PSTN to complete > the call and you will > be charged anyway. The problem is as you point out: you may dial a > national number > and the User ENUM query returns an international number: Do you forward > this number > now also to the carrier or not. The basic question here is the (undefined) > user interface: > do you get a warning that the call may be more expensive? > > In the above case you mention IMHO there has to be a prior agreement > between user > and carrier how the procedure should be in such cases. > > BTW: we had this problem in implementing the generic gateways for calls > to ENUM-only > numbers from the PSTN. Since the call on the PSTN is only charged to the > gateway, there > is no way to recover the additional charges from the calling party if an > ENUM entry > contains a tel URI to a PSTN number. The solution was that this calls are > not completed > with announcement: service not provided. It is strongle recommended to > users of > ENUM-only numbers to provide a sip URI in any case. > > >And finally, if the User ENUM query returns a link to a web page, what > should the Carrier do? > > Nothing. the user requested a voice call, so he may either look up > carrier ENUM or if this also > does not work: "Service not available.", same if you see an ifax:mailto > Have you ever had a meaningful conversation with a fax machine on the > PSTN? ;-) > > Jim > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jmce@nortel.com Wed, 27 Jul 2005 18:25:00 -0400 From: "James McEachern" Date: Wed, 27 Jul 2005 18:25:00 -0400 To: "Stastny Richard" Subject: RE: [Enum] E.164 communication assumptions/requirements Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Richard, > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] > ENUM-only numbers cannot be in carrier ENUM per se because > there is no hosting carrier. A carrier could pretend to be stupid and > route all calls to the PSTN and charge for them. > I'm not sure I understand what it would mean to route an ENUM-only number to the PSTN. Jim _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jmce@nortel.com Wed, 27 Jul 2005 18:36:05 -0400 From: "James McEachern" Date: Wed, 27 Jul 2005 18:36:05 -0400 To: "Pfautz, Penn L, NEO" Subject: RE: [Enum] E.164 communication assumptions/requirements Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Penn, Does this extend to the Carrier being able to decide what to use when the User ENUM query returns several records? Jim > -----Original Message----- > From: Pfautz, Penn L, NEO [mailto:ppfautz at att.com] > > Richard, > I think the carrier can make that decision in the absence of some other > restriction. > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ppfautz@att.com Wed, 27 Jul 2005 20:00:47 -0400 From: "Pfautz, Penn L, NEO" Date: Wed, 27 Jul 2005 20:00:47 -0400 To: "James McEachern" Subject: RE: [Enum] E.164 communication assumptions/requirements Message-ID: <34DA635B184A644DA4588E260EC0A25A0ABFB506@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Status: R I'd expect so although there might some argument about records with the same service but different preference levels. -----Original Message----- From: James McEachern [mailto:jmce at nortel.com] Sent: Wednesday, July 27, 2005 6:35 PM To: Pfautz, Penn L, NEO; Stastny Richard Cc: enum at ietf.org Subject: RE: [Enum] E.164 communication assumptions/requirements Penn, Does this extend to the Carrier being able to decide what to use when the User ENUM query returns several records? Jim > -----Original Message----- > From: Pfautz, Penn L, NEO [mailto:ppfautz at att.com] > > Richard, > I think the carrier can make that decision in the absence of some other > restriction. > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From lendl@nic.at Thu, 28 Jul 2005 07:03:26 -0400 From: Otmar Lendl Date: Thu, 28 Jul 2005 07:03:26 -0400 To: enum at ietf.org Subject: Re: [Enum] E.164 communication assumptions/requirements In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C063@oefeg-s04.oefeg.loc> Message-ID: <20050728110309.GA412@nic.at> MIME-Version: 1.0 Content-Type: text/plain Status: R On 2005/07/27 22:07, Stastny Richard wrote: > Penn, > > if you say so. > > Nevertheless, do not forget that with ENUM calls > may terminate on the PSTN and also on IP (via ENUM) > Do you think the carrier may decide without the user > consent where to terminate the call? > > -richard > > ------------------------------------------------------------------------ > > Richard: > The ITAC report was not as you interpret it. Opt-in for the calling > entity means there is no duty to query or to use the result if the query > is made. The originator in this clause was NOT restricted to be the end > user but could be the calling user's carrier. There is a nice non-ENUM related example for such rerouting of calls: The German incumbent T-Com offers its customers a product called "Switch&Profit". (sorry, only german links) http://www.pcwelt.de/news/vermischtes/115495/ http://www.golem.de/0507/39117.html The idea is the following: When T-Com user A wants to call T-Com user B on his mobile (operated by e.g. Vodafone), then T-Com has to play rather high termination fees to Vodafone to complete the call. Those costs are of course charged to user A. [Remember: in Europe it's sender pays all for calls to mobiles. There are no charges incurring on the receiving side.] Now, when B is actually at home, there is no need to use the Vodafone mobile to reach him, calling him on his fixed line is good enough. Here is where "Switch&Profit" comes in: if B subscribes to this service and tells T-Com that he is at home, then T-Com will re-route the call to B's fixed line. T-Com will still charge A the same $/min, but T-Com does no longer need to play Vodafone. That profit is shared between T-Com and B who receives 2.59 cent/min for such calls. --------------------- As with ENUM, the destination of a call advertises the availability of an alternative way of completing the call. If it's financially beneficial for an originating telco to take up this offer, why should it decline to do so? The only open issue here is of regulatory nature. In the example from above: Does Vodafone have a right to receive the call to B even if B told T-Com that an alternative is fine with him? I've no idea whether the legal aspects of this service have been settled yet. Given http://www.teletarif.de/arch/2004/kw42/s15139.html, it looks like there have been legal disputes already. (hehe, and they even have the same validation issue as with user ENUM: http://www.xdial.de/arch/2004/kw42/s15152.html ) /ol -- < Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Kim.Fullbrook@o2.com Thu, 28 Jul 2005 08:48:06 -0400 From: "Fullbrook Kim \(UK\)" Date: Thu, 28 Jul 2005 08:48:06 -0400 To: Subject: RE: [Enum] E.164 communication assumptions/requirements Message-ID: <0CD3FFEAEC982F489F872AB8DA32D624019D44B8@Uksthmsx012> MIME-Version: 1.0 Content-Type: text/plain Status: R >> [Remember: in Europe it's sender pays all for calls to mobiles. There >> are no charges incurring on the receiving side.] This is not true. In all the mobile networks I know, customers roaming in foreign countries are charged for incoming calls. (There may be some exceptions I'm not aware of). Also, customers of O2 Germany's "Genion" service pay charges for incoming within-Germany calls in some circumstances. Although probably not relevant here there are also charges for receiving certain types of premium SMS, Kim Fullbrook O2 UK ===================================================== This electronic message contains information from O2 which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. ===================================================== _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From home_pw@msn.com Thu, 28 Jul 2005 09:42:41 -0400 From: "Peter Williams" Date: Thu, 28 Jul 2005 09:42:41 -0400 To: enum at ietf.org Subject: Re: [Enum] E.164 communication assumptions/requirements In-Reply-To: <20050728110309.GA412@nic.at> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R As with ENUM, the destination of a call advertises the availability of an alternative way of completing the call. If it's financially beneficial for an originating telco to take up this offer, why should it decline to do so? The only open issue here is of regulatory nature. In the example from above: Does Vodafone have a right to receive the call to B even if B told T-Com that an alternative is fine with him? ok. Lets sideline the direct issue of this personal/telco profit driver, and focus on the indirect infrastructure requirements that flow from such incentives. A ENUM convergence strategy CANNOT diminish the effectiveness of current regulatory practice in such areas as wiretap: Court C orders trap and trace and a wiretap on B, for some legitimate reason. How do we discover all the parties (VAR, telcos, ISPs, and ENUM providers) who might query ENUM (for trap and trace) or actually complete the call (for wiretap), so we can present the order? Not interested now in dealing with the 20% of folks who might use end-end IP encryption, or route-hiding based on walled-garden ENUMs, or those who hide secret routes in their User ENUM URLs in the e164.arpa. Lets just focus on the 80% of folks who simply subscribe to PSTN-regulated or regulated VOIP carriers. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ppfautz@att.com Thu, 28 Jul 2005 09:57:47 -0400 From: "Pfautz, Penn L, NEO" Date: Thu, 28 Jul 2005 09:57:47 -0400 To: "Peter Williams" Subject: RE: [Enum] E.164 communication assumptions/requirements Message-ID: <34DA635B184A644DA4588E260EC0A25A0ABFB71A@ACCLUST02EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Well, you have to go after party B's various service providers, PSTN and ISP, which is pretty much what you have to do today. If you want to know who's communicating with B you then must work backward with the (court-authorized, we hope) help of B's SPs. Of course, the people in the other 20% who use the peer-to-peer with encryption are the ones to really worry about... -----Original Message----- From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Peter Williams Sent: Thursday, July 28, 2005 9:42 AM To: lendl at nic.at; enum at ietf.org Subject: Re: [Enum] E.164 communication assumptions/requirements >As with ENUM, the destination of a call advertises the availability of >an alternative way of completing the call. If it's financially beneficial >for an originating telco to take up this offer, why should it decline to >do so? > >The only open issue here is of regulatory nature. In the example from >above: Does Vodafone have a right to receive the call to B even if B >told T-Com that an alternative is fine with him? > ok. Lets sideline the direct issue of this personal/telco profit driver, and focus on the indirect infrastructure requirements that flow from such incentives. A ENUM convergence strategy CANNOT diminish the effectiveness of current regulatory practice in such areas as wiretap: Court C orders trap and trace and a wiretap on B, for some legitimate reason. How do we discover all the parties (VAR, telcos, ISPs, and ENUM providers) who might query ENUM (for trap and trace) or actually complete the call (for wiretap), so we can present the order? Not interested now in dealing with the 20% of folks who might use end-end IP encryption, or route-hiding based on walled-garden ENUMs, or those who hide secret routes in their User ENUM URLs in the e164.arpa. Lets just focus on the 80% of folks who simply subscribe to PSTN-regulated or regulated VOIP carriers. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jim@rfc1035.com Thu, 28 Jul 2005 10:13:16 -0400 From: Jim Reid Date: Thu, 28 Jul 2005 10:13:16 -0400 To: "Peter Williams" Subject: Re: [Enum] E.164 communication assumptions/requirements In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R On Jul 28, 2005, at 14:42, Peter Williams wrote: Court C orders trap and trace and a wiretap on B, for some legitimate reason. How do we discover all the parties (VAR, telcos, ISPs, and ENUM providers) who might query ENUM (for trap and trace) or actually complete the call (for wiretap), so we can present the order? I do not understand what point you're making. Or if there even is a point. DNS lookups provide a means of finding an end-point for some method of communication. This is completely orthogonal to how or even if that form of communication is used. Besides, getting the IP addresses of whatever looked up this intercepted number is a completely different thing from identifying the client which initiated the lookup. There's almost always at least one open recursive name server in between the originating client and the authoritative name server. _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From clive@demon.net Thu, 28 Jul 2005 10:46:17 -0400 From: "Clive D.W. Feather" Date: Thu, 28 Jul 2005 10:46:17 -0400 To: Peter Williams Subject: Re: [Enum] E.164 communication assumptions/requirements In-Reply-To: <20050728110309.GA412@nic.at> Message-ID: <20050728144612.GA3471@finch-staff-1.thus.net> MIME-Version: 1.0 Content-Type: text/plain Status: R Peter Williams said: > Court C orders trap and trace and a wiretap on B, for some legitimate > reason. Not in the UK, it doesn't. > How do we discover all the parties (VAR, telcos, ISPs, and ENUM > providers) who might query ENUM (for trap and trace) or actually complete > the call (for wiretap), so we can present the order? The same problem already occurs with call diversion or number portability. -- 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 at ietf.org https://www1.ietf.org/mailman/listinfo/enum From jmce@nortel.com Thu, 28 Jul 2005 10:52:19 -0400 From: "James McEachern" Date: Thu, 28 Jul 2005 10:52:19 -0400 To: "Otmar Lendl" Subject: RE: [Enum] E.164 communication assumptions/requirements Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Otmar, Thanks for the fascinating example. There is however one interesting difference between this and ENUM. In this instance the user (B) who subscribes to the service is also the one getting (at least part of) the value (2.59 cent/min). In the previous ENUM example, user B subscribes to ENUM, but it is user A (or the carrier) who receives the benefit of cheaper calls. Jim > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of > Otmar Lendl > Sent: Thursday, July 28, 2005 7:03 AM > There is a nice non-ENUM related example for such rerouting of calls: > > The German incumbent T-Com offers its customers a product called > "Switch&Profit". > > The idea is the following: > > When T-Com user A wants to call T-Com user B on his mobile (operated by > e.g. Vodafone), then T-Com has to play rather high termination fees to > Vodafone to complete the call. Those costs are of course charged to user > A. [Remember: in Europe it's sender pays all for calls to mobiles. There > are no charges incurring on the receiving side.] > > Now, when B is actually at home, there is no need to use the Vodafone > mobile to reach him, calling him on his fixed line is good enough. > Here is where "Switch&Profit" comes in: if B subscribes to this service > and tells T-Com that he is at home, then T-Com will re-route the call to > B's fixed line. T-Com will still charge A the same $/min, but T-Com does > no longer need to play Vodafone. That profit is shared between T-Com and > B who receives 2.59 cent/min for such calls. > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From axelm@nic.at Thu, 28 Jul 2005 11:16:28 -0400 From: Alexander Mayrhofer Date: Thu, 28 Jul 2005 11:16:28 -0400 To: James McEachern Subject: Re: [Enum] E.164 communication assumptions/requirements In-Reply-To: Message-ID: <42E8F654.8000005@nic.at> MIME-Version: 1.0 Content-Type: text/plain Status: R James McEachern wrote: Otmar, Thanks for the fascinating example. There is however one interesting difference between this and ENUM. In this instance the user (B) who subscribes to the service is also the one getting (at least part of) the value (2.59 cent/min). In the previous ENUM example, user B subscribes to ENUM, but it is user A (or the carrier) who receives the benefit of cheaper calls. Well, that's like in the "traditional" domain space - it is the equivalent of you paying for a domain name which points on your web server, so that others can visit your site (for free). In either case, you pay for the facility which allows others to address you ... (ok, there's a minor difference with ENUM as you can still use the PSTN) cheers axelm _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Thu, 28 Jul 2005 15:36:29 -0400 From: "Stastny Richard" Date: Thu, 28 Jul 2005 15:36:29 -0400 To: "James McEachern" Subject: Re: [Enum] E.164 communication assumptions/requirements Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C065@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R >I'm not sure I understand what it would mean to route an ENUM-only number to the PSTN. All E.164 numbers needs to be (should be ;-) routed on the PSTN, so an ENUM-only number is routed to the nearest GW capable of querying ENUM. For each such number range at least one default GW exists. This is especially necessary if say an operator in the US does not now or does not care that +43780xxxx is an ENUM only range, the call still can be completed by simply routing the call to +43 -richard ________________________________ Von: James McEachern [mailto:jmce at nortel.com] Gesendet: Do 28.07.2005 00:24 An: Stastny Richard Cc: enum at ietf.org Betreff: RE: [Enum] E.164 communication assumptions/requirements Richard, > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] > ENUM-only numbers cannot be in carrier ENUM per se because > there is no hosting carrier. A carrier could pretend to be stupid and > route all calls to the PSTN and charge for them. > I'm not sure I understand what it would mean to route an ENUM-only number to the PSTN. Jim _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From james.f.baskin@verizon.com Fri, 29 Jul 2005 15:35:37 -0400 From: james.f.baskin@verizon.com Date: Fri, 29 Jul 2005 15:35:37 -0400 To: enum at ietf.org Subject: Re: [Enum] E.164 communication assumptions/requirements Message-ID: MIME-Version: 1.0 Content-Type: text/plain Status: R Richard Stastny replied to James McEachern: >>I'm not sure I understand what it would mean to route an ENUM-only number to the PSTN. > >All E.164 numbers needs to be (should be ;-) routed on the PSTN, so an ENUM-only >number is routed to the nearest GW capable of querying ENUM. > >For each such number range at least one default GW exists. >This is especially necessary if say an operator in the US >does not now or does not care that +43780xxxx is >an ENUM only range, the call still can be completed >by simply routing the call to +43 > So there is a kind of ^carrier-of-record^ even for ENUM-only numbers, at least in Austria. I would hope that other countries will require similar arrangements if they allow ENUM-only number assignments. By the way, if the governments of countries allowing assignment of ENUM-only numbers want to consider a completely level playing field for telecommunications users and providers (and require true portability), the number ranges for ENUM-only numbers won't stay purely ENUM when some users port those numbers to PSTN carriers. This may be country- dependent. Jim > >-richard _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mhammer@cisco.com Fri, 29 Jul 2005 16:36:34 -0400 From: "Michael Hammer \(mhammer\)" Date: Fri, 29 Jul 2005 16:36:34 -0400 To: Subject: RE: [Enum] E.164 communication assumptions/requirements Message-ID: <072C5B76F7CEAB488172C6F64B30B5E366918F@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain Status: R Quick check. Is it correct to refer to these as ENUM only numbers, or are they IP-domain numbers for which ENUM is just one method of routing to them. This might be country-specific. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of james.f.baskin at verizon.com > Sent: Friday, July 29, 2005 3:34 PM > To: enum at ietf.org > Subject: Re: [Enum] E.164 communication assumptions/requirements > > > > > > Richard Stastny replied to James McEachern: > > >>I'm not sure I understand what it would mean to route an ENUM-only > >>number > to the PSTN. > > > >All E.164 numbers needs to be (should be ;-) routed on the > PSTN, so an > ENUM-only > >number is routed to the nearest GW capable of querying ENUM. > > > >For each such number range at least one default GW exists. > >This is especially necessary if say an operator in the US > does not now > >or does not care that +43780xxxx is an ENUM only range, the > call still > >can be completed by simply routing the call to +43 > > > So there is a kind of ^carrier-of-record^ even for ENUM-only > numbers, at least in Austria. I would hope that other > countries will require similar arrangements if they allow > ENUM-only number assignments. > By the way, if the governments of countries allowing > assignment of ENUM-only numbers want to consider a completely > level playing field for telecommunications users and > providers (and require true portability), the number ranges > for ENUM-only numbers won't stay purely ENUM when some users > port those numbers to PSTN carriers. This may be country- dependent. > > Jim > > > > >-richard > > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Fri, 29 Jul 2005 17:34:35 -0400 From: "Stastny Richard" Date: Fri, 29 Jul 2005 17:34:35 -0400 To: "Michael Hammer \(mhammer\)" Subject: Re: [Enum] E.164 communication assumptions/requirements Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C06E@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R Mike, James The ENUM-only numbers are real E.164 - in case of the +43780 out of the Austrian numbering plan This implies that the rules are country specific > So there is a kind of ^carrier-of-record^ even for ENUM-only > numbers, at least in Austria. well observed, James ;-) This is a kind of "chicken-and-egg" problem. The rules in Austria require that a registrar needs to have a contract with a "carrier-of-record" operating the gateway, but there is an additional problem: one side the gateway operator may route all numbers within the range, on the other hand the registar cannot insist that calls to his numbers are routed via this gateway. And in addition the registar does not need to provide a VOIP service at all. This is very funny and very disturbing for bell-heads More information only with a consulting contract ;-) -richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Michael Hammer (mhammer) Gesendet: Fr 29.07.2005 22:36 An: james.f.baskin at verizon.com; enum at ietf.org Betreff: RE: [Enum] E.164 communication assumptions/requirements Quick check. Is it correct to refer to these as ENUM only numbers, or are they IP-domain numbers for which ENUM is just one method of routing to them. This might be country-specific. Mike > -----Original Message----- > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On > Behalf Of james.f.baskin at verizon.com > Sent: Friday, July 29, 2005 3:34 PM > To: enum at ietf.org > Subject: Re: [Enum] E.164 communication assumptions/requirements > > > > > > Richard Stastny replied to James McEachern: > > >>I'm not sure I understand what it would mean to route an ENUM-only > >>number > to the PSTN. > > > >All E.164 numbers needs to be (should be ;-) routed on the > PSTN, so an > ENUM-only > >number is routed to the nearest GW capable of querying ENUM. > > > >For each such number range at least one default GW exists. > >This is especially necessary if say an operator in the US > does not now > >or does not care that +43780xxxx is an ENUM only range, the > call still > >can be completed by simply routing the call to +43 > > > So there is a kind of ^carrier-of-record^ even for ENUM-only > numbers, at least in Austria. I would hope that other > countries will require similar arrangements if they allow > ENUM-only number assignments. > By the way, if the governments of countries allowing > assignment of ENUM-only numbers want to consider a completely > level playing field for telecommunications users and > providers (and require true portability), the number ranges > for ENUM-only numbers won't stay purely ENUM when some users > port those numbers to PSTN carriers. This may be country- dependent. > > Jim > > > > >-richard > > > > _______________________________________________ > enum mailing list > enum at ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From mah@inode.at Sat, 30 Jul 2005 02:23:09 -0400 From: Michael Haberler Date: Sat, 30 Jul 2005 02:23:09 -0400 To: "Michael Hammer \(mhammer\)" Subject: RE: [Enum] E.164 communication assumptions/requirements In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E366918F@xmb-rtp-20b.amer.cisco.com> Message-ID: <6.2.1.2.2.20050730081458.056f2a08@localhost> MIME-Version: 1.0 Content-Type: text/plain Status: R At 22:36 29.07.2005, Michael Hammer \(mhammer\) wrote: Quick check. Is it correct to refer to these as ENUM only numbers, or are they IP-domain numbers for which ENUM is just one method of routing to them. This might be country-specific. Good point. The difference between ENUM-only like the +43780 range and IP-domain numbers is that number status is linked to the ENUM domain: if an ENUM domain exists under 0.8.7.3.4.e164.arpa, the number is assigned, otherwise it is unassigned. Actually, the allocation process is reversed wrt a normal ENUM domain (you have a number, obtain an ENUM domain to go with it): you register the domain for an unallocated number, and simsalabim, you obtain the right in the number once you have the domain. -Michael _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From ray@bango.net Sat, 30 Jul 2005 02:52:15 -0400 From: Ray Anderson Date: Sat, 30 Jul 2005 02:52:15 -0400 To: enum at ietf.org Subject: Re: [Enum] E.164 communication assumptions/requirements In-Reply-To: Message-ID: <6.1.2.0.2.20050730075105.02d61490@smtp.bango.net> MIME-Version: 1.0 Content-Type: text/plain Status: R At 20:34 29/07/2005, james.f.baskin at verizon.com wrote: > >For each such number range at least one default GW exists. >This is especially necessary if say an operator in the US >does not now or does not care that +43780xxxx is >an ENUM only range, the call still can be completed >by simply routing the call to +43 > How can the call be "completed" if there is no human or voice source at that ENUM (i.e. its just a web page for example) _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Richard.Stastny@oefeg.at Sat, 30 Jul 2005 03:37:07 -0400 From: "Stastny Richard" Date: Sat, 30 Jul 2005 03:37:07 -0400 To: "Ray Anderson" Subject: Re: [Enum] E.164 communication assumptions/requirements Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C06F@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain Status: R >How can the call be "completed" if there is no human or voice source at >that ENUM (i.e. its just a web page for example) RC: service not available -richard ________________________________ Von: enum-bounces at ietf.org im Auftrag von Ray Anderson Gesendet: Sa 30.07.2005 08:52 An: james.f.baskin at verizon.com; enum at ietf.org Betreff: Re: [Enum] E.164 communication assumptions/requirements At 20:34 29/07/2005, james.f.baskin at verizon.com wrote: > > > >For each such number range at least one default GW exists. > >This is especially necessary if say an operator in the US > >does not now or does not care that +43780xxxx is > >an ENUM only range, the call still can be completed > >by simply routing the call to +43 > > How can the call be "completed" if there is no human or voice source at that ENUM (i.e. its just a web page for example) _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum From Tim@bango.com Sun, 31 Jul 2005 18:17:03 -0400 From: "Tim Moss" Date: Sun, 31 Jul 2005 18:17:03 -0400 To: "Ray Anderson" Subject: [Enum] RE: COMMENTS on draft-ra-shin-enum-mobileweb-01.txt Message-ID: <2BC2AEC80DD48B40AAAB98A4BE71B5C979C1D1@erol.Westbrooke.bango.net> MIME-Version: 1.0 Content-Type: text/plain Status: R I very much agree with Ray here. It would definitely be a good idea to discuss this proposal with the World Wide Web Consortium (W3C) Mobile Web Initiative (MWI) as they are putting significant resource into this area, in particular there are three W3C working groups that should be contacted. These are the Device Independence Working Group (DIWG), the MWI Best Practices Working Group (BPWG) and the Device Description Working Group (DDWG). I don't believe that ENUM is necessarily the right place for storing general device capabilities. A single phone number could be used by multiple devices (e.g. if the internet connection is initiated over Bluetooth to a mobile device) with varying capabilities, or the same device may have multiple 'browser' clients installed on it e.g. WML browser, IMODE browser, video player etc. However, ENUM could be a good place for a user to describe their particular preferences with respect to how they would like content to be presented to them, and potentially override any automatic content adaptation that may otherwise occur. This should definitely be worked out in detail with the MWI though rather than splintering off into two (or more) different solutions for achieving the same result. Tim Moss CTO Bango e: tim at bango.com m: +44 78 8779 4032 t: +44 12 2347 2823 w: http://www.bango.com Mobile Content World 2005 ****************************************************************** "Come and see us on stand 14 at MCW 2005 Olympia Conference Centre, London, UK 13th - 15th September 2005" www.mobilecontentworld.biz > -----Original Message----- > From: Ray Anderson [mailto:ray at bango.net] > Sent: 25 July 2005 11:42 > To: lconroy; Richard Shockey > Cc: 'enum at ietf.org' ENUM; Tim Moss > Subject: COMMENTS on draft-ra-shin-enum-mobileweb-01.txt > > > Here are my top level comments: > > The idea here seems to be to provide "clues" about the > services available at an ENUM addressible site so that a > device or user that could make use of those clues could > provide a better service to the end user. > > The aims are good, but acfetr careful consideration I believe > that this proposal is wrong in its approach, and also wrong > as an ENUMservice. I recommend the authors get involved in > the Mobile Web Initiative. > http://www.w3.org/2005/MWI/ > > (1) Wrong Approach > > The W3C is currently engaged on a Mobile Web Initiative which > is working hard to ensure that web sites can give an improved > experience to mobile users. Currently most web sites are > optimized to big screen users > with a "PC environment (keyboard, distraction level etc.). > There are many > parts to this, not least of which > is that the web site can use information presented by the end > user device (HTTP_ACCEPT among others) to determine how best > to deliver a good experience to users. In addition, the site > can redirect to alternative services that might help, if teh > device has certain characteristics. > > Therefore, the idea of tagging a site with different URL's > that are selected between by the client device or the user > should not be necessary, and in fact is more limited because > the hosting site should be able to evolve and adapt its > capabilities much faster than the client device. > > There are many reasons why one URL for content promotion / > bookmarking / passing on is a good thing. Thats probably why > the .MOBI TLD met with so much derision, and was rejected by > W3C, 3GPP, and content providers. > > > (2) Wrong as an ENUM service > > If the ENUM service approach (not withstanding the above) > was to be useful, then surely it should be available across > all domains, not just those in e164.arpa, for example in > www.neustar.biz so that devices accessing those domains can > also provide more appropriate URL's depending on the support > for WAP, ME, iMode, xHTML, VoiceXML, Flash, etc. In that > case, the extra "clues" should become a general DNS facility, > otherwise only sites accessed by enum URL's could provide the > ease of use. > > In that case I assume there is some other working group that > should look at the proposal. > > > > > At 13:09 23/07/2005, lconroy wrote: > >Hi Folks, > > In case no-one noticed, the mobileweb draft has been updated > >to "draft-ra-shin-enum-mobileweb-01.txt". > > > >This draft is covered in section 3.3 of the Agenda. > >I would suggest that folk look at the new version BEFORE the ENUM > >meeting - the changes are editorial rather than technical, > but given how some > >people seem to have interpreted the -00 version so far, > perhaps this one > >will clarify things and avoid unnecessary flights of fancy. > > > >I would also advise folk to look at the "modest proposal" draft, but > >as it seems vanishingly unlikely that there will be time to > cover that in > >the meeting, questions/comments to the list would be appreciated. > > > >all the best, > > Lawrence > > _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum