Subject: RR Type allocation for infrastructure ENUM BLR/EBL record

From: Otmar Lendl <[email-masked]>
Date: Mon, 15 May 2006 17:26:53 +0200

Hello everyone,

some of you may have been at the ENUM WG at IETF65 in Dallas.

There was some discussion there regarding an interim solution (before
moving to a new tree (e.g. ie164.arpa)) where one branches off the
User-ENUM tree at a specific point.

The storage of the information where and how to branch to this
provisional I-ENUM tree has been the source of some rather heated
discussion.

Last year a proposal (and code) used TXT records at the country-code 
level to store this information.

This has made a lot of people queasy, and visiting people from DNS
related WGs remarked that creating a new RR Type isn't that much of a
deal any more as RFC3597 is widely supported.

See http://www1.ietf.org/mail-archive/web/enum/current/msg04856.html
for the WG minutes.

So I took up that suggestion, wrote a quick RR Type definition
(http://www.ietf.org/internet-drafts/draft-lendl-enum-branch-location-record-00.txt)
[feedback is welcome on that, too!] and added support for that RR type
to the OpenSER SIP proxy.

One issue is still unresolved: What RR Type code should I use?

I've looked at RFC2929, and went for 65300 for now. This is not optimal.

Problems:

* I don't think an I-D fulfills "Specification Required as defined in [RFC 2434]",
  thus I can't get a code in the 32768 - 65279 range.

* RFC4020 is way too heavyweight for my purpose.

* I can't wait for my draft to become RFC (or even WG document).
  We're about to release that code now, and as Austria has already
  launched an Infrastructure ENUM trial last week, we need to agree
  at least locally to one code ASAP. The whole point of that
  record is international compatibility, thus a "Private Use." code
  is definitly counter-productive.

* There is no shortage of type-codes. This is not a scarce ressource. 
  We're at less than 70 of 65536 possible codes. That's about 0.1 %
  utilization.

Summary:

RFC3597 is very helpful to deploy new ressource record types.

The process of selecting a type code is not as easy and quick as I hoped.

Recommendations?

/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: Sam Weiler <[email-masked]>
Date: Mon, 15 May 2006 12:51:45 -0400 (EDT)

I think you should try to get a real assignment from IANA, and I'm 
curious as to why you think 4020 is too heavyweight.

Aside from that, the most expeditious route may be to publish the 
draft elsewhere (e.g. a corporate tech report series) and ask IANA to 
make the allocation based on a document other than an RFC.  I did this 
a few months ago (for the TA typecode), and it worked relatively 
smoothly -- it was certainly faster than trying to get an RFC 
published.  IANA will almost certainly ask whether your document is 1) 
readily available and 2) permanent, per the criteria in 2434 and 
draft-narten-iana-considerations-rfc2434bis-04.txt

A couple of more ideas:  look again at 4020 and see if you can 
tolerate it.  Or ask the IANA to implement a template procedure for 
typecodes, so that the template becomes the permanent reference.  I 
think 2929bis is attempting to do that, but I also believe IANA has 
the option to implement a template system on its own -- I was trying 
to get that to happen a few months ago but dropped the ball on it. 
If it would make a big difference to you, I'd be happy to try to get 
that moving again.

I'm also CC'ing the ADs who have overseen DNSEXT in recent years. 
Thomas Narten, in particular, may have some more ideas for you.

-- Sam

> some of you may have been at the ENUM WG at IETF65 in Dallas.
...
> [feedback is welcome on that, too!] and added support for that RR 
> type to the OpenSER SIP proxy.
>
...