Conferencing Scenarios
RFC 4597

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    xcon mailing list <xcon@ietf.org>, 
    xcon chair <xcon-chairs@tools.ietf.org>
Subject: Document Action: 'Conferencing Scenarios' to 
         Informational RFC 

The IESG has approved the following document:

- 'Conferencing Scenarios '
   <draft-ietf-xcon-conference-scenarios-06.txt> as an Informational RFC

This document is the product of the Centralized Conferencing Working 
Group. 

The IESG contact persons are Allison Mankin and Jon Peterson.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-xcon-conference-scenarios-06.txt

Adam Roach has been the working group shepherd for the document.

Note to RFC Editor
 
 Expand first use of IVR to Interactive Voice Response,
 first use of DTMF to Dual-tone Multi-Frequency.

5.  Security Considerations

OLD:
   Conferences generally have authorization rules about who may or may
   not join a conference, what type of media may or may not be used,
   etc.  This information, sometimes called the conference policy or
   common conference information, is used by the Conferencing System to
   admit or deny participation in a conference.  For the conference
   policy to be implemented, the Conferencing System needs to be able to
   authenticate potential participants.  The methods used depend on the
   signaling protocols used by the conference.  This can include a
   challenge/response mechanism, certificates, shared secret, asserted
   identity, etc.  These conference-specific security requirements are
   discussed further in the XCON requirements and framework documents.

NEW:
   Conferences generally have authorization rules about who may or may
   not join a conference, what type of media may or may not be used,
   etc.  This information, sometimes called the conference policy or
   common conference information, is used by the Conferencing System to
   admit or deny participation in a conference.  For the conference
   policy to be implemented, the Conferencing System needs to be able to
   authenticate potential participants.  The methods used depend on the
   signaling protocols used by the conference.  This can include a
   challenge/response mechanism, certificates, shared secret, asserted
   identity, etc.  

   Conferences often require that their content be confidential.
   In addition, secure authorization of participants is incomplete
   if access to the media can be gained by unauthorized participants.
   Functions for securing the media, and for key management
   and distribution to authorized participants need to be
   provided by the Conferencing System. In some cases the
   functions used for participant authorization can be
   leveraged for this purpose.

   Privacy is an important aspect of conferencing.  Users may wish to
   join a conference without anyone knowing that they have joined, in
   order to silently listen in.  In other applications, a participant
   may wish just to hide their identity from other participants, but
   otherwise let them know of their presence.  These functions need to
   be provided by the Conferencing System.

   These conference-specific security requirements are discussed
   further in the XCON framework document.