[RUS-WG] Updates to the WG Charter

[Rosario Piro]

Hi all!

Gilbert Netzer wrote:
> 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.

I really don't think that it is a good idea to immediately change the
original document when you have a proposal. If I accept certain changes
and remove the markup, someone else doesn't like them and remove the
changes themselves and adds own stuff, etc. we will end up with N
different verions of the same document and never get to anything stable.

Proposals should be made, _discussed_ and be _approved_ (accepted by most
RUS-WG participants) BEFORE document changes are made. That does not mean
that proposals cannot be in document form. The best way would be:

1) Write a _distinct_ document (learly maked as _proposal_) that describes
the proposal in a detailed way (if it is more complex, otherwise this
point can be skipped).
2) Write a brief description of the proposal to the mailing list (and
eventually point to the proposal document of point 1).
3) Discuss the proposal (in a phone conf but _also_ on the mailing list,
since not everybody can always participate in the phone conf).
4) If the proposal is accepted _then_ (and only then) change the original
document that is affected by the proposal.

This is _especially_ advisable for the RUS specification itself! And with
that I also refer to "draft-19". Please don't get me wrong (above all you
Chen, some of you proposals are really interesting), I really appreciate
whoever is willing to invest time and energy, and shows enthusiasm and the
willingness to contribute. But please: do not just change official or
semi-official documents without asking anybody beforehand. Before changing
the specification these changes need to be discussed and accepted. And
above all documents that propose changes have to be _clearly marked_ as
proposals and NOT as new versions of the draft! A new version of a draft
schould be made public only _after_ we have agreed on what we want to
change in the previous draft. Otherwise this will lead only to confusion
(and I know of people new to the RUS who actually were very confused when
they saw "draft-19" that is very different of the current version draft-17
and didn't know anymore what they should start implementing ...).

In other words: if you have a proposal for changes, make sure everybody
(also somebody who just by case stumbles over the document) understands
that it is a _proposal_ and still has to be discussed. The changes in
"draft-19" are proposed changes and need to be _marked_ as such (the
entire document should not state that it is draft-19, but a proposed
change of draft-17!).

Again, I don't want to scare away nobody, especially if he invested as
much time and energy as Chen (thanks for that!), but please do not write
own versions of the specifications on your own. We'll never get to
anything stable that way, because if we all do that then we will have a
new RUS specification every two weeks and each one with different kind of
changes. Immagine what happens if I now remove a few things from
"draft-19" that I don't like and set them back to the draft-17 version, I
let other things I like and add some own changes ... then I name that
document draft-20 without having previously discussed the changes with the
rest of the WG. Morris takes that and removes my changes, because he
doesn't like them, he adds a few "draft-19" things I removed because he
actually thinks they are great and instead removes a few other "draft-19"
things that I had accepted before. Then he names that draft-21. Then,
Gilbert and someody else contemporarily make incompatible changes on that
document ... and so on ... the end will be a mess.

That's why I propose we adopt the procedure I've descibed above (make
changes to official or semi-official documents only _after_ discussion and
approval). I also propose we consider "draft-19" as a collection of
proposals to draft-17 (some of which are actually very interesting, but
they still have to be discussed and approved) and mark it clearly as such
(hence do not call it a new verison of the specification, and state
clearly in the document itself that it is a proposal).

I will send my own comments to Chen's proposal to the ML soon (but in a
differnt mail, because I don't want to mix the two distinct discussions).

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

Actually I think if changes are made before discussion it will slow down
the entire process of getting to a stable product.

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

Right, proposal documents (that go more into detail if a mail isn't
enough) should be uploaded, not also to prevent mailboxes from exploding
:o), but also for the purpose of having a visible and public documentation
on the work that has been done. From that point of view it is good that
the proposed changes to the RUS specification have been uploaded, they
simple shouldn't have been marked as "draft-19".


Cheers,

Rosario.

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

-------------------------------------
   Rosario Piro (piro at to.infn.it)
    http://www.to.infn.it/~piro/
-------------------------------------
Istituto Nazionale di Fisica Nucleare
Sezione di Torino
-------------------------------------
National Insitute for Nuclear Physics
Section of Turin, Italy
-------------------------------------