Subject: [e2md] alt structure suggested for CNAM

From: Dean Willis <[email-masked]>
Date: Wed, 24 Mar 2010 11:48:08 -0500

Ray, Bernie, Brian Rosen, and I sat down with Jon Peterson yesterday and
talked about things.

Here's a point he made that we may wish to consider.

The usage scenario for CNAM is entirely different from that for our
other current use cases. It's something that one generally queries when
receiving a call, not when placing a call. The data returned has
absolutely nothing to do with the routing/numbering topology. It's not
"metadata" about the enum tree, it's "data" related to the phone number.
Putting it in a NAPTR record is also pointless: not only is NAPTR a
clumsy format for calling-names, one generally does NOT want or need the
CNAM to come back in the other cases where one might query for all NAPTR
records associated with a given E.164, so having it in a NAPTR simply
creates extra network traffic and processor load while achieving no benefit.

Consequently, one approach for CNAM would be to define another resource
record type that would fit the problem space better.

Would this be a viable approach?

--
Dean

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 24 Mar 2010 13:07:15 -0400

Short answer NO.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
Willis
Sent: Wednesday, March 24, 2010 12:48 PM
To: E.164 To MetaData BOF discussion list
Subject: [e2md] alt structure suggested for CNAM

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

---

From: Jim Reid <[email-masked]>
Date: Wed, 24 Mar 2010 19:31:15 +0000

> creates extra network traffic and processor load while achieving no  

Maybe, maybe not. If the application is going to do a NAPTR lookup,  
the response might as well include a CNAM NAPTR (if such a beast  
exists). The network overhead of an additional RR and the extra CPU  
cycles to chomp through a list of N+1 instead of N NAPTRs is unlikely  
to matter. This would certainly be cheaper than having to make a  
second DNS query for some other RRtype.

> record type that would fit the problem space better.

Maybe. Getting a CNAM RRtype would be a whole lot less painful than  
getting CNAM as a NAPTR subtype/URI.

---

From: Dean Willis <[email-masked]>
Date: Wed, 24 Mar 2010 15:18:35 -0500

Jim Reid wrote:
> Maybe, maybe not. If the application is going to do a NAPTR lookup, the
> response might as well include a CNAM NAPTR (if such a beast exists).
> The network overhead of an additional RR and the extra CPU cycles to
> chomp through a list of N+1 instead of N NAPTRs is unlikely to matter.
> This would certainly be cheaper than having to make a second DNS query
> for some other RRtype.

True, if doing a NAPTR dio, the extra overhead of getting back CNAM is
pretty small.

But the "called" party isn't likely to a NATR lookup for anything but
the CNAM, and if we put CNAM in NAPTR, it's going to get the whole set
of records back, most (all but CNAM?) of which it does not need.

> getting CNAM as a NAPTR subtype/URI.

What are the deployment implications? How hard is it to access a new RR
with most of the current libraries? What about impacts on name servers
and DNS proxies?

--
Dean

---

From: Jim Reid <[email-masked]>
Date: Wed, 24 Mar 2010 20:35:39 +0000

On 24 Mar 2010, at 20:18, Dean Willis wrote:

> What are the deployment implications?

Define deployment. Is this something that goes on behind closed doors  
amongst consenting adults or is it something will or could be visible  
on the public internet?

> How hard is it to access a new RR with most of the current libraries?

How long is a piece of string? Presumably the only libraries that need  
to know about this new RRtype will be those that are used specifically  
for looking it up.
The rest should support RFC3597 (unknown RRtypes) and just do the  
Right Thing: treat the RDATA as an opaque blob of data and leave it  
alone. There will of course be libraries and servers who don't support  
RFC3597. I'm not sure if these matter or not for this particular case.

> What about impacts on name servers and DNS proxies?

Depends. Decent implementations will support RFC3597. Stupid ones  
won't. Proxies, firewalls and middleware may well barf on RRtypes they  
don't understand. They will no doubt barf on anything other than A,  
CNAME, MX and NS record lookups.

---

From: [email-masked]
Date: Wed, 24 Mar 2010 12:43:13 -0800

> Proxies, firewalls and middleware may well barf on RRtypes they 

That assertion isn't actually backed up by my own research into DNS 
proxies - we didn't find any issues with unknown RRtypes at all.

Ray

---

From: Dean Willis <[email-masked]>
Date: Wed, 24 Mar 2010 15:49:51 -0500

> proxies - we didn't find any issues with unknown RRtypes at all.

I know my own proxies will also pass at least TXT and PTR, and AFAIK,
the Linksys  devices up to last year (have no knowledge of newer ones)
were open to unknown RRs.

But right offhand, I don't know how to write an app that queries for a
new RR. Of course, I still use gethostbyname()...

--
dean

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Wed, 24 Mar 2010 17:20:32 -0400

As is the case with the SS7 networks, which use a TCAP message to lookup the CNAM, CNAM ENUM queries to lookup CNAM data are not sent to the same ENUM server that are used to lookup the other NAPTRs that are stored in ENUM, if any.  This is because "usually" carriers are charged per dip into the CNAM data.  So comingling it with other data that would result in CNAM data being returned in cases where it is not needed is something that is not usually done.

So this email chain seems to be mostly a red herring.  As with several of the other email chains about E2MD and its potential use cases which make erroneous assumptions about where E2MD data will/does live, exactly who will and who will be able to query it, and under what circumstances they will query it.

Today, in production, CNAM data is already being looked up using TCAP, ENUM, and SIP.  The goal here is to get the structure of the ENUM response that contains the ENUM data oficcially standardized.

Ken

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Dean Willis [[email-masked]]
Sent: Wednesday, March 24, 2010 4:18 PM
To: Jim Reid
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] alt structure suggested for CNAM

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: Jim Reid <[email-masked]>
Date: Wed, 24 Mar 2010 21:22:03 +0000

On 24 Mar 2010, at 20:49, Dean Willis wrote:

> Of course, I still use gethostbyname()...

Real programmers (TM) use res_mkquery() and friends... :-)

gethostbyname() doesn't always use the DNS.

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 24 Mar 2010 17:44:12 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Cartwright, Kenneth
> Sent: Wednesday, March 24, 2010 5:21 PM
> 
> As is the case with the SS7 networks, which use a TCAP message to lookup
> the CNAM, CNAM ENUM queries to lookup CNAM data are not sent to the same
> ENUM server that are used to lookup the other NAPTRs that are stored in
> ENUM, if any.  This is because "usually" carriers are charged per dip into
> the CNAM data.  So comingling it with other data that would result in CNAM
> data being returned in cases where it is not needed is something that is
> not usually done.

Yes you're right of course, but I think to get this standardized here we'll need to consider (or accommodate) a model where it's:
	1) in public DNS
	2) in a single DNS server along with any/all other NAPTRs for the same number

Don't get me wrong though - I would *rather* just use draft-ietf-enum-cnam-08.txt as is without any changes.

I think our choices are:
	1) Use a new DNS service (e.g., "E2CNAM")
	2) Use a new type in a new framework (e.g., "E2MD+cnam")
	3) Use a new RR type, not NAPTR (e.g., "CNAMR")
	4) Define a specific root (e.g., "5.5.5.1.cnam.e164.arpa")
	5) Define a specific query key extension (e.g., "_cnam.5.5.5.1.e164.arpa")

Personally I like #5 of the choices.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Wed, 24 Mar 2010 16:49:02 -0500

Cartwright, Kenneth wrote:
> As is the case with the SS7 networks, which use a TCAP message to
> lookup the CNAM, CNAM ENUM queries to lookup CNAM data are not sent
> to the same ENUM server that are used to lookup the other NAPTRs that
> are stored in ENUM, if any.  This is because "usually" carriers are
> charged per dip into the CNAM data.  So comingling it with other data
> that would result in CNAM data being returned in cases where it is
> not needed is something that is not usually done.

Hold on a sec:

You're telling me that I should select which NAPTR records come back by
picking different DNS roots (via different servers, as access points
into different DNS splits)for different queries, and the question of
"how do I know which root to query" is entirely settled by provisioning?

In other words, if I want E2M+CNAM I might query server X, and for
E2M+UNUSED I might query server Y, and I just have to know in advance
which server to query?

--
Dean

---

From: [email-masked]
Date: Wed, 24 Mar 2010 13:53:25 -0800

>    5) Define a specific query key extension (e.g., 
"_cnam.5.5.5.1.e164.arpa")

You missed one:

     6) use E2U+cnam, as defined in the current draft.

> Personally I like #5 of the choices.

FWIW, my preference (in decreasing order) for CNAM in particular would be:

  2 - E2M as originally envisioned (before the layer 9+ crap got in the 
way)
  6 - leave the draft as is
  3 - OK, but only if the CNAM query is standalone and independent of 
other NAPTRs
  1 - too heavy in spec requirements, IMHO
  5 - requires additional lookups
  4 - requires a whole new tree, bleugh

For unused and send-n some of this doesn't apply, but #4 and #5 really 
need to be off the table ASAP.

Ray

---

From: "Maharishi, Manjul" <[email-masked]>
Date: Wed, 24 Mar 2010 18:01:05 -0400

Yes, indeed - the same registry (or dns root) may or may not hold *all* possible pieces of data. However, a registry provider may offer a service where it does all of this in the background for you and returns the required information back.

On the question of "requiring" multiple dips to get different pieces of information - e.g.: portability info, service provider/authoritative carrier/SPID info, and CNAM info - there are different use cases and possibly different points-in-call for each of these, and as there are financial terms involved - the originator of the query will most likely have to pay for these services. Accordingly, the originator of a call may not want to pay for CNAM dip - that is presently done by the terminating entity.

Manjul

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Wednesday, March 24, 2010 5:49 PM
To: Cartwright, Kenneth
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] alt structure suggested for CNAM

Cartwright, Kenneth wrote:
> lookup the CNAM, CNAM ENUM queries to lookup CNAM data are not sent to
> the same ENUM server that are used to lookup the other NAPTRs that are
> stored in ENUM, if any.  This is because "usually" carriers are
> that would result in CNAM data being returned in cases where it is not
> needed is something that is not usually done.

