Subject: RE: Every time ..., was Re: General formula

From: Alan Lloyd <[email-masked]>
Date: Fri, 4 Jun 1999 17:30:12 +1000

Gosh Andy - all you ever do is spend is two bob - which represents AU$
0.50. :-)
 For my three bobs worth, the fundamental issue is that a complex
problem like the lifetime of a lump of data cannot be solved by a simple
(or lightweight) solution or formula eg. good old LDAP did not and will
not solve directory SYSTEM issues - just server - access issues.

Cert validity / lifetimes should be modelled in terms of operational
usage with the reliability requirements of the service.. ie from a
requirements perspective  in the context of a system design - not a
predictive perspective  based on theory or massive assumptions about the
data.

The process of ILS, LCC, error mode and criticality analysis and service
availablity prediction processes work for me in this regard - as it
takes into account the system components, their architecture and their
usage, etc.. 

Perhaps a discusion on ILS and LCC might be useful eh!

regards alan 

> -----Original Message-----
> From:	Andrew Probert 
> Sent:	Friday, June 04, 1999 10:57 AM
> To:	PKIX
> Subject:	RE: Every time ..., was Re: General formula
> 
> Two bobs worth ..
> 
> Erlang calculations have been tablulated to give people an easy lookup
> for
> telephony calculations.  Given a presented load in seconds, and a
> number of
> lines, what is the percentage of calls that will get a busy signal?
> 
> It works, given 3 factors you can lookup any way you like.
> 
> However for this, or any capacity planning exercise, real-world data
> and
> assumptions are input to the model.  
> 
> Erlang tables require the user to input their assumptions on presented
> load
> (an average) and number of lines avaliable to derive busy.
> Alternatively
> how much busy time they can tolerate, for a given load to derive a
> minimum
> number of lines.
> 
> I'm all for a model, please send me the Excel spreadsheet
> implementation
> when its complete.  
> 
> However, I think the real world of certs is too complex.
> 
> 
> Andew Probert
> Rotek Consulting   http://www.rotek.com.au
> a Division of Secure Network Solutions
> Tel  +61 3 9690 8877
> Fax +61 3 9690 8171
> 
> 
> 
	snip

---

From: Ed Gerck <[email-masked]>
Date: Fri, 04 Jun 1999 09:44:27 -0700

Alan Lloyd wrote:

> (or lightweight) solution or formula

Alan:

I feel that a summary is in order -- too many subjects and topics
on this issue ... we need to see the forest in spite of the trees.
I also include some comments to other msgs and will try to
synthezise list arguments so far.

1. never say never -- I mean, we don't have a dogma here, do we?

2. The more you say it is impossible, the happier I feel ;-)

3. As I commented before, I am thankful for your doubts -- they
have helped me bring to the forefront issues such as Poisson and Erlang
statistics. Even though I may not have been 100% successfull (it seems)
to convince everyone, if my private mailbox can be proof then I have
been at least partially successfull in pointing out that modelling is much,
much better than guessing ;-)

4. But, I also do not want to impose upon this list a course on poisson
statistics modelling  -- just using the results is usually fine for all engineering
purposes. Further, I take that current doubts from Tom and others can be
solved by resorting to  textbooks, so I am trying to wait and see what
happens in time on this regard.  Again, the equation does not have to be
deduced before it is used ;-) It is already there and those that may feel
more confortable with examples will be able to verify that it works; again,
in their own due time and there is no pressure.

5. If you don't trust the equation, then I suggest you *first* do the only
thing available today -- wild guess the result. Then, I suggest you do
calculate it. Then, I suggest you use whatever you feel is better  -- the
"wild guess" or the "wild calculation" ;-) (as you may call it). Then, I
further suggest you wait out and check what happens in the practice.
With all due respect to theory, this is IMO a far more significat test
than pages and pages of equations -- paper is too flexible and,
bytes too easily changed, as we all know ;-)

6. If you do want to "wild calculate" then please do read the inlined
reference [1] in my original posting -- it explains the modelling phase that
*must* precede any lifetime calculation using that equation. As it was very
timely remarked here yesterday by Andrew Probert:

"However for this, or any capacity planning exercise, real-world data and
assumptions are input to the model."

Thus, slightly paraphrasing Andrew's following text, I may say:

"Gerck's certificate lifetime equation requires the user to input their
assumptions on each presented attribute validity lifetime (an average)
of a *given* certificate, when a single exponential decay is assumed for
each attribute validity.  When this is not true for an attribute (eg, in the
case of a square-function validty) but the attribute can be described
by a piecewise exponential decay (as it generally can, at least
approximately) then the user must define and assume enough delayed
sub-attributes to that attribute so that the each sub-attribute validity
function is given by a single exponential decay in its time slot *and*
the user must also consider the resulting piecewise application of the
certificate lifetime equation -- so that in each time slot, all attributes
and sub-attributes are given by single exponential decays.
Alternatively, the user can input what certificate lifetime is desired,
for a given set of operational conditions, to derive a maximum number
of attributes of equal lifetime or a mix of attributes of different lifetimes.
The user does not need to make any assumption about attribute
dependency besides the trivial case of not using fully redundant
(whatever this may mean in the operational context) attributes; such
as repeatingly using the same attribute lifetime in the equation if the
attribute happens to repeated verbatim in the certificate -- since the
attribute is essentially "one" if simply repeated."

Hope it is clearer.

Cheers,

Ed Gerck