Saturday, May 20, 2006
The ENUM Babuschkas and US Provider ENUM
At my short introduction moderating the "ENUM Now" panel I mentioned the ENUM Babuschkas: User - Infrastructure - Private - Carrier - Operator - Enterprise - Federation ENUM (Note: I will report on this panel as soon as I have all slides available)
The US ENUM LLC was not happy with these naming options and decided to introduce a new term: Provider ENUM. But they also allow you to call it "Carrier" or "Infrastructure" ENUM ;-)
So the group reacted quite fast on the restriction imposed not to do Infrastructure ENUM in e164.arpa and simply implements the trial in a separate tree - in this case "e164enum.us."
Congratulations to all involved here!
In a press release from May 16, 2006 the Country Code 1 ENUM LLC (LLC) announced the launch of a second ENUM technology trial that will focus on service provider interconnection requirements:
The U.S. Provider ENUM trial will be based on the "Framework Document for a U.S. Provider ENUM Trial" . The trial of Provider ENUM (sometimes referred to as "Carrier" or "Infrastructure" ENUM) is expected to be conducted over a four-month period beginning in July. This trial will be carried out in parallel with the current End-User ENUM trial and will use a different domain name and separate numbering resources. As with the End-User ENUM trial, no commercial end-users will be involved in the Provider ENUM trial.
TSPs with assigned numbering resources that seek to exchange end-user traffic with other TSPs on an IP basis are encouraged to participate.
The results of the trial will form the basis of requirements for a commercial implementation to assist U.S. service providers. The CC1 ENUM LLC plans are consistent with the Internet Engineering Task Force (IETF) ENUM Working Group efforts to progress a global solution for Provider ENUM. The proposed U.S. implementation, targeted for 2007, should be easily transitioned to the global solution when it becomes available.
I like the last paragraph, because it shows a way forward and is not incompatible with the now envisaged future developments in IETF ENUM WG.
I am sceptical about another statement in the framework document
In addition to the basic trial as outlined below, the trial implementation will provide a platform that may be used to test other architectural alternatives and capabilities, which may include:
2. and 4 allow to do "Linkage with other non-US trials" as pointed out also in section 7.3.2 of the framework, but please not with a DNAME (this would not work with i.3.4.e164.arpa), but by using the EBL ressource record as described in draft-lendl-enum-branch-location-record. Provided they are allowed to put this record into the sacrosanct e164.arpa.
In this section there seems also to be a slight misunderstanding where ie164.arpa belongs too: ie164.arpa as defined in draft-ietf-enum-nfrastructure does NOT belong to ETSI.
Anyway, once again, well done!
The US ENUM LLC was not happy with these naming options and decided to introduce a new term: Provider ENUM. But they also allow you to call it "Carrier" or "Infrastructure" ENUM ;-)
So the group reacted quite fast on the restriction imposed not to do Infrastructure ENUM in e164.arpa and simply implements the trial in a separate tree - in this case "e164enum.us."
Congratulations to all involved here!
In a press release from May 16, 2006 the Country Code 1 ENUM LLC (LLC) announced the launch of a second ENUM technology trial that will focus on service provider interconnection requirements:
The U.S. Provider ENUM trial will be based on the "Framework Document for a U.S. Provider ENUM Trial" . The trial of Provider ENUM (sometimes referred to as "Carrier" or "Infrastructure" ENUM) is expected to be conducted over a four-month period beginning in July. This trial will be carried out in parallel with the current End-User ENUM trial and will use a different domain name and separate numbering resources. As with the End-User ENUM trial, no commercial end-users will be involved in the Provider ENUM trial.
TSPs with assigned numbering resources that seek to exchange end-user traffic with other TSPs on an IP basis are encouraged to participate.
The results of the trial will form the basis of requirements for a commercial implementation to assist U.S. service providers. The CC1 ENUM LLC plans are consistent with the Internet Engineering Task Force (IETF) ENUM Working Group efforts to progress a global solution for Provider ENUM. The proposed U.S. implementation, targeted for 2007, should be easily transitioned to the global solution when it becomes available.
I like the last paragraph, because it shows a way forward and is not incompatible with the now envisaged future developments in IETF ENUM WG.
I am sceptical about another statement in the framework document
In addition to the basic trial as outlined below, the trial implementation will provide a platform that may be used to test other architectural alternatives and capabilities, which may include:
- Non-terminal NAPTR records
- Carrier (Provider) domain branch under e164.arpa
- The provision of NAPTR records in Tier 1
- Linkage with other, non-NANP Provider ENUM trials
- Selective Control of Resolution/Call Admission
- Hiding the “root” of the Provider ENUM tree (i.e., e164enum.us) from everyone but “authorized” service providers (i.e., trial participants).
2. and 4 allow to do "Linkage with other non-US trials" as pointed out also in section 7.3.2 of the framework, but please not with a DNAME (this would not work with i.3.4.e164.arpa), but by using the EBL ressource record as described in draft-lendl-enum-branch-location-record. Provided they are allowed to put this record into the sacrosanct e164.arpa.
In this section there seems also to be a slight misunderstanding where ie164.arpa belongs too: ie164.arpa as defined in draft-ietf-enum-nfrastructure does NOT belong to ETSI.
Anyway, once again, well done!
Comments:
Post a Comment
