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

[Ólafur Guðmundsson /DNSEXT co-chair <[e-mail]>]

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

At 07:30 11/12/2006, Otmar Lendl wrote:

>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/>