Entities to be discussed:

Phone Meeting

• Date: 21 Nov 2007
• Time: 10 AM Chicago, 4 PM London, 5 PM Rome (conversion to other timezones)
• Duration: 1,5h
• Calling number: +41 22 76 77000 (ask to be connected to "Glue Schema Meeting")
• Shared screen session information:
  • URL: http://glue-wg.glance.net
  • Key: 2111

Agenda

• Action review
  • 6075->6078
• Minutes review
• Discuss open questions from Balazs_list
• UserDomain
• AOB

Participants:

• Sergio Andreozzi (CNAF)
• Michele Carpenè (CNAF)
• Marco Canaparo (CNAF)
• Stephen Burke (RAL)
• Balazs Konya (Lund University)

Apologize:

• Shiraz Memon (FZJ)
• Felix Ehm (CERN)
• Laurence Field (CERN)

Minutes Review

• Accepted

Review Open Questions since last OGF sent to the list

Discussing UserDomain

• Stephen: do we have a model for VO's organized in hierarchy?
• Sergio: VOMS supports VO's described as DAG
• Stephen: yes, but at the moment we use FQAN to express policies; EGEE has a WG working on defining policies for Computing and Storage Resources; e.g.: LCAS/LCMAPS have order in applying rules, we may need to capture them

• Open Questions:
  • in policies, you have a subject; this subject is expected to be published in the information service? (e.g., group as UserDomain)
  • how do we render the Policy in XML; i.e. what is the parent element?
  • can we have policies expressed following different schemes for the same entity?
  • added action: artf6080

<AdminDomain ID="urn:infn:cnaf">

• <Service ID="urn:infn:cnaf:wms">
  • <Endpoint ID="urn:infn:cnaf:wms:wmproxy">
  • <AccessPolicy>
    • <Scheme>VOMS-FQAN</Scheme>
    • <Rule>VOMS:/CMS/Production</Rule>
    • <TrustedCA></TrustedCA>
    • <TrustedCA></TrustedCA>
  • </AccessPolicy>
  • <AccessPolicy>
    • <Scheme>NORDUGRID</Scheme>
    • <Rule>VOMS:/CMS/Production</Rule>
    • <TrustedCA></TrustedCA>
    • <TrustedCA></TrustedCA>
  • </AccessPolicy>
  • </Endpoint>
• </Service>

<AdminDomain ID="urn:infn:cnaf">

• <Service ID="urn:infn:cnaf:wms">
  • <Endpoint ID="urn:infn:cnaf:wms:wmproxy">
  • ....
  • </Endpoint>
• </Service>
• <AccessPolicy>
  • <Scheme>VOMS-FQAN</Scheme>
  • <Subject>....<Subject>
  • <Rule></Rule>
  • <TrustedCA></TrustedCA>
  • <TrustedCA></TrustedCA>
  • <TrustedCA></TrustedCA>
• </AccessPolicy>

<UserDomain ID="urn:VO:CMS">

• <Level>0</Level><

<UserDomain ID="urn:VO:CMS:production">

• <Level>1</Level>

• back to userDomain
  • Balazs: main purpose is to describe VOs or groups
  • Sergio: the missing information is if this should be explicitely referenced by Policies or not; how it should be used in policies
  • Stephen: we could decouple UserDomain and UserGroup
  • Sergio: having a common entity can give more flexibility in query
    • e.g.: to query VOs: Level=0, to query up to third level: Level<3
    • moreover, most of the attributes are optionals
  • Stephen: decoupling is good for relational implementation
    • we should ask for opinions from othe Grids

• ManagerService: change to Endpoint, it was defined before the change of Service to Endpoint

• • Stephen: we may need more attributes, in EGEE there are different types of VOs
    • e.g.: approved VOs, regional VOs
  • Stephen: we may also want to represent Grids such as EGEE, GridPP
  • Balazs: we can use adminDomain
  • Sergio: we have both hierarchical associations and peer relationships

New actions:

• artf6080, artf6081, artf6082, artf6083
• artf6079
  • to be scheduled when Computing Entities are finalized