[Pgi-wg] OGF PGI - Review of notes of OGF30 sessions on 26 October 2010 - Counting votes for requirements

Sun Nov 7 16:14:20 CST 2010

Hi,

thank you Andre for explaining the procedures, and Morris for being so positively inclined :-)

On a sarcastic note, the simplest working code on which a consensus can easily be reached is "return 0". In PGI, we are up to much more challenging goals. Allow me this copy-and-paste from the current PGI charter:

<quote>
Goals
This group will deliver the following document:

* Production Grid Infrastructure Roadmap Document (GFD-I)
* Provides an overview of missing links between open standards and the fundamental motivation for standardization of the production grid infrastructure profiles
* Secure Job and Data Management Profile in Production Grids (GFD-R.P)
* Develop a job/data/security profile assuming an deployed computing endpoint is already known by an end-user
* Secure Information Profile in Production Grids (GFD-R-P)
* Allows a user to discover resources that are appropriate for their request and that they are authorized to access
* Secure Accounting Profile in Production Grids (GFD-R-P)
* Develop an accounting profile that allows services to securely update a service within information about the resources they have used on behalf of a user.
* Secure Monitoring Profile in Production Grids (GFD-R-P)
* Develop a profile that allows services to securely record in a service the progress of an activity.
</quote>

Pretty challenging, IMHO. I only hope "rough consensus" will be possible - and indeed *useful* for code - in each of these cases.  Unless of course the "living charter" process will evolve these goals into something easier to achieve.

Cheers,
Oxana

