April 2006 - enum-wg - mailman.ripe.net

Re: [enum-wg] Follow up on Jim Reid's presentation - CRUE and relation to IETF work
by Jim Reid 01 May '06

01 May '06

On Apr 28, 2006, at 07:58, Michael Haberler wrote: > I'm a bit puzzled though about your slides where you mention > "CRUE" (Carrier Registration in User ENUM) and its potential > international interoperability aspects. > > currently the IETF work on Infrastructure ENUM is progressing > nicely - I expect the long-run solution to be a separate apex (like > ie164.arpa for instance) and http://www.enum.at/ietf/draft-haberler- > carrier-enum-02.html will be the backwards-compatible interim > solution until ITU and friends have their act together. Looks like > all this is done this year. This will provide a easy manageable > home for carrier-related information. Michael, CRUE has no bearing whatsoever on Infrastructure ENUM. This will be apparent when the CRUE document is published on the new UK ENUM web site. [I'll make an announcement about that when it goes on- line.] The object of CRUE is to get lots of meaningful data into the UK ENUM tree so that ENUM-aware applications can be encouraged because there's a better chance of getting a successful ENUM lookup. The scheme is simple. Communications Service Providers register a block of numbers. This gets verified against the regulator's public database of block allocations to CSPs. The registry enters 2 NAPTRs for these numbers: a tel: URI and a sip: URI. The only "control" the CSP has here is the name of the SIP server: ie how non-PSTN calls can be terminated on their network. Now there's a lot of detail about ported numbers, allocation to end users and so forth. But that still doesn't make CRUE a replacement for "Infrastructure ENUM" whatever that happens to mean today. BTW I don't share your optimism that standardisation of Carrier ENUM can be completed this year. But let's not jump down that rat-hole. > I'm a bit concernced about diverging developments - maybe you can > enlighten us where you're heading and how this will interoperate > with the rest of us. CRUE is not a "standard". Or a protocol. It's just a means to get lots of NAPTRs populating the 4.4.e164.arpa name space. So there are no interoperability issues.

2 4

RE: [enum-wg] Follow up on Karen Mulberry's presentation today
by Mulberry, Karen 01 May '06

01 May '06

Carsten, My responses Q1: The number resources the FCC is meant to set aside for the ENUM trial - will they cover all US geographic area codes or is that somehow limited? If so, what will be the limits or restrictions? The US trial committee participants are identifying the geographic areas (NPAs) and the amount of numbers they require to conduct their ENUM test cases. Since the FCC has not responded to the wavier request with any restrictions or limits, there are none that I am aware of at this time. Trial participants do not expect to have limits placed on them beyond what the USG terms and conditions called for - that all numbers to be used in the US ENUM trial must be allocated under wavier by the FCC. Q2: In slide 5, 9 and 10 you mention the "Trial Participants Advisory Committee (TPAC)", what roles will be involved when in the trial and what documentation TPAC is meant to produce. I just wonder to what extent the users - aka. number holders, aka. ENUM domain name registrants - will be involved, as they seem to not be mentioned explicitly? The trial MOU calls for trial participants to identify what role or roles they intend to play in the US trial. The ones that I outlined in my presentation are the options that a trail participant can choose from. Such as number holders are identified as End Users and ENUM Domain Name Registrants once they have been authenticated and verified. There are several parties that have indicated that they intend to be End Users for the trial. Also the TPAC will produce reports on its trial activities on a monthly basis for the CC1 ENUM LLC. Initially these reports should contain the organizational plans (who is playing what role(s)) and test case development associated with the three phases of the trial. Once the trial starts, I expect that the monthly reports will contain the results of the tests that have been run during that month. Once the trial has ended, a final report that summarizes all activities and results will be complied for the LLC. Karen Mulberry Neustar Inc. -----Original Message----- From: enum-wg-admin(a)ripe.net [mailto:enum-wg-admin@ripe.net] On Behalf Of Carsten Schiefner Sent: Thursday, April 27, 2006 8:50 AM To: enum-wg(a)ripe.net Subject: [enum-wg] Follow up on Karen Mulberry's presentation today [Background: Karen Mulberry gave a presentation on "Country Code 1 and the US ENUM Trial" this afternoon during the ENUM WG session, currently available at: http://www.ripe.net/ripe/meetings/ripe-52/presentations/uploads/Thursday /mulberry-country_code_1_and_the_us_enum_trial.pps - the following questions relate to that presentation] Karen, I have two questions in relation to your presentation: Q1: The number resources the FCC is meant to set aside for the ENUM trial - will they cover all US geographic area codes or is that somehow limited? If so, what will be the limits or restrictions? Q2: In slide 5, 9 and 10 you mention the "Trial Participants Advisory Committee (TPAC)", what roles will be involved when in the trial and what documentation TPAC is meant to produce. I just wonder to what extent the users - aka. number holders, aka. ENUM domain name registrants - will be involved, as they seem to not be mentioned explicitly? Thanks, Carsten

