2929bis RRTYPE Allocation for the ENUM Branch Location Record

[Otmar Lendl <[e-mail]>]

Hello,

Section 3.1 of draft-ietf-dnsext-2929bis-04 specifies a DNS RRTYPE
Allocation Policy which involves Expert Review after the submission
of an allocation template to this list.

Although this draft has not been elevated to RFC status yet, the
DNSEXT chairs have agreed to give this new procedure a test-drive
using my EBL draft as the guinea pig.

So here is the template for your consideration:

--------------------------------------------------------------------

	  DNS RRTYPE PARAMETER ALLOCATION TEMPLATE

Date: 

  2006/12/11

Originator: 

  Otmar Lendl <[e-mail]>, [phone]

Specification: 

  http://tools.ietf.org/html/draft-ietf-enum-branch-location-record-01

Need for this RRTYPE:

  ENUM as defined in RFC3761 supports various applications as selected
  by the "service" parameter in the NAPTR record.

  That works very well if all these applications are based on the same
  administrative model where a single shared entity manages the ENUM
  zone for a number.

  In the context of Infrastructure ENUM, this does not hold: The
  end-user has control over the RFC3761 domain on one hand and the
  carrier needs to control (both in terms of content and availability)
  the records for I-ENUM.

  See draft-ietf-enum-infrastructure-enum-reqs-02 for the requirements
  concerning Infrastructure ENUM.

  At the IETF meeting in Dallas there was agreement to pursue a
  two-prong strategy: In the long run a new domain apex for I-ENUM
  is viewed as the right solution. This involves a lot of politics
  (including ITU interactions), thus an interim solution which
  introduces branches to the RFC3761 tree is needed as well. See
  http://tools.ietf.org/html/draft-ietf-enum-combined-01

Alternatives:

  The last two years has seen two proposals on how to integrate
  User-ENUM and I-ENUM in a common tree by a) using non-terminal NAPTR
  records (http://tools.ietf.org/html/draft-pfautz-lind-enum-carrier-00)
  or b) by adding delegations at the number level
  (draft-ietf-enum-3761bis-00.txt + the URI draft).

  One of the main reasons why these proposals were dismissed is the
  existence of "open numbering plans" where the length of a number is
  not fixed. For a long explanation, see
  http://www1.ietf.org/mail-archive/web/enum/current/msg05108.html

  The first proposals regarding branching off the User-ENUM tree
  used static or off-line specified branch locations. One iteration
  (draft-haberler-carrier-enum-01) and proof-of-concept code used a TXT
  record.

  Based on feedback from the dnsext folks this was changed to a
  new RRTYPE which added some more flexibility.

  Non-terminal NAPTRs were considered. For terminals, the regexp
  parameters is very helpful when dealing with open numbering plans,
  e.g. by mapping +1555123(.*) to \[e-mail] with a single record. 
  The "replacement" field, on the other hand, is constant. There is
  no way to capture the concept of "the ENUM tree for this number-range
  is located -> there" with non-terminal NAPTRs.

Mnemonic:

  The RRTYPE is called "ENUM Branch Location" record, thus we propose
  EBL as mnemonic.

  Earlier drafts used "BLR" for "branch location record". This was changed
  as "record" should not be part of the acronym to avoid incorrect language
  like "BLR records".

Registries:

  No new IANA registry is requested. 

Special handling:

  The EBL record does no change the behaviour of DNS servers and needs
  no special casing. It can be treated as an Unknown RRTYPE.

Comments:

  Support for the EBL record (and thus I-ENUM) has been added to
  the OpenSer SIP proxy and will appear in the 1.2 release. The
  code can be found in the OpenSer CVS.

  A patch for Asterisk has been submitted as well. 
  See http://bugs.digium.com/view.php?id=8089

  While testing these patches, a plain bind 9.3.2 installation was
  used as the nameserver. Example resource record:

  infrastructure.1        TYPE65300       \# 14 (
		04    ; position
		01 69 ; separator
		04 65 31 36 34 04 61 72 70 61 00 ; e164.arpa
		)

  This corresponds to 

  infrastructure.1 EBL 4 "i" e164.arpa.

  --

  draft-ietf-enum-branch-location-record-01 does not define an IANA
  registry for labels where EBL might reside. The reason is that
  I don't want to restrict uses of EBLs to special labels. Other
  applications might just as well use EBLs directly at the
  number level, e.g.

  6.1.4.6.5.0.5.1.3.4.e164.arpa. EBL 0 "" enum.nic.at.

  One might suggest that drafts defining EBL use-cases should
  use "_"-prefixed labels to minimize the chance of collisions.
  (plus the proposed registry for these labels)

  Right now, the chance of collision is miminal as no labels
  other than single-digit ones are used in the ENUM tree.

--------------------------------------------------------------------

Any feedback, both regarding the protocol part, as well as the language
of draft-ietf-enum-branch-location-record-01 is very much welcome. The
ENUM WG will put this draft up for last call soon, so I'd prefer to make
any changes as soon as possible.

Thanks!

/ol
-- 
< Otmar Lendl ([e-mail]) | nic.at Systems Engineer >

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>