Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-)

From: [email-masked]
Date: Sat, 1 May 2010 07:11:36 +0000

On Fri, Apr 30, 2010 at 03:51:44PM -0400, Tony Rutkowski wrote:
> Hi Richard,
> >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.
> >   
> 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.

	pointers to the published research please?
	(english prefered)

--bill

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

---

From: [email-masked]
Date: Sat, 1 May 2010 07:13:01 +0000

teach me to read to the -end- of the thread first.
 thanks Tony.

--bill

On Fri, Apr 30, 2010 at 05:15:24PM -0400, Tony Rutkowski wrote:
> On 4/30/2010 5:02 PM, Richard Shockey wrote:
> >Really .. I'm genuinely intrigued. Any URL's?
> >   
> http://hdl.cnnic.cn/
> 
> http://middleware.internet2.edu/pki06/proceedings/sun-handle-dns.ppt
> 
> --tony

---

From: Jim Reid <[email-masked]>
Date: Sat, 1 May 2010 10:52:28 +0100

On 30 Apr 2010, at 19:44, Bernie Hoeneisen wrote:

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

Who has these concerns and on what grounds? I think this is yet more  
FUD Bernie. Cache size concerns are coupled to RAM prices. Last time I  
looked 1 GB of RAM was about $30 retail.

The only concern for a resolving server will be when DNSSEC validation  
gets switched on and throughout plummets through the floor,  
particularly on very busy servers. Even that's a non-issue IMO: just  
throw commodity hardware at it or maybe some crypto accelerators. And  
IIUC there aren't any resolving servers (ie caches) inside the  
architectures where E2MD is likely to be used in anger.

---

From: Lawrence Conroy <[email-masked]>
Date: Sat, 1 May 2010 11:41:46 +0100

Hi Jim, folks,
 Slight clarification: there aren't any *broken* resolving servers (i.e. caches) inside the architectures where E2MD is likely to be used in anger.

If there ARE any badly broken resolvers out there on the wild interweb, they're going to have fun with DNSSEC.
atb,  Lawrence

On 1 May 2010, at 10:52, Jim Reid wrote:
> And IIUC there aren't any resolving servers (ie caches) inside the architectures where E2MD is likely to be used in anger.

---

From: Jim Reid <[email-masked]>
Date: Sat, 1 May 2010 12:39:54 +0100

On 1 May 2010, at 11:41, Lawrence Conroy wrote:

> Slight clarification: there aren't any *broken* resolving servers  
> (i.e. caches) inside the architectures where E2MD is likely to be  
> used in anger.

OK.

> If there ARE any badly broken resolvers out there on the wild  
> interweb, they're going to have fun with DNSSEC.

Not necessarily. There are badly broken resolvers out there. They  
don't seem to be breaking (well breaking any more than usual) as  
DNSSEC roll-out continues. Famous last words...

We'll know for sure next week. There will only be 1 root server (A)  
with the unsigned root zone from Thursday. So if there's a spike in  
strange traffic -- too many TCP priming queries, too many repeated  
priming queries, etc -- at A after that point...

---

From: Dean Willis <[email-masked]>
Date: Mon, 3 May 2010 10:59:22 -0500

On Apr 30, 2010, at 4:55 AM, Jim Reid wrote:

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

I believe the argument about lack of specificity in the query  
mechanism of DNS was raised by both John Klensin and Dave Crocker.  
Crocker, in particular, took us to task during the BOF for not having  
considered an _prefix model for selective queries. In a side  
conversation I had with him, Klensin seemed to be concerned that we  
really NEEDED a database query language sort of expressivity here,  
while insistent that the DNS was not the right place to be doing  
database queries.

Peter Koch and Olaf Kolkmann also spent a fair bit of time at the mic  
during the BOF.

