[UR-WG] Actions for next phone meeting on 21.02.2012, 15:00 CET

[Mike Jones]

John,

The only contentious difference between what you are arguing for and what I am 
arguing for is that in your case you require the grid to perform the 
interpolation.

I argue that the grid, as one relying party, is _not_ the best place for this, 
as URs may go anywhere.  If a document bearing only the state of the system at 
an instant in time does not go into the system with the logic to interpret 
that data (i.e. the algorithm and the sampling rates) then those documents are 
worthless.

Therefore, I hold to my opinion that any interpolation must be done at the UR 
creation point (i.e. in the domain of the resource provider) regardless of 
whether their storage system has journalling, relies upon sampling or employs 
whatever alternative means to arrive at an integrated value.

In this light I do not believe your argument has any weight stating that it is 
too difficult to supply an integral value when, at a bear minimum, the resource 
provider can perform locally the same algorithm that you would have the 
accounting system perform remotely.  Further: Assuming sampling, the 
storage system has better indicators of how its facility is used. It will 
therefore be in a better place to increase sampling rates and adjust the 
algorithm used to achieve more accurate usage values should it need to do so.

> Mike, I think you are way out of line here. As long ago as Munich OGF we
> discussed time integrals for UR and I thought we reached a consensus (well
> maybe everyone except you) that we could not ask storage systems to start
> evaluating integrals of storage usage for the use of UR. They don't do it
> and we would be asking them to implement journaling or to recalculate
> usage at every file interaction (or at least write/modify/delete). Just
> not on.

I do not believe I am "way out of line".  I am not the only person to have the 
view that integrated values are a requirement of a definition of usage.

The following people were at the Munich meeting:
Gordon, John - STFC
Kennedy, John - Rechenzentrum Garching (RZG)
Keskrand, Kalle - EENet
Kretzschmar, Michael - MNM-Team
Maier, Andreas - LRZ Garching
Raitviir, Tõnu - EENet
Reetz, Johannes - Max-Planck-Institut für Plasmaphysik
URBAH, Etienne - LAL, Univ Paris-Sud, IN2P3/CNRS
Wolfrat, Jules - SARA

I believe Etienne also shares my view strongly about integrals vs 
instantaneous values.

I was not able to attend UR-WG in Munich as it clashed with security sessions.  
I am sorry for this.

I believed you had a reasonable understanding of what would constitute a 
storage usage record. At that time I was happy to leave it at that.

> I thought we all understood that this is a compromise for the pragmatic
> purpose of getting a UR soon that can be implemented in the real world.

I cannot find minutes of that meeting only the preprepared slides.  The slides 
do not (in fairness as they were probably written prior to discussion cannot) 
support that statement of compromise.

> You seem to enjoy the tautological discussion of what accounting should be
> in the theoretical world. I just want to start writing records tomorrow,
> if not today.

Please leave the rhetorical aspersions out.  My "Tautological discussion" as 
you put it is not so. I repeat myself merely to put across the same argument 
in different words so as to help you and the group understand where I'm coming 
from.  -- I have not yet heard a counter argument strong enough to make me 
put-up and shut-up.

> 
> In the longer term maybe we make requirements against storage systems that
> they implement integrals as well as user level and i/o accounting.
> 
> For now can we concentrate on agreeing something that can be implemented.

Any of this can be implemented and easily.
And as I understand UR v1 should be sufficient for your needs as it stands.

Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2787 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/ur-wg/attachments/20120228/2dc3d9fc/attachment.bin>