OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

rights message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [rights] getting started on requirements


Title: getting started on requirements

I'm eager to start getting requirements and it strikes me that there is significant overlap between that process and the liasion process with related standards efforts and other organizations with interests in DRM.

Specifically, the best way to achieve broad consensus and buy-in on a DRML is to

1)identify the relevant organizations

2)invite them to review the current specifications, especially the use cases (since these are the most accessible point to get started), and submit any new requirements or use cases, along with any schedule constraints or milestones in their activities that present opportunities for synchronization

  [i'm reacting here to the unidimensional view in our kickoff meeting that seemed to make the MPEG21 milestones the only ones that matter to us]

3)do a careful job of analyzing their requirements


I've thought about the impact of a request like this on standards activities that I'm currently involved in (like UBL) and I suspect that we'd need to give the organizations we identify in step (1) here at least a month to get back to us.  It is unreasonable to give them any less time; for example, in the UBL case, there is intense work going on to get ready for a 1-week face to face meeting the week of June 2-6, and nothing is going to get higher priority. So the earliest there could be any serious consideration of DRM issues would be the second week of June, and that ignores the "catch up" time needed when you get back to work after being out of touch at a standards meeting for a week.

My point here is that we have to be realistic about the schedule for collecting requirements from other standards efforts. If we don't give people sufficient time to do this according to their own processes, they will not buy into the idea that our TC is going to speak for them.

I also think that we need to cast a wider net than simply the standards organizations that Brad listed on Tuesday. We need to identify some in the user community rather than the technology or content communities because I think that in the former is where our acceptance and credibility problems are most likely to appear. I will start down that road assuming that Brad and others already have a handle on the groups who are creating their own DRMLs.

-bob



Robert J. Glushko, Ph.D.
Engineering Fellow 
One Market Street, 13th Floor Steuart Tower
San Francisco CA 94105
415-644-8731



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC