110 likes | 211 Views
Infrastructure ENUM Options. Richard Stastny Michael Haberler IETF#65 Dallas, TX. One Tree. common consensus to have ONE common global public tree for Infrastructure ENUM even from people currently offering Infrastructure ENUM services in private federated ENUM trees
E N D
Infrastructure ENUM Options Richard StastnyMichael Haberler IETF#65 Dallas, TX
One Tree • common consensus to have ONE common global public tree for Infrastructure ENUM • even from people currently offering Infrastructure ENUM services in private federated ENUM trees • “a common tree would be preferable (if it is mine)” • Requirement 2.1. • Infrastructure ENUM SHALL provide a means for a provider to populate DNS RRs in a common publicly accessible namespace for the E.164 numbering resources for which it is the carrier-of-record. Richard Stastny
In .arpa • Infrastructure ENUM could be implemented in any domain • Requirement 2.6. • Infrastructure ENUM SHALL be implemented under a TLD that can support reliability and performance suitable for PSTN applications. • We propose to use .arpa also for Infrastructure ENUM Richard Stastny
Advantages of .arpa • Involvement of IETF, IAB, RIPE and ITU-T necessary • Existing international and national procedures and policies may be re-used • No need (and time required) to create a new governing body to define the policy framework Richard Stastny
Three Options in .arpa • Above the Country code • either „i.e164.arpa“ (or „e164i.arpa“) • Somewhere below the country code • e.g. carrier.3.4.e164.arpa • Pursue Option 1 and Option 2 in parallel • All options fulfill requirement 2.8 Richard Stastny
Option 1 • Above the Country Code e.g. in i.e164.arpa • most straightforward solution • minimum impact on RFC 3761, no add. RFC needed • minimum impact on clients • IETF, IAB, RIPE and eventually ITU-T involvement necessary • it has to be checked with ITU-T if the existing Interim Procedures are still valid or have to be modified • but this can only be done AFTER principal agreement by IAB and RIPE • If done according to the existing Interim Procedures, opt-in into Infrastructure ENUM is also a national decision like User ENUM (and an opt-in of the CoR) • These activities will require definitely some time Richard Stastny
Option 2 • Below the Country Code e.g. in .e164.arpa • not so straightforward • no impact on RFC 3761, but add. RFC needed • more impact on clients (SP only) • No IETF, IAB, RIPE and ITU-T involvement necessary • a national matter only: • decision to put in the Branch Location Record (BLR) • where to put the Infrastructure ENUM tree • split off at or below the CC • on any other domain • Can be implemented immediately (NOW!) Richard Stastny
Option 2 Examples • The Branch Location Record (BLR) gives the following information: • where the split occurres • what the label of the split tree is • what the apex of the tree is • in infra.3.4.e164.arpa • BLR 2 “infra” “e164.arpa” in 3.4.e164.arpa • in carrier.a.p.n.1.e164.arpa • BLR 4 “carrier” “e164.arpa” in 1.e164.arpa • in 9.4.e164.info • BLR 0 “” “e164.info” in 9.4.e164.arpa • for more info and how to locate the BLRsee draft-haberler-carrier-enum-02.txt Richard Stastny
Option 1+2 • Option 1 may take some time, • OTOH the need for Infrastructure ENUM is immediate (at least for trials), • it is proposed to pursue Options 1 and 2 in parallel • Countries using Option 2 now may choose anytime to fall back on Option 1 • by simply moving their tree over and • changing their BLR to BLR 0 “” “e164.arpa” Richard Stastny
Summary • Proposed way forward for Infrastructure ENUM • finalize requirements • decide to use .arpa • pursue options 1 and 2 in parallel: • IAB and RIPE • draft RFC 3761bis • RFC to define interim BLR Richard Stastny