Subject: [e2md] What the IETF does and does not do

From: Cullen Jennings <[email-masked]>
Date: Wed, 17 Mar 2010 18:37:53 -0600

Typically the IETF attempts to produce protocols that have reasonable privacy and security characteristics (See BCP 61). For the most part, the IETF does protocols that are applicable to the "Internet"  but there are some notable exceptions - for example DHCP.

Charters are one of the things that define what the IETF is doing and also what is out of scope for any WG to do. Regardless of what we have done with ENUM, DNS, and others in the past, part of the purpose of this BOF would be to see if we can get consensus on what we want to do in the future. I would be surprised to see people willing to just ignore any privacy issues. It seems the two leading proposal for dealing with the privacy issues could roughly be categorized as 1) don't put private things in DNS or 2) don't allow the DNS out of a private space. Both of these have pros/cons. I was hopping some useful discussion of these, or discussion of other alternatives, might be one of the things that comes out of the BOF.

Cullen <RAI AD>

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Mar 2010 02:32:18 -0500

On Mar 17, 2010, at 7:37 PM, Cullen Jennings wrote:

>  I was hopping some useful discussion of these, or discussion of  
> other alternatives, might be one of the things that comes out of the  
> BOF.
>

Other alternatives I have heard so far include:

1) Encrypting the metadata; it's in the public DNS, but not  
compromised as reading it takes a key. Key management is the issue.

2) Putting an HTTP link to the metadata into the DNS instead of the  
raw metadata. The web server can then do conventional web-AAA checks  
to decide what to return. This has the added advantage of allowing  
different results to be returned based on aspects of the requestor,  
such as identity, location, etc. This might also work for Daryl's  
egress routing scenario.

For example: cnam=https://meta.example.com/cnam/+19725199190

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 18 Mar 2010 08:29:24 -0600

On Mar 18, 2010, at 1:32 AM, Dean Willis wrote:

> 2) Putting an HTTP link to the metadata into the DNS instead of the raw metadata. The web server can then do conventional web-AAA checks to decide what to return. This has the added advantage of allowing different results to be returned based on aspects of the requestor, such as identity, location, etc. This might also work for Daryl's egress routing scenario.
> 

Speaking of such things, one person asked me, why use DNS at all. Why not just do a HTTPS lookup like

https://meta.example.com/+19725199190/cnam 

I realized I could not really answer that question. 

Cullen

---

From: [email-masked]
Date: Thu, 18 Mar 2010 14:40:40 +0000

> I realized I could not really answer that question. 

For a start:

1.  it's not hierarchical

   - hence there's no way to divide responsibility

2.  it's slower than DNS

   - although that's obviously still a problem if you 
     use E2MD -> HTTP redirection

3.  using DNS allows E2MD results to be delivered "for free"
    at the same time as E2U lookups.

Ray

---

From: Jim Reid <[email-masked]>
Date: Thu, 18 Mar 2010 14:45:39 +0000

> https://meta.example.com/+19725199190/cnam

Because the overhead of setting up a TCP connection, then doing SSL  
authentication over it will always lose to a DNS query-response over  
UCP. It's not just the extra packets and latency -- a big deal in  
things like 3G networks where users get to pay by the packet -- but  
the impact on the web servers, SBCs or whatever that would get  
bombarded with bazillions of presumably short-lived TCP connections.

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 18 Mar 2010 11:16:08 -0400

And the vendors wont put new stacks in the proxy/softswitches.  SIP and ENUM
are there, they work, proven and scalable. Modifications to existing
implementations are minimal.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim
Reid
Sent: Thursday, March 18, 2010 10:46 AM
To: Cullen Jennings
Cc: [email-masked]
Subject: [e2md] HTTPS as an alterative to DNS lookup

Because the overhead of setting up a TCP connection, then doing SSL  
authentication over it will always lose to a DNS query-response over  
UCP. It's not just the extra packets and latency -- a big deal in  
things like 3G networks where users get to pay by the packet -- but  
the impact on the web servers, SBCs or whatever that would get  
bombarded with bazillions of presumably short-lived TCP connections.
_______________________________________________
e2md mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/e2md

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Mar 2010 10:20:52 -0500

> I realized I could not really answer that question. 

1) Some of the metadata works really nicely for the cached-distribution
model of the DNS.

2) we have a way to discover the local DNS server -- DHCP.

3) a centralized root HTTP would be overloaded, so some sort of
distributed model is required. We could use anycast to find a server,
but would still need a method for selectively propagating the data to
that server. DNS already has this, called "recursive query". Yes, we
could reinvent this using HTTP, at which point we are well on our way to
making a new DNS based on HTTP. This might be a good idea, but it
requires a different sort of buy-in.

4) The DNS model is really handy in a closed environment; change the
data in the root server, and all the secondaries and caches get updated
hands-free. This leads people to want to use the DNS for distributing
local-knowledge data like egress SIP routes even though these data do
not fit well into the public DNS topology.

As a consequence of these properties combined with the fact that we are
already using the DNS to answer the question "What is the SIP URI for
this phone number?", the DNS appears to be well situated to answer 
"What (or where) are the metadata for this phone number?"

The DNS appears to be much less well-suited (although in some cases
useful) for answering locally-specific questions, like "What is the
optimum route for me to use in order to reach this phone number?", as
such queries require a selective-response capability that the DNS does
not, in general, provide and which can be synthesized  operationally
only  in very restricted  environments. It does appear that a hybrid
model, DNS->HTTP->metadata, could increase the range of cases wherein
the system could selectively respond based on characteristics of the
requester.

--
dean

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 18 Mar 2010 11:21:48 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
Willis
Sent: Thursday, March 18, 2010 3:32 AM
To: Cullen Jennings
Cc: [email-masked]
Subject: Re: [e2md] What the IETF does and does not do

RS>  If people want to encrypt things that's fine put but in private
deployments in the field the encryption is usually at Layer 2 or so . IP sec
between network elements.

>RS There is nothing wrong with this but it cant be a requirement to use.

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Mar 2010 10:30:47 -0500

> bombarded with bazillions of presumably short-lived TCP connections.
Why not have a long-lived HTTP connection to your nameserver(s), which
maintains long-lived connections back upstream for recursion and
shorter-lived connections to peers? Yes, it is a rewrite of DNS. Is that
bad?