Hold on a sec:

You're telling me that I should select which NAPTR records come back by picking different DNS roots (via different servers, as access points into different DNS splits)for different queries, and the question of "how do I know which root to query" is entirely settled by provisioning?

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 24 Mar 2010 18:01:26 -0400

> Dean Willis

Yes, today that's often exactly what happens.  You query server X for CNAM, which is a separate ENUM/DNS server than Y which you query for destination/target route resolution, which is where "unused" resides.  In fact, it's not uncommon that you also dip another DNS server Z for number portability resolution, too.

It's not always the case - some ENUM vendors consolidate the separate databases into one ENUM interface, so you query one server for all purposes.  But in the back-end behind-the-scenes that ENUM query makes the server end up doing dips into separate databases for you, or you're given a different root name depending purposes of the query, and they use that to know what you want. (some ENUM server vendors present a DNS protocol interface for queries, but store their data in a very different format/structure from DNS)

-hadriel
BTW, for the "unusued" case, it CANNOT be a separate RR or domain name prefix or anything - because by definition you have to get it back when you do a "normal" enum NAPTR query.

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 24 Mar 2010 18:04:32 -0400

Why does #5 require "additional" lookups?  The lookup you do for target/destination is already a different key anyway - it requires a separate lookup every time regardless (unless people use source-uri draft, I guess :)).

-hadriel

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 24, 2010 5:53 PM
To: Hadriel Kaplan
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] alt structure suggested for CNAM

You missed one:

  2 - E2M as originally envisioned (before the layer 9+ crap got in the way)
  6 - leave the draft as is
  3 - OK, but only if the CNAM query is standalone and independent of other NAPTRs
  1 - too heavy in spec requirements, IMHO
  5 - requires additional lookups
  4 - requires a whole new tree, bleugh

For unused and send-n some of this doesn't apply, but #4 and #5 really need to be off the table ASAP.

Ray

---

From: [email-masked]
Date: Wed, 24 Mar 2010 14:53:32 -0800

> Why does #5 require ?additional? lookups?  The lookup you do for 
> target/destination is already a different key anyway ? it requires a
> separate lookup every time regardless (unless people use source-uri 
> draft, I guess J).

Yes, good point - I was forgetting that CNAM is looked up by the target 
end, and not the caller.

Ray

---

From: [email-masked]
Date: Wed, 24 Mar 2010 14:54:39 -0800

> -hadriel
> BTW, for the "unusued" case, it CANNOT be a separate RR or domain 
> name prefix or anything - because by definition you have to get it 
> back when you do a "normal" enum NAPTR query.

Likewise for Send-N.

The only alternative (and it's not a pretty one) is to require DNS 
"Additional Section Processing".

Ray

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 24 Mar 2010 22:55:54 +0000

Actually, CNAM is only one thing that may be useful when I get an incoming call.
I can think of a whole bunch of other things of interest, as Hadriel already suggested.
Those things are going to be NAPTRs. Thus I WILL be looking for NAPTRs.

---

From: Jim Reid <[email-masked]>
Date: Wed, 24 Mar 2010 23:20:44 +0000

> "Additional Section Processing".

This is not a viable option Ray. Though you already know this.  
Tinkering with Additional Section Processing semantics will mean  
changes to all DNS servers and resolvers. [Read "not going to  
happen"...] IMO it's unlikely anything which requires new Additional  
Section Processing would emerge unscathed from the DNS WGs or make it  
out alive from the DNS Directorate this side of the next Ice Age.

To get back to Hadriel's list, my preferences would be (in decreasing  
order):

a)	Use a new type in a new framework (e.g., "E2MD+cnam")
b)	Use E2U+cnam, as defined in the current draft
c)	Use a new RR type, not NAPTR (e.g., "CNAMR")
d)	Define a specific query key extension (e.g., "_cnam. 
5.5.5.1.e164.arpa")
e)	Define a specific root (e.g., "5.5.5.1.cnam.e164.arpa")
f)	Use a new DNS service (e.g., "E2CNAM")

c) and d) are more or less equal because they both require an  
additional lookup. d) is slightly worse because it means using an  
additional owner-name which could make provisioning clumsier. e) and  
f) are non-starters and not worth pursuing.

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 25 Mar 2010 08:30:19 +0100

> Actually, CNAM is only one thing that may be useful when I get an incoming call.

Not at all.

Imagine you're getting a SIP call over the public Internet and it claims to
be from a certain E.164 number.

If we ever want to build something that allows the receiving party to
validate that claim, a lookup into ENUM / E2MD to query for data associated
with that number (public key for SIP identity, some SPF-like info,...) will
be really helpful.

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

---

From: [email-masked]
Date: Thu, 25 Mar 2010 06:13:16 -0800

>>  Actually, CNAM is only one thing that may be useful when I get an 
incoming call.

Otmar, I think you mis-parsed Lawrence's e-mail.  I did too on first 
reading.

He did not mean it's the _only_ thing, he meant it was just _one of many_.

> with that number (public key for SIP identity, some SPF-like info,...) 
will

That's pretty much what Lawrence was saying too.

Ray

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 25 Mar 2010 14:27:58 +0000

Hi Ray, Otmar, folks,
Amen to that. Of course, "many" is gated by a reasonable RRSet size at this owner :).
Obviously (i) we're wildly agreeing, and (ii) English is self-evidently not my first language.
all the best,  Lawrence

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Fri, 26 Mar 2010 11:10:51 -0400

Exactly.  And there are of course extremely good reasons why one must usually ultimately go to different "resolution" server(s) to lookup data like CNAM.  First and foremost, the calling name data is usually collected and consolidated and managed and offered up by a separate company or organization whose business it is to do that.

Ken

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Wednesday, March 24, 2010 6:01 PM
To: Dean Willis; Cartwright, Kenneth
Cc: E.164 To MetaData BOF discussion list
Subject: RE: [e2md] alt structure suggested for CNAM

-hadriel

---

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

Cartwright, Kenneth wrote:
> Exactly.  And there are of course extremely good reasons why one must
> usually ultimately go to different "resolution" server(s) to lookup
> data like CNAM.  First and foremost, the calling name data is usually
> collected and consolidated and managed and offered up by a separate
> company or organization whose business it is to do that.

So how do you find out what server to query? Is there something like an
indirection record in the DNS, or is it just a matter of configuring
your systems to query against different roots for different sorts of
information?

I'm pretty sure it's the latter, but I'm fishing for some kind of reason
why we're using "the DNS" instead of having an entirely independent
protocol and operations framework that just sort of works like the DNS.
If we were doing the latter, I'm pretty sure we would not get so much
micromanagement from the appointed guardians of the DNS. This might make
our lives a whole lot easier.

--
Dean

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Fri, 26 Mar 2010 14:00:50 -0400

Different organizations use different CNAM data providers.  So they configure their systems to access the CNAM data source that they have decided/agreed/contracted/paid to use (if any).  However, it would of course be good if that data could be looked up and structured in a standard form, which is the goal of the CNAM proposal.  You're exactly right.  And because many of those organizations already use ENUM for other VoIP related lookups, having the technology for the CNAM lookup be very similar to ENUM is a no brainer.  (And to draw an analogy, in the "legacy" SS7 world TCAP, which is used for SS7 call routing, is also used to lookup CNAM data, using an SS7 message that is sent specifically to lookup CNAM data. Iow, they did not invent some completely different query/response protocol outside of TCAP just to lookup CNAM data.  That would have been overkill.).

The CNAM proposal is necessary and is not really about "The DNS" imo.  And the notion that these proposals are about "The DNS" got much of the BOF discussions way off track imo.  From my point of view, these proposals are about using DNS related technologies (DDDS, domain names, NAPTR RRs) to lookup data about TNs.  Organizations already lookup CNAM data using E2U today and would like to do it in a standardized way.  And, believe me, the organizations that serve up CNAM data today know how to "keep it safe".  And while it would definitely be useful to have further technical tools in the standard toolkit around E2U/DDDS/E2M to allow it to be "kept safe" in a more standard or elegant fashion, ***that is a broader subject and should definitely be handled as a separate discussion track***.

The "unused" proposal would also be a very useful tool to have in the toolkit.

The improvements that I would like to see added into the technology toolkit around E2U/E2M/DDDS are:
1) The ability to, in the resolution request, to specify which serviceType-SubType pairs the querier is interested in.  This is useful for more than one reason (allowing a specific querier to vary the content of their response per query, without requiring them to use a different root domain).  Right now this is done via other means, some of which Hadriel has described.  But, again, ***this item is a broader subject and should definitely be handled as a separate discussion track***.
2) The ability to determine the "source" of the query in a standardized manner.  Hadriel has a proposal out there on a way to do this.  But, again, ***this is a broader subject and should definitely be handled as a separate discussion track***.

Ken

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Friday, March 26, 2010 12:25 PM
To: Cartwright, Kenneth
Cc: Hadriel Kaplan; E.164 To MetaData BOF discussion list
Subject: Re: [e2md] alt structure suggested for CNAM

--
Dean

---

From: "Maharishi, Manjul" <[email-masked]>
Date: Fri, 26 Mar 2010 14:01:00 -0400

>> So how do you find out what server to query? Is there something like an indirection record in the DNS, or is it just a matter of configuring your systems to query against different roots for different sorts of information?
>> I'm pretty sure it's the latter,....

Yes, indeed, it is the latter. That is not to say that the same server CANNOT provide you with more than just the CNAM service. However, it should not be a requirement for the same server to provide *all* possible kinds of data. Like I mentioned in one of my posts earlier this week, it could be upto the ENUM server vendor to decide which of the data it supports, and accordingly advise its querying nodes. You can have multiple different trees and servers each of which could be supporting different sets of data.

Manjul

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Friday, March 26, 2010 12:25 PM
To: Cartwright, Kenneth
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] alt structure suggested for CNAM

> company or organization whose business it is to do that.

So how do you find out what server to query? Is there something like an indirection record in the DNS, or is it just a matter of configuring your systems to query against different roots for different sorts of information?

