Subject: [e2md] Rough minutes of today's conf call

From: Bernie Hoeneisen <[email-masked]>
Date: Mon, 26 Apr 2010 22:11:33 +0200 (CEST)

Please holler in case we caught anything wrongly!

Goals of the call:

* Get a common understanding on what this objections are
* Prepare the way forward

Agenda:

* Hadriel's source URI proposal (brought in during the meeting)

* List of Objections (draft version)
   http://trac.tools.ietf.org/bof/e2md/trac/report/10

* List of Requirements (draft version)
   http://trac.tools.ietf.org/bof/e2md/trac/wiki/RequirementsList
   --> Needed to be skipped for this conf call
       (decided on separate conf call on this)

* Discuss alternatives for way forward

Participants:

- Jay Delay
- Gonzalo Camarillo (RAI AD)
- Bernie Hoeneisen (chair)
- Ray Bellis
- Lawrence Conroy
- Victor
- Jay Carpenter
- Hadriel Kaplan
- Dean Willis (secr. 1st half)

CONCLUSIONS:

The following was seen a reasonable proposal forward by the participants 
of the conf call around 19:30 UT (after the official end). If anybody 
disagrees, please state your opinion to the e2md mailing-list:

- Split up the problem space to make target smaller
- AD sponsored is not a sensible way forward, nor is individual submission
- Have a less agressive schedule to form a Working Group
   - Informal Meetings in Maastricht (IETF-78)
   - Formal WG-forming BoF earliest by Beijing (IETF-79)

3 Informal Meetings in Maastricht:
- How to deal with objections?
- Short term requirements (around ENUM)
- Longer term requirements (Destination Groups, Source URI, ...)

Conference Calls before Maastricht:
- Longer term requirements; in about 2 weeks; by Hadriel
- Requirements discussion; in about 4 weeks; by Bernie
- Continue discussion; in about 6 week; by Bernie

NOTES:

Below Dean Willis' notes from the first half of the meeting. Thanks Dean! 
(unfortunately Dean had to leave early and no-one else volunteered for 
taking notes):

Bernie chairing.

Noted that purpose of call is to resolve objections.

Jay Daley asked: Why does Hadriel think we have to do redirection at the time 
of receiving a request instead of doing it later?

Jay restated proposal: basically same as destination group that Ray has already 
drafted. Two types of carriers; do and do not publish interconnect data. 
Proposal allows publication of data that is meaningless unless you have the 
destination-group map in hand. Ray says this is also the core of the proposed 
spec for the UK number portability database.

Hadriel thinks he understands the proposal, but that as he understands it it 
has nothing to do with the problem that source-uri was trying to solve.

Hadriel re-stated the use case of source-uri; the source information affects 
the result of the lookup.

Jay proposed putting source and results in response and letting subscriber 
filter. Discussion followed.

Lawrence posed a question for clarification: one use case for source-uri is 
when incoming calls from a particular carrier (or associated trunk), other when 
caller is from a particular area or carrier, and therefore the source impacts 
the decision of where to go next. He suggests that Hadriel elucidate in the 
draft.

Ray noted that there have been proposals in dnsext to tailor response based in 
requesting IP address. or other identifying strings.

Lawrence noted that UK carriers had argued strongly against putting the actual 
routing tables in the DNS, and that they had instead proposed to put table 
indices in their and share the topology information offline.

Chair moved discussion onto open objections.

Starting at Objection #2:

Open Issue: Is everything a DDDS? I Is it a a NAPTR?

Lawrence asserts that the major problem in ENUM is DDDS specification, which 
was hard to write and harder to read. The problems were all caused by people 
understanding DDDS differently. However, the idea of NAPTR with a side-tag 
seems reasonable. Suggests we do NOT do another DDDS application.

Ray noted that DDDS implies NAPTR (or SNAPTR or UNAPTR...).

Noted that part of our goal here is to reduce load on IESG by having smallest 
possible changes from ENUM. Having a work item that extends four really obscure 
documents is hard for them.

Concluded: We are NOT talking about a different port. We are talking about how 
hard it might be to get an entirely new DDDS approved. Our current proposal is 
to just reuse the E2U DDDS with a new label.

If we don't want to have URIs, why are we using NAPTRs?

Lawrence noted that the general question: Should application-specific data 
being put in to the DNS? This seems to be a real debate question on 
name-droppers. TXT is real data... maybe we really COULD use TXT.

Hadriel noted that one of the problems in the bof was that the use-cases are 
unclear. Which use-case are we working on? Discussion of send-n use case 
followed, as it's not "new data", it's an optimization for reducing further 
queries. It really DOES have to be a type-35 record. Is this really E2MD? Are 
the other things metadata or just data?

One of Olaf or Peter may have suggested during the BOF that the "unused" and 
"send-n" problems are more general DNS problems. Noted that this stemmed in 
part from insistence in 3761 that any query should be for a fully-qualified 
number.

