Subject: [Enum] ENUM Next Generation

From: Patrik Fältström <[email-masked]>
Date: Sun, 9 Jul 2006 07:19:33 -0400

In paris I floated some ideas with some people, including non-enum  
people, DNS people etc.

This idea tries to solve two problems:

(1) When looking for URIs with ENUM today we use NAPTR records that  
imply one get back a very large resource record set. When signing  
this with DNSSEC, the size of the set will grow even more. This even  
though we when issuing the query already know what service field(s)  
we are interested in.

(2) In infrastructure ENUM, I think one of the requirements that  
weighs in the heaviest is the ability for the service provider of the  
service the URI refer to can edit the zone where the record is stored  
that holds the URI.

I have also walked through the issues people have created tickets for  
(and you will see the list at the ENUM meeting this week), and see  
that many are related to NAPTR resolution, which in turn is connected  
to (2) above.

To understand some of the thinking behind this proposal, it might be  
interesting to read draft-iab-dns-choices-03.txt that I am the editor  
of.

If I could turn the clock back to 1997 when I started looking at what  
ended up being ENUM, I think I would have designed it a little bit  
different. Not much. And the question is whether we can do anything  
about it.

If you look at how NAPTR was defined from the beginning, it was in  
"cooperation" with the SRV record. The NAPTR and SRV solve two  
different things:

- NAPTR is used when you want to know what services exists for a domain.
- SRV is used when you know the service and domain and want to know  
more.

With ENUM we try to do both with the NAPTR alone.

An architecturally better solution would be to do something more  
similar to the NAPTR+SRV thing. The NAPTR list what services exists,  
and the SRV give back detailed data. Issue is of course that the SRV  
RR Type today give back only hostname and port number part from the  
weight and order, and what we need is a full URI.

What if we create a new RR Type that give back a URI?

Example 1 (not completely good, but read on to example 2):

Look for information about +46-8-1234.

Look up NAPTR for 4.3.2.1.8.6.4.e164.arpa.

Result might be (where "f" is a new random flag):

"E2U+sip"  "f" _sip._enum.4.3.2.1.8.6.4.sipprovider.net.
"E2U+smtp" "f" _sip._enum.4.3.2.1.8.6.4.emailprovider.net.

Then we issue a 2nd query depending on what we are looking for either  
of these two:

_sip._enum.4.3.2.1.8.6.4.sipprovider.net. IN URI "sip: 
[email-masked]"

_sip._enum.4.3.2.1.8.6.4.emailprovider.net. IN URI "mailto: 
[email-masked]"

This of course does not create any ability to directly query for the  
URI resource record type if we only know the E.164, and on top of  
this, it is not backward compatible with user ENUM.

Example 2:

Look for information about +46-8-1234.

Look up NAPTR for 4.3.2.1.8.6.4.e164.arpa.

Result might be:

"E2U+sip"  "u" "!.*!sip:[email-masked]!"
"E2U+smtp" "u" "!.*!mailto:[email-masked]!"

Then we issue a 2nd query depending on what we are looking for either  
of these two:

_sip._enum.4.3.2.1.8.6.4.e164.arpa. IN URI "sip:[email-masked]"

_smtp._enum.4.3.2.1.8.6.4.emailprovider.net. IN URI "mailto: 
[email-masked]"

Note what we do in the 2nd case. We keep the NAPTR as defined, but we  
also create the new URI records that are in subdomains of the zone  
where the user ENUM records are stored. The name of the subdomains  
are the service fields in the _enum subdomain.

That way, we can say that if you know what service field you are  
interested in, you can query directly for the URI resource record  
type. You get smaller RR Sets, and (a good thing for infrastructure  
ENUM I think) it is possible to do delegations from the zone that is  
today User ENUM to the service providers. I.e. if the zone for the E. 
164 is held by a neutral party (just like the parent zone(s)), the  
delegation for the tel service field can be made to the carrier of  
record for the E.164 number. It is also possible to, in a similar  
way, delegate the email service field to the email service provider.  
Infrastructure ENUM can then be "first query for the URI record for  
the E.164, and if that fails, fall back to query for the NAPTR to see  
what other services exists".

Now, what do you say?

Should "RFC 3761 bis" include something like this and try to solve  
infrastructure ENUM and user enum at the same time?

For how long do we have to store the URIs in the NAPTR?

     Patrik

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Bernie Hoeneisen <[email-masked]>
Date: Sun, 9 Jul 2006 16:53:43 +0200 (CEST)

Hi Patrik

Interesting ideas...
Comments inline.

On Sun, 9 Jul 2006, Patrik Fältström wrote:

> Then we issue a 2nd query depending on what we are looking for either of 
> these two:
>
> _smtp._enum.4.3.2.1.8.6.4.emailprovider.net. IN URI "mailto:[email-masked]"

could it be that this example (smtp) contains a typo?
I would rather expect:

_smtp._enum.4.3.2.1.8.6.4.e164.arpa. IN URI "mailto:[email-masked]"

Or did I miss anything?

> and (a good thing for infrastructure ENUM I think) it is possible to 
> do delegations from the zone that is today User ENUM to the service 
> providers. I.e. if the zone for the E.164 is held by a neutral party (just 
> like the parent zone(s)), the delegation for the tel service field can be 
> made to the carrier of record for the E.164 number.

