Feedback on draft-ietf-webdav-acreq-01.txt

I've read the WebDAV ACLs Requirements document, and I have some rather
detailed feedback on it.  Will there be another version of this document
sometime?  It looks like it will expire in a couple days.

In general, I see a lot of sentences which say "the server may" or
"servers should".  We don't want to define the protocol yet, or say how
the implementations must work.  Instead, language can be carefully
restricted to "the protocol must define whether implementations..." and
"the protocol should specify how...".  Requirements should be stated in
terms of what the functional result should be, rather than the framework
for how to achieve that functional result.  In other words, we should
constrain protocol functionality, not protocol design.

The scope is very broad for something we'd actually like to accomplish.
I'd like to see a narrower required scope, with fewer features "required"
of the protocol, and the others can be "desired" features of the protocol.
The document could be more specific on precisely which features are MUST
have, SHOULD have and MAY have features.

Here is a section-by-section list of my comments on the draft.  Many of
the comments can be boiled down to saying that the requirements document
needs to focus on the desired or required functionality of the protocol,
not on the server implementations.

Section 3.  Terminology

It may be useful to define what you mean by ACE and ACL, but I'm not sure
that ACEs would be required by a successful protocol design that met the
functional requirements.  Recommending the use of ACE's be investigated
would be enough of a requirement, so that we can avoid hampering protocol
designers.

The definition for a Principal Description requires use of boolean logic.
There may be another way of describing a principal that could meet the
functional requirements.

The rest of the definitions are very useful by defining existing or
required concepts such as a collection.

Section 4.3. Access Control Entry (ACE)

"An Access Control Entry is the most fundamental unit of access control
policy.  An ACE contains a list of access rights, a principal
description, and an indication of whether the specified access rights
are to be granted or denied for principal identities which match the
principal description.  An ACE has no applicability to principal
identities which do not match its principal description."

This presumes the existence of ACE's, then constrains ACEs.  This
definition belongs in the protocol specification document, if anywhere.
What if the protocol designers decide to allow only one access right per
entry?  Having a single access right per entry could still meet the
functional requirements.

Section 4.4. Access Control List (ACL)

"An Access Control List is an ordered list of ACEs which are directly
associated with a given resource.  When policies expressed by the ACEs
in a given ACL are in conflict, the policies expressed by ACEs nearer
the beginning of the list have precedence.  "

This constrains protocol design.  How about rephrasing this in terms of
required functionality:  "The protocol must allow access rights to be
associated with a given resource.  The protocol may define some method to
avoid conflicting access rights."

"Evaluation stops either when all requested access rights have
been granted by one or more ACEs, or when any one of the requested
access rights has been denied by one of the ACEs.  ACEs containing
principal descriptions that do not match the current principal identity
have no effect on the outcome of the evaluation."

Same thing.  How about "The protocol may define short-circuit methods by
which servers can make a decision on access rights before all possible
access rights are evaluated."

Section 4.5.  Inheritance

Is it required for the protocol to do discovery and conflict resolution of
inheritance?  This could be difficult to standardize.  Are there other
models for inheritance besides the ones you've defined (static & dynamic)?
Is dynamic inheritance always done in exactly the way you've defined?

Section 4.5.2. Conflict Resolution

 - Good discussion and information on some of the issues that will have to
be addressed.
 - However, some of the things you said were quite implementation
specific:
"potential conflict between inherited ACLs, the resource ACL, and
user-based ACLs is also resolved by specifying a logical ordering or
precedence."
That assumes logical ordering is the way to resolve conflicts.  I think
that should be left open in the requirements doc, so that it can be
resolved either in the protocol specification or in each implementation.

"The order is different for dynamic inheritance.  First, any dynamic,
user-based ACL is evaluated, then any dynamic ACL on the collection root,
and so on, down to any dynamic ACL on the collection containing the
resource being access, and finally, any resource ACL on the resource
itself."

Are all implementations of dynamic inheritance already in compliance with
this statement?

Section 4.5.3. Distinction of Inherited ACLs

"Servers should interpret operations to retrieve and set the ACL of a
resource as applying only to the resource ACL on that resource, and not to
any inherited ACLs."
This should be left up to the protocol specification or to each
implementation.

Section 4.7. Other Access Control

"A compliant server may support other kinds of access control, which are
outside the scope of this protocol.  "

This is the kind of sentence that could well go into the protocol
specification, not the requirements doc

Section 5.1. Discovery

"The protocol must provide a way for a client to discover any optional or
extended functionality that may be implemented on a server, without
side-effects.  "
That's a big requirement for the protocol!  ANY optional or extended
functionality?  Discovery mechanisms are difficult.

"Compliant servers must be able to respond meaningfully to discovery
operations."
This specifies behaviour for servers, which the protocol should be doing
rather than the requirements doc.

Section 5.2.1.1. Rationale [for discovery]

Should it be possible to add an ACE without having permission to read the
whole ACL?  I can see that this would be desirable, but the requirements
document seems to preclude this.

Section 5.2.2. ACL Creation

This section specifies that certain features must be done with separate
operations.  That unduly constrains the protocol design.  Saying that the
protocol must support these features should be sufficient.

Section 5.2.4.  ACE Insertion

Supporting ACE insertion could be difficult.  I'd like to see this
optional in the protocol.  It depends on how the protocol resolves
conflict, which could be via ordering or some other mechanism.

Section 5.2.6. Test access

Why is this required of the protocol?  Perhaps it should be optional.

Section 5.3.  ACE Contents

"The contents of an ACE must include a list of access rights, a principal
description, and an indication of whether the rights are granted or
denied for matching principal identities."

This constrains the protocol to a very specific design.  This could be
rephrased as "The protocol must support multiple access rights granted or
denied to a described principal."  to leave the protocol designers free to
use some other mechanism to achieve the same functionality.

Section 5.4. Principal Description Semantics

Is it necessary to support arbitrary boolean expressions in defining a
principal?  Will all implementations that wish to support DAV ACLs be
willing to support that requirement?  Also, the requirement that
implementations must do short-circuiting is too restrictive for a
requirements document (should go in protocol specification if at all).

Section 5.6. Principal Attributes.

I don't see support for access based on group membership  (For example, to
allow full access to all members of group "sysops").

Section 5.6.3. User Name

By user name, do you mean "userid"?  Do you mean "lisadu" or "Lisa
Dusseault" or both or neither?

Section 5.7.1. Rationale [ for access rights]

"Some server implementations may perform mappings between WebDAV access
rights and native file system access rights.  "

I agree this is desirable.  How about rephrasing it as "The protocol
should make some allowance for implementations which map WEbDAV access
rights to native file system rights."

Section 5.7.2. List

"If a client attempts to create an ACE containing the "list" right, but
not the "read" right, such a server should return an error indicating that
"list" is not supported as an independent right."

A cool idea, but this defines the protocol, not requirements for the
protocol.


Lisa Dusseault