I'm pretty sure it's the latter, but I'm fishing for some kind of reason why we're using "the DNS" instead of having an entirely independent protocol and operations framework that just sort of works like the DNS.
If we were doing the latter, I'm pretty sure we would not get so much micromanagement from the appointed guardians of the DNS. This might make our lives a whole lot easier.

---

From: Dean Willis <[email-masked]>
Date: Fri, 26 Mar 2010 15:59:37 -0500

One of the most divisive points for our recent BOF was along the
relationship between E2MD, ENUM, and the DNS.

Many in our community have asserted that what we're doing has nothing to
do with the DNS other than the fact that it shares some protocol
machinery, and that therefore the people who consider themselves
guardians of the DNS shouldn't be worried about it.

In the other camp, people assert that we have no way to extend the
protocol machinery of ENUM without actually extending the protocol
machinery of the DNS, and that extensions to the protocol machinery of
22the DNS have to be very carefully considered because experience shows
that they WILL be used outside of their original conceptual model,
meaning that anything we add for E2MD is very likely to show up
somewhere in the Internet's core name resolution service, therefore we
need to be very careful as to how we extend it.

Much of this goes back to the original argument for ENUM, and yes, I was
there for the first BOF on the topic. ENUM was originally intended as a
way to make telephone numbers accessible ON THE INTERNET. It had NOTHING
   AT ALL to do with routing telephone calls in private networks, and
everything to do with two end-user nodes on the Internet finding each
other in order to talk.

Consequently, a certain awkwardness in the join between E.164 and DNS
was acceptable to the community. It just "had to be that way" to kludge
the two together, as we couldn't find  a better alternative at the time.
Surely nobody thinks that treating every digit of a phone number as a
subdomain of the digit before it is optimal. It works, it has good
expressive properties, but it really isn't an efficient database
tolopogy. But we use it precisely because it works with the DNS, and the
DNS is where we need this sort of name-locator resolver on today's Internet.

But now we're talking about what are for all practical purposes
non-internet usages of the DNS protocol as a high-speed data retrieval
mechanism for data keyed by phone numbers. We do not consult "the DNS"
and let its resolution function find the right place to ask. Rather, we
know a priori exactly which server to ask a given question, and we use
the DNS query protocol as a high-speed access to that server's database.
we have different servers to ask different questions; one for ENUM,
another for CNAM, another for egress routes within our own domains, etc,
 We blithely ignore much of the operational guidance of the DNS, because
it really doesn't apply to our case.

Folks, please understand that it is not just John, Alan, and Jon that
are blocking us. The greater body of the IETF, if they understood what
we are proposing, would reject it out-of-hand. This doesn't mean that
what we want to do is bad or not needed; it just means that doing it
inside the DNS in the IETF is not a politically tenable approach. If we
want to get this specified in the IETF, then I believe we're going to
have to find a different approach.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 26 Mar 2010 23:16:04 -0400

> your systems to query against different roots for different sorts of

It's provisioned.  This stuff isn't stored in "The Internet DNS".

-hadriel

---

From: Eric Burger <[email-masked]>
Date: Sun, 28 Mar 2010 09:09:03 -0700

I hope the logical conclusion from the argument below is NOT that since many of these use cases could be used on the Internet but will be used in private networks, the people that want to do this work decide to do it outside of the IETF.

That would be a bad outcome.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 28 Mar 2010 12:51:20 -0400

No, I would agree that would be bad - instead, a few of us have been talking about possibly offering a Plan-B to the IETF: a separate database for ENUM.
Same protocol on the wire, but for a different port number than 53, and only for E.164 to Foo resolution, not domain names.  Whether there'd be a global root or not is debatable, but we'd split out from The DNS.

That way we could have unused, send-N, cnam, source-uri, and anything else we actually need for ENUM but that the IETF is concerned about adding to The DNS.

-hadriel

> Eric Burger
> Sent: Sunday, March 28, 2010 12:09 PM
> To: Dean Willis
> 
> I hope the logical conclusion from the argument below is NOT that since
> many of these use cases could be used on the Internet but will be used in
> private networks, the people that want to do this work decide to do it
> outside of the IETF.
>

---

From: [email-masked]
Date: Sun, 28 Mar 2010 18:38:04 +0100

> No, I would agree that would be bad - instead, a few of us have been
> talking about possibly offering a Plan-B to the IETF: a separate 
> database for ENUM.
> Same protocol on the wire, but for a different port number than 53, 
> and only for E.164 to Foo resolution, not domain names.  Whether 
> there'd be a global root or not is debatable, but we'd split out from 
The DNS.
> 
> That way we could have unused, send-N, cnam, source-uri, and 
> anything else we actually need for ENUM but that the IETF is 
> concerned about adding to The DNS.

Ultimately as a DNS head I simply canott support this - the idea of what 
_would_ in effect be an alternate DNS root is anathema to me.

Ray

---

From: [email-masked]
Date: Sun, 28 Mar 2010 18:40:52 +0100

> canott

Wow, jetlag does weird things :(

Ray

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 28 Mar 2010 13:44:32 -0400

I don't think it's an alternate root for DNS.  It happens to use the protocol mechanics/syntax of DNS, but it's not used for Domain Name resolution - just E.164 number resolution.

-hadriel

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, March 28, 2010 1:38 PM
To: Hadriel Kaplan
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling

> there'd be a global root or not is debatable, but we'd split out from The DNS.
>

Ultimately as a DNS head I simply canott support this - the idea of what _would_ in effect be an alternate DNS root is anathema to me.

Ray

---

From: Lawrence Conroy <[email-masked]>
Date: Sun, 28 Mar 2010 20:44:58 +0100

Hi Eric, folks,
 Wasn't that the intent?
I don't have any other logical interpretation I can put on this thread.

The alternatives of being forced to use other ports, or doing
anything like that, is absurd, and evil (i.e. bad and wrong).
ENUM works quite nicely on the DNS on port 53, despite the surreal
and/or doom laden air. But it doesn't gain traction in the IETF.

As Dean says, it takes a people to make a pope (or three).
We are not the people, ergo ...

all the best,
  Lawrence

---

From: Dean Willis <[email-masked]>
Date: Mon, 29 Mar 2010 01:19:21 -0500

> and/or doom laden air. But it doesn't gain traction in the IETF.

I suspect that part of the problem is that ENUM isn't REALLY in "the 
DNS". Some IETFers probably feel like they bent over backsards to put 
phone numbers into the scope of the Internet, and then the phone 
oeprators went and did these private ENUM things (which might use DNS 
technology but aren't "the DNS"), thereby making a walled-garden even 
more walled. Why should we do funky things to a core Internet technology 
in order to facilitate the priavte non-Internet use of somebody who has 
already proven not to be working on the best interest of the Internet?

That said, there are people in the IETF who are interested in providing 
a high-speed distributed hierarchical database for phone-numbers and 
related data.  However, those people just don't constitue a large enough 
chunk of the DNS leadership to be able to make changes to the DNS. But a 
  closely-related technology that uses lessons learns fom the DNS but 
that is itself not the DNS would probably make the metadata problem more 
attractive to the IETF DNS pundits.

--
Dean

---

From: Jay Daley <[email-masked]>
Date: Mon, 29 Mar 2010 21:02:26 +1300

On 29/03/2010, at 7:19 PM, Dean Willis wrote:

> I suspect that part of the problem is that ENUM isn't REALLY in "the DNS". Some IETFers probably feel like they bent over backsards to put phone numbers into the scope of the Internet, and then the phone oeprators went and did these private ENUM things (which might use DNS technology but aren't "the DNS"), thereby making a walled-garden even more walled. Why should we do funky things to a core Internet technology in order to facilitate the priavte non-Internet use of somebody who has already proven not to be working on the best interest of the Internet?
> 
> That said, there are people in the IETF who are interested in providing a high-speed distributed hierarchical database for phone-numbers and related data.  However, those people just don't constitue a large enough chunk of the DNS leadership to be able to make changes to the DNS. But a  closely-related technology that uses lessons learns fom the DNS but that is itself not the DNS would probably make the metadata problem more attractive to the IETF DNS pundits.

I finally understand where you are coming from!  There is so much to pick up on in your post that this is quite a long response, apologies in advance for that.

1.  ENUM did not originate with carriers trying to pollute the Internet and the IETF did not bend over backwards to put phone numbers onto the Internet.  Quite the opposite.  There was a lot of opposition to ENUM from ITU types as they saw it as a cunning IETF plot to take over telephony.   

There are many public ENUM trees (at the country code level), it is hard to see what is really more in the DNS than that.  The success of ENUM in a private context is surprising given the original hostility to ENUM from some carriers, but is not an indication that this is a private protocol.

Carriers are not working against the best interests of the Internet, they are just trying to bring their experience, their values and their way of working to the Internet.  You might disagree with those but nobody holds the keys to the Internet, that is the whole point.

2.  You are confusing 'the DNS' with 'the IANA root'.   You are right to describe the use of ENUM in private networks as a walled garden but for the wrong reasons.   It is not the private use of an Internet protocol you should be blaming as that happens everywhere in other contexts.  For example EPP is only ever used within a contractual framework.  There is no such thing as a public EPP server.  What is 'walled' about private ENUM is the data in those trees.

What I want from e2md and many others I suspect also want, is to get that data out into the open.  Probably not in the e164.arpa tree but certainly the public DNS. 

3.  I don't mean to be rude but I don't think you understand DNS at all.  For a start we are not taking about making changes to the DNS at all because NAPTR already exists.   All we are talking about it a standard data representation within NAPTR.  To suggest creating a technology that is similar to DNS but is not DNS is both impractical as it means an extraordinary volume of work and unnecessary because DNS and ENUM already exists.

It appears to me from your statements above that all the various objections, rat holes, mis-respresentations and distractions that you have raised on this list are entirely of a political layer-9 origin and in no way technical.  Ironic since it the IETF way that you claim to be defending.

regards
Jay

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

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 29 Mar 2010 13:36:24 +0200

> 1) The ability to, in the resolution request, to specify which
> serviceType-SubType pairs the querier is interested in.  This is useful
> for more than one reason (allowing a specific querier to vary the
> content of their response per query, without requiring them to use a
> different root domain).  Right now this is done via other means, some of
> which Hadriel has described.  But, again, ***this item is a broader
> subject and should definitely be handled as a separate discussion
> track***.