Also, we spent a rather large amount of pre-meeting time with the less- 
bearded Jon Peterson chewing on the loose ends of the spec. He seemed  
to be most concerned about the open-endedness of the framework model.  
If we were adding one type of metadata per standards-track RFC, he  
might be less concerned. But perhaps he's merely maneuvering us into a  
path that gives him better tools for obstructing the work, because  
it;s fairly easy to hold up a standards-track document .

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

RIght. But if the data were structured differently (as per using an  
_prefix to make a new node for a specific datum), then the responses  
won't be so chubby.

To me, it comes back to the question of whether or not one needs all  
that data at the same time. For example, when routing an outgoing  
call, one really needs all the NAPTR records for that routing process.  
But when one is receiving a call and only needs is the calling-name,  
why should we also send all the records that would be used to route  
the call?

Would it be reasonable for us to differentiate between bits of  
metadata based on when in the process that metadata gets used, and  
perhaps use this differentiation to break the data up into different  
nodes?

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

What about the impact of that middle ground of "larger than one  
packet" UDP responses? EDNS0 (RFC 2716, 4.5) would appear to allow for  
some hefty datagrams before truncation, and those make the transport  
people nervous.  Would it be reasonable for E2MD to suggest a max  
datagram size of 1280?

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

OK, that's a good proposal. I think something like it is really going  
to be required for E2MD to succeed.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 3 May 2010 11:23:11 -0500

On Apr 30, 2010, at 8:00 AM, Richard Shockey wrote:

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

 From the people that were beating us up in and out of meetings at  
IETF 77.

> -----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'
> Subject: Re: [e2md] Rough minutes of today's conf call
>
>
> 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.
>
> 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.

If we have an open-ended framework for defining metadata, and a  
generic RR format for putting that metadata into, then it's certainly  
not outside the realm of possibility for somebody somewhere to decide  
that it's a Good Idea to have 200 RRs. That "somebody somewhere" might  
even include another SDO.  It's no crazier than some of the things the  
mobile-phone SDOs have done.

Consequently, there are people who believe that open-ended frameworks  
with loose registration policies for this sort of thing are  
inappropriate, and it's better to get community consensus for each new  
use-case.

>> ...
>
> 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.
>
> RS> Makes who nervous? A bunch of people who never actually deployed  
> ENUM
> databases?

A bunch of people who see themselves as the guardians of the Internet  
and its operational principles, specifically around congestion control.

I don't suppose you've noticed, but its pretty much impossible to get  
any new UDP application past Transport these days, and has been for a  
long time.

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

The ones I talked to seemed to understand, at least to the limits of  
my (admittedly limited) ability to tell.

>
>> The idea that you cannot create a technical standard derived from an
>> existing technical standard is fundamentally contrary to the IETF
>> 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.

I don't disagree. There are, however, people who don't much like 3761,  
and they're part of the community that's sending up flak. We have to  
deal with them one way or another.

Maybe just shouting louder will work eventually, but it gives me a  
headache.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 3 May 2010 11:30:41 -0500

On Apr 30, 2010, at 9:42 AM, PFAUTZ, PENN L (ATTCORP) wrote:

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

3. That innocent intermediate nodes, not designed for the load, will  
gag. Envision a user on an enterprise network that runs a DNS-relay  
firewall. Said user runs an app that makes an E2MD query, and the  
enterprise firewall falls over. The owner of the queried domain  
involved might not care that much, but it's certainly going to annoy  
the corp IT guy.

4). That other traffic on the network links will be impacted by large  
UDP datagrams that fall somewhere between the path-MTU and the  
configured upper-limit of the EDNS0 nodes involved, which might well  
approach 64k before they start truncating and falling-back to TCP.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 3 May 2010 11:36:34 -0500

On Apr 30, 2010, at 10:47 AM, Richard Shockey wrote:

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

But that's just the problem. The corporate firewall is probably not an  
ENUM aware and optimized caching server. It's probably something  
hacked together by two graduate students using a codebase derived from  
BIND-2 that's been ported to an embedded operating system.

