You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Overview

This working group will focus on defining staged requirement sets for a service catalogue and make recommendations as to how to implement such a service and where this should be hosted. Use cases to inform the service 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 be categorized? Does a new taxonomy need to be developed, or is there something that can be reused?
  • How should catalog data be ensured to be accurate and reflect services that are offered and not retired?
  • What information about the service 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?


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), with which we might be expected to interoperate or serve or avoid duplicating.


Problem areas

  • Lack of one-to-one matching of SP entity to concrete service offering.  SP proxies are the obvious, many publishers offer strange bespoke links per institution so it's hard to capture the service view etc.


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/

  • No labels