[RUS-WG] Updates to the WG Charter

[Rosario Piro]

Hi Gilbert!

Gilbert Netzer wrote:
> Hi Rosario,
>
> that is exactly what I did with this document. I made a different
> document on the GridForge in a different folder called PROPOSALS, simply
> by taking the old document, making the changes and uploading it into
> that folder. You will have to give it a sensible name, but the system
> will not allow you to not do that.
>
> It is NOT the same document, as you can see it even containes a
> reference in the decsription of the document to the original document
> and GridForge was smart enough to make a link out of it. I simply put
> the artifact id doc14134 into the description and it recognized that, so
> that's a nice feature!

The point is: the new document is named "Charter_Update_20070328.doc"
and in the document there is no indication that it contains just propsed
changes. However will find this document (without by chance reading the
short description on gridforge; maybe because he/she finds a direct link
to the doc or finds it on some other page, or simple doesn't look at the
description) will think that it is a version that replaces the previous
one. It's the same problem as with "draft-19". In my opinion documents
that do not replace the previous versions must not be called like them and
must _within the document_ clearly state that they are just proposals. But
even this will lead to confusion. It is better to write completely new
proposal documents (a different type of document) instead of updating
always the original documents with changes that have not been discussed
and approved.

For the charter maybe it doesn't make that much different, but it is
_essential_ not to have different incomaptible versions of the
specifications around of which only one is the approved version (and all
others look the same since there is no clue in the document that they are
just proposals) ...

>
> By the way this is the folder for proposals to the Charter, not the spec
> and the document I uploaded was for the Charter.

The problem is that gridforge is not the only way of getting these
documents. You can most probably simply google up a direct link so the
document status has to be clear from the document alone, and not only
considering the folder or the folder description.

>
> The spec has been marked as proposal since yesterday, the folder name is
> called
> draft-wsi-19 (PROPOSAL)

The _folder_ is marked as proposal, the _document_ itself doesn't say so,
it says:

GWD-R (draft-ggf-wsi-rus-19)

and it says:

"Abstract
This document describes the Resource Usage Service (RUS) core
specification ..."

Whoever finds the document somewhere else (or doesn't pay attention to
folder namings) will automatically assume that draft-17 is deprecated and
replaced by this document.

Again, the documents _themselves_ have to make clear what there status is
and what they are meant for! Putting them in a different folder is _not_
sufficient for making that clear because we cannot assume that gridforge
is (or will remain) the only source of information where these docs can be
found. It is enough that someone who downloaded it from us sends it then
by email to a friend who then puts it on his project webpage ...

>
> I guess we are already suggesting the same things, but it's good if that
> gets state a few times in different words.

Not really, I suggest that proposals are not written in the original
document, but in different proposal documents with a clear statement (and
that do not look like a new version or at least learly state that they are
not and point to the actual document). And that original documents are
changed only when the proposals have been discussed and agreed upon. This
is most important for the specifications. In the specifications (or the
draft specifications, but also charter) themselves modifications should be
made _only_ if they are likely to remain there. If we add each proposal
prior to discussion will have no stability since we continuously will add
things, then remove them because somebody didn't like them, then remove
old things, add them again because somebody liked them, sometimes have two
different versions derived form the same document because people worked
contemporarily, etc. ... The risk currently may not be high, but when the
WG will get a little more busy (and I hope it will) the confusion will be
great.

And believe me, as a programmer that is looking for a nice interface, I
would in any case choose _not_ implement a specification that changes
every few weeks! That's not good for what we want to do: propose a
standard. For that, we need at least some stability, even for draft
specifications.
Therefore: let's discuss things and when we have agreed upon changes that
we want to keep in future versions then put them in the draft.

Cheers,

Rosario.

>
> Best Regards
> Gilbert Netzer
>
>
> Rosario Piro wrote:
>> 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
>> -------------------------------------
>>
>>
>

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