Re: OSI-DS 33 and 34 - DUA and DSA Metrics

[[e-mail]]

And now a few fast comments about OSI-DS 34:


1. data-organisation model and distribution.

   Even if this (osi-ds 34) paper does not aim at covering distribution,
real life performance issues are dramaticaly impacted by these.
I would just suggest to add to the DSA presentation and prior to
measurment a few question permiiting to describe the choices
of the implementation.
     For example I have in mind the "one-level-knowledge" feature
	of QUIPU which has for consequences that even in case of
	distribution
		search-one-level operations are efficiently performed
	whereas other choices may result in an unnaceptable cost
	the same operation.
     Thus the questionnaire should help understand, when a subtree
	is managed by another DSA, what are the local facilities
	available.

	  eg.                  \
				A
			       / \
			      /   \
			     /  +------------------------------+
                            /   |   \             Remote       |
                           /    |    \             DSA         |
                          B     |     C                        |
                         / \    |    / \                       |
                        D   E   |   F   G                      |
                                |                              |
                                +------------------------------+

     From A
	with a QUIPU DSA: a search-one-level is a single operation
		(ie. a copy of the C entry must be in the local directory)
	with a Pizarro based DSA: only a list operation will
		result in a local operation (any search or read will
		be chained or return a referal, which is much more costly)


2. I fully support Andrew Waugh remarks about the flat vs deep trees
remarks.

2.1.
From what begins to be observable, it seems that some large
institutions will  choose to use at least 3 levels of OUs
(plus eventualy a locality attribute) in the DN of people
(or other objects). Thus at least part of the measures should be done
in order to reflect the behaviour and performance in such a case.
	eg. double measurements
	one with a P4 Depth  (C=; O=; OU=; CN=;)
	one with a P5 Depth  (C=; O=; OU=; OU=; OU=; OU=; CN=;)
		always starting at the O level for the queries.

2.2.
  The proposed entries for the tests/measurement are in my mind too small
	too reflect actual entries. People entries as generaly
	observed will contain several additional attributes.

   I thus propose that the attributes of the entries are:
	(a) CN
	(b) S
	(c) Phone
	(d) PostalAddress
	(e) Class
     plus
	(f) Fax
	(g) Rfc822_mailbox (~18 chars)
	(h) Text_encoded_OR_Address (~45 chars)
	(i) X.400 OR_Address

2.3.
  I doubt that people will (in normal operation and not for a pilot)
often set up a DSA for 100 entries.
I thus suggest that figures and measurements are given for
the following values
	1000	entries
	10000	entries
	100000  entries (or max efficiently supported on the
			given typical platform)
instead of 100 and 5000.


2.4. (5.2.2 page 10)

With the same justifications I would suggest to
add to 5.2.2 a
	30b.	1000 entries


2.5. (5.2.3. page 10)
  I think the first search operation (i) description should state
	100 OU entries OF the LOWEST LEVEL
  for the case of deep trees


2.6. (5.2.5 page 11)

Please add
	(d) 1000 children

2.7. (5.2.7 page 11)

Please add
	(c) 1000 children





regards

-- PAP