[rights-requirements] 02-05-03 Req SC draft meeting minutes (plaintext)

[Anne Anderson <Anne.Anderson@Sun.com>]

A plain text copy of the draft minutes for the Feb 5, 2003
Requirements Subcommittee Meeting is appended for the benefit of
those who find it easier to review minutes in this format.

Anne
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

Requirements SC Meeting
Date: February 5, 2003
Time: 11:00 - 12:00 PM EDT


Roll Call
Hari Reddy, ContentGuard
Anne Anderson, Sun Microsystems
Aaron Burstein, Samuelson Law, Technology & Public Policy Clinic
Robin Cover, Individual
Thomas DeMartini, ContentGuard
Patrick Durusau, Society of Biblical Literature
John Erickson, HP
Brad Gandee, ContentGuard
Thomas Hardjono, VeriSign
Brian LaMacchia, Microsoft
Deirdre Mulligan, Samuelson Law, Technology & Public Policy Clinic
Ram Moskovitz, VeriSign
M. Paramasivam, Micorsoft
Harry Piccariello, ContentGuard
Lisa Rein, Individual
TJ Pannu, ContentGuard

Agenda:
1. Approve meeting minutes:
01-29-03: http://lists.oasis-open.org/archives/rights-requirements/200301/msg00026.html
2. Review open action items.
3. Discussion on process.
4. Continue the discussion on reviewing comments and the RLTC
   Requirements document now at revision 16. 
http://www.oasis-open.org/committees/rights/documents/subcommittee/requirements/analysis-wip/Rev16/RLTC%20Requirements%20Rev%2016.doc


Action
Date 
Assigned
Description/Resolution
Issued
Status/
Date
1
10-02-02
Closed/
10-30-02
Lisa Rein
D: Provide reference to the comment that "most rights expression
languages to date have rights and permissions" to the email list
R: Lisa stated that she was incorrect. Lisa will provide list
with information by 10-23-02.
2
10-02-02
Closed/ 10-16-02
Lisa Rein
D: Provide list of "10 words" to discuss on email.
R: Will add to the list provided by Deirdre and Aaron
3
10-02-02
Closed/
10-02-02
Thomas DeMartini
D: Provide the two clarifying questions resulting from the email
analysis by Thomas and Patrick
R: email sent to SC list on 10-02-02
4
10-02-02
Closed/
10-16-02
Deirdre Mulligan
D: Provide a list of terms to be defined on email
R: Sent to list on 10-16?not needed in light of Action 8.
5
10-02-02
Closed/ 10-02-02
Peter Schirling
D: Post comment on parallel systems to the email list
R: John Erickson responded on email list.
6
10-02-02
Closed/
10-16-02
Aaron Burstein
D: Provide information on schedule to the email list.
R: Provided a synopsis of the OASIS TC Process. There was
misunderstanding by the group?several members were expecting a
suggested schedule which was not Aaron's understanding.
7
10-02-02
Moved to Action 11

Deirdre Mulligan
D: Provide a list of issues regarding a "general expression
language" referencing the Sameulson submission to the email list
R: Aaron sent response to the list on 10-11-02?SC would like more
information?Moved to Action 11
8
10-09-02
Closed/
10-15-02
Parama
D: Provide an Introduction to the Requirements Document to
clarify the scope and the terminology used in the Requirements
Document.
R: Parama sent Draft Introduction to the SC list on 10-15-02
9
10-16-02
Closed/
10-17-02
John Erickson
D: Provide input to Action 8 with respect to permissions.
R: John made the addition and sent it to the list on 10-17-02
10
10-16-02
Closed/
10-17-02
Hari Reddy
D: Update the Requirements Document upon receiving final input
from Action 8 and 9.
R: Done?updated as Requirements Rev 14.
11
10-23-02
Closed/
10-30-02
Deirdre Mulligan and Brian LaMacchia
D: Clarify expressions not mathematically expressible in the
current language
R: Will meet on 10-24 or 10-25 and report back to the SC on 10-30-02. 
12
10-30-02
Closed/ 11-06092
Req SC
D: Submit any comments on the RLTC Requirements Introduction by 11/6/02.
R: No comments were posted. No objections were noted in the
11-06-02 call. SC has decided to agree on the Introduction.
13
10-30-02
Closed
Deirdre Mulligan
Submit schedule proposal for reviewing examples or use cases.
R: Examples submitted 01-15-03
14
11-06-02
Done
Req SC
Review the Requirements Document against the
Introduction. Comments are due before the 11-12-02 meeting.
15
11-06-02
Done
Hari Reddy
Update Requirements Document and send to SC to review
16
11-20-02
Closed
Thomas DeMartini
Submit descriptive example to be placed into the texts for SX15
and R25.
17
11-20-02
Closed
Aaron Burstein, Thomas DeMartini, Lisa Rein 
Submit changes to Introduction Paragraph 5.
18
12-04-02
Open
Hari Reddy, Bob Glushko
Develop a schedule for the Requirements SC



Agenda:


1.Approve meeting minutes:
01-29-03:
http://lists.oasis-open.org/archives/rights-requirements/200301/msg00026.html

Hari:  Does anyone have any comments on the minutes?

Anne:  Submitted comments this morning via email.  Still
preparing my comments and would like approval of minutes be
delayed another week.

Lisa:  I haven't had a chance either.  The conversation in the
minutes, it was a long process, I need more time.

Hari:  Does anyone have any objections to waiting until next week
to approve the minutes (no comments)

Hari:  Will you be able to submit your comments in the next few
days or by next week's call?

Lisa:  Absolutely

Anne:  If possible

Brian:  Would like to request the comments come in at least 2
days before the meeting so we can read them.

Hari:  That's fair.  Can you do that?

Anne:  You requested comments on the minutes go to you.  Now you
want them to the list.

Hari:  Please send them to me and I'll send them to the list.
Everyone should have time to read the updated minutes so people
can have time to approve them.  Brian is requesting that he, as a
member, get the updated version 2 days prior to having to vote on
it.

Anne:  I hope I will be able to get them in.  They were
transcripts, not minutes.  There were omissions and I need time
to recreate what was omitted.

Harry:  Anne, if you were there, then you should know whether the
minutes were correct or not.

Deirdre: I don't think that this is a productive use of our
time. If people need more time than that is what we should do.

2.Review open action items.
3.Discussion on process.


18
12-04-02
Open
Hari Reddy, Bob Glushko
Develop a schedule for the Requirements SC


Hari:  With regards to this action, Bob and I have talked but we
have not developed the schedule. In support of this action, I
have been trying to have discussion with members on the schedule
and also the overall process. One point that has become evident
is that there is a wide understanding of the actual process on
many different levels. While we reviewed elements of the process
at the kick-off session in May of last year and some other
subsequent sessions, I think it might be beneficial for people
here to discuss the process again.  This may be helpful to give a
context to our work.

Hari:  At the highest level, we talk about the TC process.
First, there is no standard process in OASIS for developing a
work product. There are elements such as one needs to perform
certain reviews but how one develops a work product is completely
up to the individual TCs.  I've looked at other TCs and with the
hope of trying to understand what mechanisms they have. It seems
ad hoc.  Each team gravitates to the process that will lead them
to a final work product.

Hari:  What we talked about in the May, 2002 meeting was the
process to get to the final specification, the final work
product.  The first step is the requirements process, coming out
of that is the requirements document.  The confusion that I heard
at one of our previous Requirements SC meetings is that approval
of the requirements documents means approval of the spec.
Absolutely not!  What we had thought about was more of an
engineering process. We approve a Requirements doc, we then, as a
group, present it to the general body to review, then the general
body needs to accept this sub-committee's output.  The next step
would be the specification; the submission would need to be
updated.  There have been many posts in the past few months that
state that the specification does not meet the current
Requirements doc and that there needs to be changes to the
submission. What happened last year, in order to compress the
schedule, the spec team looked at the Requirements doc and
developed change requests that would map to that doc. They were
then waiting for the Requirements doc to come to finalization.
They looked at the trajectory and based on that, they developed
change request that would come out of that process. This was done
at last year's (Sept, 2002) face-to-face.  They have essentially
stopped all work waiting for the Requirements SC to provide the
Requirements Doc to the General Body. After the Spec team
delivers a spec,  we then test the spec against certain criteria
such as "Can we develop examples using the spec.?", "Can we
develop profiles?", "Can we develop extensions, what would
extensions look like?",  "Can people develop an interpreter to
interpret this language?", "What guidance can we offer to users
of the spec?" This was discussed explicitly at the May, 2002
meeting which initiated the discussion for the need to have
Examples, Profiles and Extensions SCs. I believe that we here
also talked about what we can provide to people so that they
could use this spec in various scenarios.  One item was "What are
the incentives or guidance we can give to people developing
systems that would address fair use" as an example of a scenario.
So, if the spec cannot meet these requests, for example if the
Profiles SC determines that a profile cannot be created of the
updated spec with some other technology XYZ, they would submit a
change request to the spec committee and say "It looks like there
is something broken here, can we make a change?"  The spec team
would release another version. There is an interaction cycle
here.  We've also talked about, it's not just the spec, and it's
all these other supporting documentation and guidelines we would
deliver as part of that process like an extensions development
guides.  That collection of work is then brought to the General
Body.  The work product of these various sub committees converges
and is presented to the General Body for a vote "do these work
products meet the needs of the General Body."  It's not just
approval of the spec, but also all the supporting docs.  Then we
make a decision as to whether to advance this spec as an OASIS
wide spec. Then we follow the OASIS process to go for a public
review period and people provide comments and suggestions based
upon not only the spec, but all of the other supporting docs.

Hari:  Do people have questions on that process at that level?
Or comments?

Robin:  I didn't hear you talk about the public review period,
which was mentioned several times before.

Hari:  We went through the last call for comments and, true, it
was just to the General Body.  But, it's my belief that the
requirements only tell part of the story.  It would help to have
a public review period on all the elements of the work products.
When I was looking for guidance from the other OASIS TCs, I
didn't see any other TC requiring a public review period on just
the requirements.  I think OASIS would like the public review on
the entire specification or package. As we found out there are
also some TCs, that have requirements doc that do not even
correlate to the exact spec.  So basically there are different
levels of quality on the OASIS requirements docs.  I'd like to
have the public review policy with all the elements of the
story.

Deirdre:  I do not think that's the understanding.

Robin:  I also don't think it makes much sense, the Requirements
doc is guidance. It doesn't make much sense to complete a spec.

Lisa:  I agree with Robin.

Hari:  If that's the feeling of this group.  I don't have any
other guidance from any other TC on how to do a public review on
just the Requirements doc because all the other TCs have opted
not to do that.  I'd like open the floor for suggestions.

Lias:  What suggestions are you looking for?

Hari:  On the process.  Karl Best has a certain way to do the
public review policy for the complete output of a TC.  Does
anyone have any documentation on how to do it just for a
Requirements doc?

Deirdre:  I think it was Hari and Bob who put together a list of
groups you wanted to solicit from. I suggest that you make sure
you specifically request comments on a Requirements doc from
them, and with regards to the procedure within OASIS, it sounds
like there may not be one.

Hari:  You're right. There is none for a sub-committee
output. They have procedures for a final spec.  Bob and I could
write letters to the various constituents of these other
organizations and request feedback.

Anne:  I was just a by-stander on the XACML TC, but maybe I can
relate what we saw.  We can inform all the other industry groups
that to spread the word that there is a review in progress, point
them to the docs and present their comments to a mailing list.
Then those comments are collected. I think it would be a
reasonable process to go through for any doc here.

