WG Co-chair hat OFF
Matt,
I'm happy to accept that the new wording is poor, but I'm pretty
sure the old wording was also bad, and I think this discussion is
important.
Please do not misunderstand me - I was not implicitly expressing a
preference for the old wording when I questioned the change you've
made to this version draft. What I was wondering about was the
viability in terms of both server load and relying party actions in a
fully populated system if the relying parties implemented such a
recommendation with a three hour refresh cycle time, and I was
wondering about the query load on the server under an idealized load
model and the viability of the relying party to complete a sweep of a
fully populated and fully distributed repository publication system
within a 3 hour time period.
You have raised some good questions in your note:
1) So the first implicit question is: Should the working group be
making a recommendation as to the frequency with which a relying party
pulls from the repository?
2) The second question is: If we make a recommendation regarding
frequency with which relying parties should pull updates, what
frequency should we recommend.
And perhaps I could add a third, on a more procedural note:
3) Should such operational recommendations be made in an architecture
document or collected together in an operational guidelines document?
The original rough guesstimates about load in my response to your
original note to the WG were just that, and doubtless an answer to
question 2 would benefit form some more detailed analysis of a number
of possible deployment scenarios, as you have also noted. Whether the
recommendation needs to encompass a worst case deployment scenario, or
to what extent any such recommendation is affected by the nature of
the deployed environment of certificate and signed object publication
points probably merits some study in the WG as well.
The "currency" of the data and the "responsiveness" of the system of
changes are to my mind important topics. Given that the repository
publication system is passive, in that new data cannot be pushed to
replying parties, but instead relies on the actions of replying
parties to discover a change, then the recommendations to relying
parties, and the associated implications of overall system load are
all relevant considerations here.
Geoff
WG Co-chair hat OFF
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
