RE: [XCON] I-D Action:draft-ietf-xcon-framework-10.txt

["Mary Barnes" <[e-mail]>]

Hi all,

This updated version is the result of IETF LC comments from the gen-art
and secdir reviews, along with some initial IESG feedback (OPS and
Security) (document was deferred from 11/1 telechat and is on the agenda
for 11/15).  The summary of the changes is below.  There shouldn't be
anything of controversy as these are all clarifications or corrections
to existing text.  The diff is not yet available on the tools page, but
should be there shortly. In the interim, you can easily create your own
diff by using the rfcdiff tool:
http://tools.ietf.org/rfcdiff  

Thanks,
Mary


Changes from -09 and -10 of XCON FW:
=====================================
1) Abstract and Section 1 (IESG (Dan Romascanu) Comment):

OLD:
  The Centralized Conferencing Framework defines logical entities and
  naming conventions, along with a high level conferencing data model.

NEW:
  The Centralized Conferencing Framework defines logical entities and
naming conventions. 

2) Section 5.2.1: removed confusing unclear 2nd sentence since it really
added no value(Scott Brim's comment from gen-art review) and changed the
tense of the 3rd sentence (editor's comment):

OLD:   
   In order to make each conference object externally accessible, the
   conferencing system allocates a unique URI per distinct conference
   object in the system.  The conference object identifier is created
   both by the conferencing system based on internal actions as well as
   based on specific conference protocol requests.  A conferencing
   system will allocate a conferencing object identifier for every
   conference blueprint, for every conference reservation and for every
   active conference.
NEW: 
   In order to make each conference object externally accessible, the
   conferencing system allocates a unique URI per distinct conference
   object in the system.  A conferencing
   system allocates a conferencing object identifier for every
   conference blueprint, for every conference reservation and for every
   active conference.

3) Updates to security section based on secdir (Kurt Zeilenga) and IESG
(Tim Polk) comments:

3a) Section 10. Added a fourth paragraph about DoS attacks at the end of
that section just prior to 10.1:
OLD (last sentence 3rd paragraph):
    A final set of
   issues involves the privacy and security of the identity of a user in
   the conference, which is discussed in Section 10.2.

NEW:
   Another set of
   issues involves the privacy and security of the identity of a user in
   the conference, which is discussed in Section 10.2.  

   A final issue is related to Denial of Service (DoS) attacks on the
conferencing 
   system itself. In order to minimize the potential for DoS attacks, it
is 
   recommended that conferencing systems require user authentication and

   authorization for any client participating in a conference.  It is
   recommended that the specific signaling and media protocols include
mechanisms 
   to minimize the potential for DoS.

3b) Section 10.1.  Clarifying Authentication versus Authorization

3bi) Renamed section:
OLD: 
   Authorization

NEW: 
   User Authentication and Authorization

3bii) First paragraph: expanded acronyms and clarified text. Added 2nd
sentence (removed last sentence) and moved 4th and 5th sentences to the
end:
OLD:
   Many policy authorization decisions are based on the identity of the
   user or the role that a user may have.  There are several ways that a
   user might authenticate its identity to the system.  The conferencing
   system may know about specific users and assign passwords to the
   users.  The users may also be authenticated by knowing a particular
   conference ID and a PIN for it.  Sometimes, a PIN is not required and
   the conference ID is used as a shared secret.  The call signaling
   means can provide a trusted form of the user identity or it might
   just provide a hint of the possible identity and the user still needs
   to provide some authentication to prove it has the identity that was
   provided as a hint in the call signaling.  This may be in the form of
   an IVR system or other means.  The goal for the conferencing system
   is to figure out a user identity and a role for any attempt to send a
   request to the conferencing system.

   
NEW:
   Many policy authorization decisions are based on the identity 
   of the user or the role that a user may have. Conferencing systems
typically
   require authentication of users to validate their identity. 
   There are several ways that a user might authenticate its identity to
the system. 
   For users joining a conference using one of the call signaling
protocols, the 
   user authentication mechanisms for the specific protocol often
suffice. 
   The conferencing system may also know (e.g., out of band mechanisms)
about specific 
   users and assign passwords to allow these users to be authorized.  In
some cases
   additional authorization may be required to allow the user to
participate in the 
   conference. This may be in the form of an Interactive Voice Response
(IVR) system
   or other means.  The users may also be authorized by knowing a
particular
   conference ID and a Personal Identification (PIN) for it.  Sometimes,
a PIN is not 
   required and the conference ID is used as a shared secret.  

3biii) 3rd paragraph (change "authenticates" to "authorizes"):

OLD:
   When guest users interact with the system, it is often in the context
   of a particular conference.  In this case, the user may provide a PIN
   or a password that is specific to the conferences and authenticates
   the user to take on a certain role in that conference.  The guest
   user can then perform actions that are allowed to any user with that
   role.

NEW:
   When guest users interact with the system, it is often in the context
   of a particular conference.  In this case, the user may provide a PIN
   or a password that is specific to the conferences and authorizes
                                                         ^^^^^^^^^^
   the user to take on a certain role in that conference.  The guest
   user can then perform actions that are allowed to any user with that
   role.

3biv) 4th paragraph: Reworded to add detail about the number of
digits/characters associated with specific numbers of bits in first two
sentences:
OLD:
   The term password is used to mean the usual, that is to say a
   reasonable sized, in number of bits, hard to predict shared secret.
   Today users often have passwords with more than 30 bits of randomness
   in them.  PIN is a special password case - a shared secret that is
   only numeric and often contains a fairly small number of bits (often
   as few as 10 bits).  

NEW:
   The term password refers to the usual, reasonable sized and hard to 
   predict shared secret. Today users often have passwords containing up
to 
   30 bits (8-16 characters).  PIN is a special password case - a shared
secret 
   that is only numeric and often contains a fairly small 
   number of bits (often as few as 10 bits or 3 digits).   


4) Updated references (gen-art review comment):
   OLD:
       draft-ietf-simple-message-sessions
       draft-ietf-xcon-bfcp-connection
   NEW:
       RFC 4975
       RFC 5018

5) Updated Chris' affiliation.


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Friday, November 09, 2007 12:10 PM
To: [e-mail]
Cc: [e-mail]
Subject: [XCON] I-D Action:draft-ietf-xcon-framework-10.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Centralized Conferencing Working Group
of the IETF.


	Title           : A Framework for Centralized Conferencing
	Author(s)       : M. Barnes, et al.
	Filename        : draft-ietf-xcon-framework-10.txt
	Pages           : 64
	Date            : 2007-11-09

This document defines the framework for Centralized Conferencing.
The framework allows participants using various call signaling
protocols, such as SIP, H.323, Jabber, Q.931 or ISUP, to exchange media
in a centralized unicast conference.  The Centralized Conferencing
Framework defines logical entities and naming conventions.  The
framework also outlines a set of conferencing protocols, which are
complementary to the call signaling protocols, for building advanced
conferencing applications.  The framework binds all the defined
components together for the benefit of builders of conferencing systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-xcon-framework-10.txt

To remove yourself from the I-D Announcement list, send a message to
[e-mail] with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
	"get draft-ietf-xcon-framework-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-xcon-framework-10.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


_______________________________________________
XCON mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/xcon