--
dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Mar 2010 10:36:34 -0500

> between network elements.
That's fine for private deployments, but the DNS is a fairly public sort
of thing. How do we solve privacy problems on the Internet?

And no, DNSSEC is not an answer here.
>> RS There is nothing wrong with this but it cant be a requirement to use.

I'd see it as a fair alternative to saying "you can't put that metadata
into the public DNS", so public or mixed-use DNS environments could well
require a mechanism like that for sensitive metadata.

--
Dean

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 18 Mar 2010 11:53:36 -0400

RS> NO IMHO it just wont deploy.

---

From: Jim Reid <[email-masked]>
Date: Thu, 18 Mar 2010 15:53:48 +0000

On 18 Mar 2010, at 15:30, Dean Willis wrote:

> shorter-lived connections to peers?

I'm not sure I understand you. Why would this hypothetical HTTP- 
capable name server need to maintain a long-lived connection to an  
upstream resolver? Surely it would resolve things for itself? And what  
do you mean by a connection to a peer? What would this HTTP-capable  
name server be connecting to and why?

> Yes, it is a rewrite of DNS. Is that bad?

Yes. Very bad. Very, very bad. DNS is too deeply embedded in the guts  
of the Internet to undergo a radical rewrite or the mother of all flag  
days. And anyway long-lived connections are not going to work  
particularly well for devices which move around the network by design.

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 18 Mar 2010 11:57:03 -0400

RS> you could do it in ENUM if Hadriel Kaplan's source URI draft were
adopted.  So Hadriel what is the status of that draft? :-)

---

From: Jim Reid <[email-masked]>
Date: Thu, 18 Mar 2010 15:57:55 +0000

> of thing. How do we solve privacy problems on the Internet?

That's like asking how do we solve world hunger. It's out of scope for  
this list/WG.

It is possible to safely publish private data in the public DNS.  
Public key crypto is being used in .tel to encrypt NAPTRs as data URIs.

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 18 Mar 2010 12:00:21 -0400

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Thursday, March 18, 2010 11:37 AM
To: Richard Shockey
Cc: 'Cullen Jennings'; [email-masked]
Subject: Re: [e2md] What the IETF does and does not do

RS> RATHOLE ALERT RATHOLE ALERT RATHOLE ALERT  :-)  How do we solve privacy
problems on the Internet...humm just think about that for a moment. :-) 

Rs I'd rather say .."you really sholdn't put that data in the public DNS" or
a bunch of guys in dark suits and big Chevrolet Suburbans are going to come
and get you. 

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Mar 2010 14:29:25 -0500

> RS> NO IMHO it just wont deploy.

That's what everybody said about TCP based presence and IM systems, and
they seem to work pretty well.

--
Dean

---

From: Jay Daley <[email-masked]>
Date: Fri, 19 Mar 2010 08:35:24 +1300

> they seem to work pretty well.

That is completely and utterly different! 

Of all the protocols out there DNS is probably the most scrutinised, the one where changes get the most input and the most carefully changed.  You can't just suggest a rewrite of DNS on a whim and expect to be taken seriously. 

Jay 

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

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Mar 2010 14:45:50 -0500

Jim Reid wrote:
> I'm not sure I understand you. Why would this hypothetical HTTP-capable
> name server need to maintain a long-lived connection to an upstream
> resolver? Surely it would resolve things for itself? And what do you
> mean by a connection to a peer? What would this HTTP-capable name server
> be connecting to and why?

A name server can only resolve things for itself that it is either
authoritative for (primary or secondary) or that has cached. It has to
go upstream occasionally. For example, the NS for subdoomain
"research.softarmor.com" frequently talks to the NS for domain
"softarmor.com". Why wouldn't a long-lived connection work here?

Similarly, once "research.softarmor.com" has used "softarmor.com" to
find "marketing.softarmor.com", it may well connect directly to
"marketing.softarmor.com" to find the IP address for URI
"sip:[email-masked]". My guess is that it "research"
talks to "marketing" fairly frequently (or at least their name servers
do). Why wouldn't an HTTP connection work here?

Another way to model this is a straight-up port of current DNS, with
zone transfers being simple HTTP GET requests on the zone files, etc.
wherein the HTTP layer is tuned to hold up the TCP connection "as long
as reasonable", for which there are several evident mechanisms.

> Yes. Very bad. Very, very bad. DNS is too deeply embedded in the guts of
> the Internet to undergo a radical rewrite or the mother of all flag

ENUM and metadata aren't all that entrenched. And the hacks that we keep
making with longer and longer resource records, along with other hacks
to return requester-specific data, etc. are going to give those guts a
bad case of indigestion if we're not careful.

Also, there's no reason a migration to HTTP couldn't happen in a
backward-compatible manner. It would be pretty straightforward to build
a server that works in both modes, and then use a modifier at the NS
level to indicate support for the new protocol at the server. New
protocol systems would talk to new protocol systems using the new
protocol, and everybody else would use the crufty old DNS we know and love.

Although once again: this would be outside the scope of E2MD, which is
still the fundamental answer to Cullen's question if the "we involved is
E2MD.

--
Dean

--
dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Mar 2010 14:55:49 -0500

> That's like asking how do we solve world hunger. It's out of scope for

Okay, I'll restate.

How do WE (the E2MD group) solve privacy problems for the metadata we're
proposing to shove into the DNS, when that DNS is used on the Internet?

> 
> It is possible to safely publish private data in the public DNS. Public
> key crypto is being used in .tel to encrypt NAPTRs as data URIs.
> 

Excellent! That's an answer to the question "how do we solve privacy
problems for dns-delivered metadata on the Internet. Is this answer (or
something like it for metadata that is not a URI) acceptable for
consideration in the E2MD process, or are we just going to say "if there
is sensitive data in your records, just use a private network and for
your private DNS, and don't blame us if it leaks"

Look, I'm not trying to be obtuse and say we can't solve the problem and
therefore must not even try. There are several potential solutions. I'm
saying we have to RECOGNIZE that there is a problem (step 1 of 12,
right?), see if we can agree what that problem generally is, and plan to
come up with a problem statement along with one or more solutions in
that problem space. I don't even want a final solution now (unless one
is blindingly obvious) -- I just want people to understand that this is
part of the problem that we need to work on, and to commit to doing that
work if the WG is approved.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Mar 2010 15:03:40 -0500

