This also makes sense. -----Original Message----- From: Richard Bennett [mailto:[email protected]] Sent: Thursday, April 30, 2009 6:58 PM To: Nicholas Weaver Cc: DePriest, Greg (NBC Universal); Paul Jessop; alto; [email protected] Subject: Re: [alto] The origins of the piracy debate...
As long as ALTO is defined as a service that maps a content ID to a collection of paths, it seems to me that it's piracy-neutral. I'm disturbed by a system that is passed a collection of paths and asked to rank them, as that would seem to have a definite pro-piracy bias. But I agree with Nick (I think) that a system that accepts a transient content ID and returns a list of paths is neither pro-piracy or anti-piracy. The rights management function can be layered on top of ALTO, as I think it should be, as a kind of DNS-for-content that takes some sort of textual description of the content and returns an identifier that ALTO can then use to guide toward the best paths. The higher level function - the content mapper - can be developed independent of IETF guidance and in accordance with some sort of deal between content producers and network operators. The content mapper is where the rights management goes, not in ALTO. RB Nicholas Weaver wrote: > > On Apr 30, 2009, at 2:19 PM, DePriest, Greg (NBC Universal) wrote: > >> Thanks to Enrico and Nicholas for providing additional background and >> explanations. >> >> The key point of disagreement seems to be that adding a content >> protection requirement to ALTO would "hugely complicate and compromise >> the design of >> ALTO." >> >> I'm not an expert in such matters, have very limited exposure to the >> area, and can't help but wonder if that is, in fact, correct. >> >> Was there a serious investigation or did someone simply do a >> back-of-the-envelope analysis. > > For me, its "Intuition backed up by a threat analysis and usage cases": > > We have legitimate uses which requires ID churn: its the only way to > guarantee that a rebalancing is fresh. Especially since nodes churn > all the time, and ALTO may not have notification when nodes leave. > > We have legitimate uses which require IDs to be arbitrary (rather than > representative hashes): ALTO is not just for file distribution, but > other P2P optimization (eg, optimizing for low latency for DHTs) where > hashes don't have meaning. ALTO doesn't want to deal with particular > P2P protocols, which all may have different representations of what > data or blocks are. And doesn't want to deal with colliding > namespaces from different P2P programs. Thus defining ID as a UUID or > other opaque identifier means ALTO doesn't have to deal with these > problems. > > We have legitimate uses which require IDs to be creatable at-will by > any party: Otherwise, ALTO becomes an admission only system which > limits utility. > > > Yet all three decisions (allowing churn, opaque-data IDs, at-will ID > creation) and there becomes an easy countermeasure to ANY system > predicated on "block bad IDs", as long as that system has a slower > response time than the P2P network you are trying to prevent > optimizing its communication, and you can't do "only allow good IDs" > if IDs are creatable at-will by any party. > > And "if a defense has a trivial countermeasure, don't bother deploying > it". > > Thus this means the only way to make ALTO "content protecting" is to > remove one of those three constraints. But all three features are > very valuable in a localization service. > > > > Additionally, there is a large bias in the network community in > general to be "content neutral". Any time you cease to be content > neutral on the technical level, it must necessarily impose constraints > and costs on the system. > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
