From xcon-bounces@ietf.org Wed Sep 05 08:24:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISttk-0007eC-DS; Wed, 05 Sep 2007 08:22:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISttj-0007e7-QA for xcon@ietf.org; Wed, 05 Sep 2007 08:22:19 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IStth-0001a1-QV for xcon@ietf.org; Wed, 05 Sep 2007 08:22:19 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l85CLhhm005022; Wed, 5 Sep 2007 15:22:09 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Sep 2007 15:22:05 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Sep 2007 15:21:51 +0300 Received: from [10.144.23.81] ([10.144.23.81]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Sep 2007 15:21:50 +0300 Message-ID: <46DE9F5E.8060602@nsn.com> Date: Wed, 05 Sep 2007 15:21:50 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: XCON Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Sep 2007 12:21:50.0289 (UTC) FILETIME=[55EB5C10:01C7EFB7] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b4b36b0fb877eeac6f347960137fc10b Cc: Dave Morgan , Roni Even , Gonzalo Camarillo Subject: [XCON] Miguel's Review of the XCON data model X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi: This is my review of the XCON data model Document: draft-ietf-xcon-common-data-model-05.txt Reviewer: Miguel Garcia Review Date: 4 Sep 2007 1) The the scope of the document is not very clear to me. To be precise, I am not totally sure what the model represents. It can be any of: a) The data in a conference that can be manipulated with a conference control protocol. b) All the exhaustive data needed to instantiate a conference, including data manipulated by the conference control protocol, data needed to control a mixer, data needed to provide scheduling, notifications, etc. c) Data needed to provide an extended notification to participants. I think the aim is 'b', but it is not really clear to me. And this is a fundamental question that the document have to answer. I would suggest that whatever is the answer, it is clearly written perhaps in the abstract and the introduction. 2) The document positions itself as an extension to the conference event package (RFC 4575). However, RFC 4575 contains two topics: an event package and a data format for such event package. Since the XCON data model has little (or nothing) to do with the event package, it would be nice to clarify that the XCON data model is an extension to *the data format* specified in RFC 4575. This is visible, for example, in the Abstract: The conference information data model defined in this document is an extension of (and thus, compatible with) the model specified in the Session Initiation Protocol (SIP) Event Package for Conference State. I suggest rewording, such as: The conference information data model defined in this document constitutes an extension of the data format specified in the Session Initiation Protocol (SIP) Event Package for Conference State. Furthermore: RFC 4575 does not use the term "data model", but instead "data format". Please, be precise with the terminology when referring to RFC 4575 (don't refer to the "data model specified in RFC 4575"). 3) On the data model itself. Is there a container for the credentials of the conference? In PSTN conferences these are typically a conference ID number and a PIN. I noticed the element has an attribute 'PIN code', but I am missing the conference ID. On the other side, if you have SIP, these could also be a username/password/realm combination of the conference. I haven't seen these containers, so... am I missing something? 4) Section 1, third paragraph, describes Figure 1 and says: A conference control protocol provides the interface between a conference and media control client, and the conference control server. I am not sure if I can understand the sense of the sentence. Furthermore, I didn't find the "media control client" in Figure 1 or defined elsewhere, so probably this is a leftover from the past 5) Section 1, last paragraph: The data model defined in this document extends the one defined in RFC 4575 [1]. I would say that this document is a "superset" rather than "extends": The data model defined in this document constitutes a superset of the data format defined in RFC 4575 [1]. 6) Figure 1. There are one or more objects called "Conference Object". Each one contains just another object called "Conference Information Data Model". According to the figure, the Conference Object just contains a Conference Information Data model, nothing else, nothing more. This makes me thing that both things are the same. Or, in other words, perhaps the "Conference information data model" should be removed from the figure. Or, if it shouldn't, then you need to describe the relation between both in textual form. 7) Section 3.1 starts with a description of the XML elements of the model. However, it is not mentioned that some of these elements are the same defined in RFC 4575. For example, the text in 3.1 reads: All the information related to a conference is contained in a element. The element contains the following child elements: o The ... Later i the document, it is clearly described that , and other elements are those defined in the data format in RFC 4575. But is not the case here in Section 3.1, which is the main overview. So, please, write it also here. Write a context indicating that some elements are those in RFC 4575 and not invented here, so that the reader knows where he is. Once you have created the contact, you can, for example, use the adjectives "existing" and "new". You can then refer to the "existing element" and a "new element". 8) I miss a motivation for the existence of roles at the beginning of Section 3.2 9) Section 3.2, second paragraph, defines several roles. I guess you want to say that a "participant" is the role that provides the user with the privilege to send and receive most of the media streams. Similarly, and "observer" is the role that provides the user with the privilege to receive, but not to send, media. If this is correct, I like these definitions above those in the document. Also note that unlike the document say, these are not _logical entities_, but *roles* 10) Section 3.2, last paragraph. The normative "SHOULD" and "MAY" have no impact in interoperability. So this makes me thing that they aren't normative. Proposal: If no roles are defined for an entity, they should default to "participant" but local policy can define an alternative. 11) Section 4, the paragraph above Figure 2: it mentions the XCON-URI without a reference to where it is defined. Then I saw it in the IANA considerations section, so THIS might be the canonical document that defines it. So, I think the XCON URI deserves a section by itself, describing the semantics, syntax, etc. 12) Section 4.1, 1st paragraph: Why is there a normative SHOULD in: It SHOULD have an extra attribute 'xml:lang' to specify the language used in the contents of this element as defined in Section 2.12 of [8]. I think it's nice to see the 'lang' attribute, but honestly, the lack of it is not going to create an interoperability problem, so I consider the SHOULD as a should. 13) Section 4.1, reads: The child element describes the capabilities of the conference. I don't think describes any general capabilities of the conference. 14) Section 4.1.1: The second paragraph refers to DTSEND and DTSART fields without describing what are those. Then later I understood they are iCal fields. So please, say it and add a reference to the iCal spec. 15) Section 4.1.1, second paragraph. The element is mixing two semantics: one one side, it indicates whether mixing starts according to either a specified time or when a participant with a role joins. I think it would much clear to create three elements instead: one is a , which can take the values "by-time", "by-joining-role", or "at-first-join". Another would be the existing , which would be restricted to indicating a time, and only available when takes the value "by-time". A third one is which would take the values "participant", "moderator", "administrator", and is only available is takes the value "by-joining-role". 16) First paragraph in Section 4.1.5. The text reads: The 'name' attribute identifies a codec, and the 'decision' attribute contains the policy for that codec (allowed, or disallowed). I suspect you cannot write a free text in the 'name' attribute. Most probably you want to say that the list of possible codecs is controlled by some IANA registry. I suspect that you are looking at the 'encoding name' column in the IANA registry for RTP Payload Types, http://www.iana.org/assignments/rtp-parameters Most likely you also have to take into account the 'subtype' column of the RTP Payload Format media types per [RFC4855] available in the same IANA web page. 17) Section 4.1.5, last paragraph describes the attribute. I am sorry to say, but it was hard to understand what this is. I still have my doubts. So... for example, in an audio stream. In a conference with 50 participants, if takes the value 3, which 3 input streams are input to the output stream? Similarly, in a video stream. If takes the value 5, then how does this affect the output stream and which 5 input streams are selected? 18) Same section 4.1.5 last paragraph. The text reads: The child element MUST contain one and only one of the "Moderator-controlled", "FCFS", and "Automatic" values indicating the default algorithm to be use with every media stream. Can you please describe the semantics of these values? Since I understand (a bit of) English, I more or less can figure out what you mean. But think for a while if these identifiers would be just called id1, id2, and id3 and try to explain them. 19) Section 4.1.5.1.1 defines the element and Section 4.1.5.1.2 defines the element. I think these two are very similar, the only difference being that the former applies to audio streams, the latter to video streams. I would like to see a single element, perhaps called or something like that. This could apply for any kind of media stream, even for MSRP. 20) Section 4.1.5.1.3 defines the element. I am missing attributes that defines the minimum and maximum levels. Without it, if I get that the mixing level is 10, I have now idea if it is 10 in a scale 1-10, 10 in a scale 1-100, or 10 in a scale 1-1000. Further more, without the maximum/minimum level, it wouldn't be possible to create a UI scale representation, making the control totally useless. 21) Section 4.1.5.1.4 defines the element. One possible value is 'multiple-5x1', where "one panel will occupy 4/9 of the mixed video stream while the others will each occupy 1/9 of the stream". My question is: how to select the input video stream that will go into the big panel? And how to select each of the other video streams, if you have, say, 20 input video streams? The same is applicable for any video/audio stream where there more inputs than possible outputs. And how does this element interact with the element? It seems that the indicates a pure maximum number of inputs, where I think it is irrelevant when you have a element. For example, what is the meaning of having both: automatic automatic 22) More on Section 4.1.5.1.4. The last paragraph defines the 'automatic' value as: automatic: This option allows the focus to add panels as streams are added up to a limit of "panels". What is this 'limit of "panels"'? Is it a local policy? In either case, I think there should be means to configure this maximum number of panels, so I am missing a "max-panels" attribute or something like that. 23) Section 4.4, first paragraph describes the element and says: This element has its own XML namespace. What is this own XML namespace. Which one is it? Where is specified? Why none of the examples show any namespace? 24) Section 4.4, second paragraph tries (but fails) to define the element: The is used by a floor control server to provide a client with a conference ID. The text says how is this used, but doesn't say what it is and how it differentiates from the other zillions conference identifiers we already have. So please first explain what is this element, how is it different from other similar ones, and then you keep the explanation of how it is used (which I haven't understood so far). 25) Section 4.4, 5th paragraph reads: Note that placing a value of "block" for this element does not guarantee that a participant is blocked from joining the conference. Although the spirit of the text is to avoid misleading the user, it just got the opposite effect. I am aware we are discussing floor control issues, so bringing here the concept of joining a conference created a restart in my mind. I would suggest to either delete or rephrase it better: Note that this section discusses floor control information, therefore, the value "block" in a element is not related with the "block" value in the element (see Section 4.5). 26) Same paragraph in Section 4.4 reads: Any other rule that might evaluate to TRUE for this participant that carried an action whose value was higher than "block" would automatically grant confirm/allow permission to that participant. First, the text seems to imply that there are some precedence order between several values, but does not say which are those values. If such precedence order exists, it probably needs to be specified, otherwise, users will have unexpected behaviors depending on the manufacturer of the conference server. Second. Is the paragraph true? Can you give an example of "other rule that might evaluate to TRUE for this participant" that would grant confirm permission instead of block? Third: Which participant this rule applies? I didn't find an element to specify participants in , so I don't understand anything. 27) Section 4.4, 6th paragraph: The text reads: The element is mandatory and contains the required boolean attribute that indicates if the floor is moderator controlled or not. Please mention the name of the attribute, which I believe is 'moderator-controlled' Second and more important thing: I think the schema makes 'moderator-controlled' an attribute of , not an attribute of as the text suggest. 28) Same section and topic: I noticed that 'moderator-controlled' can be either an attribute of or a value in the element. I would suggest to rename one to avoid collisions between attributes and values of elements. 29) Same section 4.4, still 6th paragraph: Every floor is defined using the 'label' attribute. I would say that floors are not _defined_, but _identified_, using the 'label' attribute. Also, the schema says 'label' is mandatory, so say it: Every floor is identified by the mandatory 'label' attribute. 30) Same section 4.4, still 6th paragraph: A floor can be used for one or more media types; the mandatory element can contain zero or more of the