> problems on the Internet...humm just think about that for a moment. :-) 

C'mon Richard. You know that we were talking about the privacy of ENUM
metadata, not solving the Internet's privacy problem as a hole.  That's
a cheap shot, so I think you owe me a not-so-cheap shot from the hotel bar!

> a bunch of guys in dark suits and big Chevrolet Suburbans are going to come

Ok, that's a possible answer, too. It does raise the question of why the
IETF is standardizing data that can't be put on the Internet, but at
least it recognizes the problem.

It does leave the question "What advice do we give to people about
deciding which data should and should not be put unprotected on the real
Internet". And it leaves the question of where to record that advice, as
well as who records it. I'm thinking that the advice is important, and
that the proposed WG needs to decide what advice to give and needs to
document that advice in an RFC as part of our work product.

--
dean

---

From: Jay Daley <[email-masked]>
Date: Fri, 19 Mar 2010 09:05:02 +1300

On 18/03/2010, at 1:37 PM, Cullen Jennings wrote:

> Charters are one of the things that define what the IETF is doing and also what is out of scope for any WG to do. Regardless of what we have done with ENUM, DNS, and others in the past, part of the purpose of this BOF would be to see if we can get consensus on what we want to do in the future. I would be surprised to see people willing to just ignore any privacy issues. It seems the two leading proposal for dealing with the privacy issues could roughly be categorized as 1) don't put private things in DNS or 2) don't allow the DNS out of a private space.

That hasn't captured it at all.  The various views are:

1.  Putting private data in DNS automatically means it cannot go into a public tree making this a private protocol and therefore out of scope for the IETF.

2.  There are mechanisms to obscure private data that could be used such as encryption or indirection.

3.  The data we are talking about may or may not be private that depends on the legal status of the subscriber and the laws of local jurisdictions not on the data per se and so the protocol should allow that differentiation to be flagged in the data but leave the appropriateness of publishing what might be classed as private data to the local jurisdiction.

4.  The privacy issues faced by e2md are entirely the same as ENUM and so can simply pull over the wording and reasoning from there.

5.  The privacy issues faced by e2md are qualitatively different from ENUM because of the nature of the data.

> Both of these have pros/cons. I was hopping some useful discussion of these, or discussion of other alternatives, might be one of the things that comes out of the BOF.

I would suggest that a logical path needs to be worked through rather than the "statement of belief" tennis we are currently engaged in.  My suggestion is:

Q1.  Is the nature of the data proposed for e2md different from the data in ENUM such that it should have different privacy considerations?

If the answer is no then we can just pull over the wording and reasoning from ENUM (p1), if it is yes then we move onto question 2.

Q2.  Is the data always private or is that down to externalities to the protocol, such as the legal status of a subscriber?

If the answer is always private then it implies we *must* have mechanisms to obscure data that *must* be used otherwise this becomes a private protocol (p2).  

If the answer is that externalities determine what is private then we move onto question 3.

Q3.  Is it sufficient that the protocol acknowledges that the result of privacy protection for certain subscribers is the omission of their data (and that it flags that as the reason) or should we provide an obscuring mechanism to allow that data to be included?

If the answer is that omission is sufficient then the scope stops there (p3).  If we should accommodate publication of the data in an obscured way then we will get to the scope that includes that (p4).

My personal view is that we should be at p1 but I can live with getting to p4 as a compromise.

regards
Jay

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Mar 2010 15:22:56 -0500

This is excellent work!

Jay Daley wrote:
> Q1.  Is the nature of the data proposed for e2md different from the
> data in ENUM such that it should have different privacy
> considerations?
> 
> If the answer is no then we can just pull over the wording and
> reasoning from ENUM (p1), if it is yes then we move onto question 2.
> 

I believe the answer is "yes", at least for some of the metadata. For
example, putting the calling name for my unlisted phone number into the
DNS is clearly a different thing than is listing the SIP URI at which I
prefer those calls to be routed by.

> Q2.  Is the data always private or is that down to externalities to
> the protocol, such as the legal status of a subscriber?

Excellent question; one might reasonably include externalities that
relate not to the subscriber, but the consumer of the metadata.

I believe that not all metadata is always private. Some might be always
private, but certain elements such as "unused" are clearly interesting
at a public scale.

And there IS a big furball around status of the subscriber. For example,
many legal domains restrict information about minors.

> 
> If the answer is always private then it implies we *must* have
> mechanisms to obscure data that *must* be used otherwise this becomes
> a private protocol (p2).
> 
> Q3.  Is it sufficient that the protocol acknowledges that the result
> of privacy protection for certain subscribers is the omission of
> their data (and that it flags that as the reason) or should we
> provide an obscuring mechanism to allow that data to be included?

We may also need to address privacy protection affecting certain
consumers of the data rather than the subscriber. For example, one might
wish to obscure parts of metadata across one peering relationship, but
not another. Or an operator might consider part of the metadata private
with respect to the general public, but authorize access to that same
part for diagnostic and law enforcement purposes.

But please, please do not let me turn this into a repeat of the
redistribution-allowed fight in GEOPRIV.

--
dean

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 18 Mar 2010 14:56:27 -0600

Thanks Ray, 

So just to make sure I am understanding the deployments correctly for the E2MD data, the hierarchal is important because in the practical deployments will have a bunch of different administrative domains that are responsible for metadata for different numbers.

>     at the same time as E2U lookups. 

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 18 Mar 2010 14:56:36 -0600

Thanks Jim

So making sure I understand the requirement here ... we need to be able to lookup the metadata from an end users phone or terminal? Clearly if we it was only needed from the call agents or SBC in the middle of the network, long lived connections would work fine. (I realize we also need to be able to make metadata queries from the call agents, SBC, etc. ) Do I have the right understanding here?

On Mar 18, 2010, at 8:45 AM, Jim Reid wrote:

> Because the overhead of setting up a TCP connection, then doing SSL authentication over it will always lose to a DNS query-response over UCP. It's not just the extra packets and latency -- a big deal in things like 3G networks where users get to pay by the packet -- but the impact on the web servers, SBCs or whatever that would get bombarded with bazillions of presumably short-lived TCP connections.

Cullen Jennings

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 18 Mar 2010 20:58:41 +0000