I know you think that E2MD will only be used in private networks, but  
unless the specifications clearly say "ONLY FOR USE IN PRIVATE  
NETWORKS THAT ARE DESIGNED FOR ENUM" (and maybe even then) somebody is  
likely to innocently build an application that runs on "the real  
Internet" and there will be great surprise and dismay when things  
start breaking.

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

It's based on empirical fact in closed networks carefully managed by  
experts to work well with ENUM. Where ENUM is used "on the Internet"  
today, it has quite small RRsets; typically one record per node.

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

Point! I'm still waiting to see DNSSEC in the wild.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 3 May 2010 11:44:18 -0500

On May 1, 2010, at 4:52 AM, Jim Reid wrote:

> FUD Bernie. Cache size concerns are coupled to RAM prices. Last time  
> I looked 1 GB of RAM was about $30 retail.

Some of the DNS relays out there don't cost $30. I think the one that  
runs my office cost $19.95...

>
> The only concern for a resolving server will be when DNSSEC  
> validation gets switched on and throughout plummets through the  
> floor, particularly on very busy servers. Even that's a non-issue  
> IMO: just throw commodity hardware at it or maybe some crypto  
> accelerators. And IIUC there aren't any resolving servers (ie  
> caches) inside the architectures where E2MD is likely to be used in  
> anger.

You're still saying that E2MD isn't going to be used on the open  
Internet, just in specially-walled gardens. That might be true. If it  
is, then making a strong case for it being that way in the  
specification might help. It'll also draw fire from people who think  
we have no business inventing a walled-garden protocol in the IETF,  
but that's a different issue.

--
Dean

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 3 May 2010 12:57:01 -0400

RS> I did not say E2MD will ONLY be used in private networks. Only that is
clearly one of the strongest use cases and where nearly all of the existing
applications are.  You are arguing for a negative. There is no empirical
evidence that even if this technique were used on the "real Internet" it
would break anything.  As for the problems that some in the IETF have with
ENUM in general...tough. That was a political issue not a technical one. I
can appreciate the frustration some have had with the deployment of
e164.arpa but its irrelevant to this discussion. We need an application that
does number translations.   

--
Dean

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Mon, 3 May 2010 12:57:48 -0400

Dean:
Thanks for the clarification. If I understand, e2md is not breaking DNS
per se but some other stuff along the query response path.
While I still think rational self-interest on the part of those owning
the domain name would tend to restrict this, we certainly know that
rational self-interest doesn't always happen.
That being said and acknowledging the possibility of a problem, I'm not
sure why we can't have a working group but one specifically tasked with,
among other things, addressing the potential problem. I was only
listening in remotely but kind of got the feeling that we were being
told we couldn't have a WG until we arrived at a conclusion about the
solution to the problem. 

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Monday, May 03, 2010 12:31 PM
To: PFAUTZ, PENN L (ATTCORP)
Cc: Richard Shockey; Cartwright, Kenneth; Bernie Hoeneisen; E.164 To
MetaData BOF discussion list
Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-)

--
Dean

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 3 May 2010 13:08:57 -0400

RS> What is the DNS if not a distributed database that you query against?   

RS> So what? Have you noticed how many E2U definitions we have now?  

http://www.iana.org/assignments/enum-services

RS> Dean this is a old argument us ENUM greybeards have had for years. You
get back all the records from the query and then sort. End of story.

RS> NO.

RS> you can make all the recommendations you want but understand that they
will be promptly ignored in the field.

RS> We need some clarity here, sooner rather than later. If it clear that
all we are going to get is a bunch of FUD from some IETF quarters and we end
up having to reinvent DNS code here than it makes no sense to continue this
elliptical conversation.  We cant continue to argue with Peter, John K,
Peterson etal if they choose not to participate on this list.  Having you
essentially acting as a proxy for them is not productive. --
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 3 May 2010 12:10:34 -0500

> told we couldn't have a WG until we arrived at a conclusion about the

