[XCON] Review of draft-ietf-xcon-common-data-model

[Richard Barnes <rbarnes at bbn.com>]

Hi all,

In my effort to get up to speed on XCON, I'm in the process of reviewing 
the active working group drafts (in addition to the other relevant 
background).  My review of draft-ietf-xcon-common-data-model is below.

--Richard


-----
Draft:  draft-ietf-xcon-common-data-model-13
Reviewer: Richard Barnes
Review Date: 13 Mar 07

General Comments:
1. The major challenge I had with this document there doesn't seem to be 
a clear separation in some cases between what the document describes, 
and what actions are implied.  I'll call out specific instances below, 
but in future revisions, I would encourage the authors to focus 
describing clearly what the state of the conference is that this object 
describes, and separately, what actions this state requires or allows.

Specific Comments:
Section 1, Paragraph 1
The phrase "... using an Extensible Markup Language (XML)-based."  does 
not parse.

Section 1, Paragraph 3
s/and specifies who/and specifies by whom/

Section 3.3.1, ABNF
It seems like a lot of the ABNF for the SIP URI (RFC3261, page 222) 
could be re-usable here.  E.g., you could just say
  XCON-URI = "xcon:" [ userinfo ] hostport
This would align the sets of allowed characters in what is now the 
conf-object-id, which could make parsing easier.  It would also add back 
in the "password" field (within userinfo), which could be useful when 
these URIs are used to access XCON conferences via CCMP (you would 
however, have to REQUIRE that the password be the same as the 
<conference-password>).

Section 4.2.1
It seems like there should be some structure to the <language> element, 
e.g., using the language tags from RFC1766.

Section 4.2.6
This section specifies the meaning of this element if it is present and 
set to true, but not what it means for it to be present and false, or 
absent.  Is the default for sidebars to be disallowed, confirmed by a 
moderator, etc.?

Section 4.2.9, <mixing-start-offset> bullet
This section says that the element specifies when mixing starts "before" 
the conference starts.  Should this be "relative to", or is it not 
allowed for mixing to start after the conference starts?

Section 4.2.9, <allowed-extend-mixing-end-offset> bullet
It's a little bit confusing that this element ends in -offset but isn't 
an offset.  Does this interact with the requiredParticipant attribute of 
the <mixing-end-offset> element?  E.g., can this element indicate that a 
privileged participant should be denied an extension to the mixing time?

Section 4.2.13, <available-media> bullet
This section specifies what the "Moderator-controlled" and "FCFS" 
policies mean (although it's not clear to me what "a 
first-come-first-served" algorithm is when comes to media), but doesn't 
define what the "Automatic" algorithm means.

Section 4.2.13, <controls> bullet
It's really unclear what this element means.  Are the sub-elements of 
the "controls" element describing controls that are available to a user? 
 Constraints on how the current media streams are handled?  I.e., does 
<mute>true</mute> tell the conference server to stop sending audio, or 
does it tell a client to show a "mute" control to the user?

Section 4.2.13, <video-layout> bullet
Why are these controls necessary?  Are there systems that are doing 
video layout on the server?  If not, then isn't it just a client UI issue?

Section 4.6.2
For clarity, it might be helpful here (and in the Security 
Considerations) to say that these elements specify only that the clients 
must authenticate to the server, using a mechanism of the server's 
choosing -- the specific mechanism(s) to be used are determined by 
individual servers for individual CSPs, and are beyond the scope of this 
document.

Section 4.6.5
Why does the "entity" attribute have to be unique in the scope of the 
conferencing system, rather than within the scope of the conference?  At 
first blush, it might seem like this is necessary for CCMP, but in that 
case, there is always a conference-ID present to disambiguate.

Section 4.6.5.3
s/provides anonymity/specifies what level of anonymity the server should 
provide/

Section 4.6.5.7
s/boolean action/boolean value/

Section 4.6.5.*
It seems like there's an element missing, something like 
<allow-allow-users-dynamically>.  <allow-invite> and <allow-refer> 
correspond to the "dial-out", and "refer" values for "method" above; 
what about "dial-in"?

Section 4.6.5.10, paragraph 3
Is this phrase correct? "... a floor that joins the participant in the 
conference"?

Section 8.1
See above comment on Section 4.6.2

Section 8.2
This section should be rewritten to be a little less hand-wavy.  The key 
points are (1) conference information can be sensitive, so (2) protocols 
that transmit conference object need to be able to 
confidentiality-protect them.  Couple of sentences describing the risks, 
then one sentence saying the "Protocols that transmit conference objects 
(or fragments thereof) MUST be able to provide confidentiality 
protection to them."

Section 8.3
Since we're mostly talking about an object as it resides on the 
conference server, most of the integrity are related to authentication 
and access control.  So this section could probably be deleted in favor 
of changing the title of 8.1 to "Authentication, Access Control, & 
Integrity".  The only addition that might be necessary is to ensure that 
protocols that carry these objects over the wire provide them with 
integrity protection in order to ensure the integrity of the management 
process; essentially the confidentiality sentence above, 
s/confidentiality/integrity/.