DePriest, Greg (NBC Universal) wrote: > I understand your frustration and hope you'll feel my pain. > > There are a couple of things missing in your critique. > > One is the history of ALTO, its arbitrary exclusion of content > protection, and the total inability of anyone to articulate the reasons > for it having done so other than to say a decision was made (over the > objections of content creators) and that's that.
Greg, reverting a decision made some time ago is not the problem -- it happens so often in the IETF that we have RFCs defining procedures for that. The problem is that there is strong consensus that there is no effective way for asserting content legality in the protocol the ALTO WG is supposed to specify. Let me try and summarize the many discussions that drove the group to such a conclusion. The protocol will be used between applications and some kind of servers to exchange information related to the topology and the policies of the underlying network, to let applications make better-than-random decision when they can choose among a large set of endpoints to connect to. The mechanisms for content protection considered for this scenario -- at least those the group was aware of at the time of the discussions -- are all based on some sort of content ID sent by the client (i.e. the application) to the server; however, while the server could use such IDs for optimization (e.g. to pass additional endpoints he's aware of, most likely caches), because the content could be virtually everything (other than pirated movies, also YouTube-like user generated content, porn of any kind, or even, in the case of Pando, large email attachments), it would not have any reasonable means for asserting their authenticity. In other words, if a client sent a fake ID in a request -- say, the ID of the King James version of the Bible if not a random token -- the server would not be able to detect it without relying on huge databases (that would be a nightmare to maintain) and DPI solutions whose costs would immensely exceed the savings due to the reduction in cross-domain traffic. Now, since the group agreed to reflect such a conclusion in the charter, this discussion is currently out of scope for the ALTO WG. However, if people are aware of other content protection solutions not considered to date that would integrate well with ALTO, I will be happy to discuss them and to help investigate opportunities to extend the current charter as per RFC 2418. But that has to be done off the ALTO mailing list. > As for the role an ALTO server might play in the piracy ecosystem, I'd > welcome that discussion. Your second paragraph minimizes it as ALTO "is > an optional service." > > Yet it seems to be a law of nature that options must, over time, become > standard features. So I worry. > > But my larger point is that it's just wrong to leave open the potential > to expedite delivery of any pirated content. Any improvement in the network has the potential to expedite delivery of pirated movies, as well as communications among terrorists, exchanges of pedo-pornographic content and many others. Unfortunately nobody can address them all at the core of the technology; the approach engineers are used to following and that proved to be quite successful at least in the designing of the Internet consists in defining building blocks, as simple and extensible as possible, upon which they and others can then implement solutions for any sort of higher level problems. And I'd say that this is the right approach for ALTO too, not because a decision was arbitrarily made months ago, but because so far the WG has shown strong consensus to do so. -- Ciao, Enrico
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
