Infrastructure ENUM Options Richard Stastny Michael Haberler IETF#65 Dallas, TX

March 2006Richard Stastny2 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.

March 2006Richard Stastny3 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

March 2006Richard Stastny4 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

March 2006Richard Stastny5 Three Options in.arpa 1.Above the Country code –either „i.e164.arpa“ (or „e164i.arpa“) 2.Somewhere below the country code –e.g. carrier.3.4.e164.arpa 3.Pursue Option 1 and Option 2 in parallel All options fulfill requirement 2.8

March 2006Richard Stastny6 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

March 2006Richard Stastny7 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!)

March 2006Richard Stastny8 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 BLR see draft-haberler-carrier-enum-02.txt

March 2006Richard Stastny9 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”

March 2006Richard Stastny10 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