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

From: Oscar Novo <[email-masked]>
Date: Wed, 3 Feb 2010 16:11:10 +0100

Hi Richard,

I'm sorry to reply to your comments so late.

Some comments inline.

Cheers,

Oscar 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: 16. elokuuta 2009 23:14
To: [email-masked]
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.

[ON] I'm sorry I think I don't understand this comment. That's a simple text. What do you mean by 'does not parse'?

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

[ON] Now, it's fixed

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

[ON] The XCON-URI is a top level identifier. It provides a binding with the rest of the conference object identifiers. I think linking the password to the XCON-URI identifier is not a good idea since it creates constraints to the conference. For instance, if later you need to modify the password of the conference you might have to modify the XCON-URI of the conference and in some systems that might not be the best idea. 

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

[ON] I have included a structure to the <language> element following the RFC5646 and the IANA docs. RFC5646 replaces 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.?

[ON] I have added the following text to the definition: "If absent, or set to FALSE, the conference can not create sidebar conferences."

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?

[ON] The Conference media mixing is used to apply all the properties of the conference (the properties defined in the data model), for instance, add some standard algorithms in the conference, add floor control properties, define moderator, etc... I would say, it does not have too much sense to start a conference and later the mixing. 

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?

[ON] Yes, both of the elements are linked together but it's up to the conference policy how they interact in the conference. 

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.

[ON] It refers to the scheduling policy in the media part. The "Automatic" value means the mixer choose the best scheduling policy for the conference. I've tried to clarify that point a bit better in the draft.  

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?

[ON] Those controls are linked to the media stream in the server and they're constraints of how the media is handle in the server part. So, a 'mute' control for a user means that the server stops sending audio to that 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?

[ON] From draft "draft-ietf-mediactrl-mixer-control-package": "The <video-layouts> element describe the video presentation layout configuration for participants providing a video input stream to the conference.  This element allows multiple video layouts to be specified so that the MS automatically changes layout depending on the number of video-enabled participants."

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.

[ON] I've modified the text accordingly

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.

[ON]yep, right. That's a mistake. 

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

[ON] right, now it's fixed

Section 4.6.5.7
s/boolean action/boolean value/

[ON] fixed, thanks

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"?

[ON] I think I don't understand very well the propose of your element <allow-allow-users-dynamically>. If you want to determined who can join the conference there is already an element in the conference for that, <allowed-users-list>. The <allowed-users-list> element is a "dial-in" element too. Another "dial-in" element could be <deny-users-list>.

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

[ON] I have changed that phrase: "The <floor> element refers to the floor assigned to a certain participant in the conference"

Section 8.1
See above comment on Section 4.6.2

[ON] I've modified the text accordingly in this section too.

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

[ON] I've re-written a bit this section and tried to be more specific in this section

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

[ON] I've removed this section and included the information in the authentication section.
_______________________________________________
XCON mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/xcon