Subject: RE: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements'toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs)

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 10 Nov 2006 13:07:04 -0500

To second Penn's point...  A new version of the I-D
draft-ietf-enum-infrastructure-02 is to go out soon, which addresses
this as follows:
 
3. IANA Considerations 
 
   IANA has created a registry for Enumservices as originally specified 
   in RFC 2916 and revised in RFC 3761.  Enumservices registered with 
   IANA are valid for Infrastructure ENUM as well as end-user ENUM. 
    
4. DNS Root for Infrastructure ENUM 
 
   The top level DNS zone for infrastructure ENUM must support a level 
   of performance similar to that required for root servers (RFC 2870) 
   and must be independent of e164.arpa.   

Jason

> -----Original Message-----
> From: Pfautz, Penn L, GBLAM [mailto:[email-masked]] 
> Sent: Thursday, November 09, 2006 12:29 PM
> To: Jim Reid; Pekka Savola
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Enum] Re: Last Call: 'Infrastrucure ENUM 
> Requirements'toInformational RFC 
> (draft-ietf-enum-infrastructure-enum-reqs) 
> 
> Jim:
> Just to be clear - we were not looking for a new TLD for 
> infrastructure ENUM. The authors of this draft would be happy 
> to see the infrastructure ENUM apex under .arpa. However, 
> there may be other parties involved (note that the ITU-T has 
> yet to accept e164.arpa for user ENUM beyond interim status.) 
> We'd be happy with an apex domain that meets the necessary 
> performance requirements. 
> 
> Penn Pfautz
> 
> -----Original Message-----
> From: Jim Reid [mailto:[email-masked]]
> Sent: Thursday, November 09, 2006 8:51 AM
> To: Pekka Savola
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements'
> toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs) 
> 
> 
> On Nov 9, 2006, at 12:38, Pekka Savola wrote:
> 
> >    6.  Infrastructure ENUM SHALL be implemented under a top level  
> > domain
> >        that can support reliability and performance suitable for  
> > PSTN/PLMN
> >        applications.
> >
> > ==> this seems like a NOP requirement, given that you don't describe
> > or give reference what those reliability or performance requirements
> > are.  What are the real requirements?  Is it believed that some top
> > level domains could not satisfy these?  If not, this requirement
> > doesn't seem to be useful.
> 
> Indeed. I wonder why "top level domain" gets mentioned at all.  
> There's nothing magical or special about Infrastructure ENUM that  
> requires or justifies the creation of a TLD. It would be best to  
> avoid opening up that layer-9 rat-hole in the ICANN/IANA/DoC world.  
> Besides, didn't RFC3172 decree infrastructure domains live 
> under .arpa?
> 
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
> 

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jim Reid <[email-masked]>
Date: Fri, 10 Nov 2006 18:52:24 +0000

>    and must be independent of e164.arpa.

Sorry, I cannot accept this text at all. Specific technical terms are  
being misused: like "DNS Root" and "top level DNS zone" for example.  
RFC 2870 concentrates on name server configuration and operation. It  
says *practically nothing* about performance. The RFC has no  
meaningful data points about query rates, response times, bandwidth  
requirements, service levels, etc, etc. I am also not convinced  
there's any reason why this document needs to mention domain names  
that can or can't be used for Infrastructure ENUM.

How about:

4. Zone Apex for Infrastructure ENUM

The domain name chosen for Infrastructure ENUM and any parent domains  
must be hosted on name servers that have performance characteristics  
and supporting infrastructure comparable to those deployed for the  
Internet root name servers. Those name servers for Infrastructure  
ENUM should be configured and operated according to the guidelines  
described in RFC2870.

---

From: "Pfautz, Penn L, GBLAM" <[email-masked]>
Date: Fri, 10 Nov 2006 14:14:30 -0500

This language works for me. Jason? Richard?

Penn 

-----Original Message-----
From: Jim Reid [mailto:[email-masked]] 
Sent: Friday, November 10, 2006 1:52 PM
To: Livingood, Jason
Cc: Pfautz, Penn L, GBLAM; Pekka Savola; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Enum] Re: Last Call: 'Infrastrucure ENUM
Requirements'toInformational RFC
(draft-ietf-enum-infrastructure-enum-reqs) 

How about:

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 10 Nov 2006 20:34:23 +0100

Ok with me too
 
Richard

________________________________

Von: Pfautz, Penn L, GBLAM [mailto:[email-masked]]
Gesendet: Fr 10.11.2006 20:14
An: Jim Reid; Livingood, Jason
Cc: [email-masked]; [email-masked]; Pekka Savola; [email-masked]
Betreff: RE: [Enum] Re: Last Call: 'Infrastrucure ENUMRequirements'toInformational RFC(draft-ietf-enum-infrastructure-enum-reqs) 

