Subject: Re: CAP and ACLs

From: Doug Royer <[email-masked]>
Date: Sun, 13 Dec 1998 16:55:54 -0800 (PST)

> Date: Sun, 13 Dec 1998 17:50:40 -0500
> From: "Paul B. Hill" <[email-masked]>
> 
> At 01:05 PM 12/13/98 -0800, Doug Royer wrote:
> >
> [much deleted by pbh]
> >...I hope this clarifies the issue.
>
> Yes, it does. And posting this type of information to the list, in a timely
> manner, is critical to moving the work forward.

Great!
 
>  [re-order by pbh]
> >
> >Several of us that worked on draft-ietf-calsch-capreq-02.txt
> >had been sending email and had a couple of meetings in order
> >to produce a requirements draft. It was viewed that ACLs would be
> >submitted as a separate draft. In that sense ACLs were deferred.
> >
> 
> Unfortunately, most of the email was not posted to the working group list,
> nor were meeting minutes posted to the working group list. During the
> Orlando working group meeting a commitment was made to post the meeting
> notes of future interim meetings to the list. Also a commitment was made to
> announce these interim meetings to the list ahead of time. During the
> meeting it was made clear that at least two of these meetings had already
> been scheduled for after Orlando. However, I don't recall seeing the
> information about these meetings posted to the list yet.

True - They have not yet been posted.

The first one I think will be in New York and I think that the
volunteer host for that one will be sending out email soon. He has
already contacted the cap requirements editors and asked about
typical problems and needs in order to host such a meeting.

The second one is being hosted by Sun Microsystems and I have not yet
been able to schedule a room.  I just got back from Orlando yesterday.
I commited to host a CAP meeting just hours before the CALSCH IETF
meeting last Monday.  There is just no way I could commit to the
date/time yet.

As to meeting out of band with the WG alias:  I feel that the issue
was raised in Chicago and LA.  At the IETF meetings there was mention
of out of band meeting to write the document.  I attended the previous
three meetings because I asked the most active editors to include me
in the meetings after I heard the announcements in Chicago and LA. And
they did.  Note that the IETF-Chicago meeting notes are still
unavailable for technical reasons (so I am told)

Perhaps those previous meeting times should have posted to the WG.
When you get caught up in things, you often forget one or more
of your goals (in this case to post the notes). However I stuck my foot
and nose in the door just by asking. So I don't think it was a closed
meeting.

As to the meeting notes from those meeting:  The chair should ping the
note keepers to supply those notes.  I think we kept notes on the
conclusions, not the daily discussions.  So I think they will match
the cap requirements document which I think is a formalized version of
those notes.

> >As with any IETF WG, others are also welcome to submit drafts.
> 
> I'd rather not see confusion created within the working group by divergent
> drafts. However, if the current group of _authors_ continues to act as if
> the documents were private submissions, there is a chance that there will
> be multiple conflicting submissions on the same subject. Please note that I
> was very careful in my choice of the word "authors" rather than "editors"
> in this context.

For the most part I agree with you. However draft '00' if CAP is
not out yet. So *now* is the time for ideas, submissions, and
discussions.

I can't think of a single issue that was raised on the alias or at one
of the IETF meeting that was not address by the latest cap
requirements draft.  If your mean the deferred issues.  I did send out
email asking for an accelerated cap.  There were no objections and
almost no comments.  I think that the ACL (separate draft vs.
deferred) OOPS in the cap requirements doc is an example of an error,
not planning.

In Orlando there were two issues raised (as I recall):

	(-my opinions below-)

1) Calendar locking.
   We talked a little about this at the meeting. The problem comes
   back to the locking model and current implementations.
   
   As long as CAP does not address transaction locking across
   multiple CS's, its an implementation issue inside the CS,
   not a protocol issue.

   At a later date transaction locking can be address and I think
   at the same time as group pools and group resources. After a core
   protocol is defined (again my view)
   
   Agree?
   
2) ACLs.
  I think we covered this here. There will some kind of ACLs.

Not all CS's and not all CUA's will be able to implement
a feature-rich CAP. So we need to be able to have a simple
CAP (kisCAP). Later we can add optional capabilities to the protocol.

From both the "CUA"s and the CS's point of view - I think that ACLs
are optional.  As I do not think that every CUA must understand a
CALSCH-ACL.  A PDA for example - might try to download something and
get permission denied back from CAP.  Without ever needing to know
why, and never asking for the ACL.  Or it would just succeed and never
need to know that the CS had implemented ACLs. A PDA is a form of
CS and I just do not see a PDA implementing ACLs.

Yet I think that ACLs are a MUST for interoperability.
We must define ACLs. Many implementations will provide ACLs.
Many CUAs will allow for them to be edited/created/deleted.

ACL's are a difficult and controversial issue because most existing
legacy implementations have a different idea of what is needed. Some
CUAs simply allow or disallow a feature. Example:

	- Be able to add 'user-name' as someone I designate to
	  perform operations as me.
	
It turns out that what that means varies across legacy
implementations.

I think defining a way to grant/deny access at a higher resolution in
a component will allow for the most interpretability as an
implementation or administrator might adjust what it means at compile,
install, or run time.  I feel as long as we all agree what an ACL
looks like, we should be able to understand what to do with them even
when we do not understand the legacy code that the instance was
intended to emulate.

Others think that what a 'designate' means should be spelled out in
advance and not allowed to change.  I see this as inflexible and
forcing a business policy in the protocol.

This issue consumed much time in the out of band meetings. So
we decided to submit a cap requirements draft with ACLs deferred
from that draft.

However we have not had a debate on the technical issues.  And
everyone seems to want this ability.

Where there other issues that were not addressed?

I have been on the Internet for about 20 years. Only last
year did I need to become active in WGs (a job requirement).
So I jumped in and starting participating.

For those of you that are holding back - join in. It really
is an open forum. If you don't email or talk at an IETF meeting,
things will happen anyway - just without your opinion. If you need
to clarify an issue and you don't think that the entire WG needs to
participate, then send private email and ask questions.

-Doug (A former WG Lurker)
-------------------------------------------------------------------
[email-masked]		http://www.royer.com/People/Doug
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL