Cautionary Period:
 
The OCSP Service MUST provide values for the parameters thisUpdate,
producedAt, nextUpdate according to what is defined in RFC2560 and thus keeping the following order relationship:

thisUpdate <= producedAt <= receptionTime < nextUpdate

where receptionTime corresponds to the time when the relying party receives the OCSP Response from the server. 
Normally receptionTime should be very close to producedAt. In such case, the cautionary period for a given response is determined by

[thisUpdate, producedAt]

However, when OCSP Responses are being preprocessed, producedAt equals thisUpdate but receptionTime may be much later depending on the moment at which the request was generated by the relying party. Thus, in such case, the cautionary period should be taken as the interval 
 
[thisUpdate, receptionTime]
 
The longer such cautionary period interval is, the less precision resulted
in the OCSP response being provided. Such precision factor is an indicator
of the level of risk that the relying party is willing to take when accepting the
result status coming from an OCSP Response as is. The relying party's policy SHOULD
take into account such precision factor before accepting or rejecting the
response.
 
The nextUpdate field is another parameter of the OCSP Response which SHOULD
be taken into account when caching OCSP Responses. 
If nextUpdate is not set, the responder is indicating that newer revocation
information is available all the time. Whenever such field is set, it is an
indicator that the revocation information has been retrieved from a CRL
being released only at certain intervals of time. In certain cases, such
interval may be quite large - even in the order of days -.
The longer the interval 
 
[thisUpdate, nextUpdate]
 
the longer the maximum cautionary period of the OCSP Response may become. 
Finally, it is also interesting to note the interval

[receivedAt, nextUpdate]

which may be very so short that the relying party may decide to i) discard the response and ii) contact again the OCSP Responder as soon as the new revocation information has been generated.

 Delta CRL processing:
 
As specified in RFC2459, DeltaCRLs have the same structure as a CRL but
including a DeltaCRL Indicator which includes a reference to the CRL used
as base to construct the DeltaCRL. 
Using the traditional pop mechanism, the period of time between the
issuances of two base CRLs can be divided into intervals, where each
interval represents the period of time between the issuances of two
DeltaCRLs. Each interval begins with the issuance of a DeltaCRL and ends
just before the next DeltaCRL is issued.
However, when implementing a Grid OCSP service based solely on CRLs, a push scheme can be used instead thanks to the fact that the number of OCSP servers to populate with such revocation data is relatively low. This push model could be easely implemented even on CA software not supporting DeltaCRLs compliant with RFC2459.
A push scheme is much more efficient than a pop one because DeltaCRLs only
need to be transmitted when there is a change.