Hi again Dean, Jim, folks,
 Apart from the traditionally mistaken dig at ENUM, what is this about?
<flame on>
I get this impression this is WAAAAAAAY too unfocussed for what should
be a "small bite". I expect to see implementations of what was proposed
in the charter out the door by the end of this year.

This stuff is a very close fit to DNS usage patterns. Data doesn't change
often, it's a huge database with distributed control, and it needs the
performance that would p**s all over any secure web set up. No surprise
that this stuff is intending to use DNS (and steal all the work already
done on ENUM). All very focussed.

Dean, Cullen, I get that you believe there are security issues. I also
get everyone else saying that they know there are security issues with
every piece of sensitive data placed into DNS (or anywhere else on the
Interwebs).
I expect them to do as they have already said they will, and note this
in big friendly letters on the front cover of each document. Just like
we all did in ENUM.

Any more than that is Country-specific PII/DP **POLICY**, and doing
anything more than a general advisory to not put your current location
in your domain (or the front page of facebook) is not the IETF's job.
ENUM did all it could in that direction, and I see no signs that
E2MD has succumbed to the Web 2.0 view of privacy. I suspect that
implied accusation is what rankles some of us -- we DO know about
this and we DO warn folk. We have to deal with Governments and their
separate and randomly whacky views on what IS required/banned/optional
depending on who's asking/...

So why do I still see examples of a fluffy cloud that seems to be
enveloping this stuff?

-  For those of you with a life (and not on all the other MLs), Dean
seems to be re-inventing the ideas on a new transport for DNS (using SCTP).
Why long-lived connections via HTTPS? Because it's there, I guess, and
because the expertise in DNSEXT (and the "the purgatory of TCPM") is
not considered.

I *hope* the intent is NOT to try to provide an alternative take
on "DNS-NG" -- as Jay says, that is for another bunch who can, do,
and will grind exceedingly small on any such change to DNS.
[For the joy of that discussion so far, search namedroppers for SCTP
or TCP]

- I also note what looks like an attempt to introduce general privacy
controls into the DNS. Again, that's dnsext's job if it's anyone's.
[For the narrow ENUM/E2MD take on controls, Jim's already said that
 he needs to look at x-crypto again -- brave man].

Me, I want to get this stuff out the door in an agreed form -- otherwise
it will be another piece of data to put in TXT records and x-services.
This is not, I hope, a Cult.
<flame off>

We now return you to a discussion of the things we hope to standardise.

all the best,
  Lawrence

---

From: Jim Reid <[email-masked]>
Date: Thu, 18 Mar 2010 21:17:42 +0000

On 18 Mar 2010, at 19:45, Dean Willis wrote:

> authoritative for (primary or secondary) or that has cached.

Nope. Resolution is the process of making iterative queries starting  
at some place in the tree until an authoritative server provides the  
answer to some query. Authoritative servers don't have to resolve  
anything. Some implementations of these don't even have code to *make*  
queries. By implication, these don't have caches either.

A name server can answer a query when (a) it is authoritative for the  
zone in question; (b) has cached the answer from an earlier lookup it  
made; (c) resolves the query from a client my making iterative queries  
to other servers. The choice of (a), (b) or (c) (or some combination  
of these) is down to local policy and configuration.

> It has to go upstream occasionally. For example, the NS for subdoomain
> "softarmor.com".

The DNS doesn't work that way. Sorry. If it did, it would mean every  
authoritative name server would be in regular contact with those for  
its parent zones. And so on. They're not. An authoritative name server  
doesn't have to talk to any other name server. It only has to answer  
queries.

> Why wouldn't a long-lived connection work here?

See above. There's no reason why a name server for  
research.softarmor.com would need to ever speak to a name server for  
softarmor.com. The softarmor.com servers don't speak to the .com name  
servers. And the .com name servers don't speak to the root name servers.

> do). Why wouldn't an HTTP connection work here?

Let's assume that DNS works the way you've guessed. [It doesn't.] How  
many long-lived TCP connections is the name server for  
research.softarmor.com going to maintain? How will it choose between  
them when it runs out of file descriptors?
It's not easy to model DNS traffic in the same way as say HTTP because  
DNS lookups regularly entail diversions into lookups in other domains.  
ie to resolve A, the server needs to resolve B, C & D to get to the  
name servers of E, F & G to find the addresses of the name servers for  
A.

Try doing a dig +trace on some domain name to see what's really going  
on when a name gets resolved. You'll be surprised.

> as reasonable", for which there are several evident mechanisms.

Dean, this is truly bizarre. For many zones these days, there is no  
"zone file" any more: there's a real database holding the zone data.  
And many folk don't allow copies of their zones to be slurped by axfr  
(or HTTP GETs in your model) for all sorts of reasons, some sensible,  
others stupid... I wonder if you've thought this through. The Internet  
would collapse -- as would the .com name servers -- if every lookup  
for a name in the .com domain meant pulling down the 4GB or so of .com  
"zone file".

One of the design goals of the DNS is to save every host on the net  
from knowing about everything in the name space. [That's why the  
ARPAnet gave up on hosts.txt 25 years ago.] Your proposal violates  
that. It simply won't scale.

---

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

On 18 Mar 2010, at 20:56, Cullen Jennings wrote:

> So making sure I understand the requirement here ... we need to be  
> able to lookup the metadata from an end users phone or terminal?

Well we (for some definition of "we") should not make assumptions  
about what will or won't lookup metadata if that results in coming up  
with something that can't be made to scale. DNS over long-lived TCP  
connections (or something that mimics that) has those inherent  
limitations. There are good reasons why almost all DNS traffic goes  
over UDP. And why web server generally don't like to maintain long- 
lived TCP connections from their clients.

> Clearly if we it was only needed from the call agents or SBC in the  
> middle of the network, long lived connections would work fine.

I don't think so. How many SBCs and call agents will the typical  
operator have? Long-lived connections between 'em is an N-squared  
probem. That gives me the heebie-jeebies. Keeping state and coherency  
across this matrix will be difficult and perhaps impossible when N is  
large. Then there are the interconnects between each operator's SBCs  
(or equivalent). Which begins to smell like an N-cubed problem.

I'm not sure there's any point continuing this thread. Dean's  
(throwaway?) idea of displacing DNS with HTTPS seems to have emerged  
from a misunderstanding of how DNS works. So it may be better to climb  
out of this rat-hole now instead of carry on digging.

---

From: Jim Reid <[email-masked]>
Date: Thu, 18 Mar 2010 21:47:04 +0000

On 18 Mar 2010, at 19:55, Dean Willis wrote:

>> Public
> consideration in the E2MD process

I think it could be. For the E2MD process, just define a suitable  
NAPTR service type and a data URI and we're done. Or if this list  
would be prepared to run with
	http://tools.ietf.org/html/draft-timms-encrypt-naptr-01
we're already done. :-)

The issues of managing keys and provisioning the encrypted NAPTRs is  
of course left as an exercise for the reader. :-)

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 18 Mar 2010 20:51:02 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cullen Jennings
Sent: Thursday, March 18, 2010 4:57 PM
To: Jim Reid
Cc: [email-masked]
Subject: Re: [e2md] HTTPS as an alterative to DNS lookup

Thanks Jim

So making sure I understand the requirement here ... we need to be able to
lookup the metadata from an end users phone or terminal? 

RS> In my principal use cases neither..typically internal network proxies or
SBC's. And the query is to highly localized directory/location servers. That
is why I argue that the meta data problem is both a ENUM and a SIP issue
some carriers have a preference for one vs the other. I don't care. There is
nothing wrong with giving folks both a hammer and a socket wrench and let
them choose the tool. It's the TCAP replacement model here. A session comes
into my network what do I do? I need data about this session what do I do?
Data from multiple sources can be aggregated and returned by a single query
via 3761 localized assuming that the network can trust the source of the
query. We may need a new form of SIP redirect here but I don't want to go
there. It is then presented with all available data about that session and
returns an "answer" that answer may be URI's or metadata that prompts a
secondary form of look up or a localized policy driven result.

Clearly if we it was only needed from the call agents or SBC in the middle
of the network, long lived connections would work fine. (I realize we also
need to be able to make metadata queries from the call agents, SBC, etc. )
Do I have the right understanding here?

RS> Yes and no ..there are multiple use cases here that some such as the
classic e164.arpa ones use the public DNS but others are not but both could
also support PSTN transitional environments in classic voice centric
networks. IF you are ATT and want to shut of the PSTN ( according to their
FCC filings) you still need to query for data internally and that is what
private ENUM is many environments does extremely well.  

> Because the overhead of setting up a TCP connection, then doing SSL
authentication over it will always lose to a DNS query-response over UCP.
It's not just the extra packets and latency -- a big deal in things like 3G
networks where users get to pay by the packet -- but the impact on the web
servers, SBCs or whatever that would get bombarded with bazillions of
presumably short-lived TCP connections.

Cullen Jennings

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 18 Mar 2010 20:58:32 -0400

RS> Right but what we do know from the split DNS experience is that some
results are more authoritative than others about internal network topology.
The confusion Dean is bringing to the table here is what those of us in the
ENUM wars have known for ever. There are two views of data. In the classic
E.164 world there is, sometimes, a marked preference for knowing everything
you can locally and demanding that that the response to a query be done in
120 ms. 

Heck memory resident terabyte resident databases are cheap and fast and a
lot less expensive than classic PSTN Service Control Points. 
_______________________________________________
e2md mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/e2md

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Mar 2010 22:36:45 -0500

> in the charter out the door by the end of this year.

What are you talking about, Lawrence? The stuff that I said was  
clearly outside the scope of ENUM because it constituted a replacement  
for DNS?

> done on ENUM). All very focussed.

While I have not proposed that we reinvent DNS, once you add DNS  
security, the performance difference relative to HTTPS isn't as  
dramatic as you might think. You are using DNSSEC, aren't you? Why not?

> in big friendly letters on the front cover of each document. Just like

That might be suitable. But I'd like us to understand that's what  
we're doing, and that we're doing it on an element-by-element  basis,  
not just as a blanket statement for every document the WG might produce.

> depending on who's asking/...

Well, here's he counterpoint. By proposing that our charter contain a  
blanket statement saying in effect that privacy and security issues  
are Somebody Else's Problem, we started looking like people who wither  
did not understand or did not care about the issues. That set off Big  
Red Flags that I'm trying to get pulled in by saying, in our proposed  
charter, that we both understand the security questions and are going  
to deal with them. That's it, and that's all there is to it.

> So why do I still see examples of a fluffy cloud that seems to be

Because you aren't reading what was actually written, maybe?

> because the expertise in DNSEXT (and the "the purgatory of TCPM") is

Cullen asked the question "Why aren't we doing metadata with HTTP?" I  
answered -- "because doing so would lead us down the path of  
reinventing DNS using HTTP. It's not necessarily a bad idea (as some  
have suggested) but it is OUTSIDE THE PROPOSED SCOPE FOR E2MD."

I HAVE NOT PROPOSED TO GO THERE IN E2MD! AFAIK, NOBODY HAS!

> [For the joy of that discussion so far, search namedroppers for SCTP

Aarg! Richard misquotes me, and everybody reacts to his misquote.

> he needs to look at x-crypto again -- brave man].

If you're going to put generally sensitive data into the DNS, you may  
well need general privacy controls.

Or you might just decide that the DNS is NOT the place to put your  
sensitive data.

It is OK for E2MD to say "That use case contains such sensitive data  
that we don't want it in the DNS. Go find another mechanism." Will the  
WG be willing to make that call, and will it be willing to write  
guidelines to help reviewers who come after us make that call? I hope  
so.

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Mar 2010 23:03:10 -0500

On Mar 18, 2010, at 4:17 PM, Jim Reid wrote:

> anything. Some implementations of these don't even have code to  
> *make* queries. By implication, these don't have caches either.

That's an euphemistic play on resolution. Another way to look at it is  
"everything that happens when an app calls gethostbyname" and invovles  
"libresolv" or the local equivalent. This library is by the "resolver"  
and what it  does is "resolution".  Historically, the set of hosts to  
use for the library was configured in "resolv.conf", which also hints  
at doing resolution.

Note also that what happens in "the DNS" isn't necessarily the only  
way to make a name service work.

