[RUS-WG] Updates to the WG Charter

[Gilbert Netzer]

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!

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 spec has been marked as proposal since yesterday, the folder name is 
called
draft-wsi-19 (PROPOSAL)

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

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