[RUS-WG] Updates to the WG Charter

[Rosario Michael Piro]

Hi all!

Here are a few comments to the charter! Some of the comments might also 
be interesting to those that are not really interested in the charter 
itself. In the context of what is described in the charter I have a few 
suggestions that might be interesting for the RUS specification itself 
(and I would like to see many comments/opinions! :o)

First of all: good work!

* Section 2.1, second paragraph: This suggests that we should work on a 
RUS that can handle more than OGF-UR documents, which actually is a very 
good idea (the OGF-UR as it is now, for example isn't able to handle 
storage accounting, etc. And other formats might be interesting as 
well). In theory it might be possible to define RUS that can work with a 
generic XML document for resource usage. This would imply to things: the 
method that informs about mandatory record elements would need to be 
more generic (support arbitrary elements/properties), and an additional 
method that informs about which record format(s) is(are) handled by a 
specific implementation (e.g. OGF-UR and a costum XML format). Maybe 
that wouldn't even be difficult to achieve (since for queries 
XPath/XUpdate can work on arbitrary XML documents). But: it might mean 
that single implementations may not be interoperable due to the 
requirement of different XML documents. We should think about that, the 
idea is interesting. But for now, I would give more emphasis on OGF-UR 
and state in the charter that being compatible with that format has the 
priority.

* Section 2.1, third paragraph: I wouldn't use accounting systems as an 
example for service consumers. But they are a good example for service 
providers I'd say (an accounting system will more likely provide a RUS 
interface than use the RUS interface of another service). But I'm just 
being pedandic, of course it doesn't change much ... :o)

* Section 2.2, first paragraph: "the RUS specification does axplicitly 
not concern itself with any form of content for the used usage record 
formats". That only partly true, since the RUS specification is 
concerned with mandatory elements, and currently only specific OGF-UR 
elements/properties can be declared mandatory. But if think about 
handling things in a more generic way (as suggested above), we of course 
need to ensure that the RUS specification doesn't restrict the 
use/content of the different possible record formats.

* Section 2.3 (Goals): the distinction of core and advanced 
functionalities is a good idea. We might think about defining a method 
(in the RUC core specification) that can be used to retrieve a 
list/description of functionalities (core + advanced) that are actually 
provided by an implementation.

* Section 2.3.2 (advanced specification): "Features of interest include 
server-side aggregation, data replication, fine-grained security 
aspects, and VO-level access to usage records.". Most of these things 
are not an issue of the interface to the service, but of the 
implementation of the service. For example: the current specification 
does already allow for security as fine-grained as you want. Whenever 
the service implementation thinks that access should not be granted, it 
can respond with a RUSUserNotAuthorisedFault ... that's perfectly 
conform with the interface specification, it depends only on how the 
implementation grants access to an authenticated user. But I think this 
is in the implementation domain and the interface specification 
shouldn't really be concerned with it, because there might easily be as 
many security models as there are implementations. We just need to make 
sure that all these security models can be supported by the interface, 
but that is already be done by the RUSUserNotAuthorisedFault, each 
implementation can grant access whenever it wants to. The same is true 
to VO-level access. Whether the RUS implementation maintains a mapping 
of which user has such access or whether it determines the role of a 
user by means of a VOMS certificate or whatever, shouldn't be important 
for the interface to the service.
We should decide how far we want to go. Do we want to define only the 
interface to a service (as we explicilty say in the first phrase of 
Section 2.2 (scope)) or do we want to define (at least partly) how the 
service has to work (I'd say no)?
A similar consideration can be made when thinking about data 
replication. How and when data is replicated depends only on the 
implementation, not the interface of the service!

Section 2.8, last bullet of the first list: EGEE is project, not really 
a grid (it doesn't provide an infrastructure, it just develops 
middleware for other production grid projects).

Section 3 (appendix), 4.: I don't know if I would see a real overlap 
between DAIS-WG and RUS-WG. I'd say it's too minimal to be noteworthy. 
But we can also leave that point as it is in the charter, because we 
explicitly say that the purpose of both WGs are very different.

Section 3 (appendix), 6.: DGAS does not yet provide a (complete) 
implementation of the RUS interface, maybe it would be more correct to 
say that it is being developed.

Section 4: Can you please remove the trailing "main.html" from the 
reference to the DGAS website [7]. main.html is only the content of the 
main frame. Thanks!

For the rest: perfect! Thank for the good job!

Rosario.

Gilbert Netzer wrote:
> Dear RUS members,
> 
> I have made some updates to the proposed charter for this WG. Mainly 
> changing the wording from extended to advanced specification and grouping 
> the 6 planned documents under core and advanced specification sections. I 
> also tried to update the charter to reflect the recent publication of the 
> Usage Record Format Recommendation (GFD-R-P.98).
> 
> Please have a look at it one the GridForge and comment on it!
> 
> https://forge.gridforum.org/sf/go/doc14134?nav=1 (as MSWord document)
> https://forge.gridforum.org/sf/go/doc14135?nav=1 (as PDF document)
> 
> Best Regards
> Gilbert Netzer
> KTH
> 
> 
> --
>   rus-wg mailing list
>   rus-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/rus-wg