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

["Oscar Novo" <oscar.novo at ericsson.com>]

Hi Richard,

Still I haven't got enough time to work in your comments but,
definitely, I'll look into them when I got some time.

Thanks for your comments!

Oscar

-----Original Message-----
From: xcon-bounces at ietf.org [mailto:xcon-bounces at ietf.org] On Behalf Of
Richard Barnes
Sent: 16. elokuuta 2009 23:14
To: xcon at ietf.org
Subject: [XCON] Review of draft-ietf-xcon-common-data-model

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/.


_______________________________________________
XCON mailing list
XCON at ietf.org
https://www.ietf.org/mailman/listinfo/xcon