If the name server isn't authoritative, and doesn't have a cache, it  
can't answer directly. Somebody else has to get asked. This could  
happen in a couple of obvious ways. The name server could "pass the  
buck" by looking for an authoritative server and then querying there,  
or it could return a reference to an authoritative server and let the  
client handle the query, or it could just give up and hope the client  
finds another way to answer the query, or it could return another  
thing that the client should query on in order to get somewhere.

Oddly enough, all of these approaches have, I believe, been exercised  
at some point in the evolution of SIP's "name server" functionality,  
which is called a "location server" in RFC 3261.

Any heirarchical directory service has essentially the same pallet of  
potential mechanisms, and one can readily envision a replacement DNS  
that works just a little different from current DNS but uses  
relatively long-lived HTTP sessions for transport, rather than UDP.  
One could also envision one using XMPP, for that matter.

>
> A name server can answer a query when (a) it is authoritative for  
> the zone in question; (b) has cached the answer from an earlier  
> lookup it made; (c) resolves the query from a client my making  
> iterative queries to other servers. The choice of (a), (b) or (c)  
> (or some combination of these) is down to local policy and  
> configuration.
>
> its parent zones. And so on. They're not. An authoritative name  
> server doesn't have to talk to any other name server. It only has to  
> answer queries.

An authoritative name server will frequently handle requests from  
other servers, such as for zone transfers.. That's talking.

> softarmor.com. The softarmor.com servers don't speak to the .com  
> name servers. And the .com name servers don't speak to the root name  
> servers.
>
> Let's assume that DNS works the way you've guessed. [It doesn't.]  
> How many long-lived TCP connections is the name server for  

How does my browser know which connections to discard? Varies by  
browser. A weighted discard prioritization factoring LRU against least- 
used would seem to be reasonable.

> It's not easy to model DNS traffic in the same way as say HTTP  
> because DNS lookups regularly entail diversions into lookups in  
> other domains. ie to resolve A, the server needs to resolve B, C & D  
> to get to the name servers of E, F & G to find the addresses of the  
> name servers for A.
>
> Try doing a dig +trace on some domain name to see what's really  
> going on when a name gets resolved. You'll be surprised.
>
> And many folk don't allow copies of their zones to be slurped by  
> axfr (or HTTP GETs in your model) for all sorts of reasons, some  
> sensible, others stupid... I wonder if you've thought this through.  
> The Internet would collapse -- as would the .com name servers -- if  
> every lookup for a name in the .com domain meant pulling down the  
> 4GB or so of .com "zone file".

I certainly didn't suggest that every query be replaced by a zone  
transfer.  I did say that where zone transfers occur, one could  
effectively GET the entire zone. Or, in your terminology as I infer  
it, one could do a database table replication over TCP

More specifically, I did ay that individual query operations could  
technically be done using TCP (perhaps in an HTTP API) rather than  
UDP. Sure, there's more overhead on TCP. But IF we persist in making  
the query results humongous through putting arbitrary metadata in  
them, we're going to need TCP to handle those queries anyhow.

Every time somebody says "But if we switch from UDP to TCP, the  
Internet will collapse!" they seem to eventually be proven wrong.

> that. It simply won't scale.

Perhaps I haven't been clear. But it doesn't really matter here, as  
doing this is clearly OUTSIDE THE SCOPE OF E2MD, other than perhaps  
pondering whether particular E2MD use cases are well-handled by the  
current DNS.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Mar 2010 23:16:27 -0500

On Mar 18, 2010, at 7:51 PM, Richard Shockey wrote:

> some carriers have a preference for one vs the other. I don't care.

Richard has spoken several times of using SIP as a lookup mechanism  
for the metadata. Each time, we've sort of skipped past it to argue  
about DNS use cases.

But there may be another model or two in what he's been hinting at.

As I understand it, the model Richard has in mind is that either the  
metadata would be added to the incoming signaling by the proxy network  
so that the end-point would not have to query for it, or that the  
metadata would be provided in some sort of 3XX response to a request,  
so that the requesting node could use the metadata in its next  
signaling round.

This raises the question of how the SIP servers acquire the metadata  
themselves,  which might be through ENUM or provisioning or something  
else.

But what if we hybridized?

Perhaps the NAPTR could point at a "metadata URI", either on a per- 
metadata field level (as I did in the HTTP example that nobody seems  
to have noticed) or for all metadata relative to a NAPTR. If this URI  
were formatted as a SIP URI, we could then do a SUBSCRIBE against the  
URI, and receive a return NOTIFY containing the metadata.

So: a SIP event package that reports metadata for telephone numbers,  
which we use ENUM to bootstrap. Like the HTTP model, this lets the SIP  
server do things like AAA, make privacy decisions, and selectively  
answer based on characteristics of the requester.

Does this approach have any merit?

Here's a usage scenario:

1) Alice calls Bob, using a telephone number for source and target.

2) Bob's UA receives the call and wants to display Calling Name.

3) Bob's UA does an ENUM lookup on Alices' phone number, and gets a  
SIP URI for her metadata.

4) Bob SUBSCRIBES to the URI, the server realizes that Alice does not  
have an unlisted number, and NOTIFIES Bob with all the metadata he's  
allowed to see.

--
Dean

---

From: [email-masked]
Date: Fri, 19 Mar 2010 11:01:44 +0000

> Does this approach have any merit?

No, IMHO this approach has absolutely zero merit because NOT EVERY NETWORK 
USES SIP!!

Ray

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 19 Mar 2010 11:18:50 +0000

Hi Ray, Dean, folks,
 To clarify, not every network uses SIP for all these functions; some use IMS.
(with different functions carried out using different methods in different nets).
Many still rely on traditional (C)SS#7 interconnects, as they "work". Sigh.

E2MD via DNS may or may not be used; this is an attempt to provide another tool
for the box. For those networks that DO use SIP, *and* use it for those purposes
in the way we expect, a SIP-based approach could work. For the rest...

all the best,
  Lawrence

---

From: Jim Reid <[email-masked]>
Date: Fri, 19 Mar 2010 12:41:22 +0000

On 19 Mar 2010, at 04:03, Dean Willis wrote:

> That's an euphemistic play on resolution.

No it isn't. What I said is the strictly correct definition of that  
term in a DNS context.

