Subject: FW: [XCON] Comments on draft-ietf-xcon-common-data-model-05

From: "Oscar Novo" <[email-masked]>
Date: Fri, 12 Oct 2007 12:43:42 +0200

Hello Ben,

Thanks for your review. Comments are embedded as [ON et al].

Cheers,

Oscar

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: 7. syyskuuta 2007 1:41
To: XCON-IETF
Cc: [email-masked]; [email-masked]; Oscar Novo (JO/LMF);
Gonzalo Camarillo (JO/LMF)
Subject: [XCON] Comments on draft-ietf-xcon-common-data-model-05

Hi,

Here are my comments on draft-ietf-xcon-common-data-model-05. They are
mostly editorial in nature.

Thanks!

Ben.

---------

General:

I share Gonzalo's comment about the scope of the data model being
unclear. In particular, is it the goal of this document to define how
the contents of a conference object affect behavior of various devices?
If so, then there is a notable lack of normative language to that effect
throughout the document.

[ON et al] We'll modify the introduction of the document to make the
scope of the data model more clear. 

Many element types can be used  in different contexts (i.e. as children
of different parents), and if I understand correctly, their meaning may
be different depending on the context in which they are used. I
personally don't feel like I fully understand all of these after
multiple detailed reads of the document. It might help to have more
examples. Rather than whole documents, it might be useful to put in
document fragment examples illustrating specific usages.

Section 4 is inconsistent in how it presents elements. In some cases, an
element and its children are all defined in the same section. In others,
there is a section for each. Furthermore, it requires some reading
between the lines to understand when this document is defining an
element vs. incorporating an element defined elsewhere.
  
This is explicit in some cases, but not consistent. My personal
preference would be to give each element its own section, and use a
common list-oriented format for things like contexts, potential
children, where the element is defined, cardinality, etc. But the
important thing is consistency.

[ON et al] In the next section we'll try to re-structure the whole
document again giving a section to the element of the schema and lists
to the context of this elements. Doing that, we expect the document to
be more clear for the reader. If after re-structuring the document still
is not clear enough, we will try to put more examples in the document.

Specific comments:

Section 3.2 Paragraph 2:

Why do we need normative statements about what privileges should be
associated with each role?

[ON et al] We have thought to removed the roles section because of the
confusion created to many reviewers. The roles section is not an
important part of the document and can be described in the policy draft
in the future.

Section 4 Paragraph 1:

I assume a conference object document and a conference object data model
document are the same thing? It would be helpful to be consistent with
the terminology.

[ON et al] yes, they are the same. We'll change the name of "conference
object data model" for "conference object".

Paragraph 2:

Need a reference for the definition of XCON-URI

[ON et al] XCON-URI is defined in the data model document. We'll create
a section defining the XCON-URI in the next version. 

Paragraph 5:

(Personal pet peeve nit) I find constructs of the form "...defined in
[1]" difficult to follow. The construct "... defined in RFC XXXX[1]"  
is better. This is partly to save the reader from constant flipping back
to the end-notes. But in general the end-note reference is
parenthetical, and the sentence should still make sense if the reference
is completely removed.

[ON et al] We'll do that.

Diagram:
Is it possible to give this a referenceable "figure" number? Also, it
would be helpful if the diagram could show cardinality somehow.

[ON et al] we'll give a figure number to the diagram. TO give a
cardinality is going to be more complicated.

Section 4.1: Paragraph 1.

The section gives brief descriptions of each child elements, but the
real descriptions occur in the following sections. It would be better to
just mention the child elements by name, and refer to the sections for
each. Repeating the same info twice is likely to create inconsistencies
as the document evolves.

[ON et al] we'll fix that in the next version.

4.1.1

This is an example of a section that defines child elements in the same
section as its parents. I personally think this would be easier for
readers if each element got its own section. But in any case, it should
be consistent from section to section.

[ON et al] we'll do that.

4.1.5.1 Paragraph 1:

What does it mean for an element to contain controls? How is the element
actually used? Assuming this is described elsewhere, can we put in a
reference to that description

[ON et al] when we say 'controls', we refer to 'controls elements'. In
next version we'll try to put this in the text more clear. 

4.1.5.1.4.

Entire Section:

I find it naive to believe we can specify all useful or likely layouts
in advance. Wouldn't it make more sense to describe these in terms of
what the focus has to do rather than how a client displays things? (I
don't mean to question wg concensus if this has already been discussed
to death)

[ON et al] yes, we try to reflect the wg consensus but it's possible to
discuss again the layout element in the wg if it's not very clear
enough. 

Paragraph 2:

I find no reference to a <layout> element elsewhere. Should this be
<video-layout>

[ON et al] yes, that's a typo.

4.5

I am really confused on how all the <users> sub-elements fit together.
For example, what would it mean to have <join- 
handling>allow</join-handling>, an <allowed-users-list>, and a <user>
element in the same <users> parent? Some more example scenarios would
help.

[ON et al] This is explained in a bit more detail in RFC 4575. That's
why we try don't repeat again the same thing in the data model. Readers
should read first RFC 4575 before to read the data model.

5:

I am not familiar with RELAX NG. Hopefully an expert in this is
reviewing the document?

7. Example

<conf-uris> contains a child element of <SIP>. The text said that we
reuse <entries> for SIP URIs in this context for backwards compatibility
with the SIP conference model.

Same for <host-info>.

[ON et al] yes, that's another typo.

8. Security Considerations

This section seems rather lightweight. The text motivates why we care
about authentication, but does not provide motivation for
confidentiality and integrity. I suspect a discussion of possible
privacy issues may be in order. Also, I assume these documents may be
stored and cached, as well as transferred, so some considerations about
whether it is okay to just leave them laying around might be worth
having.

[ON et al] we'll provide in the next version a confidentiality and
integrity section. 

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

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

---

From: "Oscar Novo" <[email-masked]>
Date: Fri, 12 Oct 2007 12:43:55 +0200

Hi Srivatsa,

Thanks for your review of the document. Comments inline as [ON et al].

Cheers!

Oscar

-----Original Message-----
From: Srivatsa Srinivasan [mailto:[email-masked]] 
Sent: 7. syyskuuta 2007 8:28
To: XCON-IETF
Cc: [email-masked]; [email-masked]; Oscar Novo (JO/LMF);
Gonzalo Camarillo (JO/LMF)
Subject: Comments on draft-ietf-xcon-common-data-model-05

Hi,

Here are the review comments for the data model. Some of the comments
are from an older review and I have repeated them for completeness.

Regards,
Srivatsa.

An overall comment is that the document needs to describe in text those
elements that are new and should not re-define elements that were
previously described in RFC 4575. 

[ON et al] This is a bit problematic in RELAX NG because RFC 4575 does
not have an informative RNG schema. We could not re-define these
elements but from real validation pov this is worse. 

This needs to be changed throughout the document. Also, sections of the
text that describe XML elements should be very explicit about whether
this is optional or not.  

[ON et al] Some people has complained about that. We'll try to change it
in next version. 

Furthermore, you should be very explicit about which elements have a
state attribute defined now (this is missing in various places, like
<media> and <controls> and <from-mixer>, <to-mixer>). The RELAX-NG
schema is also missing this in one location.

[ON et al] The state attribute should be defined in the notification
packages but not in the data model. This attribute indicates the amount
of information the user receives from the data model. 

Section 3

"   The data model defined in this document is the result of extending
   the data model defined in RFC 4575 [1] with new elements, which carry
   information such as non-SIP URIs or floor-control-related
parameters."

[SS] Suggest rewording -- "The data model specified here includes
extensions to the schema defined in RFC 4575. Examples of such
extensions include scheduling elements, media control elements, floor
control elements, some conference policy elements and addition of
localization extensions to text elements."

