Subject: RE: [Enum] FW: Last Call or New Draft? - .arpa or .e;164.itu.in t ?

From: [email-masked]
Date: Mon, 17 Jul 2000 07:03:59 +0300

Hi Patrik,

> How many?

Initially, more than 10 per E.164 number.
 
> I.e. I don't understand what you belive is a scalability issue. You 
> also have to think about what is handled through different URIs 
> (different NAPTRs) and what is handled through the URI resolution.

If 'properly' engineered DNS records using NAPTRs scale, then
I have no problems using them. 
 
> It could be more interesting to query on the service field 
> than the protocol.

thanks,
John

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

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 17 Jul 2000 17:42:50 +0900

>I have no problems using them.

Ok, I then urge people to think about NAPTR scaling, test, and 
eventually come out with a new version of the NAPTR RFC one day when 
we know that it doesn't scale, and how the scaling issues should be 
(re)solved.

Personally, if the problem is the number of records, I would firstly 
want to query for a specific service, not protocol, and see if that 
is enough. I.e. in many cases you don't know what protocol you look 
for, or you want to have this or that (not only one protocol). But, I 
belive that you for every step in the NAPTR resolution algorithm is 
interested only one of the services.

I suggest (the wg chair is making this call) that this question 
should be taken back to the URN wg where the NAPTR is discussed.

I do not see that this changes the paper I have written, as it uses 
the NAPTR record as defined in the NAPTR paper. If that is replaced 
by a new paper, then the algorithm defined in my paper will change 
accordingly. If people belive that I have written too much about how 
the actual NAPTR algorithm is, instead of referencing the NAPTR 
paper, then let me know and I'll remove text.

    Patrik