07.11.2010 20:06, Morris Riedel пишет:
> Hi,
>
>   that's what I had in mind too.
>
>> -- If a group is deadlocked like PGI (or rather if it is running circles
>> -- as PGI seems to do), it is the duty of the chairs to push the group
>> -- along.  In the worst case, if full consensus cannot be reached, a vote
>> -- on the available options can lead to rough consensus, which ought to
>> -- be enough to get things going again.  "Rough consensus - running code"
>> -- is the motto for OGF (borrowed from IETF,
>> -- http://en.wikipedia.org/wiki/Rough_consensus).
>
> This particular approach turned already out to be a very effective tool since a couple of months (2 documents out) and with this I see no problem in moving forward and reaching consensus also on the specification level.
>
> In the initial cycle we did not used this 'tool' trying always to reach a full consensus of all and that was hard.
>
>
> Nevertheless, let's not forget that we produced two documents and increased the mutual understanding.
>
>
> Thanks for this Andre,
> Morris
>
>
>
>> -- -----Ursprüngliche Nachricht-----
>> -- Von: andremerzky at gmail.com [mailto:andremerzky at gmail.com] Im Auftrag von Andre Merzky
>> -- Gesendet: Sonntag, 7. November 2010 19:01
>> -- An: Oxana Smirnova
>> -- Cc: Riedel, Morris; pgi-wg
>> -- Betreff: Re: [Pgi-wg] OGF PGI - Review of notes of OGF30 sessions on 26 October 2010 - Counting votes for
>> -- requirements
>> --
>> -- Hi all,
>> --
>> -- On Sun, Nov 7, 2010 at 6:14 PM, Oxana Smirnova<oxana.smirnova at hep.lu.se>  wrote:
>> -- >  Hi,
>> -- >
>> -- >  I'd like to point out that my "interesting thoughts" are directly based on
>> -- >  the PGI group description here:
>> -- >
>> -- >   http://forge.gridforum.org/sf/projects/pgi-wg
>> -- >
>> -- >  This was the mandate of the group when it was approved by the OGF, and it
>> -- >  explicitly contains the list of relevant standards and specifications, which
>> -- >  we just re-discovered. It even contains SRM and GridFTP, well in line with
>> -- >  the stated group's committment to deal with data management - something that
>> -- >  was contested by the management in Brussels.
>> -- >
>> -- >  Perhaps the group description needs to be updated, if management believes it
>> -- >  contains controversial statements.  What is the procedure for this?
>> --
>> -- purely from the OGF procedure perspective, the process would be to
>> --
>> --   - draft an agenda update,
>> --   - get rough consensus on that update via the mailing list (one week
>> -- final call)
>> --   - either submit that update to your area director,
>> --   - or  submit it online to OGF's living charter (which will trigger
>> -- the AD as well).
>> --
>> -- The update will then be reviewed by the GFSG, and usually accepted if
>> -- it is within OGF's mission statement.
>> --
>> --
>> -- For PGI, my very humble opinion is that a charter update is not needed
>> -- as long as the group is undecided on the explicit way forward -- and
>> -- that decision is long overdue.
>> --
>> -- If a group is deadlocked like PGI (or rather if it is running circles
>> -- as PGI seems to do), it is the duty of the chairs to push the group
>> -- along.  In the worst case, if full consensus cannot be reached, a vote
>> -- on the available options can lead to rough consensus, which ought to
>> -- be enough to get things going again.  "Rough consensus - running code"
>> -- is the motto for OGF (borrowed from IETF,
>> -- http://en.wikipedia.org/wiki/Rough_consensus).
>> --
>> -- Hope that helps,
>> --
>> --   Andre.
>> --
>> --
>> --
>> --
>> --
>> -- >  Cheers,
>> -- >  Oxana
>> -- >
>> -- >
>> -- >  07.11.2010 18:01, Morris Riedel пишет:
>> -- >>
>> -- >>  Hi,
>> -- >>
>> -- >>    Interesting thoughts. Indeed.
>> -- >>
>> -- >>
>> -- >>   >-- Or will we start all the specifications from scratch?
>> -- >>
>> -- >>  Depends on the rough consensus and majority decisions in the group step by
>> -- >>  step for each of the specification in question to be
>> -- >>  profiled/produces by us.
>> -- >>
>> -- >>
>> -- >>>  -- Maybe this is also something to clarify on Thursday.
>> -- >>
>> -- >>  Perhaps, but the approach is clear and has been discussed - then with the
>> -- >>  'rough consensus' no problem to move forward working on
>> -- >>  the specifications.
>> -- >>
>> -- >>
>> -- >>  Take care,
>> -- >>  Morris
>> -- >>
>> -- >>
>> -- >>
>> -- >>
>> -- >>>  -- -----Ursprüngliche Nachricht-----
>> -- >>>  -- Von: pgi-wg-bounces at ogf.org [mailto:pgi-wg-bounces at ogf.org] Im Auftrag
>> -- >>>  von Oxana Smirnova
>> -- >>>  -- Gesendet: Sonntag, 7. November 2010 17:32
>> -- >>>  -- An: pgi-wg at ogf.org
>> -- >>>  -- Betreff: Re: [Pgi-wg] OGF PGI - Review of notes of OGF30 sessions on
>> -- >>>  26 October 2010 - Counting votes for
>> -- >>>  -- requirements
>> -- >>>  --
>> -- >>>  -- Hi Morris, all,
>> -- >>>  --
>> -- >>>  -- I came to think about the process: now that we have the use cases and
>> -- >>>  have "derived" the requirements (exact set
>> -- >>>  -- of which can be still argued and prioritised in various manners), is
>> -- >>>  it time to come back to the specifications?
>> -- >>>  -- The "strawman" and such? The high-level scheme on the photo is in no
>> -- >>>  way different from what we had 2 years ago,
>> -- >>>  -- after all (remember, the group was called "BES/JSDL/GLUE" in 2008),
>> -- >>>  the circle is complete now.
>> -- >>>  --
>> -- >>>  -- Or will we start all the specifications from scratch?
>> -- >>>  --
>> -- >>>  -- Maybe this is also something to clarify on Thursday.
>> -- >>>  --
>> -- >>>  -- Cheers,
>> -- >>>  -- Oxana
>> -- >
>> -- >  _______________________________________________
>> -- >  Pgi-wg mailing list
>> -- >  Pgi-wg at ogf.org
>> -- >  http://www.ogf.org/mailman/listinfo/pgi-wg
>> -- >
>> -- >
>> --
>> --
>> --
>> -- --
>> -- Nothing is ever easy...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oxana_smirnova.vcf
Type: text/x-vcard
Size: 270 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20101107/ec8c91fe/attachment-0001.vcf 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20101107/ec8c91fe/attachment-0001.bin 