Excellent point.

I'm thinking it's more along the lines of "we can't have a working  
group that refuses to acknowledge that the problem even exists, and  
based on this is not only going to ignore said problem, but has  
predetermined to adopt an architecture that  is likely to cause said  
problem to manifest in the most direct and immediate way."

Coming back with a charter proposal that includes investigating the  
problem space, developing (and getting consensus on) requirements,  
analyzing existing protocols (like enum) as potential solutions  
against those requirements, and then developing a solution (ostensibly  
re-using as much existing specification as possible) is more likely to  
get a working group established.

But it doesn't meet the goal that I hear Richard and others driving  
at, which is to, in the shortest possible time (preferably within 90  
days) and the fewest possible changes (almost none) extend ENUM to  
deliver metadata as NAPTR records. The two approaches are pretty much  
diametrically opposed.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 3 May 2010 12:29:50 -0500

> RS> What is the DNS if not a distributed database that you query  

It's a fairly limited kind of database, in that its "query language"  
is restricted to node name (a master key)  and node type (a subkey).  
That is, a combination of name and type explicitly indicates a  
database record set, what we might call a "node" in DNS. A query  
returns all the resource records at a given node.

ENUM extended the query language with the "type+subtype" model. But  
it's important to note that this extension happens at the client end,  
not the server. The server still returns all the resource records at  
the node, then the client filters out the queried subtype and discards  
the resource records that aren't interesting.

 From a database point of view, this is a Really Ugly Hack. It's much  
cleaner to have the server process the subkey, so that the result set  
is smaller.

However, the approach used by ENUM works nicely for ENUM in that its  
not unusual for the whole result-set to be "interesting" to the  
client.  In base ENUM, the result-set consists of URIs that are used  
to connect to the target and might be tried sequentially, so sending  
back the whole set makes a sort of sense.

It is not obvious that this same property applies to all metadata use  
cases. Calling-name is a standout, where the property obviously does  
NOT apply. Of what possible benefit is the record-set related to  
calling a user, when you're querying it in response to having been  
called by that user and just need his name?

> http://www.iana.org/assignments/enum-services

For starters, the set of E2U definitions is pretty much horrifying.  
But AFAIK, all these services are still oriented to the calling party,  
rather than to the called party. Also, none of the (currently) require  
differential treatment based on the authenticated identity of the  
requesting party.

> get back all the records from the query and then sort. End of story.

Maybe so, but that;s still part of what they're complaining about. The  
argument is "If that's the way ENUM works, and you need something that  
works differently, you shouldn't be using ENUM!"

--
Dean

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 3 May 2010 13:31:59 -0400

That being said and acknowledging the possibility of a problem, I'm not
sure why we can't have a working group but one specifically tasked with,
among other things, addressing the potential problem. 

I was only

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

RS> Penn we have not been told we cannot have a WG. This entire discussion
is contrary to the way things should work in the IETF. One BOF co-chair is
attempting to engineer the solution before the WG is even formed and that is
just plain wrong. Discussing boundaries is one this discussion is not that.
The function of a BOF is to see whether A. IS there is a problem B. Is the
IETF the right place to do it  C. Are there people who want to work on it. 

Those questions have been answered in the affirmative. 

IMHO this entire discussion should be set aside and concentrate on 1.
Wordsmithing the charter 2. Getting another BOF set up for Maastricht.  The
question then is should the charter support a pure extension of the ENUM
service registration process with expert review or is this going to end up
being a one off RFC for each registration.  I do not support any general use
case document here. The use case can be defined in the registration
documents. I'm sick of use case documents. Form the WG that is the only
rational task at hand, though I will say this discussion will give the IESG
a suitable record of where folks stand.

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 3 May 2010 14:02:57 -0400

