Re: [rights-requirements] 01-29-03 Req SC draft meeting minutes

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

Hari, I request that the following item be placed on the agenda
for the next Requirements Subcommittee meeting, and on the agenda
for the next General Body meeting.  As an example motivating my
concerns, I have appended my corrections to the draft minutes for
the Jan 29 Requirements Subcommittee meeting.

  The format of the minutes needs to be modified.  Either the
  meeting should to be tape-recorded, and a full transcript
  issued, or else the minutes should be thematic, reporting the
  substance of the debate, but not the words of any particular
  speaker.

  My edition of Robert's Rules, which OASIS TCs are supposed to
  follow, states, "The general guideline for determining the
  content of minutes, except when they are published outside the
  organization, is they should record what is done by the
  assembly, not what is said by the members."  The OASIS TC
  Process modifies this only by saying "Meeting minutes should,
  at a minimum, include date and time of the meeting, a list of
  attendees, topics discussed, and decisions made."

  I am happy to have my exact words included in minutes, so long
  as they are quoted correctly and are quoted in full (so as to
  be in context), and so long as everyone else's exact, full
  words are included in the minutes.

  I suggest, however, that issuing a transcript of a meeting is
  detrimental to the goals of our committee.  We should be free
  to brainstorm, suggest solutions and reject them after
  discussion, and in general, to make allowances for slips of the
  tongue and other mistakes.  I am not an accomplished debater,
  and I fear it will delay the progress of this committee if I
  have to respond to every query with "I'll have to get back to
  you in writing" in order to have my statements approved by my
  management and in order to be sure I have made a quotable
  statement.

Anne Anderson
-- 
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

CORRECTIONS TO DRAFT JANUARY 29 2003 REQUIREMENTS SC MINUTES
------------------------------------------------------------

Agenda:
1.Review open action items
2. Continue discussion on the Samuelson Law Clinic Use Cases
3. Continue the discussion on reviewing 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

Hari:  For today's agenda, I wanted to continue some of the good
work we've been doing reviewing the work from the Samuelson Law
Clinic.  But I have some concerns; there were concerns about the
process and the work done to date.  Anne, could you please
explain more about the comments you had on the requirements.

Anne:  What more do you want explained?

Hari:  Do you have anything else to state?

Anne:  I can answer questions.

Hari: It seems from your comments that you disagree with the work
of the Clinic and the work we've been doing with regards to
addressing the fair use concerns.

Anne: I want to make sure the concerns are fully addressed before
we pass a requirements document.  You made a final call for
comments and I don't think they've all been resolved.  Like the
fair use requirements.

Hari:  In the Introduction we had stated that this language?

Anne:  You basically said it's out of scope.

Hari: (reading from the Requirements Document Version 16)
"the technical work of the RLTC is not directed to
...
Develop a language or system that addresses legal rights and
processes. Examples of these rights include, but are not limited
to, those legal rights termed as "fair use rights" and
contractual rights.
..."

We had discussed providing guidance to systems that would be able
to address the legal and fair use rights.

Anne:  I would like to see that guidance made, not just
recommendations, but mandatory for implementation for anyone
compliant with this RLTC language.

Hari:  To understand how to do that, did XACML make the same
requirements? I've seen several references both in the official
OASIS XACML website, in the call for Membership vote and in
presentations to various content owner standards bodies that
XACML is an applicable for DRM.

Anne:  We think it's targeted for a different environment.

Hari:  Your own documentation implies it's for DRM and that it is
in scope.

Anne:  I don't feel that. I can't vouch for the other members of
XACML. It's an access control language.

Brian: Is anything dealing with authorization out of scope for
XACML?

Anne:  No, anything dealing with an access control language is in
scope.  The difference is that the RLTC is targeted towards DRM.

Brian:  I disagree with that statement.  The RLTC is doing a
general authorization language. We have all made this quite clear
many times.