Hmmm, this would involve, that the Tier-1 Registry (or some other 
trusted party) needs to maintain the U-ENUM Zones, to ensure correct 
delegations to the I-ENUM entries.
Carriers put stronger requirements to (DNS) answering times and timeouts, 
as the call-setup time is crucial. Therefore no way, that a user can 
operate his own nameservers.
You could also not leave the U-ENUM zone maintainance to the carrier, as 
this might be misused to hinder or control (in a negative sense) the 
U-ENUM deployment.
Anyways, IMHO this is not backward compatible to nowadays ENUM deployment.

Furthermore this would also kind of mandate RFC 4114, Dynamic DNS updates 
or some other (possibly new) interface to change the content of the U-ENUM Zones.

> Now, what do you say?

I like the idea to keep the zones small (packet size/EDNS0 discussions), 
but I am not sure, whether this is a good way to combine U-ENUM and 
I-ENUM.

BTW: Could your idea have impact on block delegations or open numbering 
plans? I haven't studied that through yet.

cheers,
  Bernie

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 9 Jul 2006 11:27:20 -0400

On 9 jul 2006, at 10.53, Bernie Hoeneisen wrote:

>> Then we issue a 2nd query depending on what we are looking for  
>> either of these two:
>>

You are correct. This was a typo.

>> and (a good thing for infrastructure ENUM I think) it is possible  
>> to do delegations from the zone that is today User ENUM to the  
>> service providers. I.e. if the zone for the E.164 is held by a  
>> neutral party (just like the parent zone(s)), the delegation for  
>> the tel service field can be made to the carrier of record for the  
>> E.164 number.
>
> trusted party) needs to maintain the U-ENUM Zones, to ensure  
> correct delegations to the I-ENUM entries.

Yes.

> Carriers put stronger requirements to (DNS) answering times and  
> timeouts, as the call-setup time is crucial.

This is what they claim. Have you tried to set up a phone call across  
the globe to see what the call setup time in reality is, or for that  
matter a GSM call? If you get lower time than 5 seconds you are lucky.

> Therefore no way, that a user can operate his own nameservers.

Why not? And by the way, I do not see these operational constraints  
be a problem that have anything to do with the design of the  
protocol, so I want to leave those things out.

> You could also not leave the U-ENUM zone maintainance to the  
> carrier, as this might be misused to hinder or control (in a  
> negative sense) the U-ENUM deployment.

It could be left with whoever is "an approved ENUM zone maintainer".  
Remember that in more and more TLDs you have to be "an approved DNS  
provider" to have NS records point to you. I do not think that is a  
good path the DNS community is on, but it is happening.

> Anyways, IMHO this is not backward compatible to nowadays ENUM  

Why not?

> Furthermore this would also kind of mandate RFC 4114, Dynamic DNS  
> updates or some other (possibly new) interface to change the  
> content of the U-ENUM Zones.

How the zones are changed is up to the zone maintainer. But yes,  
dynamic update might be one way of doing it, even though with normal  
implementations of dynamic update you can only manage the  
authentication and authorization on the triple class, type, owner,  
which imply whoever can change one NAPTR will be able to change all  
of them.

This is why I think storing the NAPTR the way we do today in User  
ENUM is possibly a bad idea. Better to move to what I hear call "Next  
Generation ENUM" that can support both infrastructure ENUM and User  
ENUM (and on top of this infrastructure ENUM for any service and not  
only the telephony.

>> Now, what do you say?
>
> I like the idea to keep the zones small (packet size/EDNS0  
> discussions), but I am not sure, whether this is a good way to  
> combine U-ENUM and I-ENUM.

Ok. Good point.

> BTW: Could your idea have impact on block delegations or open  
> numbering plans? I haven't studied that through yet.

Possibly. I have not thought so much about it (yet). What I am  
removing is the ability to have regular expressions and rewrites in  
the URI record, and this is possibly something that is used by some  
people.

    Patrik

---

From: Bernie Hoeneisen <[email-masked]>
Date: Sun, 9 Jul 2006 18:18:04 +0200 (CEST)

Hi Patrik

>> Therefore no way, that a user can operate his own nameservers.

As said, the maintainer of the ENUM zone must be a trusted party with this 
approach, cause the maintainer of the DNS zone also affects the carrier's 
operations (e.g. in case of misconfigurations). He has to ensure that the 
NS records pointing the the I-ENUM zones are correct at any time and 
guarantee a high level of q.o.s. Looking at nameserver setups made by the 
(end)users themselves (as we see such occasionally at customers of the 
.ch/.li and the 1.4.e164.arpa Registry) do not give me a lot of 
confidence that carrier requirements would be fulfilled in every case.

> And by the way, I do not see these operational constraints be a 
> problem that have anything to do with the design of the protocol, so I want 
> to leave those things out.

I am not sure, whether those can be left out completely.

>> Anyways, IMHO this is not backward compatible to nowadays ENUM deployment.

Maybe I should have been more precise here. Technically it probabely is 
backward compatible. I was thinking more about administrative and 
provisioning issues resulting from the fact, that the choice of namesevers 
would be limited with this approach.

cheers,
  Bernie