2007/07/23IETF69 enum-combined1 draft-ietf-enum- combined IETF69 Otmar Lendl Michael Haberler Richard Stastny

2007/07/23IETF69 enum-combined2 Motivation  The long-term solution (new apex for I-ENUM) may take some time to materialize.  Interim solution to get an interoperable I-ENUM setup up and running.

2007/07/23IETF69 enum-combined3 Idea  Initial idea: Leveraging the e164.arpa infrastructure by branching off the e164.arpa tree  Q: Where to branch?  Usually at the CC level  Maybe at the NPA level

2007/07/23IETF69 enum-combined4 Evolution:  -00: external table listing where to branch  -01: DNS record at the CC level indicates where to branch (need an integer value, stored in ??)  If not found, look down the tree  Strong recommendation from DNS ppl: do your own RRTYPE  Dallas treaty:  Generic RRTYPE  combined draft uses that facility

2007/07/23IETF69 enum-combined5 Prague  Pre-IETF68 (-03):  EBL definition + ENUM w/ EBLs DDDS application  Combined draft: use-case of EBLs, EBL located at “infrastructur.CC.164.arpa”, walk down tree if not found.  dnsext interaction:  RFC 2929bis experiment  Long chat with Ed Lewis and Olafur  tree walking  location of EBL

2007/07/23IETF69 enum-combined6 -05  no more “infrastructure.3.4.e164.arpa EBL..”. EBL at CC domain itself.  -> Need a RRTYPE for each use-case of EBLs.  There is no such thing as a “generic EBL”.  Got rid of DNS tree walking.  Good DNS karma  Walking down was less a problem then walking up

2007/07/23IETF69 enum-combined7 AD-Review  Jon: “please be more specific re: motivation”  Ok, so let’s play devil’s advocate:  The IEBL contains three fields:  SEPARATOR  POSITION  APEX

2007/07/23IETF69 enum-combined8 SEPARATOR  “What label to insert in order to branch”  E.g. “i” leads to i.3.4.e164.arpa  Do we really need it?  Is it a hard requirement that countries are able to use different branch label? Not really. Nice, but not a MUST.

2007/07/23IETF69 enum-combined9 POSITION  “Where to insert the SEPARATOR”  Usually the CC length, e.g.  2: XX.3.4.e164.arpa  3:XX e164.arpa  Might be different for group-of-country codes:  4:XX.N.P.A.1.e164.arpa  But: in such cases the GoC have to agree on the EBL (remember: no more tree-walking!), so why not agree on double delegations like  N.P.A.1.e164.arpa and N.P.A.XX.1.e164.arpa  Thus: the EBL does not buy a NPA independence from the GoC any more.  We already need the prior knowledge of the CC lengths, so why not just make that table be the POSITIONs?

2007/07/23IETF69 enum-combined10 APEX  “what replaces e164.arpa”  Facilitate the transition to the long-term solution.  3.4.e164.arpa IEBL 0 “” i-enum.arpa *.  Not all countries will switch at the same moment. Older clients MUST be redirected to the new tree.  That’s a known problem in the DNS space. Solution:  XX.3.4.e164.arpa DNAME 3.4.i-enum.arpa * whatever the final apex will be.

2007/07/23IETF69 enum-combined11 So we’ve come full circle  By removing some features, a simpler solution is possible:  Always branch at a statically configured position, using the same label.  Use DNAMEs for the transition to the long-term solution.

2007/07/23IETF69 enum-combined12 Hum 1  What should we do:  Keep the EBL work, polish the drafts and off to the IESG we go. or  Junk the EBL draft, rewrite the combined draft to use simpler solution. WG Last call ASAP.

2007/07/23IETF69 enum-combined13 Hum 2 (if EBLs are junked)  What (fixed) label to use for branching:  “i”  “infrastructure”  “ienum”  “i-enum”

2007/07/23IETF69 enum-combined14 Hum 3 (if EBLs are junked)  Fix the location on the CC length. vs.  Define an exception for +1 (branch at NPA level).

2007/07/23IETF69 enum-combined15 Reserve Slide: What was the issue with DNAME?  Can’t use DNAME if POSITION > CCLEN, e.g.  i.1.e164.arpa DNAME XX.N.P.A.1.e164.arpa