#2: Objection noted to operational considerations in architecture document
-----------------------------+----------------------------------------------
Reporter: g...@… | Owner:
Type: task | Status: new
Priority: major | Milestone:
Component: arch | Version:
Severity: In WG Last Call | Keywords:
-----------------------------+----------------------------------------------
Comment(by g...@…):
- Matt Lepinski (6/11)
With regards to the frequency with which relying parties fetch data from
the repository system (be that authoritative publication points or caches
operated by ISPs or RIRs), there appears to be a trade-off between "max
time to fix a problem" vs "work required by the repository system and the
relying parties". From this thread, it seems that there isn't an obvious
right answer with regards to how often relying parties should query the
repository system, but that there are risks associated with queries that
are too frequent or too infrequent.
To me, it seems that the best way to address this problem is to publish an
"operational practices" document of some sort that documents this (and
other) operational concerns and recommends practices to mitigate such
risks. [That is, Sandy's (b) option].
With regards to the architecture document (which I would very much like to
see leave the working group in near future), I believe the best way
forward is for the architecture document to be silent on this issue. For
example, consider the following text for Section 6 (last paragraph on page
15 of the arch-09):
"Note that since relying parties will perform these operations
regularly, it is more efficient for the relying party to request from
the repository system only those objects that have changed since the
relying party last updated its local cache. A relying party shall choose
the frequency with which it downloads and validates updates from the
repository system."
--
Ticket URL: <http://trac.tools.ietf.org/wg/sidr/trac/ticket/2#comment:1>
sidr <http://tools.ietf.org/sidr/>
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
