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

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

Ed - some comments

> -----Original Message-----
> From:	Ed Gerck 
> Sent:	Saturday, June 05, 1999 2:44 AM
> To:	Alan Lloyd
> Cc:	'Andrew Probert'; PKIX; tgindin@us.ibm.com
> Subject:	Summary, was Re: Every time ..., was Re: General formula
> 
> 
> 
> Alan Lloyd wrote:
> 
> >  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
> 
> 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?
	Is this statement in relation to simple things dont solve
complex problems - if so please prove (operationally) otherwise.

> 2. The more you say it is impossible, the happier I feel ;-)
	Is this statement in relation to simple things dont solve
complex problems - if so please prove (operationally) otherwise. And I
did not say you cannot determine cert life time - Its a qualitative
thing. Some believe - take a set of assumptions from a data perspective
- add a formula or two - and hey presto - an answer pops out - which can
also look about right - from a perspective.

	In system enginnering for business enterprises there are
doctrinal, operational, policy, procedural and human factors to consider
- as well as system and detailed technical matters - eg implementation
quality, deployment and scaleability, reliability issues.. I tend to
work on these aspects..



> 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 ;-)
> 
	Perhaps what is exact to you - ie a set of assumptions about
attributes and applying  formula - is exact. and that you call modelling
However, my view of  this issue is related to modelling operational
systems with the parameters as described above - and I expect that to be
more useful. I dont call what I do 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. 
	Another approach is to ignore the equation. And do a full
operational system analysis - because is that,  what the customer wants
to know - and pay for..
> 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.
> 
	WoW - and groan...
> 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.
> 
	No - its all missed the point - A certficate lifetime ( its
validy and usefulness) also depends on the business and operational
context it lives in..

	A theory about a certificate is just that - for a theoretical
and limited world . If that is useful to you then so be it. It is not
very useful to me because theory is about 10% of my world.

	May I also say that a directory system is about distributed,
object oriented, name based transaction systems - on which (distributed)
PKI and certificate functions are applied.. It is a new approach and
tool set to engineering distributed systems - ie. not just as
client-servers, or applications with databases or simple protocols..
When new tools arrive on the scene - the job gets done differently,
designs get done differently and new theories should be applied...

	just thoughts.
	regards alan

> Cheers,
> 
> Ed Gerck
>