Slashdot Mirror

A switch is distinctly non-trivial for a very simple reason:

Solutions which involve changing the problem to fit the solution rather than the other way around are inevitably poorly received. This explains the continued popularity of Sharepoint - it allows people to continue to email documents around (even if those documents are never likely to be printed) in exactly the same way as they used to before web-based services became common.

Today, thousands of businesses have software in place where there's an uneasy truce which may well involve some minor problem changes but by and large the software suits the problem.

But a lot of F/OSS software is developed to solve a particular (maybe rather specific) problem and the suggestion that it could be modified to solve both the original problem and another, new problem winds up getting shot down in flames. Example:

http://www.watersprings.org/pub/id/draft-zeilenga-ldup-harmful-02.txt
    (notwithstanding the fact that by this time virtually every major LDAP server on the planet except for OpenLDAP supported multimaster replication)

I've been waiting for the superpda wearable thingy since the late 1980s. After all it was obvious that if you could do away with the huge laptop screens they'd be lighter and consume less power.

Add the other advances e.g. controlling devices by thought - possible already just needs to be safer etc, and video neural interfaces current = very low res vision for blind. Google "seeing tongue".

Include a good UI, video cams and you'd have a "auxiliary brain" which allows people to perform virtual telepathy and virtual telekinesis as a day to day thing, with other benefits like photographic/videographic/audiographic memory.

Some years ago I also proposed that the .here TLD be reserved, to make it easier for people to find stuff ( devices, people, services, information) available in the general physical area. It would be useful to be able to quickly list, control and access stuff "virtually" in your surroundings. And I proposed .here and _one_ stepping stone to making the addressing easier. Right now when you use free WiFi at some place, it's often not easy to figure out who is providing it, why, what's the T&C, what local services are available, etc. Easier if you could just do http://here/.

I even submitted an internet draft: http://www.watersprings.org/pub/id/draft-yeoh-tldhere-01.txt
Also emailed some people who were in the ICANN.

But the ICANN seemed more interested in approving "Yet Another Dot Coms" like .biz and .info. Which to me added very little benefit to the world.

Anyway, I guess the MPAA and RIAA would require "auxiliary brains" to be crippled by DRM. Maybe people would have to pay USD0.99 for each recall ;).

Shame though. The technology is all there, all it needs is someone to put it all together in a form that's practical and usable.

So when Lenovo comes out and basically says the future of the netbook is a larger netbook aka "laptop", it's quite disappointing or even disgusting to me.

Many years ago I proposed .here as something like the DNS equivalent of RFC1918 IP addresses[1].

e.g. anyone can then use *.here for their own network (stuff like .local or .localnet would probably be for machine use - but AFAIK they are not formally reserved either).

So if you roam to a WiFi network within range, http://jukebox.here/ could control a jukebox for that location.

And http://about.here/ might actually tell you something useful. On most wifi networks this could say something like:

"Welcome to the default LinkSys WiFi homepage. The owner of this network has not set a usage policy yet. You should probably assume you're not supposed to use this network unless otherwise authorized. Please be nice :)".

But some might provide permission (maybe with some T&C).

Of course it would be safer if https was used, or the http redirected to a FQDN + https e.g. https://about.mydomain.com/.

But you'd get lots of grumbles about certs and all that...

Unfortunately I don't have millions of dollars spare to buy a TLD and then give it to the world to use.

[1] http://www.watersprings.org/pub/id/draft-yeoh-tldhere-01.txt
http://www.circleid.com/posts/top_level_domains_for_addressing_by_physical_context/

There is an expired RFC draft for cryptographically signed web-content:

http://www.watersprings.org/pub/id/draft-jbendtsen-writing-rfcs-00.txt
(I was Jons adviser on the project, creating the draft)

--
Niels

There are, actually, enough keys in the world for every player to have its own, thanks to cryptographic trickery. That is one of the extremely clever parts of AACS. Keys can be revokes for individual players.

See for instance:
http://www.watersprings.org/pub/id/draft-irtf-smug -subsetdifference-00.txt
http://forum.doom9.org/showthread.php?t=122363

Block .xxx? Huh, all along I thought a valid technical reason for having .xxx was so people looking for porn could do the following google searches:

site:.xxx ;).

Seriously though IMO .xxx is more justifiable than .biz or .info.

However, I disagree with you and the GP on TLDs.

I have long been arguing for .here to be a reserved TLD for free use for everyone - like the private RFC1918 IP addresses (10.x.x.x 192.168.x.x etc).

Basically everybody can host their own airconditioner.here in their houses/offices/rooms, and control it with http://airconditioner.here/set?temp=25c. And _polite_ people trying to figure out whether they are explicitly allowed to use an open WAP can go to http://here/ to look for terms and conditions, more info etc.

For more do a search on tldhere:
http://www.watersprings.org/pub/id/draft-yeoh-tldh ere-01.txt

I think my proposal had and has a lot more merit and utility than .xxx, .biz, .info and maybe even .tel.

But I just don't have USD100K to give to ICANN to try to get .here and then give .here to the whole world.

But it may not be as bad as all that. Not that I think it is a great idea, but Japan for example is starting domain naming in Japanese characters (hiragana and katakana alphabets, or kanji which are basically Chinese characters). So you need UTF-8 and Japanese font display and input support just to type in the domain name.

Check out this page which says it is ICANN authorized plus it offers .jp domains in kanji ("IDN multilingual domains") side by side with English ones.

I also note that i-dns.net in California supports root domains and they provide soft keyboard java applets to input them. I don't know anybody using them, though a 2000 press release mentions a couple well known companies in Japan, but I can see that the top selection in the dropdown menu (read as "koushi" or public in Japanese, though it is really Chinese which I can't read) is possibly what they will use for ".com" for example the Japanese versions use "kaisha" (company) and "netto" (net) as .com and .net equivalents it seems.

I found a 2002 Internet Draft from JPNIC on this sort of thing. It seems to me the biggest problem is that you have to be able to read a language to access an address written in that language. May be useful for old folks but at present it seems to be quite unpopular in Japan.

.here

You know about 192.168.x.x, 10.x.x.x, 172.16.x.x and 172.17.x.x private IPs?

I've been trying to get ICANN to officially reserve a TLD for _free_ _private_ use.

e.g. *.here

Then everyone who owns a network gets to define names in .here. like airconditioner.here. what.here who.here where.here or just plain here.

IMO that'll be more useful than stupid stuff like info and biz. Which are just Yet Another .Com. TLD.

Then it'll be easier to have defacto standards for accessing stuff in various _locations_ e.g. go to a cafe with a controllable jukebox, http://jukebox.here/ and you'd be able to select songs.

http://here/ and you could learn more about the free wireless access you are using and the terms and conditions (sure you can do part of that by nocatauth but then people have to remember your URL or how to return to it after they clicked OK to browse), whereas http://here/ is simpler.

See internet-draft:
http://www.watersprings.org/pub/id/draft-yeoh-tldh ere-01.txt

Alternate: http://www.circleid.com/print/540_0_1_0/

It sounds like you want a protocol that will allow you to communicate/control each device. I have written an RFP draft for a Universal Packet Driver Protocol (UPDP) based on ICMP extensions. It's basically a protocol to allow devices to announce themselves, describe how they can be controlled, and provides for authentication. Tell me if it is something your interested in working with.

MPLS totally sucks. It's the X.25 of the new millenia, just as ATM was the X.25 of the 90's. Why? It's a CIRCUIT SWITCH methodology on top of a PACKET SWITCHING network. Dumb! It's another thing to manage and break from a network engineering point of view. That, and most vendors implementations don't work worth a damn today.
[snip]

This would be enough for a person with an average education in MPLS to judge how much you (don't) know about MPLS. I am doing MPLS-oriented research for the last 1.5 years so let me try clearing some of the "bad air" around the issue:

1) MPLS is NOT circuit switching ON TOP of packet switching. If you would care to do some minimal reading before you flame a subject, you would find out that MPLS is not ISO layer >= 3 but it is a "layer 2.5" technology. In other words IP datagrams are carried on top of MPLS frames pretty much the way ATM worked.

2) The reasons behind MPLS are too complex to describe here (for the intrested reader, take a look at RFC3031). But basically it was acknowledged that despite ATM being "evil" circuit switched technology does offer some advantages. That's why you can (_very_ roughly) characterize MPLS as an "IP friendly ATM", minus some of ATM's design shortcomings (that were present there due to the technology limitations at that time and ATM's intended use).
But to rebute your misconception, MPLS is NOT about "routing IP datagrams fast", nor "replacing CIDR". Again, if you care to skim the mentioned RFC it is acknowledged that this _were_ some advantages few MPLS proponents claimed but this is simply not true, as you correctly state: Efficient algorithms for IP address lookup and routing are implemented in hardware by several vendors (incl. cisco, btw...) so MPLS doesn't have any edge there.

3) About "Traffic Engineering being a load of crap" I would say that few of the top 10 largest carriers in US might disagree a bit. Get a hold of an educated MCI network operations engineering (say MCI/UUNET) and ask how much improvement (and revenue) TE gives them. And yes, the reaction is "WOW".

And QoS... Same deal- load of crap.
4) Well, QoS is too broad a topic to disuss in any relevance here. But in saying that you automatically excluded _all_ mechanisms for traffic differentiation in a network. Enough said.

Also, to end this, MPLS is _not_ only about TE/QoS/IP fast switching. It is used for fast network restoration, it is extended for supporting WDM in a similar manner (see "Generalized"MPLS), etc. People w/ some network education might care to take a look here for a overall view on the MPLS-related topics.

All in all I would dare to say that your posting is the worst kind of mis-information:It contains a grain of truth and mixes completely different and unrelated subjects as "comparisons" (OPenGL w/ CIDR)

For the rest of the readers, the necessary grain of salt when reading the linked article: In IETF there is a lot of politics around MPLS (disguised in "technical debates") -- surprise,surprise. For example if someone cares to browse the MPLS mailing list archives Mr. Randy Bush long opposed BGP/MPLS VPNs (described initially in RFC2547.IIRC there is also draft updating it). Which happen to be a technology cisco pushes very hard and which Mr. Bush opposes violently.
What particular agenda Mr. Bellovin has escapes me. But I assume (again, this is _speculation_) since AT&T made a _huge_ investment in ATM in the past do not see MPLS (which is simply a better competening technology) so favorably.

All in all, remember that the most competent answer is "I don't know.It depends".


My $0.02
Florian-Daniel Otel
http://www.ce.chalmers.se/staff/otel