2 1

Re: [enum-wg] Follow up on Jim Reid's presentation - CRUE and relation to IETF work
by Stastny Richard 30 Apr '06

30 Apr '06

Hi Jim, >BTW I don't share your optimism that standardisation of Carrier ENUM >can be completed this year. But let's not jump down that rat-hole. For terminolgy: Carrier ENUM needs not to be standardized, it is Infrastructure ENUM. I agree that the long-term soltution cannot be standardized this year, because the earliest (optimistic) possible date is January 2007 JWhat Michael wanted to say is that the temporary solution defined in the Dallas treaty can be nationally implemented soon (as you will see) and could be ready for publication request this fall, so it could be used also internationally in a standadized way. Another question for clarification about CRUE: You mention that for each number a tel and an sip URI is entered. this requires each operator to provide a ingress element to their network How can this be done? Richard ________________________________ Von: enum-wg-admin(a)ripe.net im Auftrag von Jim Reid Gesendet: Fr 28.04.2006 10:26 An: Michael Haberler Cc: enum-wg(a)ripe.net Betreff: Re: [enum-wg] Follow up on Jim Reid's presentation - CRUE and relation to IETF work On Apr 28, 2006, at 07:58, Michael Haberler wrote: > I'm a bit puzzled though about your slides where you mention > "CRUE" (Carrier Registration in User ENUM) and its potential > international interoperability aspects. > > currently the IETF work on Infrastructure ENUM is progressing > nicely - I expect the long-run solution to be a separate apex (like > ie164.arpa for instance) and http://www.enum.at/ietf/draft-haberler- > carrier-enum-02.html will be the backwards-compatible interim > solution until ITU and friends have their act together. Looks like > all this is done this year. This will provide a easy manageable > home for carrier-related information. Michael, CRUE has no bearing whatsoever on Infrastructure ENUM. This will be apparent when the CRUE document is published on the new UK ENUM web site. [I'll make an announcement about that when it goes on- line.] The object of CRUE is to get lots of meaningful data into the UK ENUM tree so that ENUM-aware applications can be encouraged because there's a better chance of getting a successful ENUM lookup. The scheme is simple. Communications Service Providers register a block of numbers. This gets verified against the regulator's public database of block allocations to CSPs. The registry enters 2 NAPTRs for these numbers: a tel: URI and a sip: URI. The only "control" the CSP has here is the name of the SIP server: ie how non-PSTN calls can be terminated on their network. Now there's a lot of detail about ported numbers, allocation to end users and so forth. But that still doesn't make CRUE a replacement for "Infrastructure ENUM" whatever that happens to mean today. BTW I don't share your optimism that standardisation of Carrier ENUM can be completed this year. But let's not jump down that rat-hole. > I'm a bit concernced about diverging developments - maybe you can > enlighten us where you're heading and how this will interoperate > with the rest of us. CRUE is not a "standard". Or a protocol. It's just a means to get lots of NAPTRs populating the 4.4.e164.arpa name space. So there are no interoperability issues.

3 3

RE: [enum-wg] Follow up on Jim Reid's presentation - CRUE and relation to IETF work
by Stastny Richard 30 Apr '06

30 Apr '06

> But let's assume that happens - what is the semantics of such a SIP > URI for a) an end user and b) an operator - can I bounce a call to > sip:number@bt.com if I find <number> in 4.4.e164.arpa and it returns > such a registry-entered sip URI? Can I (do I need to?), as a > end-user, distinguish who entered which record? What if I have a IP > Interconnect agreement with BT / what if not? I would assume BT might > have an opinion here.. Tony? IMHO this could only work, especially in User ENUM, if this Sip?:number@bt.com;user=phone is used purely to indicate a Service Provider ID (SPID). The domain name given is not resolvable in the public DNS, only within the providers DNS (as proposed yesterday by GSMA with the Local Routing Tables (LRT). One way to clearly distinguish from routable SIP entries would be to use an new enumservice called e.g. SPID to indicate that the domain name has to be resolved by other means. In this case the users may simply ignore enumservice spid because they cannot use it. This enumservise may also be useful in Infrastructure ENUM to distinguish between ENUM entries routable on the public Internet and pure SPID entries (e.g. gsmaworld.com) Richard