Noted that unused and send-n work together to reduce the number of unused 
entries needed when there is a whole block of unused.

Noted also that cnam is not "something you can use to call someone". The same 
is true for the putting the caller's public key into the tree.

Suggested that we could have just extended E2U more easily.

---

From: Ray Bellis <[email-masked]>
Date: Wed, 28 Apr 2010 08:44:56 +0000

> If we don't want to have URIs, why are we using NAPTRs?

I don't recall this, and it doesn't make sense to me.

Other than the way that RFCs 3404 and 3761 define a flag value of 'u' to
mean 'the result of this lookup is a URI' it's not otherwise required by RFC
3403 which is the formal definition of a NAPTR record.

Perhaps the problem is stated the wrong way around?

Ultimately if we end up extending E2U then we do have to shoehorn our data
into a URI-like format.  That is one of the arguments for E2MD being a
separate DDDS app.

Ray

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 28 Apr 2010 11:17:56 +0100

Hi Ray,
 that's my fault, I think.

I paraphrased an *objection* we had heard as
  "if you don't want to have URIs, why are you using NAPTRs"?

As you say, the objection entirely as phrased misses the mark,
so I guess either we don't understand the real objection, or
the objector doesn't understand.

Listening in on the BoF audio, it seemed that people were
reminding us that one could put other records into an "ENUM
domain", such as TXT.

This led on to an implied principle -- should one put data
into DNS, or merely publish pointers to something else?
Given TXT is already used in DNS (and that sure is data),
can we use that?

Thus a question we do need to answer is
"why can't one just use TXT for textual data (like CNAM)"?

honest, I did say it.

all the best,
  Lawrence

On 28 Apr 2010, at 09:44, Ray Bellis wrote:
> _______________________________________________
> e2md mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/e2md

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 28 Apr 2010 08:54:57 -0400

Yea.. exactly .. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Lawrence Conroy
Sent: Wednesday, April 28, 2010 6:18 AM
To: Ray Bellis
Cc: Bernie Hoeneisen; E.164 To MetaData BOF discussion list
Subject: Re: [e2md] Rough minutes of today's conf call

Hi Ray,

honest, I did say it.

all the best,
  Lawrence

---

From: Dean Willis <[email-masked]>
Date: Wed, 28 Apr 2010 13:02:49 -0500

> "why can't one just use TXT for textual data (like CNAM)"?

See: http://ietfreport.isoc.org/all-ids/draft-iab-dns-choices-08.txt

The general answer is "because the semantics of the TXT record are  
undefined". It MIGHT be a name; it might be a racial epithet, and it  
might be a government inventory serial number. We have no way to tell.

I had proposed using an SRV style _prefix modifier to provide the  
semantic on list, and I seem to recall a good many people reacting by  
saying I was some sort enumphobic sippohile who knew nothing about the  
DNS in response. I also received the more measured response that an  
_prefix didn't work because it breaks aggregation using wildcards, and  
we really need aggregation for entire number blocks that are assigned  
to a big corporate PBX.

The IAB's current guidance, in short, says that if you think you need  
TXT, you probably need a new resource record type. I'm becoming more  
inclined to agree.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 28 Apr 2010 13:04:26 -0500

> 3403 which is the formal definition of a NAPTR record.

I believe Bernie has proposed adding a new NAPTR flag field for a  
terminal metadatum.

The better question is "If we don't need all the regexp replacement  
cruft, why are we using NAPTR?" Do we need it?

--
Dean

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 28 Apr 2010 14:39:57 -0400

I think the IAB guidance is not applicable here. I think they were looking
at an entirely different problem here. SRV records only complicate what is a
simple data retrieval problem for some of us.

The larger issue here is that you have a bunch of DNS weenies that don't
realize what we are really trying to do is make SIP actual work better when
using E164 identifiers and kill off SS7 in the process.

SPID=vkgr4356;CIC=76543 really works well. Text strings that propend SIP
URI's are not problems  LRN=7038763456;NPDI=yes seems to work. :-) 

Obviously this not this is not the case for all forms of metadata. This is a
"one size DOES NOT fit all" problem. 

Dean ..how many times have I had to tell you and the entire RAI ..there are
NO such things as Enterprise number blocks where LNP is dominant? 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
Willis
Sent: Wednesday, April 28, 2010 2:03 PM
To: Lawrence Conroy
Cc: Bernie Hoeneisen; E.164 To MetaData BOF discussion list
Subject: Re: [e2md] Rough minutes of today's conf call

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 28 Apr 2010 23:10:05 +0100

Hi Dean, folks,

On 28 Apr 2010, at 19:02, Dean Willis wrote:
> It MIGHT be a name; it might be a racial epithet, and it might be a government inventory serial number. We have no way to tell.

