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: David Walker <>
  • To: <>
  • Subject: Re: [Per-Entity] implementing a cache on the client
  • Date: Thu, 4 Aug 2016 13:04:23 -0700
  • Authentication-results: spf=none (sender IP is ) ;
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:99

A few comments on this thread:

  • IdP and SP administrators will need to do something to take advantage of per-entity metadata distribution.  Even assuming we don't ask them (or their institutions) to run the distribution layer, they still have significant work to do.
  • If we did ask them to run their part of the distribution layer, we could provide them with an instrumented VM container.
  • For those who were not in yesterday's call, the consensus was that it should not be overly difficult or costly for a federation to run the entire infrastructure.  Asking institutions to run their part of the infrastructure (as is typical with DNS) should not be necessary and, in fact, might make institutions wary of adopting per-entity metadata distribution.  We did acknowledge, though, that others not in the call might have a difference of opinion, so I'm glad we're having this discussion.

David


On 08/04/2016 07:51 AM, Chris Phillips wrote:
Yes.  We are in general alignment.  I won't go as many '>' as you however.
I'm reluctant to sacrifice instrumentation at all costs for
reliability/performance, but will definitely favour
reliability/performance.  For the report, I think it's about what's
possible and at what estimated cost for an implementation.


Do you go to a 'restaurant' for a good meal, a fast meal, or an economical
meal?  

Does one implement MDQ for reliability/performance, with visibility, or
cost effectiveness?


Either question is a pick 2 from the 3 options unless you aim for 'what's
sufficient from each?'

C

On 2016-08-04, 10:36 AM, "Cantor, Scott"  wrote:

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.

    

Attachment: signature.asc
Description: OpenPGP digital signature




Archive powered by MHonArc 2.6.19.

Top of Page