,
-prasad.
---
V. Guruprasad,
Inspired Research LLC.
http://www.columbia.edu/~vg96/papers.
Dear Keith,
Sorry I couldn't respond earlier (if, that is, a response was expected).
On Thu 2002.11.07, Keith Moore wrote:
problem is, if you keep the same API, then apps that depend on that API
will expect that the name space has the same characteristics as DNS,
(benefits and shortcomings
On Wed 2002.11.06, John Stracke wrote:
V Guruprasad wrote:
In short,
you continue to have the full socket API with no impediment to its use.
This is misleading. You say that your main motivation here is to move
the identification role out of IP up to DNS, and moving the resolver
On Thu 2002.11.07, Keith Moore wrote:
And those shortcomings are more-or-less inherent in DNS - you really
can't fix it and still have a namespace with the characteristics we
want in DNS - e.g. federated assignment, federated lookup, and ability
to assign names to groups of hosts or
On Tue 2002.11.05, Keith Moore wrote:
purposes, or for all apps. My concern is that an API that encouraged
apps to use DNS (by making it difficult or infeasible to use IP addresses)
would cripple that's platform ability to support some kinds of apps.
INFS is simply a VFS wrapper around
On Tue 2002.11.05, John Stracke wrote:
I see both as largely system calls API issues, permitting simple and
elegant solutions, and as not fundamental networking constraints that
would legitimately rule against the INFS approach.
I disagree. The answers you give seem to say that you
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
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
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.
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.
Hi everyone,
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 the following:
- eliminates
On Wed 2001.03.21, Jon Crowcroft wrote:
this is a solicitation to peopel that know london
(the venue for the next ietf)
Any idea when this is likely to be?
[
Sorry I couldn't make it to "mpls" to enjoy the winter, this prototype for
my I-D has me so tied, but I'd sure like to plan for the
Hi,
On Wed 2001.02.21, Bora Akyol wrote:
I am trying (trying is the key word) to write Internet drafts on a
powerbook using MS Word with the template from the IETF web-site,
then using a PC to convert Word to text per the instructions.
Is there a better way to write IDs on a Mac?
I
Eliot,
On Wed, 2001.02.14, Eliot Lear wrote:
With all the discussion of Napster and so-called "peer to peer" networking,
I think NATs are going to become far more visible to users as these
applications grow in popularity. Today, you can use something like Gnutella
if at least one party is
On Thu, 2001.02.15, Lloyd Wood wrote:
that webpage is still black on black.
The style file on http://affine.watson.ibm.com/tmp/ has been commented out,
since some versions of Mozilla (4.05 on SunOS 5.6??) appear to be broken.
-p.
You give a name to your house (say, "The Tulip") and
the post office knows where The Tulip is. If you move,
you can do the same at your new location, provided
there is no conflict. This seems to be more similar to the
I suspect it only works in rural areas - I recall walking past 27A
On Thu, 2001.02.01, Hilarie Orman wrote:
Dave Cheriton's TRIAD is an example of such a proposal.
Hilarie
Dave Crocker [EMAIL PROTECTED] 02/01/01 11:05AM
At 03:05 PM 1/31/2001 -0800, Ed Gerck wrote:
You miss at least one other possibility. If it is possible to develop
an addressing
{I had written:}
| from label switching, so what I'm suggesting is that we take the bull by
| the horns once and for all and run MPLS over IP instead of under it...
an mplsd-like tag fits neatly in the first half of an ipvsux destination
address, although there are other places in the
IMHO what we need to change is the *implicit* association between
"host" related identifiers and "network topology" related identifiers -
so that coders treat them as separate entities, and provide a way
for the two to be different at the IP layer - while still allowing
the optimization to
thank you, I think you've advertised this draft quite adequately for the
time being. I'm quite willing to look at it, but there are numerous
Thanks! now I will relax and go home :)
every possible alternative architecture to conclude that (a) most or all
of these identifiers are
On Thu, 21 Dec 2000, Ken Hornstein wrote:
That hasn't been my experience; I've seen what can only be described as
an "old-boy" network in operation. I'm not saying that such a thing is
necessarily bad, just that sometimes it takes significant effort to
overcome it if you're a newbie.
Both
On Wed, 20 Dec 2000, Michael Richardson wrote:
The wireless access is likely key to actually giving everyone a chance to
get online, but I recall a lot of useful work that occured in the terminal
room. I also recall deciding to go to the terminal room rather than find a
session that I
On Thu, 21 Dec 2000, Mike Fisk wrote:
Yes, I was being slightly more general to include other gateways that
don't necessarily operate at the application layer:
TCP-splicing/spoofing, NAT, SOCKS, etc.
The problem is that the protocol mechanisms to discover and use these
gateways are
On Wed, 20 Dec 2000, John Stracke wrote:
Why don't you read the I-D
I did.
Then you'd see that the invisibility refers to that of the server
host, as follows: The client sees only the service name binding
in the form of the URL, but what it gets as the data path is
a virtual path (or LSP)
I've taken the liberty of posting it to the mailing list as IMHO the issues
Joel raises are very pertinent and I believe worthy of general consumption.
[Also, I use colourful syntax highlighting in Vim under Mutt, which makes
it easy for me to view the inline quotation. I realise it will look
On Wed, 20 Dec 2000, Keith Moore wrote:
maybe the registration form should have a short quiz on material from
these documents, which must be filled out before the form is considered
complete. and if not completed successfully the prospective
registrant is warned that he may be wasting his
Hi Keith!
On Tue, 19 Dec 2000, Keith Moore wrote:
mumble. as far as I can tell, both DNS names and IP addresses
are hopelessly overloaded and are likely to stay that way until
we figure out how to make a major architectural change.
Could you please take a look at
On Tue, 19 Dec 2000, Jon Knight wrote:
are on and what the address of their gateway router is. Not exactly what
I'd call omniscience.
All right, I confess, I'm not perfect in summarising the existing art and
relating to it (yet). I promise to gratefully acknowledge comments such as
these
On Tue, 19 Dec 2000, Mike Fisk wrote:
explosion. So over time there becomes an established club of roots and
everybody else has to be a child. That creates a monopolistic situation
where you have to pay a root node for transit. It could work, but it
sounds worse than the existing DNS
On Tue, 19 Dec 2000, Mike Fisk wrote:
It's one thing to hand out addresses or names. It's another thing to run
a top-level routing server that all of your children customers have to
route through to get to other top-level providers. Your mapping between
the two would imply that, for
If you find a way to select paths in real networks using only virtual data,
we'd all be interested to hear it.
Try draft-guruprasad-addressless-internet-00.txt, and
the ECUMN'2000 paper on which it was based, at
http://affine.watson.ibm.com/tmp/vinet.pdf
The draft doesn't yet mention
Were we to i) incrementally deploy and start using new globally unique
namespace(s) [either a single one functioning much as IPv4 addresses
functioned originaly, or, as many of us think would be wise, two separate
ones, one to identify entities for end-end communication and another to give
32 matches
Mail list logo
