Previous:

The 60 day public comment period started February 20, 2015. There were no public comments.
See: https://redmine.ogf.org/boards/22/topics/423

Action (JP): Confirm what final edits we need to perform for publication
Action (Florido, JP): Complete final edits by early October and submit
Action (JP): Submit final document for publication

See: https://redmine.ogf.org/boards/25/topics/427

Action (JP): Confirm what final edits we need to perform for publication
Action (JP): Complete final edits by early October and submit
Action (JP): Submit final document for publication
Previous action (Shiraz): volunteered to upgrade Warren's bindings to Maven

Previous:

Status: Enumeration work is on hold until someone has the time to move it along. What follows is a summary prepared by Florido of work that needs to be performed:

a) Most of the enumerations contained in GFD.147 are missing from git-hub CSV files. They should be added. This 
is kind of a monkey job.

b) InterfaceName_t and Capability_t are the ones Florido and David (and every GLUE2-supported software developer in the world) should discuss. The problem is that services like GOCDB created their own names and single software created their own and sometimes they clash, i.e. an Endpoint has different OpenEmumerations representing the same thing on different systems. We should keep one of each and mark Recommended and Deprecated.
Florido once made a list of those that should be summarized, here:
 https://docs.google.com/spreadsheets/d/1zuEiCP-0mQVJWOCGWxnKJ5p9vetLMIfN_AwFvoLDdEs/edit?usp=sharing

c) Some enumerations are hard to keep track of. Examples are operating system names, versions, distributions. It is not clear how a new operating system should be mapped to its GLUE2 equivalent. Neither is clear who should collect and diffuse this information: the GLUE2 group or the users?

d) There is an ongoing debate on how to represent protocols in general. In practice the use case is on the storage elements. They want to put such information in the InterfaceName. I would rather prefer to have it in Capabilities. Either way we will have a plethora of possible combinations of interfacenames and capabilities. E.g. a storage element that can understand three protocols should have either three Endpoints with different interfacenames for each protocol or a list of capabilities for each transfer capability and protocol. Example:

Option 1) Using InterfaceNames
StorageService
3 Endpoints:
  myendpoint.http
    Capability:
      data.transfer
  myendpoint.ftp
    Capability:
       data.transfer
  myendpoint.sftp
    Capability:
       data.transfer

Option 2) Using Capabilities:
StorageService
1 Endpoint:
   mystorageendpoint
     Capability:
data.transfer.ftp
       data.transfer.http
       data.transfer.sftp