• Date: 23 Jan 2008
• Time: 9 AM Chicago, 3 PM London, 4 PM Rome (conversion to other timezones)
• Duration: 1,5h
• calling details: we'll try to use the SIP-based system to verify the quality; please, connect 5 mins in advance to check it; if it is not acceptable we fallback to CERN telecon service
• First solution:
  • traditional phone: +39 051 054 6636 (or any other on this list)
  • SIP-based phone: instructions
  • PIN: 1020
• Fallback solution: (in case previous not working well)
  • 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: 2301

Agenda

1. udpate on
   1. artf6080 + JP to ask Teragrid people about policy issues
   2. artf6104 (read this)
2. discuss computing entities
3. AOB

Minutes

• Sergio Andreozzi (CNAF)
• Balazs Konya (Lund Univ)
• Stephen Burke (RAL)
• JP Navarro (TeraGrid)
• Paul Millar (DESY)
• Laurence Field (CERN)
• Shiraz Memon (FZJ)

Minutes

• Shiraz, UNICORE: at the moment there is dynamic discovery of resources but not according to user VO; VO-based authZ info will be needed in the next months

• JP, TERAGRID: at this time no requirements/discussion being able to discover info based on VO-related policies
  • no concept of VO, there is concept of Project to which users belong to;
  • users discover resources by Web portals which
  • users log to portal, check to which projects they belong to and related resources

• JP: do we consider non-public information to be captured in the GLUE Schema?
• yes, as long they are needed for interoperability; mechanisms to restrict the access apply to the service exposing the information
• Action: JP to write email to a colleague working on metascheduler on potential appraoch to discover authZ info

• summary:
  • we agree that we need coarse-grained policy information to dinamically discover access to services or shares by users based on their VO/group/role membership;
  • this information should be possibly be restricted (a user can see only AuthZ info that apply to him/her); requirement for info service
  • still open the issue of if we want to model a single or multiple policy schemes (Balazs still discussing with colleagues)

• Action: SB to post URL of document about AuthZ architecture for EGEE-3
  • here it is: https://edms.cern.ch/document/887174/1

• AccessPolicy vs. MappingPolicy:
  • they are both AuhtZ policy; there is just a naming distinction
  • only question about TrustedCA, not needed so far in mapping policy
  • for now we stick to the distinction

• Issue: can be a user be mapped to many shares of the same Computing Service?

• • added Default attribute; need more thinking on this

• Values when Unknown Appendix
  • for required values: MUST be used by info providers for required attributes (multiplicity >= 1) and no proper values are available
  • for optional values: MUST use IF they want to advertise a value and no proper value was measured

• change 7.
  • for int32/uint32: 999,999,999
  • for int64/uint64: 999,999,999,999,999,999

• 6. counting: remove for now

• 1. simple strings: suggested value:
  • UNDEFINEDVALUE
  • UNDEFINEDVALUE + Log message

at the moment, there is no attributes for file names; we have instead path of directories

8. Pathnames

• • /UNDEFINEDPATH (or \UNDEFINEDPATH in Win)
  • /UNDEFINEDPATH/logmessage (or \UNDEFINEDPATH\logmessage in Win)

Action Summary

• JP to write email to a colleague working on metascheduler on potential appraoch to discover authZ info
• Balazs to continue investigation on need for multi-policy schemes support
• Paul to send a new draft of appendix incorporating suggested changes;