There are 40 applicants who paid ICANN $50,000 each in year 2000 who ICANN has strung along all these years, neither granting nor denying. These include IOD's application for.web.
ICANN needs to deal with this leftover business from 9 years ago.
Hewlett Packard did this 15+ years ago for purposes of device discovery and management.
They had a constrained abstract machine environment in some of their products that was intended to be "infected" by one of their worker programs.
Worker code would "infect" a machine, would send back reports about the machine, would serve as a contact point for management, and try to propagate itself to other machines.
We were doing formal proof of correctness of kernels back in the 1970's at System Development Corporation (SDC) in Santa Monica.
"Correctness" means correct with regard to a criteria, it doesn't mean that the system didn't have flaws outside of the criteria or that it worked or worked efficiently.
I personally worked with UCLA Data Secure Unix and SRI's PSOS (Provably Secure OS) and a couple of other systems.
One cool aspect was that in those days we had some machine architectures that had hardware support for "capabilities".
Generating the correctness criteria was very, very hard.
As for Haskell - we tended to use Pascal via a Pascal to C compiler.
Modern compilers do a lot of optimization. By analogy to the Wolfram claim could compiler optimized binaries be considered subject to a copyright via the compiler? That would be bad.
I may fault ICANN on many things, but I don't find myself agreeing with your characterizations of ICANN.
First off, ICANN has been glacial with regard to new top level domains - on average about one per year. That is a long way short of "barely comprehensible" and certainly not even close to "infinite soon".
As for following name conventions - ICANN has been very closely following the hostname conventions and the internationalized name rules established by the IETF. Perhaps the only thing that ICANN has done that differs is that ICANN has been questioning whether single letter top level domains ought to be allocated.
As for Beckstrom - he is unknown to me, but I do fear that his "no central point of control" point may carry him too far into believing that institutions such as ICANN don't need someone firmly in charge and willing to say "no" to expansion and mission creep.
I hope he recognizes that ICANN is supposed to make sure that the domain system works and that ICANN is not to be a policeman doing trademark enforcement for the intellectual property protection industry or enforcing various governments' views about what is acceptable use of the net.
I'm talking about attacks in which the attacker connects to the server, sends the protocol hello sequence, but either does not do a TCP ack or does not provide a sufficient receive window. In both cases the sender (the TCP stack of the machine under attack) sits waiting for a TCP state change that never occurs.
Sendmail and other servers are probably vulnerable to this kind of thing. And it is not necessarily the server application itself may not be where the core of the server slowdown occurs. For example, if one were to spread this kind of attack across several different types of TCP-based protocols (SMTP/SMTPS, IMAP(S), HTTP(S), DNS(tcp version), etc then the operating system's TCP engine might start suffer from too many TCP control blocks. (And it isn't just the memory occupied - some silly implementation might do a sequential scan rather than hash lookups when matching incoming packets to TCP connection blocks.)
There is another version of this kind of attack in which rather than sending incomplete data the attacker simply is extremely lazy about sending TCP ACKs - it does so only enough to keep the connection alive. Yet another alternative is that the attacker maintains a TCP receive window that is just a tad too small to contain what the attacked machine is trying to send back.
There is a flip side of this - one can build an email server that is closely integrated with the TCP stack so that incoming mail is validated while the TCP connection is open. Then if the incoming mail is bogus the machine can go into slow ACK/small receive window mode and try to constipate the TCP stack of the spamming machine. Unfortunatly that technique was more useful before hordes of bots were used as spam amplifiers.
I see the "demanded" part, but I don't see any evidence of the "subsequently received" part.
By-the-way, when I asked "who" I was thinking that there will be some institutional thing with the keys locked away in some vault that requires multiple people to agree to open.
But those people will work at the behest of somebody and, after watching president Nixon knock off Attorney General after Attorney General during the Saturday Night Massacre, I tend to wonder about the extreme limiting cases.
The text of the bill does not yet seem to be visible, but the Rockefeller press release suggests that open source means code that does not limit use or distribution. One could argue that GPL2/3 imposes material limitations on use and distribution and thus would not qualify under the bill.
The GPL's position under the bill may not be helped by the use of the words "free" rather than "open source" by many deep in the GPL community.
It is not at all clear that Google is breaking no laws.
Try taking a photograph of the Hollywood Sign - it's protected by trademark or copyright law and the folks in Hollywood do go after people.
The latest King Kong flick had a note in the credits that the had licensed the image of the Empire State Building.
Architects sometimes try (and succeed) in protecting their creations.
And Google is in it for the money - they use these photos to gain more click data and to sell more ads. Google is not some innocent taking a few snapshots.
So don't jump too quickly to the conclusion that Google isn't violating some of the property owners rights.
From the point of view of most users the internet address is a URL/URI, not an IPv4 or IPv6 sequence of bits.
The fact that some protocols work poorly over NATs is based on architectural aspects that we've known are wrong for years - most particularly the carriage of lower layer addresses within higher layer protocols. SIP, particularly its use of SDP, is an example of this and which is why SIP tends to have trouble with NATs and needs assistance from things like STUN. This may the reason why Skype use so greatly dominates SIP.
HTTP/HTTPS is becoming the new transport. And HTTP/HTTPs anticipates the kind of proxying and relaying that comes as the net evolves into a lumpy world of NATs, firewalls, and application level gateways.
This is a minor nit - ARP cache timeouts are normally on the order of 300 seconds, not two minutes.
A less minor nit is this: IPv6 does not help decrease the size of routing tables as seen by major providers. Nor does IPv6 reduce the burden of sending routing updates so that routing updates are propagated faster than the underlying rate of change of usable net paths. (Enterprise subnets, whether IPv4 or IPv6, don't generally propagate into the routing announcements as seen by the big carriers.)
The compelling argument, for me at least, is that IPv6 is really a new internet that runs along side of the existing IPv4 net - there is no direct interoperability. This means that pretty much any new expansion of the net is going to require IPv4 connectivity, and IPv4 addresses, to reach the legacy net. And that makes IPv6 redundant from the user's point of view. That sort of drains the oil out of the IPv6 crankcase.
Of course the biggest argument of all is that IPv6 does not solve the hard issues of propagating routing information and finding usable paths across the net, particularly as the demands of human-conversational traffic and the political acts of nations are (unfortunately) driving routing to become increasingly aware of the types of traffic being routed.
I'm waiting to be shown that I'm wrong - I helped do the very first calculation of IPv4 address consumption back in the mid 1980's. And I was in the group at Sun back in the very early 1990's where IPv6 took form. I spent time at Cisco wrestling with questions like how to efficiently mechanize 128-bit longest-prefix matching on 32 and 64 bit hardware. And my company currently has IPv6 testing products. So I've been watching IPv6 for what will soon be two decades.
To me one of the tilt-points of IPv6 will be when I can go into Frys Electronics and find IPv6 capable print servers and other widgets of that ilk on the shelves.
I saw ISO/OSI come and go (I was rather a fan of TUBA - which included the use of ISO/OSI CLNP for the new IP layer - when the various IPv4 alternatives were being considered in the early 1990's.) It would not surprise me to see IPv6 go the way of ISO/OSI.
Google blurred the satellite photo of the US Naval observatory in DC, a public building, in order to protect VP Cheney.
If Google is willing to protect the privacy of a public figure than it ought to be even more protective of the privacy of a private homeowner by burring a photo taken while being a non-invited intruder on that homeowner's own property.
As I read it Google was trespassing on private property and took photos while on that private property. The court says it is OK for Google to keep the photos.
OK, suppose now that I just happen to wander into Google 's offices in Mountain View while a receptionist is in the bathroom and go into the building and take photos of Google's stuff.
I guess under this ruling I would get to keep my photos?
There is a strong chance that many of the claims in these patents have predecessors in the Capability Based operating systems of the 1970's.
Check out the Intel 432 architecture.
Check out IBM's "SWORD" project.
Check out UCLA Data Secure Unix.
Check out the Plessy capability systems from that period.
SRI did a lot of work in this area as well. And so did we at System Development Corp. (SDC).
The idea of a capability is a descriptor that defines access rights in an extensible manner - for example one can say that the disk driver can't deal with tape hardware or that a text editor can only do certain things to a particular SQL database.
The person made his request under FOIA. That was not the best vehicle for this.
A much better law to use to get information about yourself is the Privacy Act.
The two laws have confusingly similar numbers: 5 USC 552 for FOIA and 5 USC 552a for the Privacy Act.
The Privacy Act is a much bigger hammer for getting information about yourself. Agencies have many fewer excuses and the deadlines are far shorter. And agencies generally can't make you pay for you to get their information about you.
Yes, the Privacy Act has many loopholes, but they are much fewer than those in FOIA.
So, if people are going to do this they should make sure that they make their request under the Privacy Act. They can still use FOIA, but they should do so under a separate cover because the agencies will intentionally conflate the two laws so that they can avoid fully complying with either.
Typical provider contracts for these things repudiate all of the points you would like to have. They tend to explicitly claim that they have full access rights to do data mining. They may or may not be willing to refrain from third party disclosures. But even if they do, plan on 'em laying down and playing dead if anybody shows up with a DMCA request.
As for post termination rights - One contract I looked at said that there would be no, zero, nada, none - that the email would not be returned, period. And it would be retained.
University IT departments are really selling the souls of the students, faculty, and staff for relatively little in return.
The University of California, to take but one example, could plausibly lose much of its stream of revenue, measured in cubic millions of dollars, from patent licensing because of patent failures resulting from sloppy agreements made to save a few hundred $k.
And to make it worse, some of these agreements, particularly Google's, incorporate massive amounts of language, rights, and restrictions via URLs to highly fluid external sources. In other words, it is rather hard to nail down the exact language of the contract today, and even harder to do it at any time in the future.
I looked over a contract between Google and a large university and found it to be very dangerous to the intellectual property rights of the university and to the privacy rights of students, faculty, and staff.
For example, because email is being disclosed to a third party, such as Google, it could affect the dates of disclosure (publication) of information and could, thus, cause a patent application to fail because of an excessive time lapse between publication and the application. It is necessary to bring the provider into the tent of protection so that patent rights are not harmed.
And in these days of litigation, consider who will get subpoenas, the university or the provider, and who will get notice in time to go to court to contest the delivery of the materials.
The terms in some of these contracts make the provider the copyright owner, or at least give a perpetual non-revocable license to the provider, even beyond the lifetime of the agreement. That can lead to some rather unhappy faculty who find that their publications, and their notes and discussions, have been licensed away, forever.
Also consider whether the university can get the email back at the end of the contract. There is a good chance that it will not be able to do so.
And consider whether you think it is a good idea for students, who tend to experiment with life's options, to begin to build a lifelong dossier that contains their university life emails.
The number of issues of this type is huge and most university lawyers are either not equipped to comprehend them or don't care to do so.
Most people I know who have deeply considered these things tend to find it a really bad idea to outsource university email without very, very strong contractual protections that think through the issues of now and the issues that might arise in the future, particularly when the university wants to terminate the agreement or move to another provider.
The damages owed by Exxon for the Valdez oil spill were recently limited and substantially reduced because the court found the original damages excessively punitive. So if it makes sense for Exxon perhaps it also makes sense to apply a similar theory of limitation of damages elsewhere.
Slashdot Mirror
I am curious about those "regulatory requirements" that "guide the unveiling".
Anybody know what that is all about?
There are 40 applicants who paid ICANN $50,000 each in year 2000 who ICANN has strung along all these years, neither granting nor denying. These include IOD's application for .web.
ICANN needs to deal with this leftover business from 9 years ago.
Hewlett Packard did this 15+ years ago for purposes of device discovery and management.
They had a constrained abstract machine environment in some of their products that was intended to be "infected" by one of their worker programs.
Worker code would "infect" a machine, would send back reports about the machine, would serve as a contact point for management, and try to propagate itself to other machines.
We were doing formal proof of correctness of kernels back in the 1970's at System Development Corporation (SDC) in Santa Monica.
"Correctness" means correct with regard to a criteria, it doesn't mean that the system didn't have flaws outside of the criteria or that it worked or worked efficiently.
I personally worked with UCLA Data Secure Unix and SRI's PSOS (Provably Secure OS) and a couple of other systems.
One cool aspect was that in those days we had some machine architectures that had hardware support for "capabilities".
Generating the correctness criteria was very, very hard.
As for Haskell - we tended to use Pascal via a Pascal to C compiler.
Modern compilers do a lot of optimization. By analogy to the Wolfram claim could compiler optimized binaries be considered subject to a copyright via the compiler? That would be bad.
I may fault ICANN on many things, but I don't find myself agreeing with your characterizations of ICANN.
First off, ICANN has been glacial with regard to new top level domains - on average about one per year. That is a long way short of "barely comprehensible" and certainly not even close to "infinite soon".
As for following name conventions - ICANN has been very closely following the hostname conventions and the internationalized name rules established by the IETF. Perhaps the only thing that ICANN has done that differs is that ICANN has been questioning whether single letter top level domains ought to be allocated.
As for Beckstrom - he is unknown to me, but I do fear that his "no central point of control" point may carry him too far into believing that institutions such as ICANN don't need someone firmly in charge and willing to say "no" to expansion and mission creep.
I hope he recognizes that ICANN is supposed to make sure that the domain system works and that ICANN is not to be a policeman doing trademark enforcement for the intellectual property protection industry or enforcing various governments' views about what is acceptable use of the net.
Syn flooding is very old hat - from the 1970's.
I'm talking about attacks in which the attacker connects to the server, sends the protocol hello sequence, but either does not do a TCP ack or does not provide a sufficient receive window. In both cases the sender (the TCP stack of the machine under attack) sits waiting for a TCP state change that never occurs.
Sendmail and other servers are probably vulnerable to this kind of thing. And it is not necessarily the server application itself may not be where the core of the server slowdown occurs. For example, if one were to spread this kind of attack across several different types of TCP-based protocols (SMTP/SMTPS, IMAP(S), HTTP(S), DNS(tcp version), etc then the operating system's TCP engine might start suffer from too many TCP control blocks. (And it isn't just the memory occupied - some silly implementation might do a sequential scan rather than hash lookups when matching incoming packets to TCP connection blocks.)
There is another version of this kind of attack in which rather than sending incomplete data the attacker simply is extremely lazy about sending TCP ACKs - it does so only enough to keep the connection alive. Yet another alternative is that the attacker maintains a TCP receive window that is just a tad too small to contain what the attacked machine is trying to send back.
There is a flip side of this - one can build an email server that is closely integrated with the TCP stack so that incoming mail is validated while the TCP connection is open. Then if the incoming mail is bogus the machine can go into slow ACK/small receive window mode and try to constipate the TCP stack of the spamming machine. Unfortunatly that technique was more useful before hordes of bots were used as spam amplifiers.
I see the "demanded" part, but I don't see any evidence of the "subsequently received" part.
By-the-way, when I asked "who" I was thinking that there will be some institutional thing with the keys locked away in some vault that requires multiple people to agree to open.
But those people will work at the behest of somebody and, after watching president Nixon knock off Attorney General after Attorney General during the Saturday Night Massacre, I tend to wonder about the extreme limiting cases.
Who will be the person who gets to hold the master crypto keys used to sign the root zone?
Somebody, somewhere, has to do this. Who?
Even the Whitehouse.gov website has a 1x1 pixel web bug that is in violation of their own privacy policy, not to mention 5 USC 552a.
The text of the bill does not yet seem to be visible, but the Rockefeller press release suggests that open source means code that does not limit use or distribution. One could argue that GPL2/3 imposes material limitations on use and distribution and thus would not qualify under the bill.
The GPL's position under the bill may not be helped by the use of the words "free" rather than "open source" by many deep in the GPL community.
It is not at all clear that Google is breaking no laws.
Try taking a photograph of the Hollywood Sign - it's protected by trademark or copyright law and the folks in Hollywood do go after people.
The latest King Kong flick had a note in the credits that the had licensed the image of the Empire State Building.
Architects sometimes try (and succeed) in protecting their creations.
And Google is in it for the money - they use these photos to gain more click data and to sell more ads. Google is not some innocent taking a few snapshots.
So don't jump too quickly to the conclusion that Google isn't violating some of the property owners rights.
From the point of view of most users the internet address is a URL/URI, not an IPv4 or IPv6 sequence of bits.
The fact that some protocols work poorly over NATs is based on architectural aspects that we've known are wrong for years - most particularly the carriage of lower layer addresses within higher layer protocols. SIP, particularly its use of SDP, is an example of this and which is why SIP tends to have trouble with NATs and needs assistance from things like STUN. This may the reason why Skype use so greatly dominates SIP.
HTTP/HTTPS is becoming the new transport. And HTTP/HTTPs anticipates the kind of proxying and relaying that comes as the net evolves into a lumpy world of NATs, firewalls, and application level gateways.
This is a minor nit - ARP cache timeouts are normally on the order of 300 seconds, not two minutes.
A less minor nit is this: IPv6 does not help decrease the size of routing tables as seen by major providers. Nor does IPv6 reduce the burden of sending routing updates so that routing updates are propagated faster than the underlying rate of change of usable net paths. (Enterprise subnets, whether IPv4 or IPv6, don't generally propagate into the routing announcements as seen by the big carriers.)
The compelling argument, for me at least, is that IPv6 is really a new internet that runs along side of the existing IPv4 net - there is no direct interoperability. This means that pretty much any new expansion of the net is going to require IPv4 connectivity, and IPv4 addresses, to reach the legacy net. And that makes IPv6 redundant from the user's point of view. That sort of drains the oil out of the IPv6 crankcase.
Of course the biggest argument of all is that IPv6 does not solve the hard issues of propagating routing information and finding usable paths across the net, particularly as the demands of human-conversational traffic and the political acts of nations are (unfortunately) driving routing to become increasingly aware of the types of traffic being routed.
I'm waiting to be shown that I'm wrong - I helped do the very first calculation of IPv4 address consumption back in the mid 1980's. And I was in the group at Sun back in the very early 1990's where IPv6 took form. I spent time at Cisco wrestling with questions like how to efficiently mechanize 128-bit longest-prefix matching on 32 and 64 bit hardware. And my company currently has IPv6 testing products. So I've been watching IPv6 for what will soon be two decades.
To me one of the tilt-points of IPv6 will be when I can go into Frys Electronics and find IPv6 capable print servers and other widgets of that ilk on the shelves.
I saw ISO/OSI come and go (I was rather a fan of TUBA - which included the use of ISO/OSI CLNP for the new IP layer - when the various IPv4 alternatives were being considered in the early 1990's.) It would not surprise me to see IPv6 go the way of ISO/OSI.
Google blurred the satellite photo of the US Naval observatory in DC, a public building, in order to protect VP Cheney.
If Google is willing to protect the privacy of a public figure than it ought to be even more protective of the privacy of a private homeowner by burring a photo taken while being a non-invited intruder on that homeowner's own property.
As I read it Google was trespassing on private property and took photos while on that private property. The court says it is OK for Google to keep the photos.
OK, suppose now that I just happen to wander into Google 's offices in Mountain View while a receptionist is in the bathroom and go into the building and take photos of Google's stuff.
I guess under this ruling I would get to keep my photos?
I've had Motorola phones that have a micro USB connector but refuse to accept a charge from anything except a Motorola charger.
I would hope that this agreement to use USB goes further than simply adopting the physical connector.
It should be possible to attach to any convenient USB plug - without benefit of drivers - and recharge a phone.
There is a strong chance that many of the claims in these patents have predecessors in the Capability Based operating systems of the 1970's.
Check out the Intel 432 architecture.
Check out IBM's "SWORD" project.
Check out UCLA Data Secure Unix.
Check out the Plessy capability systems from that period.
SRI did a lot of work in this area as well. And so did we at System Development Corp. (SDC).
The idea of a capability is a descriptor that defines access rights in an extensible manner - for example one can say that the disk driver can't deal with tape hardware or that a text editor can only do certain things to a particular SQL database.
The person made his request under FOIA. That was not the best vehicle for this.
A much better law to use to get information about yourself is the Privacy Act.
The two laws have confusingly similar numbers: 5 USC 552 for FOIA and 5 USC 552a for the Privacy Act.
The Privacy Act is a much bigger hammer for getting information about yourself. Agencies have many fewer excuses and the deadlines are far shorter. And agencies generally can't make you pay for you to get their information about you.
Yes, the Privacy Act has many loopholes, but they are much fewer than those in FOIA.
So, if people are going to do this they should make sure that they make their request under the Privacy Act. They can still use FOIA, but they should do so under a separate cover because the agencies will intentionally conflate the two laws so that they can avoid fully complying with either.
See: http://www.cavebear.com/archive/nsf-dns/laws.htm
Typical provider contracts for these things repudiate all of the points you would like to have. They tend to explicitly claim that they have full access rights to do data mining. They may or may not be willing to refrain from third party disclosures. But even if they do, plan on 'em laying down and playing dead if anybody shows up with a DMCA request.
As for post termination rights - One contract I looked at said that there would be no, zero, nada, none - that the email would not be returned, period. And it would be retained.
University IT departments are really selling the souls of the students, faculty, and staff for relatively little in return.
The University of California, to take but one example, could plausibly lose much of its stream of revenue, measured in cubic millions of dollars, from patent licensing because of patent failures resulting from sloppy agreements made to save a few hundred $k.
And to make it worse, some of these agreements, particularly Google's, incorporate massive amounts of language, rights, and restrictions via URLs to highly fluid external sources. In other words, it is rather hard to nail down the exact language of the contract today, and even harder to do it at any time in the future.
I looked over a contract between Google and a large university and found it to be very dangerous to the intellectual property rights of the university and to the privacy rights of students, faculty, and staff.
For example, because email is being disclosed to a third party, such as Google, it could affect the dates of disclosure (publication) of information and could, thus, cause a patent application to fail because of an excessive time lapse between publication and the application. It is necessary to bring the provider into the tent of protection so that patent rights are not harmed.
And in these days of litigation, consider who will get subpoenas, the university or the provider, and who will get notice in time to go to court to contest the delivery of the materials.
The terms in some of these contracts make the provider the copyright owner, or at least give a perpetual non-revocable license to the provider, even beyond the lifetime of the agreement. That can lead to some rather unhappy faculty who find that their publications, and their notes and discussions, have been licensed away, forever.
Also consider whether the university can get the email back at the end of the contract. There is a good chance that it will not be able to do so.
And consider whether you think it is a good idea for students, who tend to experiment with life's options, to begin to build a lifelong dossier that contains their university life emails.
The number of issues of this type is huge and most university lawyers are either not equipped to comprehend them or don't care to do so.
Most people I know who have deeply considered these things tend to find it a really bad idea to outsource university email without very, very strong contractual protections that think through the issues of now and the issues that might arise in the future, particularly when the university wants to terminate the agreement or move to another provider.
The damages owed by Exxon for the Valdez oil spill were recently limited and substantially reduced because the court found the original damages excessively punitive. So if it makes sense for Exxon perhaps it also makes sense to apply a similar theory of limitation of damages elsewhere.
Phil Karn's old KA9Q implementation of TCP (for amateur radio) was designed to accommodate very long delays.