Subject: [e2md] alt-CNAM: What's wrong with _displayname prefixed TXT records?

From: Dean Willis <[email-masked]>
Date: Thu, 25 Mar 2010 15:50:50 -0500

The ID draft-ietf-enum-cnam-08 describes an approach for associating
display names (aka "calling names") with phone numbers in the e164.arpa
tree using ENUM-style NAPTR records. For reasons discussed in
yesterday's BOF, this approach is seen by many as a not-quite-right
approach.

If ENUM is used for phone-number-to-URI mapping, then the same structure
is very attractive for distributing the display names associated with
those phone numbers. It's really too close a match to justify building
some sort of external directory structure.

But NAPTR as used in draft-ietf-enum-cnam-08 isn't quite the right
approach for processing a display name.

Alternatives include 1) using a new RR type, and 2) re-using an existing
 type.

RFC 5507 gives us guidance on extension methods, and generally
recommends a new Resource Record type. But it's worth looking at reuse
of an existing RR type.  The closest existing type is obviously TXT,
which has its problems but is worth looking at for this application.

What would be wrong with, for cases in which the calling name does NOT
require authorized access, putting it in the e164.arpa tree with an
_displayname prefix and a TXT record?

Example:

_displayname.0.9.1.9.9.1.5.2.7.9.1.e14.arpa. IN TXT "Dean Willis"

YES, I KNOW RFC 5507 and the DNS community frown on text records. But
let's go through the logic here, please ...

The _displayname key lets us know "what the TXT means", which is the
eternal problem with TXT records. It also makes a query for the display
name very easy: if you get a phone call and need to ask for the display
name associated with the source phone number, form a DNS query by
inverting the phone number, adding the "_displayname" prefix and
appending the 'e164.arpa" domain, and make a TXT query. The value of the
TXT record is the display name string; there is no need to parse it.

Let's talk through the rationale in RFC 5507 against both _prefix and
TXT usages.

1) _prefix approaches do not work well with wildcards. This doesn't
appear to be a problem for "calling name", as the use case requires a
terminal fully-specified phone number for looking up the calling name.

2) TXT records have no inherent format or semantic, and attempts to
dictate parsing rules are just silly. That doesn't seem to be a problem
for the "calling name" use case; all we want is a human-readable display
string. It has no inherent semantics, is not parsed by the application,
and one can't "break" the intended application by putting something
unexpected into the TXT record value.

3) Having the data in a TXT record, as opposed to a new RR type, makes
it a lot easier for standard tools like "dig" and "nslookup" to display
the data. And since the data has no semantic encoding -- it's just a
display string -- the result from "dig" is perfectly human-readable.

Comparison of this approach to a new RR

If we have a use case for wild-carded display names, then a new RR would
obviously become a better choice.

The standardization effort for _displayname and TXT seems to be lesser.
However, there's no registry for _prefix usages. There is an ID for
creating a registry of _prefixes for SRV records:

	draft-gudmundsson-dns-srv-iana-registry-04

Doing this approach cleanly for displayname arguably requires creating a
registry for _prefix names on TXT records, which is arguably as hard as
defining a new RR type would be, and probably politically more difficult.

On the other hand, the number of RR extension types available is not
unlimited. Is it worth defining a new type that's probably only useful
in the e164.arpa tree?

--
Dean Willis

--
dean

---

From: Jay Daley <[email-masked]>
Date: Fri, 26 Mar 2010 09:59:34 +1300

> _displayname prefix and a TXT record?

Because, as has been explained about a bazillion times, we want a *single lookup for NAPTR records under the e164 domain* (whether of caller or receiver), to then provide all the URIs and metadata for a single processing step.

Jay

> _______________________________________________
> e2md mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/e2md

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 25 Mar 2010 21:10:21 +0000

Hi Dean,
 At the risk of causing Richard to have a conniption, if you *really*
want a new TXT-like RR type, there is one already. Type 56  -- NINFO.

Jim will know whether something that describes Zone Status could be
stretched to cover the person who owns it, but ...

However, did you not see the comments that there are other things to
look at in this case?

all the best,
  Lawrence

---

From: Dean Willis <[email-masked]>
Date: Thu, 25 Mar 2010 16:13:17 -0500

Jay Daley wrote:
> Because, as has been explained about a bazillion times, we want a
> *single lookup for NAPTR records under the e164 domain* (whether of
> caller or receiver), to then provide all the URIs and metadata for a
> single processing step.

As has been asked about a bazillion times:  Why do you want the display
name to come back along with all the NAPTR records in one RR set?

We have two use case families:

1) Things one queries when setting up a call. The display name is not
needed when setting up call, and just wastes space in the response.

2) Things queried when one gets a call. So far, that set is small: just
the display name. All of the other cruft in the NAPTR records is
un-needed at this point, and just wastes space in the response.

We were asked many times yesterday: The display name is never, ever used
in routing the call. Why does it belong in the NAPTR set?

Do you have a better answer to that question than "because NAPTR is the
hammer I have handy?" If so, please clue me in!

--
Dean

---

From: Jim Reid <[email-masked]>
Date: Thu, 25 Mar 2010 21:16:37 +0000

> _displayname prefix and a TXT record?

Because there's no way of knowing what other TXT records might exist  
at that node and which, if any, of them contain the information that's  
of interest. TXT records get used for all sorts of crap: version  
control info, contact details for the DNS administrator, anti-spam  
things, etc, etc. This was why I got a typecode for NINFO, which is  
really a TXT record disguised as a simple presence indicator. A  
discrete typecode was needed to isolate that presumably useful info  
from whatever garbage people were shoving into TXT records.

Another reason for not adding another RRtype and/or QNAME is to avoid  
having to make another DNS lookup. If a single query can return  
everything of interest.... I thought we'd been over this already.

> There is an ID for creating a registry of _prefixes for SRV records

That's because those prefixes denote things like application- and  
transport-level protocols. The underscores are syntactic sugar so the  
names of SRV records can't be confused with hostnames.

---

From: Dean Willis <[email-masked]>
Date: Thu, 25 Mar 2010 16:17:20 -0500

> want a new TXT-like RR type, there is one already. Type 56  -- NINFO.

okay, that's interesting.

> However, did you not see the comments that there are other things to

Okay, but that still leaves us with "the set of things to look up when
placing a call" and "the set of things to look up when answering a call".

Is there any commonality, or are these really completely disjoint
spaces? Because they currently appear to be disjoint, and that's a large
part of why some people are pushing back. Other people have other
reasons, of course.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 25 Mar 2010 17:19:12 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jay Daley
> Sent: Thursday, March 25, 2010 5:00 PM
> To: Dean Willis
> 
> Because, as has been explained about a bazillion times, we want a *single
> lookup for NAPTR records under the e164 domain* (whether of caller or
> receiver), to then provide all the URIs and metadata for a single
> processing step.

That's not really possible with cnam, if you really mean one step.  When you look up the cnam, the key you're using for the lookup is the calling number, but when you do a lookup for every other service type defined so far, the key being used is the called number.  

In that context, it's actually more efficient to only get back the cnam entry when doing the calling-party query, instead of getting all of that number's other NAPTRs.

Unless you mean in the context of doing any/all source calling number lookups, because you have other reasons to do calling-party lookups, for either some anti-source-spoofing security check or for some as-yet-to-be-defined reasons.  I suppose we could just say use a "_src" name prefix, so it would be "_src.5.5.5.2.1.2.1.e164.arpa", and it would have a E2CNAM or E2M+cname entry plus possibly other entries.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Thu, 25 Mar 2010 16:28:54 -0500

Jim Reid wrote:
> Because there's no way of knowing what other TXT records might exist at
> that node and which, if any, of them contain the information that's of
> interest. TXT records get used for all sorts of crap: version control
> info, contact details for the DNS administrator, anti-spam things, etc,
> etc. This was why I got a typecode for NINFO, which is really a TXT
> record disguised as a simple presence indicator. A discrete typecode was
> needed to isolate that presumably useful info from whatever garbage
> people were shoving into TXT records.

The "_displayname" prefix gives us a unique node, does it not?
> everything of interest.... I thought we'd been over this already.

If "everything of interest" becomes a set of 50 records or so (and we
had a least one guy say he had use cases for 50 different bits of
metadata) then we havea real oroblem with that approach, right?
> names of SRV records can't be confused with hostnames.

Yes, and the same applies to the _ in the example I proposed.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 25 Mar 2010 18:07:29 -0400

There are a couple of rally good reasons to keep cnam a "different" lookup from destination/called-party lookups:
	1) From a performance and message size perspective, it's better to only get back what you want - and cnam is one of the rare cases where it's the only thing you want back for that query key.
	2) For some "ENUM Servers", the DNS query makes them do a TCAP query/dip behind-the-scenes.  Cnam lookups are not free, so you really want the ENUM server to know you want a cnam result when you do a DNS query.

There are only so many ways to make the query be explicit: ask for a specific RR type, which requires a new RR for cnam, or ask with a different key. (or ask a different server or port I guess)

-hadriel

> Sent: Thursday, March 25, 2010 5:17 PM
> To: Lawrence Conroy
> Cc: E.164 To MetaData BOF discussion list; [email-masked]
> Subject: Re: [e2md] alt-CNAM: What's wrong with _displayname prefixed TXT
> records?
> 
> Lawrence Conroy wrote:
> > Hi Dean,

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 26 Mar 2010 07:31:23 +0100

Dean,

> terminal fully-specified phone number for looking up the calling name.

Yes, the calling number is always a specific string of digits.

In Germany and Austria with their open dialing plans the carrier only knows
to which customer the base number is associated with. The carrier does not
know which extension do exist and what length they are.

So unless the carrier delegates the ENUM space to the customer, the carrier
has to work with wildcards for cnam in these cases.

Prefixes just do not work with open numbering plans.

otmar
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 //

---

From: Dean Willis <[email-masked]>
Date: Fri, 26 Mar 2010 11:17:47 -0500

> Prefixes just do not work with open numbering plans.

Okay, that wraps that approach up.

That leaves "some other resource record" -- either a new one, or some
other existing record that doesn't normally appear alongside a phone
number in the tree so we "knoww" it's for calling name, or that has a
subtype field inside it like NAPTR.

Assuming we don't use NAPTR because we want the calling-name queries to
happen independently of the routing queries, how about NINFO?

--
Dean