The case, regardless of its outcome, also points to a broader issue that will not go away: how to manage the meeting of two worlds of programming. The traditional kind produces proprietary software guarded by strict intellectual property laws of copyright and patent, while the fast-growing open-source movement, responsible for software like Linux, has thrived by freely sharing code and shunning the constraints of intellectual property.
Excuse me?
Software development was originally and traditionally open source. The first software came from academic researchers who had no need to sell software, and from computer equipment manufacturers who initially only viewed the market for selling hardware. There was no concept of proprietary software when the computer industry started. Eventually that was brought into the scheme of things as competitors came along, such as RCA when it first tried to clone the IBM mainframes. But all along, most academically developed software was free and open source. That tradition just became more noticed by businesses once critical mass (e.g. Linux) was reached that attracted everyone to it.
Outsourcing is shifting from H-1B to corp-to-corp where the 2nd party is in the foreign country. So H-1B will soon become irrelevant. L-1 may continue to be a problem, but most of the jobs will not be jobs anymore, but outsource contracts to foreign firms who are not obligated by US law for such things privacy, HIPAA, etc.
There's no point in having public schools push technology education anymore. It's more than self-sustaining now. They are producing far more people seeking work in technology than businesses can take up (or care to, or even respect). If anything, some of those programs need to be shut down.
I agree. Email marketing should be strictly on an opt-in only basis. That's something Europe seems to be headed in the right direction regarding.
But I do support and stand by our First Amendment. I do consider it a "Sacred Text" (as I do for the others, like the Second Amendment). I actually do receive some email advertising which I actually want. That's not spam. Spam is not about content. The definition I use, and the definition I think most people would use once they think about it, is "unsolicited bulk email". The "unsolicited" part means "I didn't ask for it" (and just because I buy something from some company does not mean I ask for their advertising). The "bulk" part means they are doing more than having a person literally type in my email address and the message text for each message sent.
Yes, the definition I gave for "bulk" does include mailing lists. But it's not spam if you subscribed.
Make the unlicensed collection of large e-mail lists a serious crime.
Actually, governments might be more inclined to tax it. Just make sure it doesn't apply to email address provided as part of confirmed subscribing.
... and create a Do-Not-Spam list of e-mail addresses similar to the FTC's new Do-Not-Call registry that has succeeded in a number of states in virtually eliminating unwanted telemarketing calls.
How many of my email addresses will I be allowed to register? Let me see, assuming a maximum of 64 characters per username (it's probably more), and 36 different characters (actually there's more there, too), that would be potentially 40119919145476304800650533877024438126904024877418 12225955731622655455723258857248542161222254985216 addresses. Of course no one would have that many and no database could store them all. But spammers could dynamically generate random ones. As more and more mail services support tagged addresses, spammers will likely start adding random tags to make sure they have a defense of "no match in the do-not-spam database".
I use a different email address for every mailing list I subscribe to. Should I register every one of them with the database? Most of them have already been spammed (probably harvested from online archives of those mailing lists).
One possibility is requiring that tagged format address be matched with respect to the base address (tag characters usually being "-" and "+"). Another is registering a whole vanity domain making it applicable to every username possibility. I'm sure aol.com will get registered like that, as will just about every domain out there. Mine will be.
Such a provision would make it easy for anyone to cause harm to a company or individual by forging spam that appears to be benefitting them. It's a bad idea.
The gradient is gamma corrected. It is not linear with respect to the byte codes, but rather, is linear with respect to the light intensity produced by the byte codes being gamma uncorrected in the monitor. What that means is that across a span of values there can be adjacent pixels that are sufficiently close in intensity to be coded with the same byte value. Where that happens in all 3 colors planes you get 2 pixels that are the same color.
I actually ran the program that generated that top image over quite a number of different square sizes using the same corner colors. Other sizes actually produced fewer different colors just because of there the points of intensity divided at N intervals happen to hit intensity byte codes based on the gamma correction involved. The 218x218 image actually had fewer colors (but I don't remember the count as this was a few years ago and I've dicarded all the work files since then).
It's not a function of the GIF format that determines the number of colors. Instead, it is a function of the base color points chosen (they were constant across all the sizes I tried from 128 to 256), the gamma value (I don't remember the exact value chosen, but it, too, was constant across all trials and was around 2.44 or so), and the use of 8 bits for value coding. You get the same effect in PPM format, TIFF format, and even PNG format.
The more that people can't write, the less grafitti will be covering all the walls. Oh wait, now they're cracking into web sites and plastering them with HTML. Nevermind.
Actually, GIF can render photo-quality images. It can do 24-bit color. It does it by means of blocks. That feature has been in there all along. It just didn't get well adopted because at the time it came out, the best video cards were no more than 256 colors. So it just came to be that all GIF images were done in a single block. To see how a GIF can in fact have well more than 256 colors, see here. It's just not efficient at it.
This decision is what hurt PNG significantly. As we see, there was no migration of animated imaging on the web from GIF to MNG. One reason is there was simply no browser support. And why did PNG take so long to get into browsers? It was developed quick enough, but it should have been in every browser version thereafter. It was not. It took a while before support started to show up. And then, there was no animation. So everyone who wanted to put animated images up had to stay with GIF. I think the PNG folks created a fine piece of technology and failed to promote it properly. And it should have had at least basic animation at a level equivalent to GIF for no other reason than to kill off GIF. But they didn't do that and decide to drag things out, and so GIF did not die.
Novell should sue SCO simply to ensure that should SCO prevail, or accept a settlement, that Novell will be assured they get their 95% of the proceeds under the terms of the contract between Novell and SCO that gives SCO the right to license Unix and keep 5% of what they get for it. The reason I believe this is important is because I believe SCO intends to take any final proceeds, distribute them to shareholders and executives who have options, and dissolve the company, leaving Novell in a position to have to pursue "lifting the veil" to recover their 95%, which won't be so easy for all shareholders.
IANAL, but I see a major legal risk in buying out SCO. While it won't be as significant as SCO winning in court, what a buyout could result in is other parties playing the same game.
Apparently, SCO does not own the actual copyright tp Unix. Instead, the own rights to license the original code, granted to them from Novell. They licensed those rights to IBM. But SCO, by not being the original copyright owner, cannot grant to IBM the right to give away the code. So even if IBM pays SCO a settlement, or buys those rights entirely from SCO, or just buys the whole company (which it could easily do), it does not begin to address the issue with regard to the original copyright holder. If IBM did give away or otherwise leak the code, the settlement may indemnify IBM, but SCO doesn't have any rights to waive liabilities for any other party it didn't specifically license things to. In the end, only Novell would have the final rights, and that could have a value 19 times that of what the SCO settlement ends up being.
SCO apparently doesn't even have the right to release the code to the public themselves. So short of a court order to openly release all the code (and a court could, and would more readily, keep everything under seal), the whole issue of whether there really is any original Unix code in Linux would remain unresolved.
So, IMHO, IBM should not buy out SCO whatsoever, nor even agree to settlement. SCO cannot themselves completely clear the issue, and a settlement would only further strengthen anyone else's claims, leaving much lingering FUD. The only way to resolve this is in court. And hopefully the court will be wise enough to determine that because of SCO's refusal to allow Linux to have the offending code removed, it loses all rights to any claims after the date the first request to show the code was made (shortly after it made these claims).
If there is code in Linux which is someone else's intellectual property, then certainly they have legal rights to make the claims and recover losses and royalties. But I know of no copyright or trademark law which allows the owner of the intellectual property to deny someone the right to not use their property.
If you'd like to do independent consulting from home, you might want to try out KEEN at the UK site or the US site. This site allows people with questions to get connected with you for help, and you get paid. I have no association with the site other than someone showed it to me a couple weeks ago.
The AT&T breakup was wrong. It was done the wrong way. A breakup was needed. But it wasn't obvious at the time the way the breakup needed to happen. The way it should have been done, which is more clear now, is to totally separate the infrastructure from everything else. And it is still possible to do this now with the coming fiber infrastructure.
What we need is an infrastructure company that does nothing else but infrastructure. That company would own the infrastructure and the access point facility. But they would not be allowed to be in any level of business beyond that in exchange for having the infrastructure monopoly. They would not provide dialtone. They would not provide IP routing. They would also not provide point to point circuits except to common carrier businesses.
Every common carrier would pay the same price to have access to the infrastructure. There would be one price for full dark fiber. There would be another price for partial bandwidth on a multiplexed fiber. Homes should have a minimum of 7 fibers, and businesses of course would have more as needed. But 7 is enough for a massive amount of service in today's terms. One fiber can run hundreds of TV channels and gigabits of digital bandwidth.
The advantage of this split, is it separates the infrastructure monopoly from fair competitive information and communications services, allows choice, and even allows multiple concurrent services. The big money is in the information and communications services, so this will help boost the economy, too. The infrastructure company would be allowed to charge actual costs plus a reasonable profit for a stable long term return on investment.
The philosophy of TCP/IP has been dumb networks and smart end points. I'd take that just a bit further. Networks are not as dumb as they seem. Routing tables represent a lot of smarts. RIP is fairly dumb. OSPF and BGP are smarter. But the one factor that doesn't scale is keeping routes in routing tables. Instead, what is needed is a way to route w/o that table. My design would work by having a route discovery protocol that lets the end points figure out the path to take in terms of a series of interface indexes. Details would be rather complex because of the need to have security integrated into it as well. But it would end up being something like source routing where the packet would contain the path it is to take and would form a reverse path for the peer to use (this is where the security is important). Instead of the path hops being described in terms of IP address, the routers involved would assign a fixed set of indexes to each interface they can route over. These indexes would be encoded like UTF-8 so for most routers only one byte is needed per hop, but the capacity exists for a router to have 2 billion interfaces. The critical part would be the route lookup. This would be done at all AS border routers not unlike BGP, but instead of holding all the routes, the routers would merely consult a routing database which may not even be in the same AS. Since these consultations would not be for every packet (only for route discovery probes), the database would not have a huge load. For performance the router can cache some routing data (I'm of the opinion that all data stored in a router should be of a cached nature, guided by a database somewhere that knows more). The ultimate caching would be stored in the end points. The route determinations would be exchanged through the consulation databases. They would build up route information not unlike BGP, except that they would not have to flush routes when an interface goes down. One requirement would be that each assigned network would also have an authenticity certificate the databases would verify. The IP packet would have to carry the actual address, the source routing path, and an index to a signed hash stored in the databases of the endpoint AS for verification (the index serves to speed up finding the route authenticity record). The end point routers would cache that certificate with the address and reverse path that created the hash. Initial verification would involve actually generating the hash and encrypting it, but subsequently, as long as the path remains the same and the data remains in cache, it only needs to be compared (so encryption work is not on a per packet basis in the router). But the path can change, or the cache entry can be discarded, and it would only need to reverify (and the database CPU may really be doing that work, anyway). Within an AS, routing could be a more conventional approach, such as an OSPF like protocol.
Regardless of whether the DNS servers are in the ISP's own facility, or if the ISP provides a circuit to me to run the DNS servers at my place, I still want the DNS servers to be able to be switched to another ISP without having to hassle with the domain registration people to get HOST records properly updated (they almost always goof it up). With a portable address space, I have control.
I do understand I can do lots of stuff without a portable address space. But I have no need for IPv6 right now. However, bribe me with IPv6 address space which I can keep forever and never have to change it, and I'll jump on the bandwagon right then. If not, then I will do what everyone else is doing, which is wait until enough others are unreachable via IPv4 to make it worthwhile.
It's more like they are tossing all the chairs and breaking all the glass in the room because they are upset over the rest of us wanting to play with someone else's toys.
It reminds me of a short skit I saw on a kids' TV show. It started with 2 kids fighting over who gets to play with a toy. The mother comes in and takes the toy, sets it aside, and demands "You two solve this like adults!". One of the kids then says to the other "You're gonna hear from my lawyer".
A more correct analogy would be a boat owner trying to sell a sinking... or sunken... ship. Or a fallen bridge. He's just trying to find a way to bail out without a total loss on his stock options.
At the very least they should post their resumes on the various online job boards by 1 June 2003. Don't even consider hiring them if its posting date is any later than that.
I certainly don't want to run my DNS server's in someone else's address space. That space could die, too. If I host with someone else, what's to prevent their AS from being misrouted, and all their multi-homed connections to become useless? You can't run DNS on more IP addresses than you can put in the NS and A records, so the parallel multiple address methods are not workable. Instead, IPv6 just needs a decent highly scalable routing system that, unlike BGP, does follow the principle of keeping the end points smart and the network stupid.
Changing the address in the LAN router is not the only issue. For example you have to list your server IP addresses (not just domain name) for domains that your DNS server serves... the GTLD and other DNS servers can't pick up on that. And the bigger issue is multi-homed connectivity. You have to announce a full portable address prefix for that to work, and thus you have to have one first.
Slashdot Mirror
Or maybe the author meant "in the world as my miniscule life has experienced it".
From the article:
Excuse me?
Software development was originally and traditionally open source. The first software came from academic researchers who had no need to sell software, and from computer equipment manufacturers who initially only viewed the market for selling hardware. There was no concept of proprietary software when the computer industry started. Eventually that was brought into the scheme of things as competitors came along, such as RCA when it first tried to clone the IBM mainframes. But all along, most academically developed software was free and open source. That tradition just became more noticed by businesses once critical mass (e.g. Linux) was reached that attracted everyone to it.
Outsourcing is shifting from H-1B to corp-to-corp where the 2nd party is in the foreign country. So H-1B will soon become irrelevant. L-1 may continue to be a problem, but most of the jobs will not be jobs anymore, but outsource contracts to foreign firms who are not obligated by US law for such things privacy, HIPAA, etc.
There's no point in having public schools push technology education anymore. It's more than self-sustaining now. They are producing far more people seeking work in technology than businesses can take up (or care to, or even respect). If anything, some of those programs need to be shut down.
What if we have to use regular expressions to cover multitudes of email addresses? How do you do regular expression matches with an MD5 checksum?
I agree. Email marketing should be strictly on an opt-in only basis. That's something Europe seems to be headed in the right direction regarding.
But I do support and stand by our First Amendment. I do consider it a "Sacred Text" (as I do for the others, like the Second Amendment). I actually do receive some email advertising which I actually want. That's not spam. Spam is not about content. The definition I use, and the definition I think most people would use once they think about it, is "unsolicited bulk email". The "unsolicited" part means "I didn't ask for it" (and just because I buy something from some company does not mean I ask for their advertising). The "bulk" part means they are doing more than having a person literally type in my email address and the message text for each message sent.
Yes, the definition I gave for "bulk" does include mailing lists. But it's not spam if you subscribed.
Actually, governments might be more inclined to tax it. Just make sure it doesn't apply to email address provided as part of confirmed subscribing.
How many of my email addresses will I be allowed to register? Let me see, assuming a maximum of 64 characters per username (it's probably more), and 36 different characters (actually there's more there, too), that would be potentially 40119919145476304800650533877024438126904024877418 12225955731622655455723258857248542161222254985216 addresses. Of course no one would have that many and no database could store them all. But spammers could dynamically generate random ones. As more and more mail services support tagged addresses, spammers will likely start adding random tags to make sure they have a defense of "no match in the do-not-spam database".
I use a different email address for every mailing list I subscribe to. Should I register every one of them with the database? Most of them have already been spammed (probably harvested from online archives of those mailing lists).
One possibility is requiring that tagged format address be matched with respect to the base address (tag characters usually being "-" and "+"). Another is registering a whole vanity domain making it applicable to every username possibility. I'm sure aol.com will get registered like that, as will just about every domain out there. Mine will be.
Such a provision would make it easy for anyone to cause harm to a company or individual by forging spam that appears to be benefitting them. It's a bad idea.
The gradient is gamma corrected. It is not linear with respect to the byte codes, but rather, is linear with respect to the light intensity produced by the byte codes being gamma uncorrected in the monitor. What that means is that across a span of values there can be adjacent pixels that are sufficiently close in intensity to be coded with the same byte value. Where that happens in all 3 colors planes you get 2 pixels that are the same color.
I actually ran the program that generated that top image over quite a number of different square sizes using the same corner colors. Other sizes actually produced fewer different colors just because of there the points of intensity divided at N intervals happen to hit intensity byte codes based on the gamma correction involved. The 218x218 image actually had fewer colors (but I don't remember the count as this was a few years ago and I've dicarded all the work files since then).
It's not a function of the GIF format that determines the number of colors. Instead, it is a function of the base color points chosen (they were constant across all the sizes I tried from 128 to 256), the gamma value (I don't remember the exact value chosen, but it, too, was constant across all trials and was around 2.44 or so), and the use of 8 bits for value coding. You get the same effect in PPM format, TIFF format, and even PNG format.
The more that people can't write, the less grafitti will be covering all the walls. Oh wait, now they're cracking into web sites and plastering them with HTML. Nevermind.
How accurately are the colors displayed in the top GIF on this page?
Actually, GIF can render photo-quality images. It can do 24-bit color. It does it by means of blocks. That feature has been in there all along. It just didn't get well adopted because at the time it came out, the best video cards were no more than 256 colors. So it just came to be that all GIF images were done in a single block. To see how a GIF can in fact have well more than 256 colors, see here. It's just not efficient at it.
This decision is what hurt PNG significantly. As we see, there was no migration of animated imaging on the web from GIF to MNG. One reason is there was simply no browser support. And why did PNG take so long to get into browsers? It was developed quick enough, but it should have been in every browser version thereafter. It was not. It took a while before support started to show up. And then, there was no animation. So everyone who wanted to put animated images up had to stay with GIF. I think the PNG folks created a fine piece of technology and failed to promote it properly. And it should have had at least basic animation at a level equivalent to GIF for no other reason than to kill off GIF. But they didn't do that and decide to drag things out, and so GIF did not die.
Must be why they bought that license from SCO.
Novell should sue SCO simply to ensure that should SCO prevail, or accept a settlement, that Novell will be assured they get their 95% of the proceeds under the terms of the contract between Novell and SCO that gives SCO the right to license Unix and keep 5% of what they get for it. The reason I believe this is important is because I believe SCO intends to take any final proceeds, distribute them to shareholders and executives who have options, and dissolve the company, leaving Novell in a position to have to pursue "lifting the veil" to recover their 95%, which won't be so easy for all shareholders.
IANAL, but I see a major legal risk in buying out SCO. While it won't be as significant as SCO winning in court, what a buyout could result in is other parties playing the same game.
Apparently, SCO does not own the actual copyright tp Unix. Instead, the own rights to license the original code, granted to them from Novell. They licensed those rights to IBM. But SCO, by not being the original copyright owner, cannot grant to IBM the right to give away the code. So even if IBM pays SCO a settlement, or buys those rights entirely from SCO, or just buys the whole company (which it could easily do), it does not begin to address the issue with regard to the original copyright holder. If IBM did give away or otherwise leak the code, the settlement may indemnify IBM, but SCO doesn't have any rights to waive liabilities for any other party it didn't specifically license things to. In the end, only Novell would have the final rights, and that could have a value 19 times that of what the SCO settlement ends up being.
SCO apparently doesn't even have the right to release the code to the public themselves. So short of a court order to openly release all the code (and a court could, and would more readily, keep everything under seal), the whole issue of whether there really is any original Unix code in Linux would remain unresolved.
So, IMHO, IBM should not buy out SCO whatsoever, nor even agree to settlement. SCO cannot themselves completely clear the issue, and a settlement would only further strengthen anyone else's claims, leaving much lingering FUD. The only way to resolve this is in court. And hopefully the court will be wise enough to determine that because of SCO's refusal to allow Linux to have the offending code removed, it loses all rights to any claims after the date the first request to show the code was made (shortly after it made these claims).
If there is code in Linux which is someone else's intellectual property, then certainly they have legal rights to make the claims and recover losses and royalties. But I know of no copyright or trademark law which allows the owner of the intellectual property to deny someone the right to not use their property.
If you'd like to do independent consulting from home, you might want to try out KEEN at the UK site or the US site. This site allows people with questions to get connected with you for help, and you get paid. I have no association with the site other than someone showed it to me a couple weeks ago.
The AT&T breakup was wrong. It was done the wrong way. A breakup was needed. But it wasn't obvious at the time the way the breakup needed to happen. The way it should have been done, which is more clear now, is to totally separate the infrastructure from everything else. And it is still possible to do this now with the coming fiber infrastructure.
What we need is an infrastructure company that does nothing else but infrastructure. That company would own the infrastructure and the access point facility. But they would not be allowed to be in any level of business beyond that in exchange for having the infrastructure monopoly. They would not provide dialtone. They would not provide IP routing. They would also not provide point to point circuits except to common carrier businesses.
Every common carrier would pay the same price to have access to the infrastructure. There would be one price for full dark fiber. There would be another price for partial bandwidth on a multiplexed fiber. Homes should have a minimum of 7 fibers, and businesses of course would have more as needed. But 7 is enough for a massive amount of service in today's terms. One fiber can run hundreds of TV channels and gigabits of digital bandwidth.
The advantage of this split, is it separates the infrastructure monopoly from fair competitive information and communications services, allows choice, and even allows multiple concurrent services. The big money is in the information and communications services, so this will help boost the economy, too. The infrastructure company would be allowed to charge actual costs plus a reasonable profit for a stable long term return on investment.
The philosophy of TCP/IP has been dumb networks and smart end points. I'd take that just a bit further. Networks are not as dumb as they seem. Routing tables represent a lot of smarts. RIP is fairly dumb. OSPF and BGP are smarter. But the one factor that doesn't scale is keeping routes in routing tables. Instead, what is needed is a way to route w/o that table. My design would work by having a route discovery protocol that lets the end points figure out the path to take in terms of a series of interface indexes. Details would be rather complex because of the need to have security integrated into it as well. But it would end up being something like source routing where the packet would contain the path it is to take and would form a reverse path for the peer to use (this is where the security is important). Instead of the path hops being described in terms of IP address, the routers involved would assign a fixed set of indexes to each interface they can route over. These indexes would be encoded like UTF-8 so for most routers only one byte is needed per hop, but the capacity exists for a router to have 2 billion interfaces. The critical part would be the route lookup. This would be done at all AS border routers not unlike BGP, but instead of holding all the routes, the routers would merely consult a routing database which may not even be in the same AS. Since these consultations would not be for every packet (only for route discovery probes), the database would not have a huge load. For performance the router can cache some routing data (I'm of the opinion that all data stored in a router should be of a cached nature, guided by a database somewhere that knows more). The ultimate caching would be stored in the end points. The route determinations would be exchanged through the consulation databases. They would build up route information not unlike BGP, except that they would not have to flush routes when an interface goes down. One requirement would be that each assigned network would also have an authenticity certificate the databases would verify. The IP packet would have to carry the actual address, the source routing path, and an index to a signed hash stored in the databases of the endpoint AS for verification (the index serves to speed up finding the route authenticity record). The end point routers would cache that certificate with the address and reverse path that created the hash. Initial verification would involve actually generating the hash and encrypting it, but subsequently, as long as the path remains the same and the data remains in cache, it only needs to be compared (so encryption work is not on a per packet basis in the router). But the path can change, or the cache entry can be discarded, and it would only need to reverify (and the database CPU may really be doing that work, anyway). Within an AS, routing could be a more conventional approach, such as an OSPF like protocol.
IPv6 doesn't have the means to add this on.
Regardless of whether the DNS servers are in the ISP's own facility, or if the ISP provides a circuit to me to run the DNS servers at my place, I still want the DNS servers to be able to be switched to another ISP without having to hassle with the domain registration people to get HOST records properly updated (they almost always goof it up). With a portable address space, I have control.
I do understand I can do lots of stuff without a portable address space. But I have no need for IPv6 right now. However, bribe me with IPv6 address space which I can keep forever and never have to change it, and I'll jump on the bandwagon right then. If not, then I will do what everyone else is doing, which is wait until enough others are unreachable via IPv4 to make it worthwhile.
It's more like they are tossing all the chairs and breaking all the glass in the room because they are upset over the rest of us wanting to play with someone else's toys.
It reminds me of a short skit I saw on a kids' TV show. It started with 2 kids fighting over who gets to play with a toy. The mother comes in and takes the toy, sets it aside, and demands "You two solve this like adults!". One of the kids then says to the other "You're gonna hear from my lawyer".
A more correct analogy would be a boat owner trying to sell a sinking ... or sunken ... ship. Or a fallen bridge. He's just trying to find a way to bail out without a total loss on his stock options.
At the very least they should post their resumes on the various online job boards by 1 June 2003. Don't even consider hiring them if its posting date is any later than that.
I certainly don't want to run my DNS server's in someone else's address space. That space could die, too. If I host with someone else, what's to prevent their AS from being misrouted, and all their multi-homed connections to become useless? You can't run DNS on more IP addresses than you can put in the NS and A records, so the parallel multiple address methods are not workable. Instead, IPv6 just needs a decent highly scalable routing system that, unlike BGP, does follow the principle of keeping the end points smart and the network stupid.
Changing the address in the LAN router is not the only issue. For example you have to list your server IP addresses (not just domain name) for domains that your DNS server serves ... the GTLD and other DNS servers can't pick up on that. And the bigger issue is multi-homed connectivity. You have to announce a full portable address prefix for that to work, and thus you have to have one first.
Switch to IPv6 now. That would have the effect of boycotting most of the US immediately.