*MACE-Dir-Metadirectories Conference Call*
April 10, 2002

*Participants*

Keith Hazelton -- Wisconsin (chair)
Tom Barton -- Memphis
Brendan Bellina -- Notre Dame
Steven Carmody -- Brown
Renee Frost -- Michigan/Internet2
Michael Gettes -- Georgetown
Steve Olshansky -- Internet2
Eileen Shepard -- Boston College
Ellen Vaughan -- Internet2
Ann West -- EDUCAUSE/Internet2
Nate Klingenstein -- Internet2 (scribe)

*Discussion*

        Steve told the group at the call's outset to not spend too much time on
wordsmithing or formatting because he offered to have a small team of
students proofread the paper.  Ann also had already done a fair deal of
wordsmithing on a forked version from the one the group was working with.
Keith also recommended that the group take more of a "kitchen sink
approach," erring on the side of excessive information so that individuals
seeking to implement metadirectories can see the full depth of the problems
involved.  Several paragraphs and sentences were moved around in the
document.
        The last paragraph of section 2, which addresses the intelligence part
of the metadirectory, lacks a discussion of thresholding.  This is the
configuration of the directory to deal with situations where there are
excessive failures; e.g., if more than 3% of all information changes, then
don't automatically update because something may be amiss.  [AI] Tom
suggested he could throw in a paragraph about thresholding.

Identifiers & Reporting

        The group had a philosophical discussion about identifiers next.
Several different types were identified; for example, instead of using a
GUID, the group mentioned building an identifier type which would be, in
Michael's words, "like a license plate."  These identifiers would be
publicly visible and long-lived.  Michael offered that these identifiers
could be used as the main identifier to link entries from many different
systems to the metadirectory entry and to other systems.  At the same time,
there needs to be an understanding of legacy systems and their own needs;
these old identifiers and crosswalks to them will need to be maintained.
While Tom mentioned that this may cause some confusion in the "support
ranks," Michael didn't think that reason enough to not do this.
        Another critical point mentioned regarding identifiers is the need to
audit all changes to identifiers and maintain a thorough history of these
changes.  Maintenance of this history is especially critical in the case of
achronistic changes.  Reporting is a similar ability in the same strain.
The group thought the bottom of section 2 would be the most logical place
to discuss which means and where to sanity check data.  This seems more
appropriate than some other choices, because intelligence is necessarily
where the decisions are made, and the reporting as an independent outcome
of that intelligence is important.  Logging of both consumer feeds and the
outcomes should be performed.
        Interestingly enough, operations can be considered a consumer much like
regular apps can be.  An operational application is intrinsically different
from standard apps, reasoned the group, because the data it will need will
be very different sorts of attributes; instead of primarily being the
data themselves, it will be more data about the data, such as how and when
those data were changed.  Normal applications generally trust the integrity
of the data in the directory and registry, but the operational application
has to be an analyzing/fixing tool which examines the data from one step
back.  [AI] Tom offered to change the beginning of that paragraph to
identify that these applications can be considered another class of
consumers of data.

Terminology

        The group discussed at length what the proper nomenclature for many of
the structures and concepts in this space is.  Entities such as the
enterprise directory, metadirectory, repository, and similar terms are
often used in different capacities, and Keith saw a worthwhile activity in
working to fully define these terms for use in this document as well as
future and other current drafts produced by the MACE-Dir groups.  Internal
consistency within the document itself with strictly defined terms is
another important goal.  Michael expressed his displeasure with
"metadirectory" itself as a term.

*Action Items*

1.  Tom will generate a paragraph about thresholding.

2.  Tom will modify a paragraph to identify that administrative
applications should be considered as a different class of data consumer.