> Another way to look at it is "everything that happens when an app  
> calls gethostbyname" and invovles "libresolv" or the local  
> equivalent. This library is by the "resolver" and what it  does is  
> "resolution".  Historically, the set of hosts to use for the library  
> was configured in "resolv.conf", which also hints at doing resolution.

You're now talking about stub resolvers. These do not do true  
resolution. They make one query, wait for a response and give up if no  
reply is received. A stub resolver has no knowledge of the name space  
or the root name servers and cannot follow a referral response. A true  
resolver does all of these things. In the early days of DNS people  
didn't make a distinction between a proper resolver and a stub  
resolver. They do now, thanks largely to DNSSEC.

The names of that stub resolver library and its config file (and their  
man pages) are an archeological relic from those faraway and naive days.

> way to make a name service work.

True. But what other name service exists today which is (a) deployed;  
(b) scalable  and (c) ubiquitious. Frankly, DNS is the only game in  
town. If you think this list/WG can come up with something better, go  
ahead. Be aware though that that particular path is littered with the  
corpses of things which have tried and failed to displace DNS.

>> The DNS doesn't work that way. Sorry. If it did, it would mean  
>> every authoritative name server would be in regular contact with  
>> those for its parent zones. And so on. They're not. An  
>> authoritative name server doesn't have to talk to any other name  
>> server. It only has to answer queries.
>

Sure. But there is no reason for an authoritative server to make zone  
transfers from parent servers. Or vice versa. The name servers for  
softarmor.com don't (and can't) slurp the .com zone. The .com name  
servers don't talk to the softarmor.com zone's servers in any way  
either. BTW it's bad DNS practice to have parent and child zones on  
the same name server because it allows broken or non-existent  
delegations to appear to work.

> transfer.

That seemed to be what you were implying with all that babble about  
long-lived TCP connections to "upstream servers" (whatever they might  
be).

> Internet will collapse!" they seem to eventually be proven wrong.

I didn't say that. I did say a model of resolution that relied on zone  
transfers (or equivalent) would cause meltdown. Assuming it could ever  
be made to work and scale. Which it can't.

---

From: Dean Willis <[email-masked]>
Date: Fri, 19 Mar 2010 13:24:51 -0500

On Mar 19, 2010, at 7:41 AM, Jim Reid wrote:

>> "resolution".  Historically, the set of hosts to use for the  
>> library was configured in "resolv.conf", which also hints at doing  
>> resolution.
>
> resolution. They make one query, wait for a response and give up if  
> no reply is received. A stub resolver has no knowledge of the name  
> space or the root name servers and cannot follow a referral  
> response. A true resolver does all of these things. In the early  
> days of DNS people didn't make a distinction between a proper  
> resolver and a stub resolver. They do now, thanks largely to DNSSEC.
>

My point  exactly. The process that a DNS server goes through to  
answer the query made by a "resolver" is "resolution".

SIP's resolution procedure is more general; every UA is expected to  
handle a referral response.

> The names of that stub resolver library and its config file (and  
> their man pages) are an archeological relic from those faraway and  
> naive days.
>
> True. But what other name service exists today which is (a)  
> deployed; (b) scalable  and (c) ubiquitious. Frankly, DNS is the  
> only game in town. If you think this list/WG can come up with  
> something better, go ahead. Be aware though that that particular  
> path is littered with the corpses of things which have tried and  
> failed to displace DNS.
>
> Sure. But there is no reason for an authoritative server to make  
> zone transfers from parent servers. Or vice versa. The name servers  
> for softarmor.com don't (and can't) slurp the .com zone. The .com  
> name servers don't talk to the softarmor.com zone's servers in any  
> way either. BTW it's bad DNS practice to have parent and child zones  
> on the same name server because it allows broken or non-existent  

One more time, I never said that the name servers for softarmor.com  
need to slurp the .com zone. They do, however, make relatively  
frequent queries for SOA within the ".com" space. A connectivity graph  
will show them talking fairly frequently to these "upstream" nodes,  
especially after a restart. The frequently used relationships are  
candidates for some sort of reused TCP connection.

> long-lived TCP connections to "upstream servers" (whatever they  
> might be).

HTTP has changed since 1.0; 1.1 prefers relatively long-lived  
connections that can process multiple queries. Haven't used the  
connection lately and no more queries in the pipeline? Close it!  
Modern TCP stacks can also handle vastly more connected TCP sockets;  
they don't use file descriptors and thereby avoid the 16-it handle  
limit. People working on the SIP list went through this enumeration  
five or six years ago during one of our regular TCP vs UDP fights.

"Upstream"  servers, for example, might include the root servers that  
the softarmor.com name server gets primed with at boot time (/etc/bind/ 
db.root)

> I didn't say that. I did say a model of resolution that relied on  
> zone transfers (or equivalent) would cause meltdown. Assuming it  
> could ever be made to work and scale. Which it can't.
>

Okay, I'll buy that.

But what about a model that uses TCP connections instead of UDP  
connections for queries? I'm thinking this is an order N increase,  
where N is relatively small, say perhaps 6 or so, if there's no reuse  
of connections. The more connections are reused, the more this  
decreases. Plus we save a bit in the database engine on resubmitted  
queries because of something UDP having gotten lost in the net  
somewhere.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 19 Mar 2010 13:27:11 -0500

> in the way we expect, a SIP-based approach could work. For the rest...

Running SIP as a query protocol doesn't really require that  SIP be  
the core signaling protocol, you know.

Would ENUM+HTTP for metadata retrieval be more broadly applicable than  
ENUM+SIP-Events? Possibly. It's certainly easier to implement with  
basic off-the-shelf libraries.

--
Dean

---

From: Otmar Lendl <[email-masked]>
Date: Sat, 20 Mar 2010 20:44:12 +0100

On 18.03.2010 21:56, Cullen Jennings wrote:
> 
> So just to make sure I am understanding the deployments correctly for 
> the E2MD data, the hierarchal is important because in the practical 
> deployments will have a bunch of different administrative domains that 
> are responsible for metadata for different numbers.
> 

IMHO this is one of the questions we need to ask right at the beginning.

If the answer is no to Cullen's question, then we don't make use of one of
DNS' primary features, making perhaps other solutions better suited.

Let's be a bit more systematic about those questions.

Q1 (Cullen): Will parts of the namespace be handled by different entities?

