Per-Entity Metadata Working Group

[David Walker <>]

Good discussion.  Have we reached consensus?  Here's a summary of where I think we are:

• It should not be overly difficult or costly for a federation to run the entire per-entity infrastructure for its members.
  
• While it is possible for institutions to run all or part of this infrastructure for themselves, asking institutions to run their part of the infrastructure is not necessary and, in fact, might make institutions wary of adopting per-entity metadata distribution.

Sound right?

David

On 08/05/2016 06:43 AM, Thomas Lenggenhager wrote:

I agree with Scott C. I would not expect many campuses to install a local MDQ server. But we need to be able to provide a reasonable option for the few ones that want to have an MDQ server under their own control.

I'd compare it with the discovery service. To my knowledge, only a single campus in SWITCHaai installed and maintains a local central DS to be independent from the federation operated one.
Very few SPs use the local Shib Embedded-DS, most rely on the central DS based on SWITCHwayf operated by SWITCH.

No question, the central MDQ of the federation needs to be as reliable as possible. My point was that using some third party file sync service could reduce the complexity to install and run a local MDQ for the few campuses that want to run their own locally.

Monitoring the freshness of the signed files automatically updated by the file sync service would be simple to integrate into a local monitoring environment: E.g. warn if the oldest file in the synced directory is older than one day.

Thomas

On 04.08.16 15:53, Cantor, Scott wrote:

Open this directory structure for access via rsync, Dropbox, OwnCloud,
'you name it' to sync the signed files to campuses operating their own
local MDQ server to get independent from the centrally operated MDQ. No
need for HTTP proxies, just for local MDQ servers at the campuses.

Right, but how many campuses will want to do that? How many will bother? How many will ignore the whole issue because they're being told that moving to this new approach suddenly requires extra work from them?

The group consenus was that while nothing we do should or will make that approach difficult for people to implement, we shouldn't focus on it as a workaround for delivering a reliable service.

All that said, the Dropbox idea is a good one. Why not piggyback on existing cloud services? I like it.

-- Scott

Attachment: signature.asc
Description: OpenPGP digital signature