*Attendees*
Lynn McRae, Stanford U. (chair)
Dave Donnelly, Stanford U.
Tom Barton, U. Chicago
Gil Singer, SNtial Technologies
Ann West, EDUCAUSE/Internet2
Michael Gettes, Internet2
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)
New *Action Items*
[AI] {Jessica} will increase visibility of integration documents in the I2MI-Common space by linking in the Signet/Grouper spaces.
[AI] {Lynn} will follow up with {Michael} regarding how much history should be kept, and just how it is kept.
[AI] {Dave} will add LDAP config samples in the wiki for sources.xml file.
Carry Over *Action Items*
[AI] {Lynn} will share an updated version of use cases for Hooks. (25-May-07)
[AI] {Tom} volunteered a role in vetting Signet with Grouper to have a common JVM. (25-May-07)
Future *Agenda Topics*
- Kathryn Huxtable - Recent Subject adapter/source activity
- consolidating subject stuff from Signet Grouper under I2mi-Common management.
- Version 1.2.2 soon, maintenance release
Moved to latest Subject API, transparent/internal upgrade
Date regularization in code – consistent
Feature – specify initial default view for users
*Agenda*
1. Integration items - I2MI-Common
2. Continue discussion of programmatic updates of metadata and assignments. Three topics, with separate write-ups (see links below)
- Metadata update utilities [1]
- Assignment XML [2]
- Subject representation in XML [3]
*Discussion*
-Integration items - I2MI-Common-
{Michael} requested specific examples to follow when configuring LDAP. {Tom} mentioned that there are some examples included in the tarballs that are not found in I2MI-Common. These could be collected for sharing in a more visible place, preferably by linking (as opposed to copying) the information. This discussion acknowledged that there is more to do in the way of producing integration documents.
[Michael] further noted that there are no obvious pointers in either the Signet or Grouper wiki spaces to integration documents, such as the Subject API or LDAPPC. [AI] {Jessica} will increase visibility of integration documents in the I2MI-Common space by linking in the Signet/Grouper spaces.
-Continue discussion of programmatic updates of metadata and assignments-
C.f. Lynn’s email’s on 2-Aug and 3-Aug with the following subjects; links appended.
--Metadata update utilities-- [1]
{Lynn} addressed the Group on the best way to better manage subsystem metadata. For the full details, refer to his proposed ideas captured in the email [1].
{Michael} shared an administrator’s perspective, which is that having to call the ‘right’ utility for the ‘right’ function is cumbersome. He suggested that a better way to approach this would be to have one utility with different functions or commands. {Tom} pointed out that there is room for error when a human must execute multiple commands, which are dependent on the success of the others’ execution. {Lynn} said it would be useful to have impact assessment per command that would provide feedback as to what would be impacted by the change.
The aim of {Lynn’s} was to provide a low-tech enough and easy-to-deliver way of managing subsystem metadata. {Tom} agreed that it is a right first step, being useful and meeting the basic requirement.
A subsystem space will not have a large number of changes at once, unlike a larger entity such as a tree. {Tom} said most changes would be incremental and small-scale. He mentioned wanting to edit the XML file for incremental import capability. Wrapping with an interactive shell may not be a first step, but it would be useful down the road. His interest lies in being able to exercise a full range of capabilities interactively via command line. {Dave} said that from a programming perspective, it should not be too difficult to wrap individual utils in a shell, given it was designed properly to handle interactively or as a one-off utility.
--Assignment XML-- [2]
[Gil] wanted to clarify that if, for example, one updated something in the middle of a tree, that there are tree commands for rebuilding the tree from the bottom up. {Lynn} responded by saying all is logically connected through declaration of the parent connections. Each node declares its parent, and not the other way around. If you change a parent, then all children move. If you delete a node, and it has children, then you need a replacement parent. However, if children are scattered among parents, you would update them and assign them to where you want in the tree. Before building the parents, you would decide where to move the children first; a node cannot be deleted if it has children. {Michael} suggested that there be a force option; not offering a force option would penalize the knowledgeable administrator, even though offering it could mean regrettable consequences for the less experienced administrator.
Any changes need to be well documented, so as to reflect the organizational change into Signet. The Group discussed in detail how a parent change for the organization would be reflected by any action taken against the child assignments. {Michael} was worried that there could be too many solutions to think through, if addressed individually. {Tom} suggested that there ought there ought to be a single way to accomplish each action, else there is the danger of ending up with multiple ways.
{Lynn} pointed out that there is an important difference between deactivate and delete; metadata once used should never be deleted. References to assignments and history are needed for auditing purposes and should not be destroyed. [AI] {Lynn} will follow up with {Michael} regarding how much history should be kept, and just how it is kept.
One of the main assignments XML is to do programmatic assignments other than directly through java. XML provides an editable medium to build up the demo population. {Tom} mentioned that the integration style of the Authority Manager at U. Chicago will be through XML. He asked about the use of ‘type’, and mentioned how, in the subject interface, the type goes away as an identifying part of the subject reference; it may not be useful in referring to a subject now, however. The type could point to a person or a group; the source must have a type, as an attribute of the source, i.e., all subjects delivered by a source will have a type.
--Subject representation in XML-- [3]
The Group discussed the semantics of identifiers used in subject representation. Some items exist purely for the human-consumption aspect. Where applicable, items should be commented if it is meant for humans to read. {Michael} requested that there be example lines of mapping standard LDAP attribute names into Signet names to show that you do need to look there for name translations for all sources. [AI] {Dave} will add LDAP config samples in the wiki for sources.xml file.
There is a mapping mechanism incorporated into Grouper to record attributes. {Michael} suggested that both Signet/Grouper should be using the same mechanism. {Tom} agreed that there ought to be common configuration files beyond the style elements. However, discussions around integration issues should also address styles of configuration management.
The next Signet Working Group call will be on Friday, August 17, 2007 at 11am EDT.
[1] Topic 1 - Updating Metadata Utilities, c.f. email from Lynn, 2-Aug-07
< https://mail.internet2.edu/wws/arc/signet-dev/2007-08/msg00001.html >
[2] Topic 2 - Assignment XML, c.f. email from Lynn, 2-Aug-07
< https://mail.internet2.edu/wws/arc/signet-dev/2007-08/msg00002.html >
[3] Topic 3 - Subjects in XML docs, c.f. email from Lynn, 2-Aug-07
< https://mail.internet2.edu/wws/arc/signet-dev/2007-08/msg00003.html >