Unless we tinker with the guts of the DNS architecture, we're limited to
the Query-Name, Query-Type and Query-Class triplet. While it's in theory
possible to add some magic to certain values of Types or Class, I doubt
this is the right path. Then there is the atomicity of RRset to consider.

> 2) The ability to determine the "source" of the query in a standardized
> manner.  Hadriel has a proposal out there on a way to do this.  But,
> again, ***this is a broader subject and should definitely be handled as
> a separate discussion track***.

Again, this requirement contradicts one of the core design principles of
the DNS architecture.

Yes, Hadrian's draft provides an idea on how one could retrofit the DNS to
accommodate this wish, but that's a very ugly hack.

IMHO we need a requirements document to determine whether the DNS path is
the right one.

otmar

---

From: Jim Reid <[email-masked]>
Date: Mon, 29 Mar 2010 13:28:41 +0100

> IMHO we need a requirements document to determine whether the DNS  

Amen! And if DNS is not the right path to take, the requirements/use  
case(s) document should explain why.

---

From: [email-masked]
Date: Mon, 29 Mar 2010 14:00:01 +0100

> It appears to me from your statements above that all the various 
> objections, rat holes, mis-respresentations and distractions that 
> you have raised on this list are entirely of a political layer-9 
> origin and in no way technical.

I'm 100% convinced that you are correct, and mutterings around the meeting 
last week back that up.

We have some defined use cases, and some undefined ones, all of which fit 
to a varying degree to the ENUM model and hence within DNS, whether that 
be public or walled-garden or somewhere in between.

Despite the misleading statements made by some, there is no protocol _or_ 
deployment police for the DNS.  The concern of the IESG and IAB should be 
to ensure interoperability and scalability, and to facilitate 
standardisation efforts thereto.  It should _not_ be for certain members 
to apparently try to actively _prevent_ the effort simply because some 
purists simply "don't like" the technology.  As yet there has been _no_ 
sound technical justification against doing this work.  All we're hearing 
is FUD, and even then it's third hand.

I do agree that NAPTR is slightly limiting because within DDDS we are 
unable to query on service type.  Well, frankly, that's tough.  It's old 
news.  It's how the IETF defined it, and it's pretty much all we've got. 
However that does not justify blocking future work just because it happens 
to specify NAPTRs.

kind regards,

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 29 Mar 2010 11:12:56 -0400

That's also the way I see it.

Ken

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Sunday, March 28, 2010 1:45 PM
To: [email-masked]
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling

-hadriel

Ray

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 29 Mar 2010 11:25:36 -0400

I'd tend to agree with most of what Jay has said below.

The only exception being that my goal of supporting E2U and E2M is not to "get this data out in the open" (and I'm not entirely sure what you mean by that), but is instead to enable existing use cases in a more standardized, and more fully baked manner.

Getting data "out in the open" is a more of a policy decision that the IETF does not really play a role in.  But creating technical standards for enabling use cases in a more standardized and fully baked fashion is definitely the role of the IETF.

Ken

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jay Daley
Sent: Monday, March 29, 2010 4:02 AM
To: Dean Willis
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling

regards
Jay

--
Dean

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

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 29 Mar 2010 11:35:58 -0400

I agree that we need a requirements document.  Source identification and differing responses based on the source is already being done today on a very large scale basis, using non-standard schemes.  But I'm fully aware that some of the DNS purists feel that this is anathema to DNS.  I see both sides of this, the principled/theoretical points of view and the practical more immediate term points of view.  We have these needs *today* and are solving these problems *today*.

As you probably know, if you have applications in the field you typically need two tracks that you are working, the near term track based on the immediate practical needs, *and* the mid to long term track based on a more elegant and broader set of principles and theories.  I have to understand appreciate both.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Otmar Lendl
Sent: Monday, March 29, 2010 7:36 AM
To: [email-masked]
Subject: Re: [e2md] alt structure suggested for CNAM

otmar

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 29 Mar 2010 11:38:38 -0400

I agree with this Ray's points below. (Is "agreeing" adding value?  :), I think so.)

Ken

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 29, 2010 9:00 AM
To: Jay Daley
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling

> origin and in no way technical.

I'm 100% convinced that you are correct, and mutterings around the meeting last week back that up.

We have some defined use cases, and some undefined ones, all of which fit to a varying degree to the ENUM model and hence within DNS, whether that be public or walled-garden or somewhere in between.

Despite the misleading statements made by some, there is no protocol _or_ deployment police for the DNS.  The concern of the IESG and IAB should be to ensure interoperability and scalability, and to facilitate standardisation efforts thereto.  It should _not_ be for certain members to apparently try to actively _prevent_ the effort simply because some purists simply "don't like" the technology.  As yet there has been _no_ sound technical justification against doing this work.  All we're hearing is FUD, and even then it's third hand.

I do agree that NAPTR is slightly limiting because within DDDS we are unable to query on service type.  Well, frankly, that's tough.  It's old news.  It's how the IETF defined it, and it's pretty much all we've got.  However that does not justify blocking future work just because it happens to specify NAPTRs.

kind regards,

Ray

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Mar 2010 11:47:25 -0400

I've been keeping out of this, but I just can't any longer...

> Different organizations use different CNAM data providers.  So they configure their systems to access the CNAM data source that they have decided/agreed/contracted/paid to use (if any).  However, i…

The above approach seems to be to be entirely contrary to the philosophy 
behind DNS.

At the very least, the server(s) that are authoritative for a given DNS 
name should be independent of who is asking.

I guess that can still be honored by using a distinct ENUM root for the 
lookup. But then, what is the *meaning* of looking up CNAM for a 
particular phone number against two different ENUM roots? Are those to 
be considered two different phone number namespaces, each with its own 
CNAM, that might potentially differ from the others? I presume not.

Apparently what you are saying is that CNAM retrieved from A.B.C.Root1 
means the same as from A.B.C.Root2 except that there is different access 
and different billing for making the query. Is that right?

Suppose that were applied to other aspects of DNS, like A records. I 
think much of the world would (rightfully) go ballistic if that were 
proposed.

	Thanks,
	Paul

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 29 Mar 2010 11:48:16 -0400

I agree that we need a CNAM "requirements" document.  However, I think what we are talking about should not be just about CNAM.  If you were to solve CNAM in isolation you would do it one way, but if you were to solve it within the VoIP/Telecom/Internet ecosystem you would solve it another.

Imo, the framework approach, of which DDDS is one, is the correct way to go.

Ken

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 29 Mar 2010 11:58:46 -0400

I understand your point of view.  And CNAM data could theoretically work the way you are suggesting (and maybe one day it will).  However, that is not the current business/policy model that underlies much of the CNAM usage scenarios.  Trying to impose the public domain name lookup business/policy model on all data that could be queried using some of the DNS technologies is probably not a good stance.  I think the technology should not get in the way of either business model, and the IETF's role, in my opinion, is not to impose one or the other.  Your vision is more purist, which is great and elegant, but is not the only one and is not necessitated by the technologies that underlie DNS.

Furthermore, there is a lot of meta-data around the public DNS's domain names and domain name data bases that is also only provided to those that either pay for it or have the legal authority to have access to it.

Ken

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Monday, March 29, 2010 11:47 AM
To: Cartwright, Kenneth
Cc: Dean Willis; [email-masked]; list
Subject: Re: [e2md] alt structure suggested for CNAM

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Mar 2010 12:15:51 -0400

> Furthermore, there is a lot of meta-data around the public DNS's domain names and domain name data bases that is also only provided to those that either pay for it or have the legal authority to ha…

And how is the "meta-data around the public DNS's domain names and 
domain name data bases that is also only provided to those that either 
pay for it or have the legal authority to have access to it" accessed 
today?

Presumably not via DNS queries.

So maybe it would be appropriate to look at how that is dealt with to 
find a corresponding approach for e2md.

	Thanks,
	Paul

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 29 Mar 2010 12:47:01 -0400

Well obviously I agree with the earlier remarks from Hadriel and Eric
Berger.  What some folks in the room IMHO did not seem to understand is that
the E2MD work is necessary to make SIP work better. This is not a DNS issue
at all .. the use of 3761 technology is simply the hammer and a very very
good one at that. It works its gobally deployed in various forms. As SIP has
fully deployed it is necessary to create more rational and more cost
effective ways of accessing what is traditionally PSTN data objects. This
whole business is being driven by cost avoidance specifically the avoidance
of TCAP dips and cost of the SS7/C7 A-links etc.

If the IETF does not confront the larger issue of SIP/PSTN interworking it
will get solved but probably somewhere else and the result would be an even
worse hack that what we have out in the field right now.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
Willis
Sent: Monday, March 29, 2010 2:19 AM
To: Lawrence Conroy
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling

--
Dean

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 29 Mar 2010 12:49:31 -0400

RS> Oh please we are long past the need for some superfluous requirements
document. What is clear to me is we are not going to invent something new
and what we have clearly works well in the field and scales very well. All I
want is a clear syntax.

otmar

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Mar 2010 13:41:12 -0400

Richard,

Its one thing to say "I want to use a hammer to drive screws".
I think the hammer manufacturer cannot forbid you from doing that, even 
if it thinks the use unwise, and voids the warranty.

Its another thing to demand changes in the design of the hammer to 
enhance its ability to hammer a wider variety of fasteners, such as nuts 
and bolts. The hammer manufacturer has every right to refuse to make 
such a change on the basis that it is outside the scope of applicability 
of the hammer design.

	Thanks,
	Paul

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 29 Mar 2010 14:06:01 -0400

Hi Paul,

You bring up a somewhat valid analogy about how "meta-data" is accessed for domain names resolved within "The DNS".

1) As I've mentioned in previous emails, there are different technologies that can be applied to the meta-data problem.  And the technologies that underlie the DNS are one such set.  And, imo, the simple fact that they underlie the DNS does not, therefore, make them off base for application outside the DNS.  That being said, however, meta-data around the domain names that are resolved via "The DNS" are not typically looked up via the technologies that underlie DNS (at least in the US).  However, as some have pointed out in response to my previous statements about this fact, some of the key use cases being considered here *will* benefit greatly from the use of the technologies that underlie the DNS as apposed to the technologies that underlie things like WhoIs, EPP, etc.  Furthermore, the unused and send-n use cases are, imo, extremely coupled with the concept of resolving a TN (which today is typically done using DNS based technologies).
2) But on the broader point, I assume that you are not suggesting that there is some person or company that should be the decider of what business models and associated policy sets are *allowed* to use the technologies that underlie the DNS.  The reason I assume that you do not mean to imply that is because that seems an untenable position to be taking.  I think you must mean something else.