Brian:  We already have that a rights-comments list as Anne
mentioned.  I think your job would be to send out the notice to
target lists that there is a doc review, it's on the web, please
respond to this mailing list for comments.

Hari:  What we'll do is use RLTC-comments.  Was the discussion
about the overall process helpful?  Are there other things we
should discuss (no comments)?

Deirdre:  We had the same conversation several times, to have the
examples committee work in parallel with the requirements
committee.  And we have submitted several rounds of examples and
as far as I know there has been no work on these.  As far as I
understand, this would be part of reviewing the requirements and
I wonder when this is going to happen.

Hari:  What we discussed was that we would take the examples and
then review each of the examples as a "use case study" and then
try to extrapolate requirements from those use cases.  This came
up I think in a few Requirements sessions ago. In one of our
first meetings as a Requirements team last year, somebody said,
if groups don't know how to articulate a rights language
requirement, how can we still get the requirements. We concluded
that we should accept a use case, do the requirements analysis
and then submit it back and then see if it meets their needs.  I
think we need to review the submitted examples as a team to see
if Requirements SC understands them and also to see if there are
requirements that we can extrapolate them.

Anne:  That's why I was puzzled when you were calling for final
comments.  I don't know how we could do final comments when those
examples had not been worked through to get those final
comments.

Hari:  What the Law Clinic sent in, Bob and I viewed them as
comments.  We want to review those comments.  The reason we asked
for a final call, is that people were not saying anything during
the meetings.  It was the consensus of the Requirements SC to
say, okay let's do this final call, if you have a concern, voice
them, then we can have something to go forward with.  Going back
to Deirdre's question, what Bob and I were thinking of was that
we'd process those use cases, extrapolate requirements from them,
submit that analysis to the examples SC. I'd like to remind
people that the examples subcommittee only has the original spec
submission which does not include  any of the change requests.
If there are things that require a pre-existing change request,
they wouldn't be able to create the XML but they would be waiting
for the spec team, which is waiting for the requirements team.

Hari:  I guess I look at the creation of the XML as a test, to
see if they can meet that example.

Deirdre:  This was a long discussion, Brian and I discussed doing
top down and bottom up and looking at examples.  Brian and I had
a back and forth discussion about doing things in parallel and
there was an agreement that the examples subcommittee would look
at them as they were submitted.  And we've gotten nothing.  The
best way is to go through and look at specific examples and not
cases and I'm frustrated the examples committee has not given us
anything we can look at.  And especially the way people were
breathing down my neck.  I'm really upset.

Hari:  Okay

Deirdre:  I'm tired of being helpful.  I've been really helpful.
Until the examples subcommittee does some work, I'm not willing
to answer more questions.  There was pressure for us to produce
things they can work with and they haven't done anything.  If
they have specific questions, I will be happy to answer them.
But I want them to do some work.

Harry:  When did you submit the examples to the Examples SC that
you're so upset about. When did you submit it?

Aaron:  We submitted 3 in October.  

Deirdre:  It's been months

Harry:  We were waiting on the submissions that you had promised
to provide. I don't understand it to be in October.

Brian:  I didn't submit my comments until early January.  I don't
know if there has been any work on the examples subcommittee.
There is a circular process going on.  Deirdre says "gee, we've
submitted this stuff and I haven't even seen them take the
current spec to see if they are doable."  Maybe someone on the
examples committee can comment on this, that they're waiting for
the requirements group to do a final doc, but you can't wait on
that, it is a process that has to go back and forth.

Hari:  I think what we thought would be helpful is to go over
some of the use cases to understand for example the different
actors and so forth because, as you pointed out in one of the
previous Requirements calls, there was some ambiguity around
"unauthorized use" or "having no communication with the issuing
party". That type of data is helpful before people develop code.
I'm speaking just as a member of the Examples committee.  I don't
think it would take that long to have a discussion on each of the
use cases so the Examples sub-committee doesn't produce something
that doesn't meet our requirements or our wishes.

Brian:  I don't know if that conversation should happen here in
the requirements SC, the examples SC or both.  I missed the call
after Deirdre and I submitted our stuff.  It seems discussion of
this got bogged down in other issues.  Maybe the answer is, we
should throw these over the wall and examples will churn on them
for awhile and we'll get dialog back and forth.  Or take what
Deirdre produced and my comments and look at XML and try to do
it.  I get the feeling everyone is waiting for someone else to
take the next move.

Hari:  If the Examples sc is able to code the use-cases in any
form, will that satisfy everyone? 

John:  I think there will be at least 3 classes as to ways the
examples SC can handle the clinic's examples.  (1) They might be
able to create code using the existing spec.  (2) they understand
the example, either by way the clinic has presented it or Brian's
comments, they understand how you would do it but pieces are
missing from the current spec so they would say "we understand
it, and this is what we need to code it".  (3) is "we don't
understand what is being asked and/or is this what you mean by
what the example is stating."  I'll assert that given the
examples SC can deal some way with all of them.  But if they can
look at them a couple of ways and give code or feedback they can
look at them right now.  There is no reason to wait at all.

Hari:  That is what I said.  If people are waiting to code them,
that's one thing.  I wanted to give more due diligence on how to
code them, but?

John:  it's whether or not the examples can be understood.  Not
unlike the clarification that Brian did in his examples.  It may
not be a coding thing at all, it may be a larger issue.  It may
be a deeper issue, but it can be dealt with, but after all there,
there may be a step saying "by the way, this is how you can
handle this in XrML code or if you had these changes in XrML code
or extensions or changes in the rules or the processes, then you
can deal with the examples, or 'we just don't understand."  I
think that can be handled.  I'd like to see, on a first pass,
something that mirrors the kind of analysis Brian did.  That
doesn't require a first pass discussion, it's let's figure this
out and provide feedback.

Thomas:  Speaking as a member of the examples SC - we have to
keep in mind that in order for a committee to do some work, we
need to know why we're doing it and what it's for.  What will go
along way in doing that, is to have a process whereby they can
see that what they're doing fits into a process.  Historically
speaking, the examples we've gotten so far are nice examples, but
we don't really have a spec or a requirements doc and trying to
produce these examples, we'll have to re-do these when the spec
gets changed.  People would be doing these examples, knowing they
will have to recreate them again and again and again.

Lisa:  This is part of the process.  You have to regenerate the
examples.

Thomas:  I agree they have to be generated more than once.  I
think the issue is how many times more than once.  I think we can
all agree that there have been different interpretations of the
words that we all agreed to.  We agreed that we would use the
submitted examples to test the requirements, but I think one
group was thinking that that meant making sure all the
requirements embodied by the example were part of the
requirements document while another group was thinking that that
meant actually writing up all the examples against the
specification to test the requirements.  And if there were any
discussions as to whether we should actually use those examples
to write up actual XML for them to test the spec, I bet we agreed
on that as well, but we probably didn't make sure that we had the
timeline right.  I think it is a fine thing to do for the
Examples SC to write up the examples to test the spec during the
spec development phase after we have the requirements document
approved.  I think we have different ideas of what the words we
agreed to mean.

Deirdre:  I'd like to get some idea of what these means.  As we
don't have a solid spec to work with and you don't have a solid
set of requirements, but that's the process.  I understand that's
what the requirements SC has asked you to do and if you are not
going to do it, you're not going to do it.

Lisa:  I think one of the problems here with this whole process
is we've taken the work usually done by a single group and split
it into different committees so there is all this liaison
trouble.  I didn't feel like I had enough to chew on until I got
that chunk from Brian in Jan.  So in the Examples SC defense,
it's only been a few weeks and it would be unable to generate
work in that time.  Still, I'm surprised that Thomas would
complain about examples getting changed all the time.  That's the
process, you realize something you've overlooked and then you
re-do the examples and you re-do the examples as the spec
changes.  I think this is an important point of the process. We
wouldn't necessarily dump it on the Examples SC all the time, we
would submit to the spec committee.

