[RUS-WG] Updates to the WG Charter

[Gilbert Netzer]

Hi Rosario, hi everybody,

thanks for you productive comments. I have included some thoughts inline 
below. I also tried to incorporate the changes you suggested into the 
charter document. I hope I was able to capture your intentions in this 
document, but please have a look. All the changes should be highlighted, so 
they should be easy to spot.

I put the proposal in a separate folder on the GridForge to prevent 
confusion until we agree on the changes. It can be found via the link:

https://forge.gridforum.org/sf/go/doc14359?nav=1

When making more proposals it could be a good idea to take the download the 
document you want to propose changes to, accept all the changes in there to 
remove the old markup, make your changes using the change tracking 
facilities, and then upload it to some clearly marked place (e.g. the 
PROPOSALS sub-folder on the GridForge) and write a short email where you 
explain what you did (on a higher level) and why. In this email you should 
also refer to the document that you uploaded. This would make it easy for 
everybody to see what you had in mind, and probably speed up the process of 
commenting on changes. Of course this is completely optionally, you can 
also simply send a email like before, but please do not attach big document 
s as that will quickly overflow at least my mailbox.

Does the above suggestion sound like a good idea?

Best Regards
Gilbert

Rosario Michael Piro wrote:
> 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!

Thanks!

> * 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.

Currently it is scoped down to "primarily focuses on an interface that 
provides access to information stored in URF", so I guess removing e.g in 
the Purpose section makes clearer that we currently focus only on URF.
On the other side there is the advanced specification, which will have a 
hard time using only plain URF, if you want to aggregate.

> * 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)

Yes and no. In the context of SGAS, the RUS component really is being used 
by the rest of the system as a pure client. I.e. URs are stored in there 
and later retrieved by the SGAS client tools. I guess the situation is 
different for other systems where the accounting system itself exposes 
information through a RUS interface.

> * 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.

I guess what I want to point out there is that RUS does not do any checking 
of that the content actually makes any sense. I.e. we check that the URFs 
contain the Charge element (if so configured), but we do not check that the 
Charge is some sensible value. Or we do not check that the supplied EndTime 
has a sensible value. However we do validate the URs against the UR-WG schema.

The other thing is that the UR-WG is defining the schema of the content for 
us.

> * 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.

Yes, probably a good idea. But i guess that should go into the spec draft, 
not the charter? Anyway we should keep that in our heads.

> * 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!

About the security:
Yes it's fully true that you can make a model as fine grained as you like 
and perfectly conform. That is also a benefit, in my opinion.
The problem I was thinking more of is that the interface mandates to give 
back whole URs and you should not silently remove fields from the URs that 
you give back, so the only decision that can be made while conforming to 
the interface is give back the whole thing or nothing.

Furthermore I don't think that the RUS should maintain any mapping between 
user and VO others already do that.

The thing with data replication is not so much an internal replication 
inside the same RUS, but managing copies of the same UR store in two or 
more RUS instances. Here we probably don't have to reinvent the wheel, 
since that seems a common problem, but the RUS WG should probably state 
which standard way of dealing with such issues.

An example would be how does a RUS know that there are other copies of the 
UR around (in other RUSes) that need to be updated?

I would say that we should only concern us with interfaces. But that will 
then also constrain how a service can work.

> 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).

Changed Grid to project.

> 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.

Added that to the last sentence, and added being it in the first, was that 
what you had in mind?

> 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!
> 

Done. Thanks, that website looks much better!

> 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
> 
> --
>   rus-wg mailing list
>   rus-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/rus-wg