Thanks
Ken

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Monday, March 29, 2010 12:16 PM
To: Cartwright, Kenneth
Cc: Dean Willis; [email-masked]; list
Subject: Re: [e2md] alt structure suggested for CNAM

        Thanks,
        Paul

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 29 Mar 2010 14:12:16 -0400

The Hammer/ScrewDriver analogy can only be taken so far.  This discussion has now become too vague.  I've lost track of what is the Hammer?  Is DDDS the hammer?

Why can't DDDS be extended?  Or why can't additional standards be created and *optionally* used in conjunction with DDDS?  This is what we are talking about, imo.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Monday, March 29, 2010 1:41 PM
To: Richard Shockey
Cc: 'E.164 To MetaData BOF discussion list'
Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling

Richard,

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Mar 2010 14:25:39 -0400

Cartwright, Kenneth wrote:
> 1) As I've mentioned in previous emails, there are different technologies that can be applied to the meta-data problem.  And the technologies that underlie the DNS are one such set.  And, imo, the simple fact that they underlie the DNS does not, therefore, make them off base for application outside the DNS.  

> That being said, however, meta-data around the domain names that are resolved via "The DNS" are not typically looked up via the technologies that underlie DNS (at least in the US). 

I think that is not an accident.
It should perhaps be viewed as a word to the wise.

> However, as some have pointed out in response to my previous statements about this fact, some of the key use cases being considered here *will* benefit greatly from the use of the technologies that underlie the DNS as apposed to the technologies that underlie things like WhoIs, EPP, etc.  Furthermore, the unused and send-n use cases are, imo, extremely coupled with the concept of resolving a TN (which today is typically done using DNS based technologies).

ISTM that *some* of these metadata issues should indeed apply to the DNS 
as a whole, with common applicable solutions.

However, some of the existing solutions may be a bit "long in the tooth" 
and not applicable unless replaced or modernized. Nevertheless, ISTM 
that it would be worth considering how many of these metadata things are 
indeed common problems. CNAM seems like one that might be.

> 2) But on the broader point, I assume that you are not suggesting that there is some person or company that should be the decider of what business models and associated policy sets are *allowed* to…

No, I'm not suggesting that.

But IIUC the current proposals are to use and extend things that are 
governed by RFCs that make up "the DNS". I'm not up on what the existing 
rules are for extension of those things. But I presume one way or 
another it will come to some kind of standards action that will require 
"rough consensus", and the community in which that consensus must be 
achieved will be the "DNS community" rather than just the "e2md" 
community. Hence the bar is higher.

(If the rule is actually that anybody can put anything into a NAPTR or 
RR on a FCFS basis with no community approval, then I guess e2md has a 
much freer hand.)

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Mon, 29 Mar 2010 13:55:35 -0500

On Mar 29, 2010, at 1:06 PM, Cartwright, Kenneth wrote:

>
> Hi Paul,
>
> You bring up a somewhat valid analogy about how "meta-data" is  
> accessed for domain names resolved within "The DNS".
>
> 1) As I've mentioned in previous emails, there are different  
> technologies that can be applied to the meta-data problem.  And the  
> technologies that underlie the DNS are one such set.  And, imo, the  
> simple fact that they underlie the DNS does not, therefore, make  
> them off base for application outside the DNS.

But we are asking the DNS directorate to authorize the making of such  
changes. That's the root of the problem. What Hadriel has suggested is  
taking an alt-root approach by saying "We're using technologies  
derived from DNS, but not extending "The DNS" itself.

> That being said, however, meta-data around the domain names that are  
> resolved via "The DNS" are not typically looked up via the  
> technologies that underlie DNS (at least in the US).  However, as  
> some have pointed out in response to my previous statements about  
> this fact, some of the key use cases being considered here *will*  
> benefit greatly from the use of the technologies that underlie the  
> DNS as apposed to the technologies that underlie things like WhoIs,  
> EPP, etc.  Furthermore, the unused and send-n use cases are, imo,  
> extremely coupled with the concept of resolving a TN (which today is  
> typically done using DNS based technologies).

> 2) But on the broader point, I assume that you are not suggesting  
> that there is some person or company that should be the decider of  
> what business models and associated policy sets are *allowed* to use  
> the technologies that underlie the DNS.  The reason I assume that  
> you do not mean to imply that is because that seems an untenable  
> position to be taking.  I think you must mean something else.

The IETF's position is that the IETF IS the decider on what  
technologies are specified by the IETF. Their work process  
specifically establishes criteria for new work in general, and more  
specifically around DNS work. They have every right to say "no".  So  
far, they haven't said "no", but they have said we haven't made a  
strong enough case.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 29 Mar 2010 14:02:24 -0500

On Mar 29, 2010, at 3:02 AM, Jay Daley wrote:
> origin and in no way technical.  Ironic since it the IETF way that  
> you claim to be defending.
>

Ok, I've had just about enough of this. I'm tired of being personally  
attacked for relaying things that various community influencers,  
primarily current/former IESG/IAB members, have told me OR TOLD THE  
E2MD COMMUNITY DURING OUR BOF about why they don't like the E2MD  
proposal. Or at least listen to the recording of the meeting, or read  
the draft minutes that I typed up and circulated for you.

I'm not making this stuff up. If you don't like the way I'm relaying  
it, go take it up with the IAB and IESG yourself.

--
Dean

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 29 Mar 2010 15:10:38 -0400

Your replies below do not seem to directly relate to the points I was making.  So I'll just say

1) Yes I understand what Hadriel is proposing and am fine with it
2) Yes I understand and agree with the fact that the IETF evaluates technologies around the DNS, but I think that the IETF should definitely not be deciding what business models and associated policies are allowed to use those technologies.  That is the job of the regulators (e.g. ICANN, et.al.) and the market place.

Given my limited time to devote to discussions like this I need to now bow out of this line of discussion about the role of the IETF and the relationship between "The DNS" and the technologies that underlie the DNS.  Others are probably better suited to that discussion anyway.

Ken

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Monday, March 29, 2010 2:56 PM
To: Cartwright, Kenneth
Cc: Paul Kyzivat; [email-masked]; list
Subject: Re: [e2md] alt structure suggested for CNAM

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 29 Mar 2010 14:19:38 -0500

On Mar 29, 2010, at 8:00 AM, [email-masked] wrote:

>
> Despite the misleading statements made by some, there is no protocol  
> _or_ deployment police for the DNS.  The concern of the IESG and IAB  
> should be to ensure interoperability and scalability, and to  
> facilitate standardisation efforts thereto.  It should _not_ be for  
> certain members to apparently try to actively _prevent_ the effort  
> simply because some purists simply "don't like" the technology.  As  
> yet there has been _no_ sound technical justification against doing  
> this work.  All we're hearing is FUD, and even then it's third hand.

Third hand? You were sitting there with me, and Hadriel, and Bernie,  
and Brian Rosen, while Jon Peterson explained his objections.

You were also in the BOF, right?  You heard Peter and Olaf and Jon and  
John Klensin rip up the proposed work? Did you disagree with what went  
into the draft minutes I posted, wherein we attempted to establish  
"what was said" so that it isn't all 3rd hand innuendo?

Now you might technically disagree with them. You might well be right  
to do so; I technically disagree with many of these people on a  
regular basis, and I hope I'm at least occasionally "right" when doing  
so.

But the IETF work process is what it is. There are limited resources  
available in the IETF, and new work gets chartered only if it meets  
the requirements of community consensus, WHERE THAT CONSENSUS IS  
DETERMINED BY THE IESG BASED ON COMMUNITY INPUT AND WITH ADVICE FROM  
THE IAB.

RFC 2418 spells out this process. Specifically, you might wish to  
eyeball section 2.1.

>
> I do agree that NAPTR is slightly limiting because within DDDS we  
> are unable to query on service type.  Well, frankly, that's tough.   
> It's old news.  It's how the IETF defined it, and it's pretty much  
> all we've got.  However that does not justify blocking future work  
> just because it happens to specify NAPTRs.
>

Several ADs pointed out that nothing is preventing the development of  
a new and more appropriate resource record type.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 29 Mar 2010 15:39:56 -0400

Most carriers I've talked to were not hostile to ENUM using DNS the protocol - they were hostile to the data being put in The DNS.  They actually like the properties of the protocol, a lot.

I think you misunderstand Dean - he's being the messenger, not the source.  That's part of his role as the BOF Chair.

3.  I don't mean to be rude but I don't think you understand DNS at all.  For a start we are not taking about making changes to the DNS at all because NAPTR already exists.   All we are talking about it a standard data representation within NAPTR.

Actually he's relaying the comments he got from other IETF folks, again as his role as BOF Chair and trying to help us move forward.  And for some of the mechanisms we need for ENUM, some IETF members appear to feel it is a change to The DNS.  Not a change to the protocol, perhaps, but to the database.  We've heard it consistently for the past 2 years: "this stuff doesn't belong in The DNS".  I and you and others feel there's nothing wrong with putting the data we want into The DNS, but if we have to get every piece of data we want past a consensus call as well as the IESG, then we should to listen to them.

-hadriel

---

From: Jay Daley <[email-masked]>
Date: Tue, 30 Mar 2010 08:44:58 +1300

