Skip to Content.
Sympa Menu

per-entity - RE: [Per-Entity] implementing a cache on the client

Subject: Per-Entity Metadata Working Group

List archive

RE: [Per-Entity] implementing a cache on the client


Chronological Thread 
  • From: "Cantor, Scott" <>
  • To: Chris Phillips <>, "" <>
  • Subject: RE: [Per-Entity] implementing a cache on the client
  • Date: Thu, 4 Aug 2016 14:36:26 +0000
  • Accept-language: en-US
  • Authentication-results: spf=pass (sender IP is 164.107.81.212) smtp.mailfrom=osu.edu; canarie.ca; dkim=none (message not signed) header.d=none;canarie.ca; dmarc=bestguesspass action=none header.from=osu.edu;
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:99

> If it was ONLY about validation then anything could carry it. But I
> contend it's not. We need health and operational instrumentation for
> diagnosis and options for predictive failure monitoring.

I would say we'd like them. I'm not sure we're willing to give up reliability
to get it.

> I would suggest that these are risks and needed expectations to call out
> in the report. If someone (institution or fed) chooses to use dropbox,
> great, but go in eyes open of what you are trading off.

Well, what I was agreeing with was that if you wanted a cheap strategy to
give campuses the ability to sync off the data, that's a simple way to do it.

> Even the largest services brownout from time to time and realize that too
> is the reality that one could be open to. If AWS region X goes down, so
> does your federation? Is that an acceptable risk?

This is why I'm not so sure of the cost involved in achieving adequate
reliability, and adding the requirement to have total visibility on top of
that may create a basic conflict. I think reliability/performance >>>
visibility.

-- Scott




Archive powered by MHonArc 2.6.19.

Top of Page