Thomas:  I agree with that process, the part of the discussion is
when do those examples start, before or after the requirements.

Lisa:  It is unusual to come up with examples before you have
requirements and a spec.  But we do have a spec and it's
something that is a charter of this committee, you do look at
that spec and develop it and iterate.

Harry:  I think it's interesting we're complaining about another
SC when we haven't done our own responsibilities.

Lisa:  I agree that the examples committee has not had time to
look at these from January.

Hari:  I agree with John, that we need to make sure we understand
our requirements before we look at doing code.  As people would
agree, there are many different ways to code any example, but
that just says that I can do it, but I'm not sure whether it
matches the intent of the person submitting the use case.  I
thought a discussion on the use case would help us as a team to
understand all of the points, so the examples SC can have
something to better understand the use cases.

Lisa:  So we still have to look at use cases before giving it to
them?

Hari:  Just as an example on the ambiguity, one of the things out
of the previous requirements calls, there was some ambiguity
about no communication back to the "content owner". If the
examples SC starts to develop using one framework and we disagree
with that initial framework, then all that work is not useful.
So if they come up with any framework and develop and example,
are we going to be happy with that?  I'd like to put that on the
floor and ask for advice. There are many ways to take an example
and code it.  It depends upon what the original framework of that
example had.  If, without understanding that framework or where
the permissions are occurring, and understanding the intent of
the use-case, the example SC, if they develop any example in any
framework but still matches what the example states, is that what
people are looking for.

Lisa:  It's a start. That's the beauty of XML, there are many
ways.  We're trying to come up with ways that is possible.

Thomas:  It's a little more than just XML.  You can model a
system in multiple different ways. You can say we're going to
check rights on this point but not that point.  Depending on what
points you choose, you're impressions are going to be different.

Lisa:  Won't those be example specific

Thomas:  Your view of the examples will reflect that.  There are
many ways to look at no communications to content holder.  Does
that mean no communication to anyone in the world or no
communication except to yourself on a notepad. If the Examples SC
spends time developing one approach and then say "here's all the
work we did and came up with this" and then people here say "No
we didn't think you could write on your own scratch pad."

Lisa:  Maybe it would help to have a paper on the liaison between
the requirements and the examples and saying the detailed
implementation and the documents that go with it.  Words to
explain how the documents fit in.

Aaron:  I'm worried about problems of ambiguities of the examples
have become overblown.  The example that keeps getting brought up
was poor drafting in the original examples we submitted.  I think
that it was not part of the heart of the examples.  Having Brian
point that out, saying "here's what I don't understand" allowed
us to clarify the example and say here's what I'm happy to do.

Harry: We make progress when that happens.

Hari:  Can we have one session of the requirements call to go
over the examples?  I think many of the examples SC members are
actually on this call.  Can I offer that as a suggestion, to go
over the examples, including the one submitted before and the
ones submitted in Jan.  I don't think that would be that arduous,
but I think it would be helpful for people.  Deirdre, could we do
that?  (no response)  Aaron?

Aaron:  I know that is what we looked at doing a few weeks ago. I
think we should look at the examples beforehand and post comments
to the list and the more people can think about it.

Hari:  Excellent idea

Thomas:  Afraid we're missing the concerns.  If we do pass
something to the examples SC, let's make it clear what we're
asking them to do and how it will fit into the overall schedule
in the interest of getting something back from them.

Hari: I think that's a fair ask.  Can we all do this on the next
meeting?  First of all, are Aaron, Deirdre and Brian available
for the next meeting?  (Brian and Aaron said they didn't have a
conflict.  Deirdre was no longer on the call.)

Hari:  Everyone, please read the examples, post the comments you
have, let's look at them on the next call and give them a good
due diligence.

Call was adjourned at 12:08pm