On 30/03/2010, at 4:25 AM, Cartwright, Kenneth wrote:

> I’d tend to agree with most of what Jay has said below.
>  
> The only exception being that my goal of supporting E2U and E2M is not to “get this data out in the open” (and I’m not entirely sure what you mean by that), but is instead to enable existing use cases in a more standardized, and more fully baked manner.
>  
> Getting data “out in the open” is a more of a policy decision that the IETF does not really play a role in.  But creating technical standards for enabling use cases in a more standardized and fully baked fashion is definitely the role of the IETF.

Apologies, I do agree but I'd already written too much by then to explain this properly.  

cheers
Jay

---

From: Dean Willis <[email-masked]>
Date: Mon, 29 Mar 2010 14:46:15 -0500

On Mar 29, 2010, at 2:39 PM, Hadriel Kaplan wrote:

> 1.  ENUM did not originate with carriers trying to pollute the  
> Internet and the IETF did not bend over backwards to put phone  
> numbers onto the Internet.  Quite the opposite.  There was a lot of  
> opposition to ENUM from ITU types as they saw it as a cunning IETF  
> plot to take over telephony.
> There are many public ENUM trees (at the country code level), it is  
> hard to see what is really more in the DNS than that.  The success  
> of ENUM in a private context is surprising given the original  
> hostility to ENUM from some carriers, but is not an indication that  
> this is a private protocol.
>
> Most carriers I’ve talked to were not hostile to ENUM using DNS the  
> protocol – they were hostile to the data being put in The DNS.  They  
> actually like the properties of the protocol, a lot.
>
> Carriers are not working against the best interests of the Internet,  
> they are just trying to bring their experience, their values and  
> their way of working to the Internet.  You might disagree with those  
> but nobody holds the keys to the Internet, that is the whole point.
>
> I think you misunderstand Dean – he’s being the messenger, not the  
> source.  That’s part of his role as the BOF Chair.
>
> 3.  I don't mean to be rude but I don't think you understand DNS at  
> all.  For a start we are not taking about making changes to the DNS  
> at all because NAPTR already exists.   All we are talking about it a  
> standard data representation within NAPTR.
>
> Actually he’s relaying the comments he got from other IETF folks,  
> again as his role as BOF Chair and trying to help us move forward.   
> And for some of the mechanisms we need for ENUM, some IETF members  
> appear to feel it is a change to The DNS.  Not a change to the  
> protocol, perhaps, but to the database.  We’ve heard it consistently  
> for the past 2 years: “this stuff doesn’t belong in The DNS”.  I and  
> you and others feel there’s nothing wrong with putting the data we  
> want into The DNS, but if we have to get every piece of data we want  
> past a consensus call as well as the IESG, then we should to listen  
> to them.
>
>

Thank you, Hadriel!

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 29 Mar 2010 15:47:40 -0400

> Otmar Lendl

Huh, I thought is was an elegant hack. :)
It's not changing the structure of DNS - it just gives the server additional data with which it can filter the response.  I.e., the server has a big list of matching NAPTRs for the query key, but the extension gives it a filter to apply to reduce the set it gives back in the response. 

-hadriel
p.s., it's "Hadriel" - hopefully my comments have not created a wall in Britain. ;)

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 29 Mar 2010 15:48:03 -0400

Point taken.  :-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Monday, March 29, 2010 3:46 PM
To: Hadriel Kaplan
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling

On Mar 29, 2010, at 2:39 PM, Hadriel Kaplan wrote:

> Most carriers I've talked to were not hostile to ENUM using DNS the
> protocol - they were hostile to the data being put in The DNS.  They
> I think you misunderstand Dean - he's being the messenger, not the
> source.  That's part of his role as the BOF Chair.
>
> Actually he's relaying the comments he got from other IETF folks,
> protocol, perhaps, but to the database.  We've heard it consistently
> for the past 2 years: "this stuff doesn't belong in The DNS".  I and
> you and others feel there's nothing wrong with putting the data we

Thank you, Hadriel!

---

From: Jay Daley <[email-masked]>
Date: Tue, 30 Mar 2010 08:59:35 +1300

On 30/03/2010, at 8:39 AM, Hadriel Kaplan wrote:

> 
> Most carriers I’ve talked to were not hostile to ENUM using DNS the protocol – they were hostile to the data being put in The DNS.  They actually like the properties of the protocol, a lot.

Very different from the echoes I heard - "it doesn't have channel security", "it doesn't have guaranteed delivery", "it doesn't have deterministic response times", "the data is in a weird (i.e. non-XML) format" and so on.

> I think you misunderstand Dean – he’s being the messenger, not the source.  That’s part of his role as the BOF Chair.

Sorry but that is just not the case.  If that was solely the voice of the messenger and not his own views then I'll put on a frilly dress and sing the Marseillaise on the Wellington waterfront.  I can sleep soundly knowing that won't happen.

> Actually he’s relaying the comments he got from other IETF folks, again as his role as BOF Chair and trying to help us move forward.  And for some of the mechanisms we need for ENUM, some IETF members appear to feel it is a change to The DNS.  Not a change to the protocol, perhaps, but to the database.  We’ve heard it consistently for the past 2 years: “this stuff doesn’t belong in The DNS”.  I and you and others feel there’s nothing wrong with putting the data we want into The DNS, but if we have to get every piece of data we want past a consensus call as well as the IESG, then we should to listen to them.

I can understand that some people think it is a change to the database not the protocol but that is a sophisticated view, not related to what Dean is saying and does not change my view that Dean does not understand DNS at all, there is too much clear evidence to support that.

You and I know that when someone says "put it into a TXT record" that means two things:

1.  They're not objecting to a change in the database, because if they were then they would not suggest keeping the same data in DNS.
2.  They don't understand DNS.

best
Jay

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 29 Mar 2010 16:13:41 -0400

As for Dean ..No we should not shoot the messenger ..especially one that has
so many guns.  I wish there was some focus here on what the problem is. How
do we help SIP network operators work better. There is a clear and
demonstrable problem that needs to be addressed in SIP PSTN interworking.
The discussion is getting wrapped up in orthogonal arguments about what is
and is not appropriate use of DNS technology.

I almost got the sense in the BOF that folks thought ENUM itself was a
mistake.  I know John Klensin almost wishes he had never heard the word J
We have a mechanism for translating E.164 keys into FOO and it works quite
well.  We need a mechanism that translates E.164 numbers into other types of
FOO otherwise SIP does not work as well as it should. 

An alternate port IMHO solves a load of problems and I don't see any problem
with that.  What I have a problem with is bashing up the proposed solutions
here without understanding what problem we are trying to fix.

This alternate use of DNS technology is well understood and widely deployed.
Gee we have split DNS right?

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Monday, March 29, 2010 3:40 PM
To: Jay Daley; Dean Willis
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jay
Daley
Sent: Monday, March 29, 2010 4:02 AM
To: Dean Willis

1.  ENUM did not originate with carriers trying to pollute the Internet and
the IETF did not bend over backwards to put phone numbers onto the Internet.
Quite the opposite.  There was a lot of opposition to ENUM from ITU types as
they saw it as a cunning IETF plot to take over telephony.   

There are many public ENUM trees (at the country code level), it is hard to
see what is really more in the DNS than that.  The success of ENUM in a
private context is surprising given the original hostility to ENUM from some
carriers, but is not an indication that this is a private protocol.

Most carriers I've talked to were not hostile to ENUM using DNS the protocol
- they were hostile to the data being put in The DNS.  They actually like
the properties of the protocol, a lot.

Carriers are not working against the best interests of the Internet, they
are just trying to bring their experience, their values and their way of
working to the Internet.  You might disagree with those but nobody holds the
keys to the Internet, that is the whole point.

I think you misunderstand Dean - he's being the messenger, not the source.
That's part of his role as the BOF Chair.

3.  I don't mean to be rude but I don't think you understand DNS at all.
For a start we are not taking about making changes to the DNS at all because
NAPTR already exists.   All we are talking about it a standard data
representation within NAPTR.  

Actually he's relaying the comments he got from other IETF folks, again as
his role as BOF Chair and trying to help us move forward.  And for some of
the mechanisms we need for ENUM, some IETF members appear to feel it is a
change to The DNS.  Not a change to the protocol, perhaps, but to the
database.  We've heard it consistently for the past 2 years: "this stuff
doesn't belong in The DNS".  I and you and others feel there's nothing wrong
with putting the data we want into The DNS, but if we have to get every
piece of data we want past a consensus call as well as the IESG, then we
should to listen to them.

-hadriel

---

From: Jay Daley <[email-masked]>
Date: Tue, 30 Mar 2010 09:18:48 +1300

> That way we could have unused, send-N, cnam, source-uri, and anything else we actually need for ENUM but that the IETF is concerned about adding to The DNS.

This proposal confuses DNS with the IANA root.  To help you understand this, think of the IANA root as the database and DNS as the protocol.  If you want to move the data out of the database then you move to a different database - i.e. another root or another branch (e164md.arpa?) - not to another protocol.

What you also appear to doing - and yes there is a bit of a leap here - is laying claim that NAPTR belongs to SIP and if we want to use it for something else then we have to go elsewhere.  Not only do we have to move to another database but we have to move to another protocol entirely.

kind regards
Jay

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 29 Mar 2010 16:19:20 -0400

That's also the way I viewed it.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Monday, March 29, 2010 3:48 PM
To: Otmar Lendl; [email-masked]
Subject: Re: [e2md] alt structure suggested for CNAM

-hadriel

---

From: Jay Daley <[email-masked]>
Date: Tue, 30 Mar 2010 09:30:19 +1300

On 30/03/2010, at 9:13 AM, Richard Shockey wrote:

> As for Dean ..No we should not shoot the messenger ..especially one that has so many guns.  I wish there was some focus here on what the problem is. How do we help SIP network operators work better. There is a clear and demonstrable problem that needs to be addressed in SIP PSTN interworking.  The discussion is getting wrapped up in orthogonal arguments about what is and is not appropriate use of DNS technology.
>  
> I almost got the sense in the BOF that folks thought ENUM itself was a mistake.  

Even for me who was not at the BOF that is coming across loud and clear.

It doesn't take much thought to recognise now, with hindsight of course, that the real culprit is NAPTR.  It creates a database within a database without the mechanism to selectively retrieve data from that second database. (in other words, you get all the NAPTRs in one go).  Either we accept that and make it easy to process, which is where the distinction between "e2u" and "e2md" is sufficient in my mind, or we put the data under different domains such as 

_e2md.7.7.9.6.1.3.9.4.4.6.e164.arpa  (which Dean? suggested previously), or
7.7.9.6.1.3.9.4.4.6.e164md.arpa

best
Jay

> I know John Klensin almost wishes he had never heard the word J  We have a mechanism for translating E.164 keys into FOO and it works quite well.  We need a mechanism that translates E.164 numbers into other types of FOO otherwise SIP does not work as well as it should.
>  
> An alternate port IMHO solves a load of problems and I don’t see any problem with that.  What I have a problem with is bashing up the proposed solutions here without understanding what problem we are trying to fix.
>  
> This alternate use of DNS technology is well understood and widely deployed. Gee we have split DNS right?
>

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 29 Mar 2010 16:37:01 -0400

Now that maybe we're back on track, here's a rough re-statement of what one might like to see from this E2U/E2M infrastructure we are supposed to be talking about, notice how similar it is to DDDS, plus some orthogonal extensions:

1)  Have a standard query data structure for E2U and E2M from a *framework* perspective (DDDS and ENUM gives us this).
2)  Have a standard query response structure for E2U and E2M from a *framework* perspective (DDDS and ENUM gives us this).
3)  Have a standard query data structure for each E2U and E2M service within that framework (DDDS and ENUM gives us this).
4)  Have a standard query response structure for each E2U and E2M service within that framework (DDDS and ENUM gives us this).
5)  Have a standard way to identify the source of a query, both at the organization level, and down to the "device/node" level within an organization (Hadriel's proposal gives us this).
6)  Have the *option* to return both E2U and E2M service responses in a single query response (I think the E2M proposal did not forbid this).
7)  Continue to allow "Bind" to function as, at least, a proxy pass-through client for queries.  Iow, the base query request/response structure needs to be backward compatible with "Bind" (DDDS and ENUM gives us this).
8)  Continue to allow both UDP and TCP as the layer 3 protocol (DDDS and ENUM gives us this).
9)  Have a standard way for the querier to specify, per query, which E2U and/or E2M services it is interested in having in its query response (although this is less vital, this is already done to a lesser extent today, but via non-standard means) (however, Hadriel's proposal might also give us this).
10)  There is of course more detail that can be added, but it just gets too much for emails....

As you can tell, I very much like the framework approach that DDDS embodies, even though it has some shortcomings.  This is because a significant number of systems in existence today return data across multiple E2U and the proposed E2M services.  So using the same query/response framework greatly facilitates that type of situation.  So I'd like to see us stick with the framework approach offered by DDDS.  This question came up at the BOF (Should we use a framework or develop a separate dedicated, RR Type for each type of meta-data).

And as mentioned in previous emails, I've not really been a fan of the fact that we turn TNs into domain names to look them up.  In fact I think it's pretty humorous.  However, that is a more principled/theoretical issue, not a practical one.  If we were to move away from treating TNs as domain names at this point, that would be too drastic a change, just to be able to lookup CNAM, unused, etc.

Ken

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Monday, March 29, 2010 4:14 PM
To: 'Hadriel Kaplan'; 'Jay Daley'; 'Dean Willis'
Cc: 'E.164 To MetaData BOF discussion list'
Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling

I almost got the sense in the BOF that folks thought ENUM itself was a mistake.  I know John Klensin almost wishes he had never heard the word :)  We have a mechanism for translating E.164 keys into FOO and it works quite well.  We need a mechanism that translates E.164 numbers into other types of FOO otherwise SIP does not work as well as it should.

An alternate port IMHO solves a load of problems and I don't see any problem with that.  What I have a problem with is bashing up the proposed solutions here without understanding what problem we are trying to fix.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Mon, 29 Mar 2010 15:37:40 -0500

On Mar 29, 2010, at 2:59 PM, Jay Daley wrote:

> Sorry but that is just not the case.  If that was solely the voice  
> of the messenger and not his own views then I'll put on a frilly  
> dress and sing the Marseillaise on the Wellington waterfront.  I can  
> sleep soundly knowing that won't happen.
>

Aw c'mon. I want to see the video on YouTube.

Seriously, I really don't give a damn about E2MD -- I've just been  
trying to help out because I was asked to. I think we've got fairly  
reasonable use cases and in general supported formation of the group.  
I also think that "the opposition" has some arguments that need to be  
understood and addressed. I'm also finding some of these arguments to  
be compelling, enough so that I'm willing to concede they might well  
be correct on several points.

>> at all because NAPTR already exists.   All we are talking about it  
>> a standard data representation within NAPTR.
>>
>> protocol, perhaps, but to the database.  We’ve heard it  
>> consistently for the past 2 years: “this stuff doesn’t belong in  
>> The DNS”.  I and you and others feel there’s nothing wrong with  
>> putting the data we want into The DNS, but if we have to get every  
>> piece of data we want past a consensus call as well as the IESG,  
>> then we should to listen to them.
>
> I can understand that some people think it is a change to the  
> database not the protocol but that is a sophisticated view, not  
> related to what Dean is saying and does not change my view that Dean  
> does not understand DNS at all, there is too much clear evidence to  
> support that.
>

I suspect I was running DNS systems before you ever heard of the  
Internet.  At least I was doing so while you were doing PC support for  
a local government. Further I was certainly working on distributed  
directory problems while you were failing to advance your education at  
Sussex. I might be outdated, but you appear to be seriously  
uninformed, not to mention a trifle rude.

> 1.  They're not objecting to a change in the database, because if  
> they were then they would not suggest keeping the same data in DNS.

I suspect  you don't understand the concept of a strawman argument. I  
find it to be a useful technique to help identify points of agreement  
and disagreement in a community.

We had numerous people (John Klensin, Jon Peterson, and Patrik  
Fältström, among others) at IETF 77 telling us that we were using an  
inappropriate DNS record (NAPTR) for metadata. This suggests  
dissecting the usage to find out what's inappropriate about it. In the  
absence of any technical discussion (and no, shouting about how stupid  
people are being does not constitute substantive technical  
discussion), I found it useful to propose a model that had the  
properties people were saying we needed and that NAPTR didn't have;  
indeed, this elicited additional required properties (support for  
wildcarding) that had not arisen in earlier discussion.  Consequently,  
I believe this to have been a useful inquiry. I might add that I have  
found your participation, both in this forum and in private mail, to  
be substantially less useful in moving towards some sort of broader  
understanding and consensus.

I believe that "broader understanding and consensus" are things we  
need a lot more of if we wish this work to advance in the IETF. We  
need to have both absolute clarity within the community of interest  
AND a consensus understanding of the opposition's objections.

So far, we have neither.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 29 Mar 2010 15:49:13 -0500

> 7.7.9.6.1.3.9.4.4.6.e164md.arpa

I liked the first suggestion at the time that Bob Penfield made it  
(Dave Crocker independently suggested it), but I believe Otmar Lendl  
pointed out the fatal flaw with _prefixes during the discussion on the  
_displayname....TXT strawman. It doesn't work right with wildcarding.  
As Otmar said:

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

Jay's second alternative here doesn't have that limitation. It also is  
consistent with a suggestion that I believe John Klensin made during  
the BOF:  formally using a different root.

It still doesn't address the "framework" vs. "specific use case"  
question raised by Jon Peterson.  Nor does it address the repeatedly- 
raised question of differentiating between "metadata you need when  
setting up a call" and "metadata needed when answering a call". But it  
could well be a step forward.

--
Dean

---

From: Jay Daley <[email-masked]>
Date: Tue, 30 Mar 2010 09:52:20 +1300

On 30/03/2010, at 9:37 AM, Cartwright, Kenneth wrote:

> Now that maybe we’re back on track, here’s a rough re-statement of what one might like to see from this E2U/E2M infrastructure we are supposed to be talking about, notice how similar it is to DDDS, plus some orthogonal extensions:

Did you intentionally include E2U?

It seems to me that the list below addresses perceived issues with ENUM not just e2md and what comes from this is revised requirements for ENUM, not just  e2md.  If dealing with the lingering concerns over ENUM is what it takes to get e2md accepted then I would prefer that to an ongoing proxy struggle in e2md that is really about ENUM.

cheers
Jay

> 5)  Have a standard way to identify the source of a query, both at the organization level, and down to the "device/node" level within an organization (Hadriel’s proposal gives us this).
> 9)  Have a standard way for the querier to specify, per query, which E2U and/or E2M services it is interested in having in its query response (although this is less vital, this is already done to a lesser extent today, but via non-standard means) (however, Hadriel’s proposal might also give us this).
> 10)  There is of course more detail that can be added, but it just gets too much for emails….
>  
> And as mentioned in previous emails, I've not really been a fan of the fact that we turn TNs into domain names to look them up.  In fact I think it’s pretty humorous.  However, that is a more principled/theoretical issue, not a practical one.  If we were to move away from treating TNs as domain names at this point, that would be too drastic a change, just to be able to lookup CNAM, unused, etc.
>  
> Ken
>  
>  
> I almost got the sense in the BOF that folks thought ENUM itself was a mistake.  I know John Klensin almost wishes he had never heard the word J  We have a mechanism for translating E.164 keys into FOO and it works quite well.  We need a mechanism that translates E.164 numbers into other types of FOO otherwise SIP does not work as well as it should.
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 29 Mar 2010 16:52:47 -0400

> From: Jay Daley [mailto:[email-masked]]
> Sent: Monday, March 29, 2010 4:19 PM
> To: Hadriel Kaplan
> 
> This proposal confuses DNS with the IANA root.  To help you understand
> this, think of the IANA root as the database and DNS as the protocol.  If
> you want to move the data out of the database then you move to a different
> database - i.e. another root or another branch (e164md.arpa?) - not to
> another protocol.

Nope, I'm not confused, or at least I think I'm not. (does a crazy person know they're crazy? ;)

I was fully expecting to stipulate that it be a new separate root, if we needed a public root.  It just wasn't apparent to me there *were* many users of The public DNS database for E.164 resolution data.  I knew about the Austrian guys, but hadn't seen anything else.  (although in my defense I don't see everyone's config and only seem to get involved in cases where a private database is being used, so it's a self-fulfilling view)

I don't think moving to another branch alone will help, fwiw.  It would have to be a new root so we can get source-uri and such, and a new "protocol" just to get out from concerns of a real alt-root scenario.  But that new "protocol" would look exactly like the old protocol.  We'd just be sending to or listening on a different port number.  And we'd probably get it accepted more easily if we adopted a new TLD that got reserved from The DNS root as well, like ".enum" or some such. (ie, it would be reserved like the ones in rfc2606)

> What you also appear to doing - and yes there is a bit of a leap here - is
> laying claim that NAPTR belongs to SIP and if we want to use it for
> something else then we have to go elsewhere.  Not only do we have to move
> to another database but we have to move to another protocol entirely.

Oh, no I definitely didn't mean that.

-hadriel

---

From: Jay Daley <[email-masked]>
Date: Tue, 30 Mar 2010 09:53:07 +1300

On 30/03/2010, at 9:49 AM, Dean Willis wrote:

> I liked the first suggestion at the time that Bob Penfield made it (Dave Crocker independently suggested it), but I believe Otmar Lendl pointed out the fatal flaw with _prefixes during the discussion on the _displayname....TXT strawman. It doesn't work right with wildcarding. As Otmar said:

Sorry, I forgot about that.

Jay

> 
> 
>> 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
>> So unless the carrier delegates the ENUM space to the customer, the carrier
> Jay's second alternative here doesn't have that limitation. It also is consistent with a suggestion that I believe John Klensin made during the BOF:  formally using a different root.
> 
> It still doesn't address the "framework" vs. "specific use case" question raised by Jon Peterson.  Nor does it address the repeatedly-raised question of differentiating between "metadata you need when setting up a call" and "metadata needed when answering a call". But it could well be a step forward.
> 
> --
> Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Mar 2010 16:56:24 -0400

Cartwright, Kenneth wrote:

> 5)  Have a standard way to identify the source of a query, both at the 
> organization level, and down to the "device/node" level within an 
> organization (Hadriel’s proposal gives us this).

I must have missed it - what was Hadriel's proposal for this functionality?

(5) seems to imply:

5b) have a way to restrict the return of certain information, or vary 
the value returned, based on the identy of the query source

And that could be at odds with caching results and returning them to 
others until TTL has expired, depending on your identity model. How do 
you expect this to be handled?

	Thanks,
	Paul

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 29 Mar 2010 17:09:37 -0400

Hi Paul,

As you may know, source based responses are all already being done today on a wide scale, but in non-standard ways.  Hadriel's proposal is one designed to standardize and enhance this capability.  He would be better to convey the details.  And the relationship between the TTL settings (caching) and the needs of the ENUM application is a matter of policy.  And these two features are not at odds.

Ken

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Monday, March 29, 2010 4:56 PM
To: Cartwright, Kenneth
Cc: Richard Shockey; 'Hadriel Kaplan'; 'Jay Daley'; 'Dean Willis'; 'E.164 To MetaData BOF discussion list'
Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling

Cartwright, Kenneth wrote:

> organization (Hadriel's proposal gives us this).

(5) seems to imply:

        Thanks,
        Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 29 Mar 2010 17:17:18 -0400

An old one: draft-kaplan-enum-source-uri-00
It's expired, but we implemented support for it and it appears to be popular for some folks.  I've gotten several customer requests to re-submit this recently, so we can get an officially reserved code number and so it's not just an individual draft.

The results are not cached - the TTL is zero.

-hadriel

> Cc: Richard Shockey; Hadriel Kaplan; 'Jay Daley'; 'Dean Willis'; 'E.164 To
> MetaData BOF discussion list'

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Mar 2010 17:18:54 -0400

> As you may know, source based responses are all already being done today on a wide scale, but in non-standard ways.  Hadriel's proposal is one designed to standardize and enhance this capability.…

They can be at odds of there is an agent doing queries on behalf of 
multiple sources. The identity of the caching agent may be used in all 
cases, rather than the identity of the caching agent's client. This may 
or may not be the intended behavior.

It at least needs to be specified.

And of course it has the potential to degrade the value of caching.

	Thanks,
	Paul

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 29 Mar 2010 17:27:59 -0400

Hi Paul,

Your use case if course valid.  And you are correct to point out that one needs to pay attention to TTL (cache settings) when establishing any data query/retrieval infrastructure.  However, these two features are not at odds.  But they do have inter-dependence under some use cases.  Iow, this is a matter of policy.  As I said, this is already being done on a wide scale today.  Nothing new under the sun here.

Ken

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Monday, March 29, 2010 5:19 PM
To: Cartwright, Kenneth
Cc: Richard Shockey; 'Hadriel Kaplan'; 'Jay Daley'; 'Dean Willis'; 'E.164 To MetaData BOF discussion list'
Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Mar 2010 17:29:38 -0400

Hadriel just sent me a ref to the proposal, which was different than I 
was imagining.

Since the "source" is an explicit argument, and the TTL is specified to 
always be zero, I don't have *technical" objections to it. (I don't 
*like* it, but that is an opinion.)

	Thanks,
	Paul

Paul Kyzivat wrote:
>> As you may know, source based responses are all already being done 
>> today on a wide scale, but in non-standard ways.  Hadriel's proposal 
>> is one designed to standardize and enhance this capability.  He would 
>> be better to convey the details.  And the relationship between the TTL 
>> settings (caching) and the needs of the ENUM application is a matter 
>> of policy.  And these two features are not at odds.
> 
>> are not the intended recipient, please contact the sender by reply 
>> e-mail and destroy all copies of the original message.
>>
>>

---

From: [email-masked]
Date: Tue, 30 Mar 2010 08:18:40 +0100

> changes.

No, we are NOT - that is FUD.

Notwithstanding that at least one of the DNS directorate is one of those 
that would like NAPTR to go away, the _current_ E2MD documentation is 
suggesting NO changes to DNS protocols and is therefore generally out of 
scope for them (IMHO).

I can double check that, though, seeing as I work in the same office as 
two of them.

Ray

---

From: [email-masked]
Date: Tue, 30 Mar 2010 09:36:11 +0100

> The results are not cached - the TTL is zero.

More strictly, that probably means they're not cached by _your_ 
implementation?

Unfortunately it's not unheard of for other implementations to ignore TTLs 
of zero and assume some other lower bound.

Ray

---

From: Dean Willis <[email-masked]>
Date: Tue, 30 Mar 2010 03:54:28 -0500

> No, we are NOT - that is FUD.

We  asked them to authorize a working group that would be defining a  
new DDDS service for metadata discovery, including extension of the  
NAPTR record format (for a "T" record), and an at-will (spec required)  
extension mechanism for subtypes, with effective carte-blanche for  
determining an initial set of subtypes with in the WG and an ongoing  
low-review-threshold mechanism for new subtypes.

I believe that qualifies as making changes to the format of data  
allowed in the DNS, and even though YOU don't plan to put any data  
into "The DNS", I suspect that the DNS directorate folks believe that  
somehow, somewhere, people are going to use our extensions to populate  
"their DNS", and will probably do so in a way they find unpleasant.

> Notwithstanding that at least one of the DNS directorate is one of  
> those that would like NAPTR to go away, the _current_ E2MD  
> documentation is suggesting NO changes to DNS protocols and is  
> therefore generally out of scope for them (IMHO).
>
> I can double check that, though, seeing as I work in the same office  
> as two of them.

Please do!

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 30 Mar 2010 12:09:50 -0400

Correct - the draft actually says both that the TTL sent in the response must be 0, and the client must not cache it, but no doubt there are those that will.  Not my problem if they do, though, really.  They were warned.
-hadriel

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 30, 2010 4:36 AM
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling

> The results are not cached - the TTL is zero.

More strictly, that probably means they're not cached by _your_ implementation?

Unfortunately it's not unheard of for other implementations to ignore TTLs of zero and assume some other lower bound.

Ray

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 30 Mar 2010 22:30:48 +0200

> Now that maybe we're back on track, here's a rough re-statement of what one might like to see from this E2U/E2M infrastructure we are supposed to be talking about, notice how similar it is to DDDS,…

I think your list is very helpful.

I'm not sure that

> organization (Hadriel's proposal gives us this).

and

> 9)  Have a standard way for the querier to specify, per query, which E2U
> and/or E2M services it is interested in having in its query response
> (although this is less vital, this is already done to a lesser extent
> today, but via non-standard means) (however, Hadriel's proposal might
> also give us this).

are compatible with

> 7)  Continue to allow "Bind" to function as, at least, a proxy
> pass-through client for queries.  Iow, the base query request/response
> structure needs to be backward compatible with "Bind" (DDDS and ENUM
> gives us this).

This also applies to other current DNS software implementations (stub
resolvers or recursors).

otmar

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Wed, 31 Mar 2010 10:21:35 -0400

I understand what you are getting at, but I do not see these statements as incompatible.  If an organization happens to be using a DNS codebase that does not support some technical features (e.g. EDNS, which I think Hadriel's proposal relies on) and/or does not support technical features that may be orthogonal to what is considered "core DNS" technologies, then that organization would of course not be able to employ the use cases enabled by those features.  But other organizations, who do have those features enabled, would.  I do not see this as an all or nothing proposition.  The willingness to do source based selection, or selection based on other criteria are a matter of policy.

That being said, number 9 is really a "wish list" item, and should definitely be regarded as less critical than other requirements.

Thanks
Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Otmar Lendl
Sent: Tuesday, March 30, 2010 4:31 PM
To: [email-masked]
Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling

I'm not sure that

and

are compatible with

otmar