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: Nick Roy <>
  • To: "Walter Forbes Hoehn (wassa)" <>, Scott Cantor <>
  • Cc: Jorj Bauer <>, "" <>
  • Subject: Re: [Per-Entity] implementing a cache on the client
  • Date: Wed, 27 Jul 2016 18:28:53 +0000
  • Accept-language: en-US
  • Authentication-results: spf=none (sender IP is ) ;
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:99

Strong +1. I'm concerned about InCommon's reputation as a federation
operator if things were to go badly.

Nick

On 7/27/16, 12:26 PM,
"
on behalf of Walter Forbes Hoehn (wassa)"
<
on behalf of
>
wrote:


> On Jul 27, 2016, at 1:06 PM, Cantor, Scott
<>
wrote:
>
> On 7/27/16, 1:56 PM,
"
on behalf of Jorj Bauer"
<
on behalf of
>
wrote:
>>
>> Sure, and DNS has the same characteristics.
>
> DNS can tolerate long outages? That is really not my experience, but
I'm no DNS expert. Can you clarify?

Your points about DNS are well-taken, but where the comparison breaks
down is that we aren’t talking about asking thousands of institutions to
point their systems at InCommon’s DNS servers. I think the major risk here is
reputational. With the centralized model we seem to be headed toward, hiccups
could be catastrophic, certainly in terms of MDQ adoption, but also perhaps
in terms of the perceived value proposition of the federation.

I’m not attempting to argue against MDQ or “our” ability to deploy
reliable infrastructure, but I think we need to have our eyes open to the
risks of the various models that we propose.

-WFH




Archive powered by MHonArc 2.6.19.

Top of Page