RUS Chairs Phone Conference

2007-01-09 16:00-17:00 CET

Attendance:

Gilbert Netzer, Secretary
Sven van den Berghe
Rosario M. Piro
Morris Riedel
Brunel 


* Next meeting

The time of the next meeting will be discussed by email. 

* RUS Charter

Sven informed us that the charter is due for discussion at a GFSC meeting
and that those meetings are usually held on the weekend before the OGF, which
would mean January 27th & 28th. We therefore decided that the charter should
be completed until then. Work on the charter will mainly be done via the
email list. Also we want to seek active input from WG members via the mailing
list. We agreed to set a preliminary deadline for the charter one week before
OGF19, on January, 19th.

To get an idea of the format and content requirements we decided to look at
other existing charters and also ask for assistance from the area directors 
and Steven Newhouse. We also decided after advice from Sven that we should
focus on the scope and exit strategy and ask the area directors about the
technicalities of the standardisation process.


** Specific questions/actions for selected parts of the charter 

*** Administrative Information

We decided to ask the old secretary (Hariharan Balakrishnan) if he is still 
active and willing to continue as secretary. If not, the chairs will 
collaboratively fill the position.

*** Scope

To clarify the scope of the RUS security model we decided to add that RUS can
only be held responsible for establishing the identity of the client 
(computing element, resource manager or owner) that stores or changes 
information in the RUS. The purpose of the auditing information in the RUS
is exactly to be able to proof who has done which changes and to allow a
RUS instance to proof that it has not been altered the stored information
in any way other than requested by clients.

*** Milestones

We wondered if implementations should be contained in the milestones section.
Sven informed us that implementations usually are not under the control of
the working group and therefore not included in the milestones. However
a full standard needs a working implementation. 

*** Standards Roadmap

For this part we think we should get assistance from an area director.

Sven volunteered pass a draft charter to the standards WG since they 
are in close collaboration.

* OGF Meeting

On OGF19 the RUS WG is having a 90min session to talk about current status and
further development of the RUS specification. We thought as a basic guideline 
to have about 45 minutes of presentation and 45 minutes of discussion, 
but would rather like to emphasise the discussion part.

For the presentation part we thought about the following four items:

- Overview about the status of the RUS Specification

- Information about existing and upcoming implementations 
  (including early previews if possible)

- Roadmap for the further development of the RUS Specification

We imagined that the discussion section mainly should focus around the
following issues:

- Discussion about the new charter
  We were not certain about that point

- Scope of the standard and requirements poll from the users
  - Get feedback from users
  - Check if the specification delivers what users require and does not
    deliver too much.
  - Enquire about the implementability of the specification
  - What features are missing? 
  - What features are present but not required and/or wanted?

- Discussion about the standard development
  - How should the specification evolve to allow for development without
    stopping implementors from using it.
  
- Discussion on relationship of XPath and RUS specification
  - What XPath expressions should be allowed by the RUS specification.
  - Allow single elements and/or whole records? 


As a preliminary schedule for more work on the outline of the OGF meeting and
for completing the presentations we agreed that most work will be done in the
week before OGF. 

* Roadmap to specification

Currently our plans are to produce a first specification based on the current
draft from the mailing list, but adding clarifications to open issues and 
minor fixes. New features should be included in a next version of the
specification that will maintain backwards compatibility.