Team Meeting March 24, 2003 Atlanta Georgia



Attendees:

Samir Chatterjee (via VC) - Claremont Graduate University

Tarun Abhichandani - Claremont Graduate University

Roy Muchtar – RADVISION

Karen Krivaa (via VC) RADVISION


Egon Verharen (via VC) – SURFnet

Henny Bekker (via VC) - SURFnet


Jill Gemmill - University of Alabama at Birmingham

John-Paul Robinson - University of Alabama at Birmingham

Jason Lynn - University of Alabama at Birmingham

Adita Srinivasan - University of Alabama at Birmingham

Tyler Johnson - University of North Carolina

Nadim El-Khoury - University of North Carolina



Summary of Discussion

1. EndPoints and TestBed status

  1. Status of commObject enabled CGU SIP client-

  2. Status of commObject enabled RADVISION H323 client

  3. Status of commObject GUI management code (discussed below)

  4. Status of commObject enabled ECS Gatekeeper

  5. Status of SIP/H.323 Gateways


Summary : all efforts need to focus on WORKING PROOF OF CONCEPT – ie, basic functionality using commObject must work among components.


John-Paul recommended use of command-line interface for testing where possible – focus on internal functionality and avoid hassle of developing GUI to send data to program.



2. H.323 Enterprise Authentication Document

Appreciation was expressed to John-Paul for this contribution. Tyler suggested that the document needs to be more strongly worded as a recommendation and less agnostic. The stages of the document suggest a development roadmap – first, do the easiest case, then implement the next harder case, etc. All agreed the document should be incorporated into the cookbook.




3. Shibboleth

Tyler asked whether HIPAA requirements could be met by Shibboleth because it seemed to be more about institution certificates than individual certificates. John-Paul said that Shibboleth can be as granular as you would like. Jill agreed.




4. commObject and X-Identities

  1. The group would like to see the ITU-T’s response to Nadim’s document from February

  2. sipIdentity will be included in May ITU-T submission

  3. Discussion about Virtual Rooms and multicast applications

  1. This brought up the question of how the group would implement an MCU in commObject. Jason suggested finding some standardized "Room" object or something similar. It was suggested to look at GRID services and D.M.T.F. (distributed MGT Task Force) for such objects. A standard room schema from Microsoft has been found subsequently.

  2. commIdentity

  1. The cookbook should explain how to create a new schema for any new protocol.

  1. Unique naming issue – does the commObject have a Distinguished Name (DN)? We all agree that the only attribute GUARANTEED to be unique in commObject is commUniqueID – if you happened to use this value for h323Identity you’d have some hope of returning a single commObject. Email addresses are unique, but one person could have the same email address in multiple commObjects. RADVISION has an algorithm requiring that for example, 3 out of 4 or 3 out of 5 names/aliases match to help identify which endpoint is contacting the gatekeeper. We left this as an implementation issue, but thought it might be worth discussing in the cookbook.

  2. Roy asked if we needed a gatekeeper list in commObject. Tyler answered that the functionality is already available with the multivalued GKDomain attribute. This way you have a choice in the endpoint to choose a gatekeeper. Egon suggested that we support profiles, as seen in Netscape. Tyler said this is also possible now, but that it is strictly up to the endpoint to implement.

  3. The focus then shifted to digital certificates. John-Paul asked how and where does the endpoint get its private key. Tyler asked if the group needed to add an attribute for this. Roy said RADVISION was not yet very familiar with Annex E. (Jill has done some subsequent reading – there is no specification of where the private key comes from; for a “standard” long-term certificate (eg from Verisign) you download the private key from the vendor’s web site. KX.509 is unusual in that the private key is generated at the client).

  4. We should aim for an ITU-T h235 Annex E (or F) Profile submission, using temporarily issued certs, - first version in fall 2003.




5. Distributed Search


Here we were greatly aided by Henny, Egon and the discussion regarding CIP (Common Indexing Protocol) which is already in use in Europe. See

http://www.surfnet.nl/innovatie/surf-ace/search/ldap/d2_ldap_tio/

for the functional design of the Desire LDAP/TIO-Index server.

  1. CIP uses an ldap prober (Pull model) : point made that any directories like UAB’s that limit results to 25 or 50 could not be searched this way

  2. Uses TIO index server (a central server that returns a pointer to the information source)

  3. LIMS is an example of a TIO server

  4. CIP can also work by sending a TIO index to the central server (PUSH model)

  5. Some decisions need to be made about what attributes to index

  6. We realized that a slight modification to existing TIO code would be needed in order to follow either commURI or commOwnerURI links. Henny will look into that. At a minimum the group decided that both commObject and people directories could be crawled.

  7. Egon needs a list of commObject and people servers to be crawled; we suggested

  1. Egon will set up and config the Directory of Directories

  2. We may want to add the address of the ldap server to the zone record.




6. Additional Cookbok/TestBed Discussion:

  1. The cookbook should include Aditya’s code for configuring endpoint via commObject

  2. The cookbook should include Aditya’s code for native LDAP search & retrieval



7. Deliverables List, Responsibilities and Dates attached


8. Next Face to Face Meeting in OCTOBER 2003