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

[Thomas Hardjono]

Hi Paul,

At 12/11/2002||04:21 PM, Paul Judge wrote:


>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.


I like the term "content protection architectures", a term which has 
come-up several times in some IETF discussions regarding suitable areas for 
the IETF.



> > >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.

Right, absolutely.  #1 and #2 are in fact in the purview of the IETF.
A possible #4 could be "look-up" technologies, such as the Handle system or 
similar systems implementing object-identifiers (like DOI).
Also needed is the management of meta-data, which may not always be stored 
with or accompany the protected data/content.



> > 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.

Agree.  Perhaps something like "content protection" or "information rights" 
could reduce the number of reporters in the room :)



> >>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'.


Great!  I agree.

cheers,

thomas
------



>Regards,
>Paul
>
>___________________________
>Paul Judge, Ph.D. Candidate
>Georgia Tech
>judge@cc.gatech.edu
>
>
>
>
>
>_______________________________________________
>ietf-idrm mailing list
>ietf-idrm@idrm.org
>http://www.pairlist.net/mailman/listinfo/ietf-idrm