[I believe Brian said: "... The RLTC is doing a general purpose
authorization language.  It is NOT targetted at DRM.  We have
made this clear..."]

Anne:  You have mechanisms in the language that is transfer of
rights which is applicable to DRM and copyright

[I believe I said: "You have mechanisms in the language, such as
transfer of rights, which are applicable to DRM and copyright."]

Brian:  Also rights for access control.  If you're drawing a
distinction between vertical environments, I don't see how you
can do that.  Either you develop a language that deals with
authorization and?

[I believe, right around here, that Brian or Hari stated: "I
don't understand the difference between authorization and access
control.  Could you explain the difference to me?

Anne: XACML is for the access control environment, RLTC is for
the DRM environment.

[I believe I said: "I'm not going to try to answer that because I
don't think that is the point.  RLTC is targetted at the DRM
market, and includes mechanisms such as rights transfer that are
necessary for that market.  XACML does not."]

Brad: That's why the bullet points were included in the
Requirements Introduction more than 3 months ago.

Anne:  By inclusion of transfer rights in the language, you are
making it different than XACML.

Brian: If we support delegation or transfer of rights, that has a
number of applications, not just for DRM. I assume that XACML has
a delegation mechanism? 

Anne: Yes. But the way it's constructed in the RLTC it is most
suited for DRM environment.

Brian:  I take issue with that. You can't make a distinction
between this and XACML language.

Lisa:  We are creating more than authorization language and if we
are going to have things like transfer of rights, which go into
the DRM space and for that reason it's important to have these
considerations as part of our requirements.  If that is what Anne
is trying to say, I agree and I see the point you are making.

Brad:  Why are we going back to October?  We've had this
discussion endlessly. The group agreed to language in the
Introduction to describe the scope of this TC and now we're
saying "no I want to have this universal thing which speaks to
any use and rights."  It's not definable; it's not universal
across the domains. We cannot say that there needs to be a
default semantic for all uses of the language saying that there
is always a protection of fair use?what is fair use in Tanzania,
what is fair to the US? to Russia?  There is no universal fair
use.

Brian:  In trying to express their use cases, what the Clinic and
I have been doing, is that we've decided the RLTC is a general
authorization language and there is another specific language
built on top of it.  The domain of interest to them is DRM and
such; this could be on top of the general usage language we're
building.  Anne, now you're saying "this is not the use we want"
and you want us to change the scope of the RLTC.

Anne:  This is the way I would respond. I feel this is a
requirement, it was submitted by a number of the members of the
RLTC in the initial requirements.  I don't see it.  You may be
addressing it in some requirement extension or define some way it
may be required; it's not addressed at all in the requirements.

[I believe I said: "This is the way I would respond. I feel this
is a requirement, it was submitted by a number of the members of
the RLTC in the initial requirements.  I don't see it [in this
Requirements Document].  You may be addressing it in some
requirement extension or define some other way it may be
required; it's not addressed at all in the Requirements."]

Hari: This team has come to this compromise to go forward. It's
as Brian states. We state that this core does not specifically
address these items and then we also want to make sure that
things can be built on top of it to address those items. We need
to make sure that there is nothing built in the core to preclude
those extensions.  Anne, this is a compromise that you were a
part of for a few months. This Requirements Introduction has been
out and discussed for several months. Personally, I was expecting
especially from someone like yourself who has been present for
most of the process to submit something that builds upon what we
have, but your statement says we should go back to ground zero.
I think the Clinic and this team did some good work to help us
get to that compromise.

Anne:  I think that work is addressing some requirements and I
think those requirements need to be stated in the document.

[I believe I said: "I have not seen that compromise [in writing].
I think the Clinic has done some excellent work.  I think that
work is addressing some of these requirements.  I just don't see
that work reflected in this Requirements Document."]

Brian:  The work with the Clinic was part of a process; we need
to make sure that their semantic domain could be built on top of
the core. You are negating the work and stating something very
different. We're talking about analyzing a use case, deriving the
DRM extension, and not to address fair use.  We made
progress...Look at the issue of revocation; from our analysis we
determined that we needed to make a minor change in the wording
of the spec.  That's why we've been going through this
exercise. To look at their semantic domain and determine if there
is anything that won't be solved by the general language.  This
is very different than saying the language needs to only address
a particular semantic domain.

Anne:  Let me review the output of the RLTC before I address
that.

Hari:  What information do you need? All of the principals are on
the call to address your questions.

Anne:  I need to sit and read it.

Hari:  Read what? Let me help you find it.

Anne:  I need to read the output to see if it fits our
requirements.

Hari: Then what you are looking for is the Requirements Document,
which has been out for several months and what you commented on.

Aaron:  I think what Brian has said about the role of use cases
as far as developing substantive input or flowing into the
requirements themselves, what Brian said about the need to
examine those for other language features, working in the use
cases, I don't know that that has been documented.  I think it's
an understanding that this SC has come to in the past couple of
months.

Hari:  I agree with you.  What I suggested to the team was to
take a look at those use cases and see if there were requirements
in those use cases.  The Requirements Document that is out there
truly doesn't have that.  Your team submitted that as part of the
comments.  What we'll do is process those and try to extrapolate
requirements from them.

Lisa:  I think the requirements you'd extrapolate from those use
cases, is what Anne would like in the Requirements doc.  Perhaps
the requirements need to be included in the requirements doc
before giving it to the general body.

Brian:  There is a distinction that might be missing.  The goal
of the work with the Clinic is not to say every particular use
case that we documented, that there needs to be a requirement in
the RLTC requirement.

Lisa:  I didn't mean those specifics.  There are things that
should be in the requirements. They don't seem domain specific,
if we figure out what they are and put then in the requirements.

Brian:  I'm not sure what they are beyond what we've got.  If
someone wants to express the ability to do delegation, you
require delegation. You make a general statement like that.
Nothing in particular related to fair use is in the Requirements
document.  We said we're not going to put anything in for
domains.  We have it so it can be built on top of the platform
that we are building.  

Lisa:  I understand, but even if it's something general that you
described, it feels we're passing the buck that we should have
some sort of requirement. If we are passing the buck then we
should state so.  Anne, were you saying you wanted more time to
look at the use cases?

Anne:  I wanted to look at this compromise, not the document.  I
wanted to look at the scope of the language and the environment
it will be used.

Brian:  The posts we've made on the list go back to Oct. We have
met for several months. I think it's quite clear from the meeting
notes and postings of what has been going on here.

Hari:  The Requirements Document is a culmination of those
discussions.  We've gone through words, paragraphs, punctuation,
etc.  I'm concerned that now people are questioning 3, 4 months
of this SC's work.  If you want to look at the compromise, it's
the RLTC document, and I think you've already looked at that.

Anne:  That doc does not address the requirements that we have.

Hari:  What does it not address?

Anne:  Requirement is that to the extent that this language is
targeted for use in environment where copyright protection is the
issue language must enable and not subvert or make difficult to
enforce the protection of traditional copyright.

Hari:  What are you reading from?

Anne:  I'm trying to phrase a requirement, what it would look
like, I'm doing it on the fly here.

[I believe I said: "Nothing.  I'm trying to phrase a ...on the
fly here.  My original comments were addressed at problems in the
Requirements Document, and I have not [previously] tried to state
exactly what [wording] SHOULD be in the Requirements Document."]

Hari:  I just wanted to make sure you're not reading from a
document we've seen.

Anne:  I think we've heard this requirement many, many times,
it's not reflected.

Brian:  But we have all stated that it's out of scope.  We've
made this decision in Oct.  I don't know how we can make a
requirement that the language is going to say anything about
that.  I don't know how to answer your requirement in a language
that is a general purpose language.

Hari:  And we looked to the Clinic as experts in this space.

Anne:  The requirements should say that where this is used in DRM
or copyright protection environment something is required as
compliance.

Brian:  Sounds like what you want is a, licensing requirement on
anyone who leverages a standard.

Brad:  There are fundamental problems with this?

Brian:  Anything we do can obviously be profiled by anyone. You
can profile it with anything you want and unless there is a
contractual licensing sort of thing, you can't enforce it.

Lisa:  There is a question of something being compliant, they can
hack it.

Anne dropped out of the meeting.

[I said: "Excuse me, but I have to drop out for a minute to pay
our plumber".  I was calling from home, and the plumber had just
finished his work and was waiting for me to sign off on the job.
At plumber's rates, I did not want to keep him waiting!]

Brian:  You can't say that the message format is not compliant.
If you define the message format and there is this nebulous
requirement, you'd never know if your implementation was
compliant or not. It's a language, it's a form of making
expression, and it's a format at the end of the day.  You're
going to write an expression, attach it to XrML.  Message
vs. protocol, we're not defining protocol in this group, we're
defining format.

Brad:  The Introduction to the Requirement doc was agreed to
Oct. 16 and discussed on Oct. 30 and now we're going back and
saying we want to have this in a domain that's out of scope.  We
are not addressing a language to define these legal rights.

Hari:  The discussion around profiling, as I recall, was also in
early Nov.

Anne came back to meeting.

Lisa:  Can we fill Anne in on what she missed, whether or not we
could have additional requirements for domains.

Brian:  What I was saying was that, because anyone can take our
spec and profile it, we have no enforcement rules as to how
someone is using our spec.

Anne:  Yes you do!

Brian: We're defining a message format, not a protocol.  You
can't hand that to someone and know whether or not they are in
compliance.

Brad:  The assumption is what comes out of the Clinic is
applicable to everyone in all domains.  It isn't true, it's not
possible.

Brian:  Yes.  When people get into specific domains and
environments, they have to go to find their specific requirements
for their domains.

Anne:  I think in international law and U.S. law that would apply
and then guidelines in other areas.

[I believe I said: "I think the guidelines could cover what is in
International Law, and provide guidelines for how individual
country laws could be satisfied.  The guidelines could be much
more specific about what is in U.S. law, and maybe some other
countries.  The Samuelson Clinic could help work out those
guidelines."]

Brian:  How do you know if you're compliant if we have no
authorization in general?

Anne:  You follow those guidelines.

[I believe I said: "An implementation that did not comply with
the guidelines would not be compliant, and could not claim to
have implemented the standard."]

Brian: If I'm building a spec and testing interoperability, what
am I going to run to see if this meets the nebulous requirements
or guidelines?

Anne: This specific domain is part of an extension of another
domain, it is, in good faith, be used in such a way that the
guidelines are being followed.

[I believe I said: "This core language will never be used on its
own.  It will always be used as part of an extension.  We could
have a requirement that, in order to be an extension that is
compliant with RLTC, the extension must follow the guidelines.
The implementer must state that, in good faith, the
implementation was compliant with the guidelines."]

Brian:  If we do what you are saying, how will we produce a spec
that would satisfy that requirements?

Anne:  We'd have a statement of guidelines of what it would take
for an extension.

[I believe I said: "We'd have a statement of guidelines of what
it would take for an extension to be compliant."]

Hari: We are not building extensions here.

Anne:  It has to include that because there will be a gazillion
extension and we need to address that.

Hari:  Each extension will have its own approval and the market
will gravitate to which extensions best meets the needs.  Are you
saying we should define these extensions, which is not what this
TC is doing or look at how extensions are built, which is what
this TC is doing?

[I believe I said, in response to "and the market will gravitate
to which extensions best meets the needs": "This is a commons
case.  The market is controlled by a small group that will buy
and implement the extensions.  There is a large group of
consumers who have a large interest, but little control over this
market."]

Brian: As a system builder of an authorization engine that dealt
with copyright, if we had the capability to do that kind of
analysis and build it in, we'd build it.  We can't be narrow and
just look at US law.

Anne:  Maybe it's not possible to write a language that addresses
these issues.  There are consumers who will be implementing this
to protect their copyright and there are consumers who want to
access this info and their interested in fair use rights and the
users will not have much say about protecting their copyright.

Brian:  What you are saying is that we should not engage in any
development of any authorization language because it could be
used by DRM or other system?

Brad: Why is Sun here to block this when XACML has the same
capabilities and somehow that gets special treatment?  It's
hypocritical and we are wasting time because you bring stuff up 3
months after it's already been decided upon.

[I said, perhaps here: "Why are you asking me this?  I just
happen to be a member of XACML as well as a member of this TC.
What if I were not?"]

Lisa:  It's our concerns that mechanisms will only take the
copyright into account and don't take the individuals accounts in
our fair use rights, there needs to be something else in the
document, if we're going to pass the buck, then I'd like to
acknowledge we're passing the buck.  

Hari: I am confused along with Brad. Where XACML seems to be
publicized to handle all of these things and I can't seem to find
out how or how they meet the DRM requirements as a general access
control language. The Requirements SC stated in the Requirements
Introduction that this language is not addressing fair use among
other things.  Fair use is not in scope of this TC. But now the
decision is being discussed again. I don't see how to do this. I
would like to understand how another standard, specifically
XACML, has addressed it.

Anne:  XACML has no mechanism for transferring right.

Hari:  But it states that it's applicable for DRM.

Anne:  It does not.

Hari:  Yes it does, it's on your XACML web site. It's in the
XACML Requirements Document, which was part of the submission for
all OASIS members to review.  If XACML addresses fair use, then
I'd like to understand how they've done it?

Anne:  We're not publicizing that.  The requirements are
old. XACML has moved beyond it.

[I meant to say "publishing", not "publicizing".  By "that", I
was referring to "XACML Requirements Document".  It is my
understanding that XACML submitted its final specification, not
the preliminary documents that led up to it, to OASIS for
approval.]

Hari:  People have asked me this; people have asked how XACML is
applicable to DRM.

Anne:  I don't feel like XACML is appropriate for DRM.

[I believe I said: "I [emphasis] have never said that I thought
XACML was appropriate for DRM.  In my personal opinion, as an
engineer, I don't feel like XACML is appropriate for DRM.]

Hari:  Anne, it was presented to OASIS as being applicable for
DRM. The Requirements document was part of the submission.
That's why we're paying such close attention to detail in the
RLTC Requirements doc. When we submit for approval, we're going
to present the requirements doc.  Now you're saying that XACML is
not applicable for DRM is confusing. This is not what was
presented to the general OASIS membership.

[There is a gap in the minutes here.

I believe I said: "I [emphasis] have never made those claims.  I
do not know what other individuals in the XACML may have said."

I believe Hari then said: "Why did Sun join the RLTC?  Was the
purpose to block ANY progress or prevent an affirmative vote in
the RLTC?"]

Anne:  Sun is participating in the TC because we're trying to
develop the standards in this area and insure that the resulting
standards are acceptable for the OASIS body.

[I said: "Sun feels we are helping the development of standards
in this area by participating in this TC.  By voicing our
concerns here, and helping to ensure that our concerns are
addressed, we are helping this TC to develop a standard that will
meet the requirements of the vast majority of OASIS members."]

Cory:  I'd like to stipulate that XACML is fit for no human
purpose and I'd like to move on.

Brad:  We have a late missive from Anne, a long email, objecting
to this TC, things that were agreed to be out of scope in Oct and
there is a pattern of re-hashing things.

Cory:  XACML is irrelevant.  

Hari:  I'm just asking for advice. If XACML has addressed this
I'd like to find out how they did it.  It's a process question.
I'm trying to understand.

Cory:  What we can learn from XACML is nothing.  I'd like to make
a motion that we move on.

Hari: Anne, XACML is not applicable for DRM, is that your
understanding?

Anne:  As an engineer, when I reviewed XACML I deemed it was not
appropriate from DRM.

Hari:  Then I guess I have to agree with Cory, we have nothing to
learn from XACML.

Cory:  Move to adjourn

Lisa:  Seconded motion

Hari:  Meeting adjourned at 11:52am