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: Tom Scavo <>
  • Cc: "" <>
  • Subject: Re: [Per-Entity] implementing a cache on the client
  • Date: Wed, 27 Jul 2016 18:53:52 +0000
  • Accept-language: en-US
  • Authentication-results: spf=pass (sender IP is 164.107.81.218) smtp.mailfrom=osu.edu; incommon.org; dkim=none (message not signed) header.d=none;incommon.org; dmarc=bestguesspass action=none header.from=osu.edu;
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:99

On 7/27/16, 2:28 PM,
"
on behalf of Tom Scavo"
<
on behalf of
>
wrote:

> We don't sign metadata on weekends and holidays.

Yes, but not signing isn't "the aggregate's not available". I thought that's
what was meant by an outage in this discussion.

> Last summer, the MDQ beta server stopped refreshing metadata. We
> didn't realize what had happened until two weeks later when local
> metadata expired. ScottK can comment on that incident since he was
> involved in the pilot.

I think a 2 week outage of the aggregate would be noticed, and would be
catastrophic. I'm not seeing a huge difference there...

Again, I'm sort of just playing devil's advocate here. I get the point you
and Walter and Nick are making. I'm just trying to say that the aggregate's
availability isn't meaningless either.

I do believe, however, that solving the problem by making every deployer
operate a caching MDQ proxy is not an answer. If the consensus of the group
is that the endpoint software needs to do more here, I can take that to
heart, but looking at the problem from a broader perspective, I think that
road leads to the conclusion that endpoints need to host the metadata.

-- Scott





Archive powered by MHonArc 2.6.19.

Top of Page