Great googly moogly.  Dean, how can you continue to paint and debate a scenario that is not being proposed?  :-)  This discussion is just too funny.

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Monday, May 03, 2010 12:31 PM
To: PFAUTZ, PENN L (ATTCORP)
Cc: Richard Shockey; Cartwright, Kenneth; Bernie Hoeneisen; E.164 To MetaData BOF discussion list
Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-)

--
Dean

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: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 3 May 2010 14:19:14 -0400

Right.  I second that.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of PFAUTZ, PENN L (ATTCORP)
Sent: Monday, May 03, 2010 12:58 PM
To: Dean Willis
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-)

Dean:

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Monday, May 03, 2010 12:31 PM
To: PFAUTZ, PENN L (ATTCORP)
Cc: Richard Shockey; Cartwright, Kenneth; Bernie Hoeneisen; E.164 To

--
Dean

---

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

On May 3, 2010, at 1:02 PM, Cartwright, Kenneth wrote:

> Great googly moogly.  Dean, how can you continue to paint and debate  
> a scenario that is not being proposed?  :-)  This discussion is just  
> too funny.

Other people have raised the questions: I'm just repeating them  
because many of the people on this list seem to think that by  
blustering on the list that they've answered the questions. They  
haven't.  I don't hold the opposition's belief's as sacred, but I  
believe that if we can't muster an argument that convinces me, we're  
not likely to convince them.

How can you say this scenario is not being proposed? We've clearly  
proposed an open-ended framework for adding new metadata types into  
the ENUM database with a minimal review policy for registering new  
metadata types. Obviously if we let just anybody register anything  
they want as metadata, we're potentially going to see many different  
metadata types, and potentially many resource-records per node.

The ENUM database is clearly a subset of DNS, and DNS affects the  
whole Internet.

We might well be thinking of ENUM as a walled-garden protocol that is  
used in an entirely different fashion than the DNS, but the DNS people  
do not see it that way.

None of our text, AFAIK in any use-case draft, solutions draft, or  
charter draft says anything about exclusively operating ENUM in  
isolation from "the DNS". If it did, we'd be having an entirely  
different debate.

If what we really want to do is define a profile of DNS that's used  
only in private networks, then let's make that abundantly clear in the  
work and most especially in the proposed charter.

If what we really want to do is investigate, define, and solve the  
metadata problem in a way that is consistent with the guiding  
principles given by the IAB, then let's build a problem statement and  
charter around that approach.

Simply trying the same "We're going to put this stuff in the DNS,  
dammit, and up yours if you don't think that's a good idea!" approach  
is probably not going to get us any further at the next BOF than it  
did at the last one. And I'm surely not going to be the one standing  
at the front of the room getting fruit thrown at me for presenting it!

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 3 May 2010 14:31:59 -0500

So, we need to show up with a problem statement and a charter around  
refining and solving that problem. This is NOT the same thing as  
showing up with a 99% complete solution that we're absolutely  
committed to delivering "now and unmodified."

This could well lead to a different solution than the one we have in  
mind. If we're OK with that, then I think we can make it happen.

--
Dean

On May 3, 2010, at 1:19 PM, Cartwright, Kenneth wrote:

> are not the intended recipient, please contact the sender by reply e- 
> mail and destroy all copies of the original message.
>

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 3 May 2010 15:56:47 -0400

But Dean that is not what you are doing. You are artificially constraining
the discussion to,   "Well you cant do this or that" since Dr. Flappinlips
went up to the microphone in Anaheim and said something. If there are
objections to a proposed solution or concerns about DNS response that should
be done in a properly chartered WG or in consultations with DNSOPS. I do not
consider the comments made in Anaheim as potentially constrictive only an
opinion at a BOF. 

Now how much time have you asked for in Maastricht? And can we constrain
further discussion to a proper revision of the charter?  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
Willis
Sent: Monday, May 03, 2010 3:32 PM
To: Cartwright, Kenneth
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-)

--
Dean

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 3 May 2010 16:09:32 -0400

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

