<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 5/14/17 7:15 PM, Tom Scavo wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAEtu=dPnOMdP6Db6PT7qtiwLBzqn4tZS2+ha4hASRqowxDdTfg@mail.gmail.com"><br>
      <blockquote type="cite">
        <pre wrap="">3) it's going to expire before the next scheduled refresh
</pre>
      </blockquote>
      <pre wrap="">
but how do you know that?</pre>
    </blockquote>
    <br>
    Each refresh operation computes the date/time for the next refresh
    and schedules it.  So the resolver knows it because it decided it.<br>
    <br>
    <blockquote type="cite"
cite="mid:CAEtu=dPnOMdP6Db6PT7qtiwLBzqn4tZS2+ha4hASRqowxDdTfg@mail.gmail.com"><br>
      <pre wrap="">
Well, you just said "next scheduled refresh," but that is a configured
event, right?</pre>
    </blockquote>
    <br>
    Well, it's computed, based on both resolver configuration and the
    metadata's validUntil and cacheDuration.  (None of this is new, nor
    has it changed in a long time).<br>
    <br>
    <br>
    <blockquote type="cite"
cite="mid:CAEtu=dPnOMdP6Db6PT7qtiwLBzqn4tZS2+ha4hASRqowxDdTfg@mail.gmail.com">
      <pre wrap="">Yeah, I guess so, but that's a bit of a concern. It means that
changing the validity interval on the file may breaking existing
configurations. For example, suppose a federation has the following
characteristics:
</pre>
    </blockquote>
    <br>
    Well, nothing is going to "break".  This is just about logging a
    WARN.  And remember that it also logs if the metadata will expire
    before the next refresh, so that takes care of the case of some
    assumptions changing.<br>
    <br>
    <br>
    <blockquote type="cite"
cite="mid:CAEtu=dPnOMdP6Db6PT7qtiwLBzqn4tZS2+ha4hASRqowxDdTfg@mail.gmail.com">
      <pre wrap="">
For the current operation, expirationWarningThreshold might be set to
PT7D (or more). For the future operation, PT3D makes sense.</pre>
    </blockquote>
    <br>
    <br>
    Well, I personally think both of those are way too long.  I think
    probably 24 hours is the most that makes sense - unless you really
    don't want to get notified and have to do something on a weekend, in
    which case maybe it's longer. (But I don't see how IT devops people
    can really get away with that these days...)   But each person will
    have their own requirements.  It's really more of an operational
    question of how paranoid you want to be.<br>
    <br>
    <blockquote type="cite"
cite="mid:CAEtu=dPnOMdP6Db6PT7qtiwLBzqn4tZS2+ha4hASRqowxDdTfg@mail.gmail.com">
      <pre wrap="">

Clearly PT7D won't work for the future operation. Should deployers be
advised to configure PT3D for the current operation so that they don't
have to reconfigure in the future?

</pre>
    </blockquote>
    <br>
    Maybe. But if fundamental assumptions about the metadata publishing
    change, then I think many of the config params (e.g. min- and
    maxCacheDuration) might have to be revisited by the deployer.  We
    can't deal with everything.<br>
    <br>
    <br>
  </body>
</html>