Re: kernelizing the network resolver

2002-11-05 Thread V Guruprasad
Dear John, On Fri 2002.11.01, John Stracke wrote: V Guruprasad wrote: - eliminates sockaddr_t handling in the user space, allowing application code to become free of IPv4/IPv6 (or for that matter raw Ethernet or ATM) dependencies; Doesn't using a shared library for the resolver give

Re: Introducing the ID tracker

2002-11-05 Thread Marcus Brunner
Thanks a lot for the effort. I like it very much and I think it is exactly the right way to open up the IESG process. I think and hope it will prevent bad feelings about decisions and suspicion of extenal influence. Marcus --On Montag, 4. November 2002 16:44 -0500 Harald Tveit Alvestrand

Re: kernelizing the network resolver

2002-11-05 Thread John Stracke
V Guruprasad wrote: On Fri 2002.11.01, Keith Moore wrote: so when the address changes out from under the app, or there are multiple hosts bound to a single domain name, the app loses. I don't see why name-address caching within the kernel cannot be as good or as bad as caching in the

Re: kernelizing the network resolver

2002-11-05 Thread V Guruprasad
On Fri 2002.11.01, Keith Moore wrote: Please check out http://infs.sourceforge.net for a novel INternet FileSystem (INFS) package which appears to be ideally suited to cell phones and other small devices or appliances. By pushing the DNS resolution to the kernel, INFS means to achieve

Re: kernelizing the network resolver

2002-11-05 Thread John Stracke
V Guruprasad wrote: On Tue 2002.11.05, John Stracke wrote: The problem is that only the app knows what kind of caching behavior it needs. For a simple protocol like SMTP or HTTP, pure DNS-based caching is fine; for a more sophisticated protocol (e.g., any sort of videoconferencing app), it

Re: kernelizing the network resolver

2002-11-05 Thread Iljitsch van Beijnum
On Tue, 5 Nov 2002, Keith Moore wrote: However, this also means that the end-to-end-ness or long term stationarity of the numeric (IP) addresses should no longer be taken for granted, and that names should be used instead as the primary reference. No it doesn't, because your overloading

Re: kernelizing the network resolver

2002-11-05 Thread Keith Moore
However, this also means that the end-to-end-ness or long term stationarity of the numeric (IP) addresses should no longer be taken for granted, and that names should be used instead as the primary reference. No it doesn't, because your overloading of DNS names for this purpose

Re: kernelizing the network resolver

2002-11-05 Thread V Guruprasad
Thanks for your thoughtful comments and look forward to more. Since I wrote INFS back in May-Jun, I already have had discussion on some of these issues, as given below. -p. On Tue 2002.11.05, John Stracke wrote: The problem is that only the app knows what kind of caching behavior it needs.

Re: kernelizing the network resolver

2002-11-05 Thread V Guruprasad
On Tue 2002.11.05, Keith Moore wrote: No it doesn't, because your overloading of DNS names for this purpose interferes with their utility for other purposes. Keith Imho, use of A records is not an overload.

Re: kernelizing the network resolver

2002-11-05 Thread Eliot Lear
Bill, The field may have been well plowed by NIMROD, but the IETF forgot to water it. This organization has never sufficiently answered the route scaling problem, and the ISPs are paying for it today. The question is really whether IPv6 is properly deployable over the long term without a

Re: kernelizing the network resolver

2002-11-05 Thread Randy Bush
The field may have been well plowed by NIMROD, but the IETF forgot to water it. it needed to be planted too, i.e. a documented and finised design randy