Richard Shockey wrote:
> In the classic E.164 world there is, sometimes, a marked preference for
> knowing everything you can locally and demanding that that the response
> to a query be done in 120ms.

>From that I'd derive:

Q2 (Richard): Do we need guaranteed response times for queries?

Also from Richard:
> you could do it in ENUM if Hadriel Kaplan's source URI draft were
> adopted.

Q3 (Richard): Will answers depend on who's asking the question?

(can't remember who)
Q4: Who will query for e2md data? User-owned devices like phones or
softswitches/SBCs/SIP-proxies which are inside the SSP's network and are
managed by the SSP? Also, in a mobile endpoint scenario, will the query be
over the long latency link of a cell-phone?

Q5: Do we absolutely want to piggyback on ENUM's NAPTR lookup?

Q6: Even in a non-public scenario, will we expect live queries across
administrative boundaries or will local databases/caches be synced up-front
so that no actual query needs to be passed between SSPs?

In other words, do we actually need the delegation/recursion feature of the
DNS, or would we better be served by some sort of directory synchronization
scheme superior to the AXFR/IXFR simpletons of the DNS?

Or, would the next point after the e2md WG then be a drinks-like WG which
then talks about how to provision these directories and how to distribute
and synchronize them?

-------------------

Personally, I think the approach outlined by Bernie's draft has merit.

But we are all old DNS hands and I'd very much like to evaluate whether we
have chosen DNS because of rational arguments, or just because it's our
default solution for everything.

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 22 Mar 2010 15:37:28 -0400

Ohhh, nice.
We were looking at submitting a draft on a very similar thing for a different purpose.

One question on your draft: why is "x-crypto" an enumservice type, as opposed to a sub-type?  I.e., why is it 'E2U+X-crypto:data:8210' and not 'E2U+sip:x-crypto:data:8210' or some such?  I ask because:
	1) I want to know that the URI is a sip one before I bother decrypting it, so I don't have to try to decrypt ones I don't care about/don't support
	2) We may make the crypto keys different for some service types, for example a cnam might use a different one than sip(because it has a different set of allowed viewers), and so it would produce decrypt failures if each record has to be decrypted to determine what type it is.

-hadriel

> Jim Reid
> Sent: Thursday, March 18, 2010 5:47 PM
>

---

From: Jim Reid <[email-masked]>
Date: Mon, 22 Mar 2010 21:10:36 +0000

On 22 Mar 2010, at 19:37, Hadriel Kaplan wrote:

> One question on your draft: why is "x-crypto" an enumservice type,  
> as opposed to a sub-type?

Extra privacy. We did not want to disclose that an encrypted NAPTR  
contained a particular URI. We felt that the trade-off of doing extra,  
possibly unnecessary, decryptions was worth it. Your mileage may vary.

The scheme used in .tel is to have a subdomain for each friend  
containing the encrypted NAPTR RRset the domain holder makes available  
to that friend. Although the names of these subdomains are not readily  
guessed, it was felt it would be bad if one friend could figure out if  
another friend got different (better) types of contact from the domain  
holder.

If the URI was a subtype of x-crypto, you might find that I've  
provisioned an encrypted SIP URI for Dean under mumble.jim.tel but not  
for you, my best buddy, under foobar.jim.tel. That could be  
embarrassing for me. And you. And Dean.

---

From: Jim Reid <[email-masked]>
Date: Mon, 22 Mar 2010 22:53:27 +0000

On 22 Mar 2010, at 19:37, Hadriel Kaplan wrote:

> 	2) We may make the crypto keys different for some service types,  
> for example a cnam might use a different one than sip(because it has  
> a different set of allowed viewers), and so it would produce decrypt  
> failures if each record has to be decrypted to determine what type  
> it is.

The scheme used in .tel provisions a public/private key pair for each  
owner-name. So how about extending the owner-name for provisioning  
service types? ie Something like:

sip.telco1.foo.bar.	NAPTR x-crypto:blah0
cnam.telco1.foo.bar	NAPTR x-crypto:blah1
sip.telco2.foo.bar.	NAPTR x-crypto:blah2
cnam.telco2.foo.bar	NAPTR x-crypto:blah3

Add syntactic sugar to taste...

Of course this means more key pairs to manage and handshake. But that  
might be an acceptable trade-off if you want to prevent multiple  
decrypts and need to avoid subtyping the x-crypto service type. BTW,  
subtyping eats into the encrypted payload. Which was another  
motivation for not doing that, particularly with more x- type  
qualifiers: for instance "E2U+voice:tel+x-lbl:Office+x-pager".

---

From: Dean Willis <[email-masked]>
Date: Mon, 22 Mar 2010 21:15:02 -0500

Jim Reid wrote:
>> for example a cnam might use a different one than sip(because it has a
>> different set of allowed viewers), and so it would produce decrypt
>> failures if each record has to be decrypted to determine what type it is.
> 
> subtyping eats into the encrypted payload. Which was another motivation
> for not doing that, particularly with more x- type qualifiers: for
> instance "E2U+voice:tel+x-lbl:Office+x-pager".
> 

This sounds reasonable to me. One of the big concerns with  E2MD is the
payload size, and Bernie's approach of putting one type/subtype per
NAPTR, while it requires more records, increases the payload per record.

Your suggestion also allows differentiated access control for each data
type. For example, someone might have the key for CNAM within a network,
but not have the key for some other record type.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 22 Mar 2010 22:20:09 -0400

> From: Jim Reid [mailto:[email-masked]]
> Sent: Monday, March 22, 2010 6:53 PM
> 

We could do that, but it gets kinda fugly.  We've got operators with NAPTR separate NAPTR entries for voicemail/voicemsg, "normal" sip, h323, pstn, and cnam.  We could have them separate those into separate roots per service type, but then for a normal call we'd have to do multiple queries.  And right now we let the operator define the service-types they want to follow/use/try from the NAPTR responses, but we get the whole list back from the DNS/ENUM server from that one query which is optimal in many ways.  Like we can fallback to a voicemail route if the primary sip/h323 don't pan out, without doing more queries.  And for the operator, for the void/unused case, they'd have to have an unused entry for each root.

No biggie though - your needs are such that you need to hide the service-type, which is what you need - it's just experimental and individual, so to each his own there. :)

> BTW,

Yes, we've been worried about the record size problem in general with encrypting it.

-hadriel