Apart from the amusement that epithet might bring (viz today's news about radio microphones and disasters), I kinda guess that there would be some restriction over the content (like it has to be your name, as agreed by the CSP, or some such PROVISIONING restriction).
Unlike SUA display strings, of course.

The nearest this gets to the IAB's pronouncement is that "CNAM in a TXT record" would require some kind of tag string to indicate that it was a CNAM.

It is however a natural example of an E2MD meta-service; stick the text inside a E2MD+cnam:data
NAPTR (i.e. the content is in the data: URL), and you know what the domain owner asserts that it is.

If it is a racial epithet, sue the domain owner/throw them in gaol.
This is not a protocol issue, it's a legal issue; don't worry, be happy.
Can you imagine the fees for expert witnesses to explain to the courts how the DNS works, how CNAM works, how by provisioning this data the domain owner is requesting that it be displayed automatically without the permission of the recipient, and how this IS publication and so covered by existing laws?
... [or argue the other way, depending on who's paying the fees :].

=> TXT needs a tag, unless we sub-domain it as you suggest, or put in a tag string as the first one in the TXT record. Why not? Everyone else does.
(the IAB made that statement because it's not like there are none of those out there in the wild already).

=> E2MD NAPTR works a charm.

all the best,
  Lawrence

---

From: Dean Willis <[email-masked]>
Date: Wed, 28 Apr 2010 18:37:37 -0500

> NO such things as Enterprise number blocks where LNP is dominant?

Hey dude, it wasn't me, it was one of the longstanding ENUMerated ones  
who said that an _prefix was a bad idea because it didn't play well  
with wildcards, and that they were still finding wildcards to be a  
necessity.

Now if that's WRONG, then we can use Dave Crocker's _CNAME prefix idea  
along with Lawrence's TXT record suggestion and solve the calling-name  
problem immediately (and do it in-line with IAB guidance). I believe I  
proposed this on-list back during IETF week:

_CNAME.0.9.1.9.9.1.5.2.7.9.1.e164.arpa. IN TXT "Dean Willis"

--
Dean

---

From: 'Bernie Hoeneisen' <[email-masked]>
Date: Thu, 29 Apr 2010 08:15:23 +0200 (CEST)

I think it was Otmar who claimed this to be a problem. In general he is 
right about this, but the CNAM case is different, as I do not 
expect the Calling Name to be the result of a Regular Expression.

cheers,
  Bernie

On Wed, 28 Apr 2010, Dean Willis wrote:

> Hey dude, it wasn't me, it was one of the longstanding ENUMerated ones who 
> said that an _prefix was a bad idea because it didn't play well with 
> wildcards, and that they were still finding wildcards to be a necessity.
>
> Now if that's WRONG, then we can use Dave Crocker's _CNAME prefix idea along 
> with Lawrence's TXT record suggestion and solve the calling-name problem 
> immediately (and do it in-line with IAB guidance). I believe I proposed this 
> on-list back during IETF week:
>

---

From: Ray Bellis <[email-masked]>
Date: Thu, 29 Apr 2010 07:28:41 +0000

> expect the Calling Name to be the result of a Regular Expression.

I believe that's true, although if Richard has suitable use cases I'd be
happy to know about them.

As Dean recalled, however, the real problem with prefixes is that it's
generally impossible to provision:

  _cname.*.2.2.3.3.5.6.8.1.4.4.e164.arpa. IN RR "Nominet"

Actually - there might be a use case for regexps:

  *.2.2.3.3.5.6.8.1.4.4.e164.arpa. IN NAPTR .....
     "!^\\+441865332(.*)$!pstndata:...,Nominet extn:\\1" .

(i.e. Automatically adding the extension number to the CNAM data).

Ray

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 29 Apr 2010 08:29:27 +0100

Hi Bernie, Dean, folks,
 Yep, 'twas Otmar beat me to the punch in reminding
folks that the world is not all fixed number plan.
However, he also mentioned wildcards. That's the kicker.

You don't need/can't use those with CNAM, but doesn't
this also preclude their use for any other TXT item?

Just define a cnam:data service with a data: URI,
put it in a NAPTR and you're done.

Except for access control, and ...

all the best,
  Lawrence

On 29 Apr 2010, at 07:15, Bernie Hoeneisen wrote:
> I think it was Otmar who claimed this to be a problem. In general he is right about this, but the CNAM case is different, as I do not expect the Calling Name to be the result of a Regular Expression.
> 
> cheers,
> Bernie
> 
>> Hey dude, it wasn't me, it was one of the longstanding ENUMerated ones who said that an _prefix was a bad idea because it didn't play well with wildcards, and that they were still finding wildcards to be a necessity.
>> 
>> Now if that's WRONG, then we can use Dave Crocker's _CNAME prefix idea along with Lawrence's TXT record suggestion and solve the calling-name problem immediately (and do it in-line with IAB guidance). I believe I proposed this on-list back during IETF week:
>>

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 29 Apr 2010 13:38:45 +0200

>> expect the Calling Name to be the result of a Regular Expression.

The regular expression isn't the real problem here.

>   _cname.*.2.2.3.3.5.6.8.1.4.4.e164.arpa. IN RR "Nominet"

Precisely. That's the issue.

Of course, once we're in "let's create a DNSng protocol for E2MD"-mode
where we add support for query-source, source-URI and other non-1034
features, then adding support for such wildcards might be possible as well.

>      "!^\\+441865332(.*)$!pstndata:...,Nominet extn:\\1" .

Yes, that would be a typical use-case for what an Austrian carrier would
need to provision for ISDN PRI lines. (And BRIs as well, if configured in
P2P mode.)

And that's both for the calling-number side, as well as for the
called-number side.

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

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Thu, 29 Apr 2010 09:49:04 -0400

Given the fact that so many systems involved in the VoIP space are built to understand DNS ENUM/NAPTRs why in the world would we introduce a completely different DNS scheme to:

(1) Recreate ENUM's "context/meaning" qualifier, the ServiceType->SubType pair, with a *less functional* alternative (the prefix).
(2) Recreate ENUM's field to hold the data, the regex/replacement field, with a *less functional* alternative (the TXT record).
(3) Recreate ENUM's specification for converting a TN to a domain name, the first well know rule, with a different rule that is no better.

There is no good reason (no advantage) to do the above, and multiple reasons not to.  Add to the 3 reasons above the fact that all systems that already understand ENUM would now have to add a separate set of code that knows how to query and parse out CNAM data from that _CNAM RR and the associate TXT record.

Furthermore, why would the people that "don't want this data in the DNS" be upset by this data being held in NAPTRs but not upset by this data being in TXT records.  Answer, if their stance is self consistent then they would be equally upset by both.  So the contrived prefix/TXT idea does not achieve the apparent goal.

And as I've said on more than one occasion, systems are already serving up CNAM data using ENUM NAPTRs.  So why did those organizations specifically chose to not use TXT records?  Answer, because using ENUM just made more sense, from both a technology perspective and a business perspective.

I think these E2M discussions would provide a year's worth of work for Scott Adams.  :-)

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Wednesday, April 28, 2010 7:38 PM
To: Richard Shockey
Cc: 'E.164 To MetaData BOF discussion list'; 'Bernie Hoeneisen'
Subject: Re: [e2md] Rough minutes of today's conf call

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: Ray Bellis <[email-masked]>
Date: Thu, 29 Apr 2010 14:15:25 +0000

On 29/04/2010 14:49, "Cartwright, Kenneth" <[email-masked]> wrote:

> ... Loads of good stuff

+1 to all that...

Ray

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 29 Apr 2010 10:42:38 -0400

+1 as well. Excellent Ken an outstanding summary of the issues.  I'm getting
a little annoyed with the discussion ..oh well the IESG won't approve this,
the IESG won't like that. It seems prudent at this time to actually ask
Gonzallo and Robert what would he be able to support and argue for in the
IESG. Most of us here know exactly what we want to do and why we want to do
it. ENUM is there it works it scales both in private and public
instantiations. We're not going to reinvent the DNS. None of us have that
long a life span. 

-----Original Message-----
From: Ray Bellis [mailto:[email-masked]] 
Sent: Thursday, April 29, 2010 10:15 AM
To: Cartwright, Kenneth; Dean Willis; Richard Shockey
Cc: [email-masked]; Hoeneisen'; 'E.164 To MetaData BOF discussion
list'

+1 to all that...

Ray

---

From: Dean Willis <[email-masked]>
Date: Thu, 29 Apr 2010 12:31:14 -0500

On Apr 29, 2010, at 1:15 AM, Bernie Hoeneisen wrote:

>
> I think it was Otmar who claimed this to be a problem. In general he  
> is right about this, but the CNAM case is different, as I do not  

I'm thinking he was referring specifically to calling-name, as it is  
not infrequent for a PBX to have a block of 10, 100, or even 1000  
numbers for which the administration wants to put in only a single  
record having the company name. Sure, for the carrier this gets shot  
full of LNP holes, but every company I've ever worked with had a  
monolithic block of numbers.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 29 Apr 2010 12:46:56 -0500

On Apr 29, 2010, at 8:49 AM, Cartwright, Kenneth wrote:

> Given the fact that so many systems involved in the VoIP space are  
> built to understand DNS ENUM/NAPTRs why in the world would we  
> introduce a completely different DNS scheme to:
>
> (1) Recreate ENUM's "context/meaning" qualifier, the ServiceType- 
> >SubType pair, with a *less functional* alternative (the prefix).
> (2) Recreate ENUM's field to hold the data, the regex/replacement  
> field, with a *less functional* alternative (the TXT record).
> (3) Recreate ENUM's specification for converting a TN to a domain  
> name, the first well know rule, with a different rule that is no  
> better.
>
> There is no good reason (no advantage) to do the above, and multiple  
> reasons not to.  Add to the 3 reasons above the fact that all  
> systems that already understand ENUM would now have to add a  
> separate set of code that knows how to query and parse out CNAM data  
> from that _CNAM RR and the associate TXT record.

Here's the "opposition" gave me.

When you query the NAPTR records for a number, you get back (over the  
wire) every last associated NAPTR record in the RRset. The client  
library then filters out the one you want.

So if all you want is calling name (because you''re answering a call),  
the server is still going to have to generate and send all the other  
resource records over the network.  That's simply inelegant, which  
offends some parties.

But inasmuch as we're doing it over a non-congestion-controlled  
transport, and the number of potential RRs is effectively unbounded,  
there's a real potential for congestive harm to the Internet (yeah YOU  
don't want to use this on the big-I Internet, but if the specs are  
published, somebody will!), And there's a large faction in the IETF,  
especially among the greybeards, who take congestion control and the  
avoidance of congestive collapse very seriously. Remember, they've had  
to nurse the Internet through several periods of "impending collapse",  
and their beliefs have been greatly influenced by these experiences.

I've been told again and again that we solve the problem by having  
different DNS servers for different subsets of the data, and  
configuring the clients to ask the right servers for specific items,  
thereby reducing the RRset size, but having different servers  
provisioned for different data isn't DNS usage "as done on the  
Internet", and these folks believe it is inappropriate to document  
such usage in the IETF. I get it They get it, too. But they DON'T  
APPROVE of our approach, because once the spec is published there's no  
way to contain it to our little private networks.

> Furthermore, why would the people that "don't want this data in the  
> DNS" be upset by this data being held in NAPTRs but not upset by  
> this data being in TXT records.  Answer, if their stance is self  
> consistent then they would be equally upset by both.  So the  
> contrived prefix/TXT idea does not achieve the apparent goal.

Some of them don't mind some level of data in the DNS, they just want  
a more selective query mechanism than NAPTR because we get such big  
RRsets in the result. But as noted, this approach certainly doesn't  
satisfy all the greybeard critics; the only one that does seems to be  
putting a metadata pointer (and nothing else) into the DNS.

The question, to me, is is there a middle ground we can compromise on  
that makes both factions happy (enough)?

--
Dean

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Thu, 29 Apr 2010 16:43:29 -0400

(1) ENUM is based on DNS and is **already** operational today.  Has it brought down "the Internet's DNS"?  No.
(2) Given the foreseeable size of the problem space, the RR set size does have to be too large.  Regardless, that will be continuously evaluated as part of the expert review for each newly proposed E2M serviceType/subtype (as it was during the ENUM expert reviews).
(3) The ENUM LLC trials were conducted and completed, years ago.  That initiative has always been designed to be a separately managed DNS ecosystem, if you will.  So what's the issue?  Are folks pretending that the ENUM LLC trials did not happen?  Or are they saying that the result of the ENUM LLC trials found that because NAPTRs use DNS technologies, oops, that the mainline Internet DNS system was going to have issues?  Or are they just not aware that ENUM, based on DNS technologies, is already in production today?
(4) Middle grounds have already been proposed and rejected for equally amorphous reasons from non-present third parties.

The idea that you cannot create a technical standard derived from an existing technical standard is fundamentally contrary to the IETF way.  And the idea that you cannot create a technical standard because someone, somewhere in the world could do something really silly with it and harm their systems is not a logical approach to standards creation, and creates an impossible solution space.

Ken

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Thursday, April 29, 2010 1:47 PM
To: Cartwright, Kenneth
Cc: Richard Shockey; 'E.164 To MetaData BOF discussion list'; 'Bernie Hoeneisen'
Subject: Re: [e2md] Rough minutes of today's conf call

--
Dean

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Thu, 29 Apr 2010 16:45:45 -0400

Typo: the RR set size does have to be too large / the RR set size does *not* have to be too large

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cartwright, Kenneth
Sent: Thursday, April 29, 2010 4:43 PM
To: Dean Willis
Cc: list'; 'Bernie Hoeneisen'; [email-masked]
Subject: Re: [e2md] Rough minutes of today's conf call

Ken

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Thursday, April 29, 2010 1:47 PM
To: Cartwright, Kenneth
Cc: Richard Shockey; 'E.164 To MetaData BOF discussion list'; 'Bernie Hoeneisen'
Subject: Re: [e2md] Rough minutes of today's conf call

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 29 Apr 2010 20:16:54 -0500

On Apr 29, 2010, at 3:43 PM, Cartwright, Kenneth wrote:

>
>
> (1) ENUM is based on DNS and is **already** operational today.  Has  
> it brought down "the Internet's DNS"?  No.

When's the last time you made an ENUM dip and got back 200 resource  
records? Hasn't happened yet? It will, if we keep up on this path.

> (2) Given the foreseeable size of the problem space, the RR set size  
> does have to be too large.  Regardless, that will be continuously  
> evaluated as part of the expert review for each newly proposed E2M  
> serviceType/subtype (as it was during the ENUM expert reviews).

So, what guidance do we give the expert reviewer? Cut it off after the  
10th resource record? The 20th? The 50th?

> (3) The ENUM LLC trials were conducted and completed, years ago.   
> That initiative has always been designed to be a separately managed  
> DNS ecosystem, if you will.  So what's the issue?  Are folks  
> pretending that the ENUM LLC trials did not happen?  Or are they  
> saying that the result of the ENUM LLC trials found that because  
> NAPTRs use DNS technologies, oops, that the mainline Internet DNS  
> system was going to have issues?

They're saying that if we document this stuff as part of the mainline  
DNS, somebody is going to use it there, and if this catches on, Kaboom!

>  Or are they just not aware that ENUM, based on DNS technologies, is  
> already in production today?

They're aware of it. When you ask for a NAPTR record for a phone  
number and get back one record containing a SIP URI, there's no  
problem. When you get two or three, there's no problem. But defining  
an unbounded framework to define lots more responses makes them really  
nervous.

> (4) Middle grounds have already been proposed and rejected for  
> equally amorphous reasons from non-present third parties.
>

There's always more middle ground somewhere. The first thing is  
understanding the objections. Based on this discussion we keep having,  
I don't think we clearly understand the DNS greybeard's arguments. I  
think they understand what we are trying to do; they just don't see  
documenting this as part of the DNS and then only using it in private  
networks to be a viable long term control mechanism for the fallout  
they're expecting.

> The idea that you cannot create a technical standard derived from an  
> existing technical standard is fundamentally contrary to the IETF  
> way.  And the idea that you cannot create a technical standard  
> because someone, somewhere in the world could do something really  
> silly with it and harm their systems is not a logical approach to  
> standards creation, and creates an impossible solution space.

We can create a derived technical standard. There's nobody in the DNS  
directorate blocking us from deriving a new "metadata protocol" that  
works pretty much like a DNS query, defining a new URL for it, and  
putting that URL into the ENUM tree and looking it up based on a phone  
number, then using it to query back all the metadata our switches  
need. Of from a dozen other approaches that might work equally well.  
 From their point of view, they're just protecting an incredibly  
important piece of infrastructure from the unintended consequences of  
our effort to extend it.

But I DO understand their argument that created an open-ended  
framework for putting arbitrary cruft into the DNS will eventually  
result in too much stuff shoved in there. It's a credible argument.  
People do stupid stuff with their toys. In the SIP work, everytime we  
created an easy way for people to do extensions, like the "P-header"  
debacle (which required expert review AND informational RFC) , they  
went off and did crazy stuff that swelled up the messages and made the  
protocol less interoperable. If we give them a way to do it, we'll  
find the entire text of the Library of Congress in the DNS not too far  
down the road. It's not that someone somewhere will do a silly thing  
with it in their own network, but that they'll do a dangerous and  
destructive thing with it right smack dab in the middle of the  
Internet's most critical name resolution facility, and it Will Cause  
Problems.

--
Dean

---

From: Jim Reid <[email-masked]>
Date: Fri, 30 Apr 2010 10:55:43 +0100

On 29 Apr 2010, at 18:46, Dean Willis wrote:

> Some of them don't mind some level of data in the DNS, they just  
> want a more selective query mechanism than NAPTR because we get such  
> big RRsets in the result. But as noted, this approach certainly  
> doesn't satisfy all the greybeard critics; the only one that does  
> seems to be putting a metadata pointer (and nothing else) into the  
> DNS.

Dean, who are these greybeard critics and what, precisely, are they  
whining about?

Whether some NAPTR or TXT record (variant) is chosen, the same  
provisioning problem remains. If someone put lots of data at some node  
in the name space, their name servers will send chubby responses. BFD.  
As you know, the DNS has robust and workable methods to deal with  
that. They're also independent of the RRset type(s) that are in the  
response.

An E2U NAPTR takes up ~60 bytes of a DNS response. So it'll be in the  
man tens of NAPTRs (maybe 100 or so) before default EDNS0 payloads  
start to bust at the seams and TCP retries become necessary. [Assuming  
nobody does the right thing and adopts even bigger EDNS buffers.] So  
that probably means a tiny percentage of queries will go over TCP.  
This is no big deal either.

Besides, if there is (or could be) and operational issue here, I'm  
sure dnsop and/or the DNS Directorate would intervene. Maybe they  
could be asked for advice about that now? This would settle the issue,  
stop the FUD, shut up these anonymous greybeard critics and give this  
list a clearer understanding of the parameters to work inside.

In DNS circles, there's a lot of discussion about the roll-out of the  
signed root zones. There was concern that poorly chosen EDNS0 buffer  
sizes would result in too many signed responses getting truncated.  
[That doesn't appear to have happened BTW.] Even so, the root server  
operators are confident their servers could cope with many thousands  
of TCP queries per second. If they can provision their servers to cope  
with that then so can anyone using DNS for serving E2MD data. Remember  
too that steady state query rates at the root will be 3-4? orders of  
magnitude greater than at the DNS servers pumping out E2MD data.

PS: Apologies for a meaningful Subject: header

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 30 Apr 2010 09:00:16 -0400

Dean ... just where are you getting your data points? You are making wild
statements that have no basis in actual deployed fact.

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Thursday, April 29, 2010 9:17 PM
To: Cartwright, Kenneth
Cc: Richard Shockey; 'E.164 To MetaData BOF discussion list'; 'Bernie
Hoeneisen'

RS> This is just absurd .. there is no possible scenario where 200 RR
records are going to be sent back but even if it was ..so what if it can
actually solve a problem in the field.

RS> Its not our business to decide this.  The existing E2U model for type is
working quite well. The world has not collapsed.

RS> Makes who nervous? A bunch of people who never actually deployed ENUM
databases? 

RS> Well Dean the first thing is I don't think the DNS grey beards
understand what we are trying to do. And this does have both public and
private usages here.

> way.  

RS> Dean this has gone far enough .. nothing in the proposed usage is
fundamentally contrary to 3761 far from it it's a modest extension.

And the idea that you cannot create a technical standard  

--
Dean

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Fri, 30 Apr 2010 10:16:39 -0400

This is a very true statement.

"You are making wild statements that have no basis in actual deployed fact."

Ken

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Thursday, April 29, 2010 9:17 PM
To: Cartwright, Kenneth
Cc: Richard Shockey; 'E.164 To MetaData BOF discussion list'; 'Bernie
Hoeneisen'

--
Dean

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Fri, 30 Apr 2010 10:42:36 -0400

Let me see if I'm thinking about this right - the concern is that owners
of ENUM domain names will provision too much data under their zones.
I imagine  two potential concerns here
1. that querying clients will gag - presumably no network operator would
do this since it would break their service. We're not THAT dumb :-); I
hope.
   Individual number owners in a pure 3761 end user ENUM might be more
foolish but will reform when their application breaks.
2. that there will just be too much data pushed through the net as a
result. I find this hard to believe. Compared to other drivers of net
traffic I think this must remain tiny.

I may well be missing something but tell me what it is. If there's a
real problem I won't object to the solution taking other paths.

Thanks,

Penn Pfautz
AT&T Access Management
+1-732-420-4962

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 30 Apr 2010 16:52:09 +0200 (CEST)

Hi Penn

> real problem I won't object to the solution taking other paths.

You left out DNS caching servers that have also been reported to be 
problematic when having big DNS responses.
(Even in the case the TTL is zero, some caching servers in the field will 
cache for a minimum time.)

However, I am not in possession of any figures on how serious this caching 
issue might be.

cheers,
  Bernie

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 30 Apr 2010 11:47:56 -0400

NO ..ENUM aware and optimized caching servers, in my professional
experience, have not had these issues. Many of them in carrier networks can
now handle up to 400 Million TN's and all the data associated with them
locally with superb response times in multi terabyte memory resident
databases. In private instantiations of ENUM all the data is usually cached
all the time and updated as needed from external data sources like LNP.
Remember these local caches usually contain internal network specific data
as well as data such as Trunk group data that are essential for internal
session routing.

Any SP that would use BIND for this is just plain nuts.

Again Ken Cartwright is right. Our knowledge of how this all scales is based
on empirical fact not speculation.

Want to see fat chubby DNS responses that will clog some networks..try
DNSSEC.

cheers,
  Bernie

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 30 Apr 2010 11:50:05 -0400

Right Jim ...if these greybeards have a problem let them whine on this list
instead of being BOF tourists.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Apr 2010 13:46:08 -0400

Actually, I'm generally on the same page, but I don't think we should dismiss this issue too quickly.  It may turn out we like green eggs and ham. ;)

For me, the huge advantages of ENUM/DNS over any other protocol are (1) performance, (2) performance, and (3) performance.  Even the built-in scalability-through-tree-distribution benefit basically boils down to performance (you could put similar logic into any database query model, but DNS is efficient at it).

So it does concern me if we think a single query could result in a huge list of records that I don't care about.  The number of E2U records in a response even in private ENUM cases has already grown into double-digits.  And it didn't take long for that to happen. :(

-hadriel

> PFAUTZ, PENN L (ATTCORP)
> Sent: Friday, April 30, 2010 10:43 AM
> To: Richard Shockey; Dean Willis; Cartwright, Kenneth
>

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 30 Apr 2010 13:56:26 -0400

> For me, the huge advantages of ENUM/DNS over any other protocol are (1) performance, (2) performance, and (3) performance.  Even the built-in scalability-through-tree-distribution benefit basically…

Curious minds would ask whether this assessment includes Handles?

--tony

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 30 Apr 2010 19:05:27 +0100

Puzzled minds would ask for a little more context: Handles -- as in four candles?
all the best,
  Lawrence

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 30 Apr 2010 14:13:53 -0400

> Puzzled minds would ask for a little more context: Handles -- as in four candles?
As in http://www.handle.net/

--tony

---

From: 'Bernie Hoeneisen' <[email-masked]>
Date: Fri, 30 Apr 2010 20:44:44 +0200 (CEST)

Hi Rich

I trust you that Telco grade DNS caches as you describe them below can 
handle long DNS answers without significant problems.

But people are rather concerned that loads of long DNS answers harm 
their (ordinary) DNS caches on the Internet. This concern needs to be 
addressed one way or the other.

cheers,
  Bernie

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Fri, 30 Apr 2010 14:51:39 -0400

>From a practical perspective, where does the worry about "a huge list of records I'm not interested in" arise?  I'm not seeing it.

However, as stated prior, I *would* like to see either E2M or ENUM extended to optionally allow the querier to list the ServiceTypes that it is interested in.  imo, this can be addressed as an optional, localized extension to the E2U or E2M specs (but this is just a tangential point that is only a nice-to-have at this point).  There is no need to re-invent a bad ENUM using prefixes and TXT records to make this improvement.  And to those **non-present objectors** please refrain from waving the "you can't add any new features any-where around the DNS technologies or ecosystem because it will get misused and bring down the Internet" flag.

Ken

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Friday, April 30, 2010 1:46 PM
To: PFAUTZ, PENN L (ATTCORP); Richard Shockey; Dean Willis; Cartwright, Kenneth
Cc: Bernie Hoeneisen; E.164 To MetaData BOF discussion list
Subject: RE: [e2md] the 200 RR of Bartholemew Cubbins :-)

-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 30 Apr 2010 15:12:38 -0400

OMG ... the Handle Vampire is back. Bob Kahn ( yea that TCP Bob Kahn ) his
favorite windmill. Tony the answer is of course yes.  Bob did the full court
press on me 10 years ago to dump DNS and consider Handle for ENUM.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony
Rutkowski
Sent: Friday, April 30, 2010 2:14 PM
To: Lawrence Conroy
Cc: Bernie Hoeneisen; E.164 To MetaData BOF discussion list
Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-)

--tony

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 30 Apr 2010 15:19:06 -0400

No ..I still don't see a problem. Dump BIND and go with UNBOUND.

Have you seen a DNSSEC response? 

So who are these "people"? I want the names of these people! Why they are
not discussing their issues on this list?  I'm getting very very tired of
"somebody said this somebody said that" 'oh the DNS wonderboys won't accept
that'. The discussion is here on this list not in private exchanges between
BOF tourists and the BOF co-chairs.

-----Original Message-----
From: 'Bernie Hoeneisen' [mailto:[email-masked]] 
Sent: Friday, April 30, 2010 2:45 PM
To: Richard Shockey
Cc: 'PFAUTZ, PENN L (ATTCORP)'; 'E.164 To MetaData BOF discussion list'
Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-)

Hi Rich

cheers,
  Bernie

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 30 Apr 2010 15:51:44 -0400

Hi Richard,
> press on me 10 years ago to dump DNS and consider Handle for ENUM.
Many of went down that path.
What's new is the research out of a CNNIC institute funded
by Cisco that suggests significant performance advantages
for Handles - especially where security is important.  CNNIC
even demonstrated a concurrent parallel implementation.

May be worth another bite...no pun intended - at least for
some applications.

--tony

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 30 Apr 2010 17:02:50 -0400

Really .. I'm genuinely intrigued. Any URL's?

-----Original Message-----
From: Tony Rutkowski [mailto:[email-masked]] 
Sent: Friday, April 30, 2010 3:52 PM
To: Richard Shockey
Cc: 'Lawrence Conroy'; 'Bernie Hoeneisen'; 'E.164 To MetaData BOF discussion
list'

Hi Richard,

--tony

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 30 Apr 2010 17:15:24 -0400

> Really .. I'm genuinely intrigued. Any URL's?
http://hdl.cnnic.cn/

http://middleware.internet2.edu/pki06/proceedings/sun-handle-dns.ppt

--tony