[ON et al] In the text we would like to state that this schema accepts
non-SIP URIs. As well, other reviewers have some comments about this
paragraph. What do you think if we reword that sentence as followed?:

"The data model specified in this document is the result of extending
the data format defined in RFC 4575 <xref target="RFC4575"/> with new
elements. Examples of such extensions include cheduling elements, media
control elements, floor control elements, non-SIP URIs, and addition of
localization extensions to text elements."

[SS] Also, a reminder that the root namespace used in this document is
"urn:ietf:params:xml:ns:conference-schema" as opposed to what RFC 4575
uses ("urn:ietf:params:xml:ns:conference-info"). Needs fixing. Also,
suggest renaming the extension namespace (where the new XML elements are
defined in this document) to "
urn:ietf:params:xml:ns:xcon-conference-info" instead of
"urn:ietf:params:xml:ns:conference-schema". Or at least something to
indicate that this is something completely different from
conference-info.

[ON et al] We'll create a new section in the overview explaining the new
namespace. We'll change the conference-schema namespace for
xcon-conference-info 

[SS] Suggest removing "This data model can be used by conference servers
providing different   types of basic conferences."

[ON et al] before to remove it, could you please explain why do you want
to remove that part? Is it not enough clear? Does it create confusion?

Section 3.1

[SS] This section has text that is already covered in RFC 4575. Why is
it needed?

[ON et al] we describe them again because they are part of the structure
of the data model. You're right and in the next version we'll explain
why we repeat that information in the data model again.

Section 3.2

[SS] It is not clear how the definitions are extensible as defined.
Also, it is not clear what a conferencing client should do when the
conferencing system does not support a certain role. Also, how does the
client learn that a conferencing client does not support that role? It
may be useful to have text that redirects some of these answers to an
external inter-op Spec(T) in-order to clearly delineate areas of the
document that were intentionally left open.

"If no
   roles are defined for an entity, they SHOULD by default be a
   "participant" but local policy MAY define an alternative."

[ON et al] Other people has complained about the roles definitions.
That's why we have decided to remove them from the data model.

[SS] A better way to put this is "If no roles are defined for an entity
or the conferencing system cannot grant the requested role, it SHOULD
default to the role of a "participant" but local policy MAY define an
alternative."

Section 3.2.1

[SS] Not clear if <floor> is optional or not.

[ON et al] Apply previous comment. 

Section 3.2.2

[SS] Eliminate this section; should be in the conference protocol
document, if at all anywhere.

[ON et al] We'll do it.

Section 4

[SS] Not clear again, if a conferencing system MUST implement/support
XCON-URI's.

[ON et al] We'll create a new section explaining the XCON-URI.

Section 4.1.2 and Section 4.1.3

[SS] Same comment as in Chicago -- not convinced of the use of <H.323>
and <PSTN-ISDN> elements.

[ON et al] After the discussion in Chicago, we'll change that part
accordingly. 
 
Section 4.1.5

[SS] I am repeating some of my comments from an earlier email regarding
mixing mode and mix level. This is an inter-op nightmare, unless
specified normatively. Is this still required even after the
<video-layout> element was added?

[ON et al] we have removed the <mix-level> element from the schema. As
you said, it was not very clear its functionality. 

[SS] Mixing mode is a very specific implementation detail of mixing.
What does it mean to define a mixing-mode for every stream -- is this
mode applied to the incoming stream to or the outgoing ones from the
mixer?

[ON et al] to the outgoing ones to the mixer. 

 And why would a conference participant (organizer or moderator or
attendee) be interested in choosing one over the other?

[ON et al] well, there is a bunch of uses cases where the organizer
would be interested to control the mixing mode, for instance, if we want
to cease the transmission of media to some of the participants instead
of all the participants. 

[SS] Also, for layouts, an enumeration of specific layout string
identifiers with localized description strings for each layout will be
more useful than just an integer aka mix-level. Note that this can be
clubbed or rather replaced with a <control> element for layouts. Also, a
specific mixer output stream may only support one layout. A client
capable of receiving multiple streams may receive more than one stream,
each with different layouts or multiple streams each with the same
layout. For example, a mixer may output two streams each capable of only
a single layout (fixed layouts by the mixer) -- the main video with
active speaker and another stream (or multiple streams) of a proprietary
mix (like enhanced video from a conference room).

