I believe that clause 30, which excludes interconnections from the scope of that rule, means that the Netflix deal is *not* affected. But I'm not a lawyer, and I haven't read all 400 pages either.:-)
The rule is written very broadly. It basically covers *anything* that improves performance for the other party, no matter how it is implemented.
However, it turns out that the rule's scope is defined later on in the document to explicitly exclude interconnections. So it won't stop peering, which is good, on the other hand it also wouldn't apply directly to the Netflix wrangle.
It might still apply to in-network hosting, I'm not sure. I think you could argue that was new traffic, which just happens to replace the old traffic. Or that it's a form of interconnection. I'll let the lawyers figure that one out, or at least someone who has read the entire document.:-)
The Wikipedia article calls it "internet transit" and distinguishes it from "peering" as follows: "Transit is distinct from peering, in which only traffic between the two ISPs and their downstream customers is exchanged and neither ISP can see upstream routes over the peering connection." That more or less matches my original understanding. Mind you, there are no citations.
The rule disallowing paid prioritization is very broad, and does *not* have an exception for normal network management. (They actually call out explicitly that this rule does not have that exception, unlike the first two.)
However, clause 30 appears to restrict the scope of the rule to explicitly exclude peering. So that's OK after all.
You appear to be using the word "peering" to include connections between ISPs and backbone providers. Last time I checked, that wasn't standard usage.
Regardless of the linguistics, though, I'm fairly sure you understood what I meant. The rules as written appear to prohibit the practice of two ISPs exchanging data directly rather than via a backbone provider.
Stopping this practice would pretty much break the internet. I don't suppose the FCC intends to interpret the rule that way. But I don't think this is a good sign, and it would appear to justify the claims ISPs are making about the new rules creating uncertainty.
You're assuming that Cogent (for instance) actually has enough capacity to carry the necessary traffic to Comcast, and that the only reason there was ever a problem was that Comcast created one artificially.
I do not claim to know whether or not this assumption is correct, but it should be noted that it is not a law of nature.
Clause 18 - "no paid prioritization" appears to prohibit peering. It favors some traffic (traffic from the peer) over other traffic (traffic not from the peer) and is done in exchange for consideration - even if it is just on a quid-pro-quo basis ("I'll accept your traffic at the peering point if you accept mine") that's still a "consideration".
So how do things like Netflix work, if they can't put their boxen inside the local network, and don't have any QoS guarantees? Or, say, an on-line gaming system that needs low latency?
(And are you sure the government isn't subsidizing access in some way?)
One possibility is that suit is based on the theory that simply sharing an address space between the GPL code and the proprietary code, e.g., because they are both running in kernel mode, is enough to create a derivative work in violation of the GPL.
As far as I know, this theory has not yet been tested in court - am I mistaken?
Not true. The FSF insists that dynamically linking proprietary code and GPL code (for example, by installing a proprietary extension in a GPL product) creates an infringing derivative work. Linus has said that creating a proprietary Linux device driver violates the GPL, even if it uses no GPL code, IIRC on the basis that the Linux driver API is itself a copyright work subject to the GPL.
(The GPLv2, at least, has language that seems to explicitly rule this interpretation out, but that doesn't appear to bother the FSF.)
I'm actually wondering if the question of dynamic linking is involved in this case.
I really don't see why privileged access has to be a problem. If there isn't some way of providing it, then either the internet is held down to the least-common-denominator, or everybody has to pay for a level of service that most of us don't need.
You just have to apply reasonable rules. I think the only ones you really need are that the money paid for privileged access must be used to provide that access, not to subsidize the network as a whole, and that the profit margins must not be excessive. Oh, and perhaps some rules about the minimum base level of service. If there's adequate competition you may not even need to go that far.
Sure, ISPs could still game the system to some extent. But not enough to be a serious problem.
I know Uber are doing well, but is it really sensible for them to be investing in research in a field whose commercial prospects are at least a few decades out?
Google can afford a research program that won't be profitable in the foreseeable future. Can Uber?
Slashdot Mirror
A couple of possibilities spring to mind. I'm just speculating, mind you.
1) Because Jordon aren't insisting on enriching the uranium themselves, or aren't planning to use enriched uranium in the first place?
2) Because their government has a reputation for trustworthiness rather than a reputation for being batshit crazy?
("Trustworthiness" is of course a relative term for governments. But still, there's a pretty big gap between Jordon and Iran.)
Cost, perhaps? Particularly when compared to solar polar, etc.?
According to Wikipedia, they are. Target of 500MW renewable energy, about 14% of total capacity, by the end of 2015.
Because if they tell us to unlock the back door in the middle of the night, or to get into that nice man's car, we probably won't do what they say?
Extra peering connections cost 0, zilch
Bullshit. There ain't no such thing as a free lunch.
I believe that clause 30, which excludes interconnections from the scope of that rule, means that the Netflix deal is *not* affected. But I'm not a lawyer, and I haven't read all 400 pages either. :-)
The rule is written very broadly. It basically covers *anything* that improves performance for the other party, no matter how it is implemented.
However, it turns out that the rule's scope is defined later on in the document to explicitly exclude interconnections. So it won't stop peering, which is good, on the other hand it also wouldn't apply directly to the Netflix wrangle.
It might still apply to in-network hosting, I'm not sure. I think you could argue that was new traffic, which just happens to replace the old traffic. Or that it's a form of interconnection. I'll let the lawyers figure that one out, or at least someone who has read the entire document. :-)
IIRC, that was because Comcast didn't want to pay for extra peering connections. I don't *think* it's relevant to this case.
The Wikipedia article calls it "internet transit" and distinguishes it from "peering" as follows: "Transit is distinct from peering, in which only traffic between the two ISPs and their downstream customers is exchanged and neither ISP can see upstream routes over the peering connection." That more or less matches my original understanding. Mind you, there are no citations.
The rule disallowing paid prioritization is very broad, and does *not* have an exception for normal network management. (They actually call out explicitly that this rule does not have that exception, unlike the first two.)
However, clause 30 appears to restrict the scope of the rule to explicitly exclude peering. So that's OK after all.
Here's a reference: http://en.wikipedia.org/wiki/I... : "Transit is distinct from peering".
You appear to be using the word "peering" to include connections between ISPs and backbone providers. Last time I checked, that wasn't standard usage.
Regardless of the linguistics, though, I'm fairly sure you understood what I meant. The rules as written appear to prohibit the practice of two ISPs exchanging data directly rather than via a backbone provider.
Stopping this practice would pretty much break the internet. I don't suppose the FCC intends to interpret the rule that way. But I don't think this is a good sign, and it would appear to justify the claims ISPs are making about the new rules creating uncertainty.
I can't find anything in that which says they'll pay for the rack space, and IIRC they don't. IOW, Netflix customers are being subsidized by ISPs.
You're assuming that Cogent (for instance) actually has enough capacity to carry the necessary traffic to Comcast, and that the only reason there was ever a problem was that Comcast created one artificially.
I do not claim to know whether or not this assumption is correct, but it should be noted that it is not a law of nature.
Clause 18 - "no paid prioritization" appears to prohibit peering. It favors some traffic (traffic from the peer) over other traffic (traffic not from the peer) and is done in exchange for consideration - even if it is just on a quid-pro-quo basis ("I'll accept your traffic at the peering point if you accept mine") that's still a "consideration".
The FSF disagrees with you:
http://www.gnu.org/licenses/gp...
Not if the rules are enforced. Or if there's enough competition that anyone offering "poor" access to the general internet won't survive for long.
So how do things like Netflix work, if they can't put their boxen inside the local network, and don't have any QoS guarantees? Or, say, an on-line gaming system that needs low latency?
(And are you sure the government isn't subsidizing access in some way?)
I reckon you should need to get a license to travel to the UAE, including mandatory training on their various absurd laws. With an examination.
One possibility is that suit is based on the theory that simply sharing an address space between the GPL code and the proprietary code, e.g., because they are both running in kernel mode, is enough to create a derivative work in violation of the GPL.
As far as I know, this theory has not yet been tested in court - am I mistaken?
The FSF insists that dynamic linking - in fact anything that puts two pieces of code into the same address space - creates a derivative work.
Not true. The FSF insists that dynamically linking proprietary code and GPL code (for example, by installing a proprietary extension in a GPL product) creates an infringing derivative work. Linus has said that creating a proprietary Linux device driver violates the GPL, even if it uses no GPL code, IIRC on the basis that the Linux driver API is itself a copyright work subject to the GPL.
(The GPLv2, at least, has language that seems to explicitly rule this interpretation out, but that doesn't appear to bother the FSF.)
I'm actually wondering if the question of dynamic linking is involved in this case.
I really don't see why privileged access has to be a problem. If there isn't some way of providing it, then either the internet is held down to the least-common-denominator, or everybody has to pay for a level of service that most of us don't need.
You just have to apply reasonable rules. I think the only ones you really need are that the money paid for privileged access must be used to provide that access, not to subsidize the network as a whole, and that the profit margins must not be excessive. Oh, and perhaps some rules about the minimum base level of service. If there's adequate competition you may not even need to go that far.
Sure, ISPs could still game the system to some extent. But not enough to be a serious problem.
You know what another word for free-as-in-beer is?
Free.
I know Uber are doing well, but is it really sensible for them to be investing in research in a field whose commercial prospects are at least a few decades out?
Google can afford a research program that won't be profitable in the foreseeable future. Can Uber?
Civ 5 was fine; you just hit the "strategic view" button as soon as it starts up and you're golden.
Beyond Earth took that away, apparently because they needed the button for satellite view and it was too hard to add another button.
The 3D view just makes it way too hard to see what's happening.