Overview

This working group will focus on defining staged requirements for a service catalog and make recommendations as to how to implement such a utility and where it should be hosted. Use cases to inform the service catalog should consider the needs of management (e.g., reporting), operators, and end users.

Terms

The following terms apply to all REFEDS Working Groups:

1. When a working group is agreed, REFEDS Participants will be asked if they wish to participate. Working Groups tend to be small, so consensus can be achieved quickly between participants.
2. A chair for the group is chosen from the REFEDS Participants.
3. GÉANT provides facilities for the working group, including meeting support, wiki space, mailing lists and, where appropriate, funding.
4. An appropriate output from the group is produced. Currently, this is typically a draft white paper or a wiki page.
5. When the Working Group is in agreement, the chair shares the outputs with the wider REFEDS community with an open period for discussion and comment. This is typically a period of 4 weeks, but may be longer if appropriate.
6. After this period of time, the REFEDS Steering Committee signs off on the work item. Work is either written up as a formal white paper, left on the wiki but promoted as finished work or occasionally submitted as an Internet Draft.

Co-Chairs

Heather Flanagan (REFEDS)
Heath Marks (AAF)

Work Items

Implementation & Operation

• What existing standards are there for service catalog description and management that can be adapted vs reinventing wheels (e.g., TMF Product Catalog API (see External Resources, below))?
• How should services listed in the catalog be categorized? Does a new taxonomy need to be developed, or is there something that can be reused?
• How should service catalog data be ensured to be accurate and reflect services that are offered and not retired?
• What information about the service catalog is relevant to which reader for which use cases?
• What degree of information should be available in the different use case scenarios?
• Should there (eventually) be some sort of crowd source rating of usability of services?

Governance

• Who would be the contact point for the catalog as a whole? (i.e., who operates the service catalog)
• Can we assume a unified view should be possible from day one (like MET), or should there be one catalog per federation that can create a merged set with an eduGAIN-like SPoC?
• Does there need to be a business model to support this utility?

Dependencies

• What other areas have service catalog work ongoing (e.g., European Open Science Cloud, GÉANT Cloud catalog I2 Net+ and it’s followups), which we may be expected to interoperate with, serve data from, or avoid duplicating effort.

Problem areas

• Lack of one-to-one matching of SP entity to concrete service offering.  For example, SP proxies are an obvious and current challenge as many publishers offer strange bespoke links per institution so it's hard to capture views or descriptions of individual services.

Calls

Bi-weekly

Resources

ACAMP 2016 notes: https://docs.google.com/document/d/1GHerhDYfwlgjN5-pQEryJF0RqOp7R_tWuHiuW5gTdjQ/edit Guide to creating a service catalog: https://www.cherwell.com/products/it-service-management/itil-processes/essential-guide-to-creating-an-it-service-catalog

Product Catalog Management API REST Specification (TMF620) R14.5.1 https://projects.tmforum.org/wiki/display/API/Product+Catalog+Management+API+REST+Specification+%28TMF620%29+R14.5.1

Examples: 

http://itcatalog.ucdavis.edu/
https://uit.stanford.edu/services
https://itconnect.uw.edu/services/