Fwd: Hotel availability in May 2003 is tight

[OKUBO Sakae]

Dr. OKUBO,

Thank you for your efforts. This appears to capture rather completely
the sum of comments and interests in this issue. We plan to submit a
draft recommendation at the upcoming meeting in San Jose that addresses
these issues, along with the normative organization that was suggested
by numerous Study Group members.

I would like to add that we have discussed items 2-5 and 2-7 at length
and have concluded that these attributes that we originally proposed,
while useful, should not be included in the standard. The reasons are
that in numerous other similar standards this information is ommitted,
and that the information may only be relevant to certain implementations.

They are quoted here for reference ********
2-5/      Include H.323 zone information - such as the zone
administrators, network identity of the gatekeeper and resources
associated with the zone. [AVD-2199]

2-7/      Enable a "whois" functionality for H.323 zones, so that one
may query the network and find contact information for a particular
H.323 zone, and published resources associated with the zone.
[AVD-2199]
****************

Also, there has arisen some concern about item 3-4:
3-4/      It should be possible to use the directory to manage the
services that are authorized for each endpoint or user once
authentication is achieved. [D271]

To solve this problem using LDAP, we have created an attribute called
h323IdentityAuthorization. However, this attribute does not exist
anywhere else in the h.323 protocol. So we are not merely representing
an attribute that is already defined, but creating a new functionality.
Many of the developers I have spoken to are supportive of this idea, as
it gives them a direct place to store information about what services
each endpoint is entitled to access. Thus, it has direct commercial
value. On the hand, from a more theoritical perspective, in the creation
of large scale systems, it may be more appropriate to handle
authorization through the use of an external authorization server. In
that case, the h323IdentityAuthorization attribute would not be used.

The advantage of including this attribute in the standard is that each
vendor could refer to it by name, opening up the possibility that
multiple gatekeepers could interact with the same LDAP server without
change to the LDAP server, by means of a simple mapping. If we do not
standardize the name, the LDAP schema would have to be redefined for
each gatekeeper. The disadvantage is that the attribute may not always
be used.

I would like to get feedback from the Study Group 16 members as to
whether they feel the h323IdentityAuthorization attribute should be
included in the standard.

Best Regards,
Tyler Johnson




