Re: draft-iab-dns-applications - clarification re: Send-N

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I don't much see the issue here.

Looking at my AT&T records, I have made about 1000 iphone calls in the past year. Of those less than 50 are to numbers not in my contacts and I probably dialed half of those using Safari.

Telephone numbers are not going away, but telephone dialing is already a necessary legacy thing more than a current requirement.


At this point I don't think that there are any telephone numbers I dial from memory. 

I think that the underlying problem here is that the crappy POTS handsets on sale today do not interface to Internet telephony systems well. 

This whole problem would go away if Cisco and the other makers of VOIP bridges worked out that the real market requirement here is for a box that plugs into an ethernet port and connects to DECT6.0 telephones rather than a box that plugs into an ethernet port and has telephone wires sticking out the back. 

That way the VOIP system knows how long the telephone number from the phone book entry. Your basic problem here is that you are losing this information by converting all your data to the obsolete POTS wire format and back.

Anyone who wants to do that should further realize that what they need to do is to allow for multiple boxes on the same VOIP connection in a secure fashion. DECT6.0 does not have the range to cover some houses and for some reason the pinheads that designed it seem to think that 6 phones is enough for one house. 


On Wed, Oct 20, 2010 at 4:18 PM, Paul Hoffman <paul.hoffman@xxxxxxxx> wrote:
At 12:43 PM -0700 10/20/10, bill manning wrote:
>while I agree that the hierarchical and distributed nature of the DNS is
>a scintillating, shimmering attractant, it is wise to be aware of the baseline
>assumption in your arguement, e.g. that a client will -ALWAYS- ask an authoritative
>source...
>
>The DNS is so designed that caching is a huge component of the scalability of
>the DNS... and its greatest hinderance for such ideas as are laid out in the ENUM
>dip lookup.    You can't be assured that the data is timely.  This is a strong reason
>to consider that the DNS is _NOT_ the droid you are looking for,  in spite of its other
>attractive qualities.

This line of reasoning is getting old. DNS records have TTLs that are established at the same time, and in the same interface, as the data itself. Caching based on TTLs is trivial to do, and devices that do it wrong usually don't do it at all, which affects long-lived TTLs just as badly.

If you want to argue "TTL=5 considered harmful", that's fine, but for the kind of data that is being discussed here (someone's phone number, not Google's IP address), the operational difference between TTL=3600 and TTL=5 is lost in the noise. And it's not like the alternative you are hoping they use, HTTP, is any different with respect to caching, systems that ignore the TTLs, and so on.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf



--
Website: http://hallambaker.com/

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]