Penn

-----Original Message-----
From: Jim Reid [mailto:[email-masked]]
Sent: Friday, November 10, 2006 1:52 PM
To: Livingood, Jason
Cc: Pfautz, Penn L, GBLAM; Pekka Savola; [email-masked];

How about:

---

From: "Richard Shockey" <[email-masked]>
Date: Sun, 12 Nov 2006 09:58:08 -0500

Seems reasonable but I think you can remove IESG from this discussion from
now on.

> Sent: Friday, November 10, 2006 2:15 PM
> To: Jim Reid; Livingood, Jason
> Cc: Pekka Savola; [email-masked]; [email-masked]; [email-masked]
> Requirements'toInformational RFC (draft-ietf-enum-infrastructure-enum-
> reqs)
>

---

From: Jim Reid <[email-masked]>
Date: Fri, 17 Nov 2006 11:02:03 +0000

On Nov 16, 2006, at 21:05, Pekka Savola wrote:

> It is not obvious to me what 'performance characteristics and
> supporting infrastructure comparable to those deployed for the
> Internet root name servers.' really means, whether this is the real
> requirement, and what are even the figures for root name servers.

This vagueness was deliberate. :-) The capacity that the root servers  
have is not usually published for the obvious reason that it tells  
the bad guys just what the limits are. [Some do publish statistics on  
the query rates they get.] And that capacity is forever changing  
anyway: systems get beefed up, more anycast nodes come on-line, extra  
bandwidth is added, peering arrangements at IXes change, etc, etc.  
The point of the original text was to say that whatever zone apex is  
chosen for Infrastructure ENUM, it better have infrastructure at  
least as good as that for the root servers. Which seems a reasonable  
heuristic.

> There are in the order of O(100) root name server instances at the
> moment [http://www.root-servers.org].  Are you referring to the
> aggregate performance of all these instances?  That would likely be
> overengineering, so I suspect the real performance required is
> somewhat lower..

It depends on what you mean by "real" performance. In a perfect  
world, there would be no broken DNS software or misconfigured name  
servers saturating the root servers with crap. Look at the CAIDA  
paper from a few years ago about root server traffic. 95% of the  
queries they get are bogus. Now are those queries "real" or not? In  
one sense they are because the packets arrive at the servers and need  
to be answered. In another sense they're not because they cannot be  
extrapolated from any analysis of how "normal" (well behaved and  
properly configured) DNS clients do lookups.

Oh and lets not overlook the impact of DDoS attacks. Even if everyone  
in Infrastructure ENUM is well behaved, what if there's a rogue  
operator or a script kiddie gets into an operator's core network?  
[Flooding DNS servers with traffic to bring down the world's phone  
system would be a really juicy target.] Or what if someone's DNS  
software goes berserk and generates far more traffic than it should?

> Having more specific data -- if anyone has sat down and done
> calculations on what's really needed -- would be useful.

I agree this would be a good exercise. But the upper bounds on what's  
really needed should be at least one or two orders of magnitude  
greater than the results of those calculations. Again, this is where  
guidance from the root server operators could be valuable. After all  
they have years of real world experience running critical DNS  
infrastructure in a hostile environment.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 16 Nov 2006 23:05:29 +0200 (EET)

By the way, hopefully the rest of the review wasn't forgotten, as all 
discussion has been about this one topic..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: lconroy <[email-masked]>
Date: Sun, 19 Nov 2006 20:37:05 +0000

Hi Pekka, folks,

One would hope this refers to the service provided by the cloud.
However, the setup delay budget for PSTN calls (and one assumes
for the VoIP provided calls as well, Jason?) is tight.
Having to retransmit an ENUM query prior to placing a call because
a DNS instance/cluster is down would be bad - not disastrous, but bad.

Given the current performance and reliability of PSTN infrastructure
I don't believe that Section 4's proposal would be overkill - it is
readily achievable, and not out of keeping with existing infrastructure
or service providers' expectations.

What it means in the real world is up to the providers - they are the
ones who pay for the system, and are very used to specifying service
availability and performance. IMHO, it would not really be appropriate
for an IETF document to delve too far into PSTN operational and
performance requirements - (that's their job :).

I of course ignore mobile/cell phone set up - one could do that with
a bit of wet string and a pair of PCs. This really has to do better.
You simply can't expect a service provider (or its customers) to be
happy with a system that can go out of service randomly and is not
properly funded and maintained.

Advice to infrastructure maintainers in every Country in the World
is worthwhile, IMHO. The reference to 2870 is exactly what is needed
from an IETF document. Less would be unfair to those whose expertise
lies in other areas, more would require that the IETF first has to
gain their PSTN infrastructure operational expertise. As is, this
document might come out before the authors retire.

all the best,
   Lawrence