2 1

Follow up on Jim Reid's presentation today
by Carsten Schiefner 30 Apr '06

30 Apr '06

[Background: Jim Reid gave a presentation on "UK ENUM News" this afternoon during the ENUM WG session, currently available at: http://www.ripe.net/ripe/meetings/ripe-52/presentations/uploads/Thursday/re… - the following question relates to that presentation] Jim, I have a question in relation to your presentation: on the second slide it reads "Tier-1 registry appointed around October" - so my understanding is that UKEC, UKEG's successor, will not have any operational business, but will act as the delegee for 4.4.e164.arpa and have operations outsourced. Is that correct? Best, -C.

3 3

+43 Infrastructure ENUM - contract concluded
by Carsten Schiefner 30 Apr '06

30 Apr '06

All, I am not entirely sure why Michael's mail did not yet show up here, but anyways: here is another attempt to spread the news. Best, Carsten -------- Original Message -------- Subject: [Enum] +43 Infrastructure ENUM - contract concluded Date: Fri, 28 Apr 2006 09:37:48 +0200 From: Michael Haberler <mah(a)inode.at> To: enum-wg@ripe.net,enum@ietf.org,ga@centr.org enum.at GmbH, operator of the +43 User ENUM registry, and RTR GmbH, the Austrian regulator,have concluded and signed a contract extension to the +43 ENUM operating contract on April 20, 2006, enabling enum.at GmbH to provide Infrastructure ENUM as currently standardized in the IETF. Service is scheduled to start next month. press releases (in german - english to follow:) http://www.portel.de/news/view_redsys_artikel.asp?id=10293 RTR: Österreich baut weltweite Vorreiterrolle bei ENUM aus ... Portel.de - Germany Wien, 27.04.06-11:45 Mit der Vertragserweiterung, die ie enum.at GmbH und RTR-GmbH am 18. April 2006 unterzeichnet haben, ist... http://www.ots.at/presseaussendung.php?schluessel=OTS_20060427_OTS0163&ch=t… Österreich baut weltweite Vorreiterrolle bei ENUM aus APA OTS (Pressemitteilung) - Austria Wien (OTS) - "Mit der Vertragserweiterung, die enum.at GmbH und RTR-GmbH am 18. April 2006 unterzeichnet haben, ist es in Österreich ... the contract addendum (also german, english translation to follow as well:) http://www.rtr.at/web.nsf/deutsch/Telekommunikation_Nummerierung_ENUM/$file… Richard Stastny blog comment: http://voipandenum.blogspot.com/2006/04/infrastructure-enum-in-austria-on-i… Michael Haberler Internet Foundation Austria

1 0

Follow up on Karen Mulberry's presentation today
by Carsten Schiefner 27 Apr '06

27 Apr '06

[Background: Karen Mulberry gave a presentation on "Country Code 1 and the US ENUM Trial" this afternoon during the ENUM WG session, currently available at: http://www.ripe.net/ripe/meetings/ripe-52/presentations/uploads/Thursday/mu… - the following questions relate to that presentation] Karen, I have two questions in relation to your presentation: Q1: The number resources the FCC is meant to set aside for the ENUM trial - will they cover all US geographic area codes or is that somehow limited? If so, what will be the limits or restrictions? Q2: In slide 5, 9 and 10 you mention the "Trial Participants Advisory Committee (TPAC)", what roles will be involved when in the trial and what documentation TPAC is meant to produce. I just wonder to what extent the users - aka. number holders, aka. ENUM domain name registrants - will be involved, as they seem to not be mentioned explicitly? Thanks, Carsten

1 0

Issues with RFC 3761 so far
by Patrik Fältström 27 Apr '06

27 Apr '06

It was mentioned in the plenary this morning the ticket system I use for creation of RFC 3761bis. The issues are so far: [Please don't respond to this email, respond to the original email that describes the ticket that was sent to the ENUM wg in the IETF, or add issues to the ticket system directly...instructions I can send on request] What I have in the tracker are the following issues: #838 ORDER/PRIORITY locality ORDER and PRIORITY is significant only within the current domain. This is not clear in RFC 3761. #861 Fast lane for Enumservice IANA registration It is proposed to establish a fast lane for rIANA egistration of non- essential Enumservices using only expert review and not the full RFC cycle. #870 DDDS - RFC3404 reserves ALL flag characters RFC 3404 specifies that all flag characters are reserved "for future versions of this document". #873 Character Set, Case Sensitivity, and NAPTR fields Character Set, Case Sensitivity, and NAPTR fields. NOTE - This is really three inter-related topics. As they are so closely tied together I have requested a single ticket. #874 REGEXP 'i' flag considered harmful RFC 3402 specifies an 'i' flag that can be applied to the REGEXP field. This flag is intended to make AUS matching case insensitive. For ENUM, this is not appropriate, as the allowed characters within an AUS are all case insensitive. #875 Only one Enumservice per NAPTR the syntax for Enumservices given in RFC3761 allows for more then one Enumservice to be given, by addiing them with a '+' #878 experimental ENUM services - clash prevention ecause of the cumbersome process of ENUMservice registration, more and more experimental services are popping up. Contrary to it's intended purpose, more and more of those services are used "de facto" not only internally, but between different parties. This increases the risk of collisions between several different implementations of "experimental" ENUMservices, hence creating the need for preventing collisions between those services. Patrik

1 0

Revised draft agenda for ENUM WG at RIPE 52
by Niall O'Reilly 26 Apr '06

26 Apr '06

Dear ENUM-WG Colleagues, Please find below the revised draft agenda for the ENUM WG at RIPE 52. Tu 25 Apr 15:00 (Plenary): Gerhard Schroeder: Security issues in ENUM Th 27 Apr 14:00 (ENUM WG slot): Start Duration Led by Description 14:00 3' Chair A: Administrivia: Welcome, Scribe, Jabberwok 14:03 2' Chair B: Minutes ENUM-WG at RIPE 51 14:05 3' Chair C: Review Action List (see notes below) 14:08 2' Chair D: Short News (if any) 14:10 8' LV E: RIPE NCC ENUM Report 14:18 10' GS/Chair F: Follow-up on Plenary: ENUM and Security G: Presentations 14:28 20' KM G1: +1 Trial 14:48 4' JR G2: +44 Update 14:52 4' JR G3: Testbed numbers 14:56 10' AB G4: +49 Commercial Operations 15:06 5' [TBA] G5: +353 Commercial Operations X: Interaction with other RIPE WGs 15:11 10' PK X1: Walking E164.ARPA 15:21 4' CS X2: DNS-WG-AP-51.5 15:25 3' Chair Y: AOB 15:28 2' Chair Z: Close: summarize actions, thanks 90' Your co-chairs are striving to minimize the proportion of the meeting given over to administrative items. Please help by sending corrections to the RIPE 51 ENUM WG minutes by e-mail to <enum-wg(a)ripe.net> to arrive no later than 12:00 UTC on Wednesday, 26 April. Notes for item C: Review action list 51.1 (RIPE NCC): Statistics from all e164.arpa servers. Report from NCC (Leo Vegoda?) at agenda item E 51.2 (Carsten Schiefner): Let NCC know details of missing links. Done? Carsten, please confirm to list in advance of meeting 51.3 (RIPE NCC): To check whether quarterly ENUM reports to IAB would still be necessary and asked for. Done. Changes are publicised on the enum-announce list. Report duplicates these. 51.4 (Peter Koch): Continue walking e164.arpa and report at RIPE 52. Report/presentation from PK at agenda item X 51.5 (Jim Reid): Stimulate discussion on testbed numbers/ranges. Presentation from JR at agenda item G3 51.6 (Carsten Schiefner): Cross-check on DNS-WG-AP-51.5. Mention at agenda item X 51.7 (All): Test reachability of non-geo +43 780 numbers. Done? Many people responded. Do the +43 ppl need anything more? Please will someone from +43 confirm in advance of the meeting. On Carsten's behalf as well as for myself, I hope to see all of you in Istanbul! Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group

2 3

Delegation of +359/9.5.3.e164.arpa completed
by Carsten Schiefner 20 Apr '06

20 Apr '06

Dear colleagues, the ENUM delegation request for 9.5.3.e164.arpa - +359 is Bulgaria's E.164 CC - was confirmed by ITU-T TSB on 12 Apr 2006. As per yesterday, 9.5.3.e164.arpa is delegated to ns.bol.bg. [193.200.15.129] ns.bolbg.com. [193.200.15.133] Welcome, Bulgaria! :-) Best, Carsten Schiefner

2 2