[IETF-IDRM] RE: [IDRM] Disband or recharter IDRM?

[Mark Baugher]

hi Thomas

At 05:37 PM 12/11/2002 -0500, Thomas Hardjono wrote:
<...>

>>In addition, with the activity around microbroadcasters this past summer, 
>>there also seems to be a need for technology that can better measure the 
>>audience size of content distributors. Such technology could potentially 
>>protect small distributors by keeping their licensing fees low but still 
>>be fair DRM-wise (Rob Johnson and I did some work in this area but I 
>>think there's still much to be done).
>
>
>Actually, this is an issue that no one has brought-up in the IETF, but 
>would be of interest to folks in the IETF who do traffic shaping and 
>traffic management.

I think it's a different critter than that:  The application that Jessica 
cites is more like an interface to a clearinghouse

Mark


>cheers,
>
>thomas
>------
>
>
>>These are very much off the top of my head and I'm sure there are more 
>>and better candidates. In any case, I would like to see the group resume 
>>activity.
>>
>>Jessica Staddon
>>
>>-----Original Message-----
>>From: Paul Judge [mailto:judge@cc.gatech.edu]
>>Sent: Wednesday, December 11, 2002 1:21 PM
>>To: Thomas Hardjono
>>Cc: glarose@info-mech.com; ietf-idrm@lists.elistx.com
>>Subject: Re: [IDRM] Disband or recharter IDRM?
>>
>>
>>
>>On Wed, 11 Dec 2002, Thomas Hardjono wrote:
>> >
>> > Right. So one of the notions we put forward in the IETF was:  is it at all
>> > possible to create "open-source DRM technologies", so that small
>> > mom-and-pop publishers need not pay $$$ for proprietary solutions.  The
>> > analogy is that with Linux and the Apache webserver, which are available
>> > for around $30.
>> > Another useful comparison in the RSA encryption algorithm, which is good
>> > technology, well understood, standardized and now finally over the patent
>> > hurdle.
>>
>>I think that this is a reasonable strategy and a worthy goal. We were
>>working on some content protection architectures here that have very
>>similiar motivations. An open-source standards-based DRM system would
>>enable the small content providers as well as provide an alternative to
>>multiple proprietary formats and systems.
>>
>> > >On a philosophical level then, I say there is a need for smart people to
>> > >build workable DRM that citizens can live with.
>> > >
>> > >The point issue of this technical group's mandate is much clearer 
>> IMO. The
>> > >core
>> > >technology challenges for DRM are terminal node challenges, not network
>> > >challenges. Sure, a network is usually involved, but DRM is nothing 
>> special
>> > >for the network. DRM's basic network needs are nothing harder than
>> > >http/https over tcp/ip. And the terminal mode challenges are largely 
>> about
>> > >things like tamper-resistance, which are proprietary and not very 
>> amenable
>> > >to
>> > >standardization. It's not something where an IETF group adds much value.
>> >
>> > Right.  This is where the word "DRM" is I think a misnomer for the IETF
>> > efforts.  You are absolutely right, that DRM is indeed "terminal node
>> > challenges" (ie. development of rights-enforcing terminals), which is not
>> > the traditional area of work for the IETF.
>> >
>> > However, there some network issues that is part of what I call the "DRM
>> > macrocosm", which included functions relating to look-ups, secure network
>> > storage, transaction clearinghouse, etc.  These would appear to be 
>> suitable
>> > for work items in the IETF.
>>
>>The way that I've been thinking about this is that DRM tries to solve
>>three problems: 1) secure distribution/conditional access, 2) protected
>>storage, and 3) output protection. True, #3 is largely about 'terminal
>>node challenges', but #1 and #2 largely include distribution architectures
>>and supporting systems. I believe that there is room in these areas for
>>IETF work.
>>
>> > Thus, one possible change to IDRM is a new name that is less likely to be
>> > controversial.
>>
>>Couldn't hurt. Even if it doesn't reduce the controversy, it may reduce
>>the confusion since DRM is such an overloaded term. If the focus becomes
>>protected distribution and protected storage areas, then how about a name
>>to describe that as opposed to the output protection area.
>>
>> >>3) Find specific technical problems that are obstacles to good (i.e.
>> >>effective but not Orwellian) DRM, which are going begging, and in scope,
>> >>and work on solutions.
>> >>
>> >>I don't have a top-of-mind suggestion for #3, but it sounds like the
>>most
>> >>fun!
>>
>> >>Yes, the keyword is "fun".  Perhaps others on the list may have specific
>> >>suggestions?
>>
>>based on what i've worked on before, there are a few things that come to
>>mind. there are a few components that must exist in a protected
>>distribution/storage environment: secure content objects, content object
>>importation system, ACL servers (1 that assigns rights and 1 that can be
>>used to lookup rights based on a user, role, or object), authorization
>>protocols, etc.
>>
>>with that said, my two cents is: 'recharter'.
>>
>>Regards,
>>Paul
>>
>>___________________________
>>Paul Judge, Ph.D. Candidate
>>Georgia Tech
>>judge@cc.gatech.edu