[ON et al] The purpose in the definition of the controls was to define
and covert the very basic use cases, for more complicate use cases it's
possible to extend the schema in the future.  

Section 4.1.5.1.1, 4.1.5.1.2, 4.1.5.1.3, 4.1.5.1.4

[SS] Overall comment: Suggest rewording by reusing some of the text from
the media usages draft or pointing to it.

[ON et al] We'll rewrote a bit this part to make it more clear

"In the
   <controls> element the schema is extensible, hence new control types
   can be added in the future.  Similarly, controls that apply to a
   specific user would appear under the <users>/<user>/<endpoint>
   element.  So moderator controls that affect all media output would go
   under the <available-media> element."

[SS] Remove the sentence starting with "Similarly" in the above
paragraph. Define it separately under <users> definition.

[ON et al] We will remove it from here and put it in the place it
belongs.

"If this control is not specified, access to the control is not
   available to the client and media SHOULD NOT be transported for the
   associated media stream."

[SS] Avoid repeating, if possible. Just point out similarities in the
controls.

[ON et al] we will remove the redundancy in this text.

"The 'video-layout' control is used in conjunction with a video stream
   to specify how the video streams (participants) are viewed by each
   participant."

[SS] This section needs to specify how this is extensible. Also, specify
whether a conferencing system should implement these? Or are they
completely optional?

[ON et al] We don't think the data model should specify how the system
should implement the controls. That's not the scope of the data model
and this is up to implementors decisions.

Section 4.2

"The <uris> child element contains a
   sequence of child elements: <entry>, <H.323>, and <PSTN-ISDN>."

[SS] Remove text.

[ON et al] OK

Section 3.7.1

" The
   'method' attribute is a list with the following values: "dial-in",
   "dial-out, and "refer".  The value "dial-in" is used by the focus to
   determine who can join the conference.  Value "refer" is used by the
   focus to determine the resources that the focus needs to "refer to"
   the conference."

[SS] Unclear why a conferencing system would want to let the conference
organizer describe "how" a conference participant joins? This is up-to
local implementation. 

[ON et al] In the IETF-60 XCON meeting, we agreed that a separate refer
list is needed, mainly because the list is not a list of users that the
focus invites to join the conference (dial-out list).

This is up-to local implementation. If a specific participant has a
value of 'dial-in' but is later dialed-out, what does that mean?

[ON et al] This is up to local policy.

4.5.2.1.  <from-mixer>, <to-mixer>

[SS] Suggest rewording section.

   "This section specifies controls that apply to a user's media stream
being sent from the mixer to the participants endpoint or to the mixer
from the participants endpoint. The <to-mixer> element details
properties associated with the streams sent to the mixer (from the
participant).
   The <from-mixer> element details properties associated with the
streams sent from the
   mixer (to the participant).  Both of these elements have the
attribute 'name'.  "

[ON et al] What do you think if we reword it as follow?

"This section specifies controls that apply to a user's media stream
being sent from the mixer to the participants endpoint or to the mixer
from the participants endpoint. The <to-mixer> element details
properties associated with the incoming streams to the mixer (streams
sent to the mixer from the participant). The <from-mixer> element
details properties associated with the outgoing streams from the mixer
(sent from the mixer to the participant). Both of these elements have
the attribute 'name'. "

4.5.3.  <sidebars-by-ref> and
4.5.4.  <sidebars-by-val>

[SS] These sections are not required (defined in RFC 4575) remove them
unless there are some specific extensions defined here.

[ON et al] we'll prefer to keep them for a matter of clarity but we'll
explain better that they are defined in RFC 4575

[SS] As an end disclaimer, I have not checked the RELAX-NG schema or the
examples.