RS> Just wonderful ..we're back to my old CNAM draft where I had to define a
new PSTNDATA URI! Hey if that can fix this argument, fine I'm all for it.
It's a kludge but A. the document was ENUM WG approved its in the IESG
queue. We can make it a general case for all metadata use the existing ENUM
service registration procedure and be done with it. It just needs a full
revision. This is what I was trying to avoid but ..hey It would work.

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 3 May 2010 16:52:55 -0400

Ok.

So I'll end my portion of this fruitless discussoin and be happy to participate in a re-constituted effort to re-define the charter and discuss the proposed RFCs.

Ken

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Monday, May 03, 2010 3:29 PM
To: Cartwright, Kenneth
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] the 200 RR of Bartholemew Cubbins :-)

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 3 May 2010 21:55:24 -0500

On May 3, 2010, at 2:56 PM, Richard Shockey wrote:

> went up to the microphone in Anaheim and said something.

Sorry.

I'm trying to say we have to have an agreed on ANSWER to Dr.  
Flappinlips that says we have a solid and presentable consensus on  
what we want to do.

> If there are

well, those are the opinions that are going to get heard when it comes  
time for the I* to decide whether or not to charter us.

> further discussion to a proper revision of the charter?

Me ask for time in Maastricht?  Haven't done it. Don't plan to. Might  
not be there -- no travel budget. I only volunteered to help chair the  
BOF for Anaheim, and it was the most embarrassing 60 minutes of my  
entire professional life, and that's including the time I drank too  
much at the company meeting and karakoed to YMCA including the dance  
steps ...   It will take many years to regain whatever shred of  
credibility I thought I had prior to that meeting!

I'll start a separate thread on whether we BOF at Anaheim.

--
Dean

---

From: Jim Reid <[email-masked]>
Date: Tue, 4 May 2010 08:25:13 +0100

On 3 May 2010, at 17:36, Dean Willis wrote:

> I'm still waiting to see DNSSEC in the wild.

You won't have long to wait. The last root server gets the signed root  
zone tomorrow.

So far, the roll-out hasn't created strange traffic patterns or client/ 
resolving server behaviour. Assuming there are no surprises, the root  
will flip to a real KSK and ZSK on July 1st: http://www.root-dnssec.org.

The data from this exercise should provide useful guidance about  
packet sizes and truncation for the discussions on this list.

---

From: Jim Reid <[email-masked]>
Date: Tue, 4 May 2010 08:30:54 +0100

On 3 May 2010, at 17:44, Dean Willis wrote:

>> Who has these concerns and on what grounds? I think this is yet  
>> more FUD Bernie. Cache size concerns are coupled to RAM prices.  
>> Last time I looked 1 GB of RAM was about $30 retail.
>
> Some of the DNS relays out there don't cost $30. I think the one  
> that runs my office cost $19.95...

So what? It's NEVER going to handle or cache large amounts of DNS  
data, whether that's E2MD NAPTRs or not.

> Internet, just in specially-walled gardens.

No I'm not. It is quite likely E2MD will mostly be used by consenting  
adults behind closed doors, but not exclusively so.

> That might be true. If it is, then making a strong case for it being  
> that way in the specification might help. It'll also draw fire from  
> people who think we have no business inventing a walled-garden  
> protocol in the IETF, but that's a different issue.

Indeed. And another angels on pinhead debate.

---

From: Jim Reid <[email-masked]>
Date: Tue, 4 May 2010 09:09:24 +0100

On 3 May 2010, at 16:59, Dean Willis wrote:

> Would it be reasonable for E2MD to suggest a max datagram size of  
> 1280?

I don't know. It's not clear to me if link-level fragmentation is  
likely to be a significant concern. And besides, there are other  
protocols like NFS which seem to get by OK with UDP jumbograms. It  
would be wise for this list to pick something that was compatible with  
RFC3226. Choosing other numbers would create a conflict with that RFC  
and no doubt least to IESG and/or AD whining.

---