OKUBO Sakae wrote:
> Dear Mr. Johnson and other experts who are interested in H.ldap,
>
> One of the action points from the previous SG16 meeting in October
> 2002 is to make a requirement capture as recorded in the meeting
> report COM16-R25:
>
> "At the WP2 review session, it was suggested to formulate a
> requirements capture that would serve a check at the final stage of
> standardization. We can find a good precedent in D.281 for H.248.MCU."
>
> I have tried a draft as attached based on the following materials:
>
>   - AVD-2199 Directory Services Architecture for Multimedia
> Conferencing (RADVISION, ViDe, Internet2), June 2002, Bruges
>   - D271 Directory Services Architecture for Multimedia Conferencing
> (Cisco Systems, Inc.)
>   - COM16-R25 Report of WP2/16, October 2002
>   - TD-61/WP2 Directory Services Work Plan (Q4/16 Rapporteur), October 2002
>
> Your additions, deletions, reorganization, improved wordings etc are
> very much welcome.
>
> --
> Best regards,
>
> OKUBO Sakae
> e-mail: okubo at giti.waseda.ac.jp
> *******************************************************************
> YRP Office
> Global Information and Telecommunication Institute (GITI)
> Waseda University
>   YRP Ichibankan 312                           Tel: +81 46 847 5406
>   3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken  Fax: +81 46 847 5413
>   239-0847 Japan
>
> GITI Headquarter
>   29-7 Waseda University Bldg.                 Tel: +81 3 5286 3831
>   1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo      Fax: +81 3 5286 3832
>   169-0051 Japan
> *******************************************************************
>
> Draft AVD-2279
> Source:  TBD
> Title:   Requirements for H.ldap "Directory Services Architecture for
> Multimedia Conferencing"
> Date:    11 January 2003
> Purpose: Proposal
>
> H.ldap will be able to support the following requirements as seen
> from the human user, gatekeeper and terminal configuration. The list
> will also serve as a checklist to verify that the proposed
> specification will support listed items. Some of the features are
> marked as advanced features and will be part of the future extension.
>
> 1.      General
>
> 1/      Service administrators need call servers that are aware of
> enterprise directories, to avoid duplication of account management
> processes. Users need directories to locate other users with whom
> they wish to communicate. All of these processes should pull their
> information from canonical data sources in order to reduce redundant
> processes and ensure information accuracy. [AVD-2199]
>
> 2/      H.ldap should accommodate H.320, H.324, SIP or other call
> signaling protocols concurrently with or subsequently to H.323,
> subject to decision of the group. [COM16-R25]
>
> 3/      The fact that recent videoconferencing products are mostly of
> H.323/H.320 hybrid should be taken into account. [COM16-R25]
>
> 4/      Standards should include information to facilitate
> implementation in addition to normative specifications. [COM16-R25]
>
> 5/      It should be possible to create very large-scale distributed
> directories. These could include white pages "portals" that allow
> searching for users across multiple institutions. In this
> application, each enterprise directory would register itself with (or
> be unknowingly discovered by) a directory of directories that is
> capable of searching across multiple LDAP directories. [AVD-2199]
>
> 2.      Object Classes
>
> 1/      Enable endpoint information to be associated with people (or
> resources such as conference rooms). [AVD-2199]
>
> 2/      Enable online searchable "white pages" where dialing
> information (e.g. H.323 URL) can be found, along with other
> "traditional" directory information about a user, such as name,
> address, telephone, email, etc. [AVD-2199]
>
> 3/      Enable all endpoint information to be stored in a canonical
> data source (the Directory), rather than local to the gatekeeper, so
> that endpoints can be managed through manipulations of an enterprise
> directory, rather than by direct entry into the gatekeeper. [AVD-2199]
>
> 4/      Store enough information about endpoint configuration so that
> correct configuration settings can be documented to end users on a
> per-endpoint basis, as a support tool. [AVD-2199]
>
> 5/      Include H.323 zone information - such as the zone
> administrators, network identity of the gatekeeper and resources
> associated with the zone. [AVD-2199]
>
> 6/      Be able to support multiple instances of endpoints per user.
> [AVD-2199]
>
> 7/      Enable a "whois" functionality for H.323 zones, so that one
> may query the network and find contact information for a particular
> H.323 zone, and published resources associated with the zone.
> [AVD-2199]
>
> 8/      Be extendable as necessary. [AVD-2199]  Defining a minimum in
> the standard with provision of an extension mechanism has been a good
> practice. [COM16-R25]  Careful consideration is needed for what
> should be in the standard and what should be left for extension.
> [COM16-R25]
>
> 9/      Be able to encompass H.32x, SIP or other related conferencing
> protocols in the future. [D271]
>
> 3.      Security, authentication and authorization
>
> 1/      It is important that the H.323 LDAP infrastructure support
> not only H.235 Annex D (hop-by-hop authentication) and Annex E
> (end-to-end authentication) modes, but that an organization could
> shift from one mode to the other without reconstructing the schema.
> [AVD-2199]
>
> 2/      Associate authentication information with a user and enable
> both endpoint and gatekeeper access to that information, in order to
> support H.235 Annexes D and E. [AVD-2199]
>
> 3/      It should allow both endpoint-centric and user-centric
> authentication. [AVD-2199] Authentication credentials, such as
> certificate or user ID / password for station and that for user can
> be separate. This separation allows for flexibility in the
> implementation of security architectures. [COM16-R25]
>
> 4/      It should be possible to use the directory to manage the
> services that are authorized for each endpoint or user once
> authentication is achieved. [D271]
>
> ----------
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at lists.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at lists.intel.com