Subject: 2929bis RRTYPE Allocation for the ENUM Branch Location Record

From: Otmar Lendl <[email-masked]>
Date: Mon, 11 Dec 2006 13:30:26 +0100

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 <[email-masked]>, +43 1 5056416 33

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 \[email-masked] 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 ([email-masked]) | nic.at Systems Engineer >

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

---

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Mon, 11 Dec 2006 09:48:26 -0500

Dear colleagues,

This message starts an "test drive" of the RFC2929bis
"IANA template registration of DNS RR types".

This is an experiment to determine if there are any obvious problems
with the template (and its process) that can be fixed before
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-04.txt
is issued as an BCP.

RFC2929bis will be advanced to the IESG this Friday unless someone
tells us there is a problem with the current document.

Time line for the experiment/test drive:
Start: December 11 15:00 Reykjavik Time  (UTC)
End:   January   1 23:59 Reykjavik Time  (UTC)
Mark Townsley our AD will appoint a special DNS expert for this experiment
    before Jan 1'st and announce his appointment on namedroppers.
Expert review due: January 15'th 12:00 UTC

The chairs are aware that there are number of holidays during this period,
please use that as a motivation to participate sooner rather than later,
by reading the template, the document referred to in the template.
Then send message to namedroppers with
         your issues
or     stating your satisfaction that the information provided is sufficient.

It is important for the working group, its reputation and future workload
that the process to register new RR types is as smooth and robust as possible.

Chairs Notes on template process:
#1 2929bis does not specify a deadline for the expert or what the default
    answer is if the expert is non responsive. In the case of single expert
    this is fine as the expert should allowed to take a long vacation :-)
    For this experiment we specified a deadline in order to conclude 
the process
    before the document is processed by the IESG.

#2 This process does not allow consideration of private messages to the
    expert.

thank you
         Olafur & Olaf