From: [email-masked]
Date: Tue, 4 May 2010 11:01:14 +0000

some of us are setting the current threshold to 1220 - instead
of 1280, due to tunnel/VPN overhead.  then there are others setting
the threshold to 9k.

--bill

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 6 May 2010 15:43:38 -0400

Right, so for the CName use-case in particular, I think we can address the issue you cited below.  We just do in public ENUM what we sometimes do today in private ENUM: we use a different subdomain.  Like .cname.e164.arpa.

Or if you want to make it more generic: .source.e164.arpa, and put any other source query-key based answers in that sub-tree. 

(not to be confused with source-uri, which is a different animal altogether)

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Dean Willis
> Sent: Monday, May 03, 2010 1:30 PM
> To: Richard Shockey
>

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 7 May 2010 00:03:57 +0100

Hi Hadriel, folks,
I'm surprised no one else jumped in.
Ahem ... if you look at rfc3761bis, RFC3761, and before that RFC2916, you will note the IANA considerations.
=> I do not believe that one can readily do that kind of delegation within e164.arpa.
I suspect that an apex outside e164.arpa. would not be covered by the agreement.
all the best,
  Lawrence

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 6 May 2010 19:14:05 -0400

I read it, and I didn't see the problem.  Can you elaborate?
I'm not saying it wouldn't take an RFC to do this - we would have to give IANA additional instructions.  So? 

Or do it for a new domain, like source164.arpa.  I don't care.  The point is it's solvable even in a "public" context. :)

-hadriel

> From: Lawrence Conroy [mailto:[email-masked]]
> Sent: Thursday, May 06, 2010 7:04 PM
> To: Hadriel Kaplan
> Cc: Dean Willis; Richard Shockey; 'Bernie Hoeneisen'; 'E.164 To MetaData
> BOF discussion list'
> Subject: Re: [e2md] Querying CName (was: lots of NAPTRs)
> 
> Hi Hadriel, folks,
> > Right, so for the CName use-case in particular, I think we can address
> the issue you cited below.  We just do in public ENUM what we sometimes do
> today in private ENUM: we use a different subdomain.
> Like .cname.e164.arpa.
> >
> >
> > Or if you want to make it more generic: .source.e164.arpa, and put any
> other source query-key based answers in that sub-tree.
> >

---

From: 'Bernie Hoeneisen' <[email-masked]>
Date: Sun, 9 May 2010 17:44:35 +0200 (CEST)

Hi Hadriel

Interesting proposal.

However, introducing new apexes results in provisioning issues. You need 
to make the same (sub-)^x delegations for every apex. This is not really 
efficient, does not scale, and introduces problems with synchronization. 
(Note: E2M+cnam and E2U+sip (and others) are likely to have the same 
source of information for provisioning, so that this does not really 
appear to be straight forward.)

This probabely works fine in environments where there are only a few 
(more or less static) delegations.

Some questions arising from this:

1) Do we really have more cnam-like use cases (so that it is worth to make 
things complicated in the first place)?

2) Are there other use case types, which would require a different apex?

3) Is cnam really so much different?

>From the lookup point of view, the only difference is that it is not used 
to make a routing decision and that the result affects the calling party 
(i.e. SIP From HF as opposed to the R-URI). The lookup is made before 
establishment of the SIP session as with any other ENUM lookup.

>From the provisioning point of view, however, it comes to the same: It is 
information about the number. The source of the information is most likely 
the same as the one used to provision all the other NAPTR RR (e.g. 
E2U+sip, E2U+h323, ...).

If the answer to all these questions is 'no', we might want to consider the 
'cnam' tale closed and treat 'cnam' as every other E2MD use case.

cheers,
  Bernie

On Thu, 6 May 2010, Hadriel Kaplan wrote:

> the issue you cited below.  We just do in public ENUM what we sometimes 
> do today in private ENUM: we use a different subdomain.  Like 
> .cname.e164.arpa.
>
>