Subject: RE: [XCON] Umesh's Comments on draft-ietf-xcon-framework-01.txt

From: "Mary Barnes" <[email-masked]>
Date: Fri, 30 Sep 2005 12:43:45 -0500

Hi Umesh,

Thank you for your detailed review of the document.  Responses are
embedded below [MB].

Mary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, September 12, 2005 3:21 PM
To: [email-masked]
Subject: [XCON] Comments on draft-ietf-xcon-framework-01.txt

Hello,

I reviewed the draft and it looks in a good shape to me, though I felt
some more detailed examples would aid in understanding it more clearly.
My comments besides the blueprint and templates which I sent in the
earlier email are as follows

1) In section 4.2 - is the conference template is used only to describe
the mixer or media related functionality only meaning - the media
controls available to end points to customize the media they receive
from the server, the ability to mute somebody in the conference based on
some privilages etc. 

[MB] I agree this remains a bit confusing.  Did you have an explicit
text change to suggest or is this just in reference to the general
concern folks still seem to have on the format of the data (i.e. DP4)?  

2) Editoral comment. In section 4.2 (3 paragraph) the sentence " This
information would allow authorized clients to manipulate mixer's
behavior and the resultant distribution of the media to all or
individual participants" should be changed to "This information would
allow authorized clients to manipulate mixer's behavior via focus, and
the resultant distribution of the media to all or individual
participants". The present sentence gives an impression that clients can
communicate directly with the mixer to change the media.

[MB] Agreed.

3)  In section 4.3, where are the permission and limits are specified in
the conference object - in the template or in the common conference
information section.

[MB] This relates to general issues that were also raised by other
reviewers (how is the policy realized in this model and the relationship
between template/common conference information/blueprint (DP4 again)?)
and needs further list discussion under a separate thread.   

4) In section 5.3, (2 paragraph) the draft says " The Conference Object
is identified by a single or a set of call signaling Conference
Identifiers, with a one-to-one mapping, as shown in the figure".  Is the
conference object identified by conference identifier (for example the
SIP URL of a SIP conference) or an conference object identifier. ?

[MB] This text needs clarification; it's really trying to describe the
relationship
of the Conference Object to the Confererence Identifier.  The conference
object is 
identified by the conference object identifier.  

5) Editorial comment. There is no definition for conference user
identifier in section 2 (convention and terminology). For consistency
sake it would be good to define it.
[MB] Agreed. 

6) In section 6.1 (page 18), how does the parent object enforce a
different policy by marking certain data elements as "parent
enforceable". Are these markings done in the conference template ?
[MB] I am proposing to add additional text to 6.1 per comments received
from Dave. Once we agree the level of detail on policy in general we
want in this document (per your comment 3 above), we add additional text
to address this concern, as well. 

7) In section 6.2, it would really help if you can provide an example as
to how an conference factory  select one of the system supported
conference object blueprint based on the privileges and media lines in
SDP. It would be good to see an SDP example with audio and video media,
how the blue print would look like to get an clear picture. 
[MB] Or, would it better to just add a new example to section 8 and
reference that here (per my response to your comment 9 below)?   I think
the intent of this section is to provide a good high level view and
"picture" of the objects associated with the system realization, but not
to provide all the details. 

8)  Section 7.3.4 - Do we still leave the section regarding NETCONF as a
possible protocol option ?
[MB] Henning posted the general question as to whether we needed any
discussion of these 
protocols in this document.  Perhaps a compromise is to put this
information in 
an appendix for now and delete it once we ship
it for publication, which should be sooner, rather than later. 

9)  In section 8.1, where an example is provided as to how an
participant is added to the conference using the conference control
protocol, it woul d be a good idea to extend the example depicting how
the new participant "Bob" gets the information from the conference
server as to what type of blueprint is being used for this conference.
Basically from a system point of view it would be good to know how when
a participant joins the conference (when an authorized participant sends
CCP request to add it to the conferene) it gets to know about the
capabilities (conference and media) of the conference. I thought it was
not obvious from the present example in section 8.1

[MB] I think what you're asking for here is yet another example titled
something like "Conference Creation".  Your concerns here are similar to
those raised in point 7 above in that there's not alot of detail around
some of these mechanisms.  Part of the reason for this lack of detail is
that we don't want to be too prescriptive in this logical model that's
presented in section 6 as an example system realization - some of this
crosses over into implementation decisions. But, I do agree that either
we add more detailed text to the examples in 6.2 (and 6.3) or add an
additional "Conference Creation" example in section 8. 

Some Nits and Typos

1) In section 3, page 7 remove the word and from the first line.
[MB] I can't find the specific sentence or paragraph you're referring
to. Did you review the txt or html version?  I have a feeling your
concern may be over the third paragraph and the phrase: " reserved
reoccurring conferences, and the standard protocols for managing and
      controlling different conference aspects."
However, the intent there was that the 2nd to the last "and" is before
the last element of the clause, "the standard protocols" which is
qualified with the phrase "for managing and controlling....".  
I can reword as:
  " reserved reoccurring conferences, the standard protocols for
managing and the
      standard protocols for controlling different conference aspects." 
But, that also seems quite wordy to me.  So, I would propose to leave it
as is. 

2)  In section 6.1 page 18 (4 paragrpah) you have reference to section
5.3.1 describing how an unique conference object URI is assigned. There
is no description of it in section 5.3.1, instead there is an reference
in 5.3.1 to TBD. So I guess instead of refering section 5.3.1 it should
refer to the correct reference.
[MB] I think the point of referring to 5.3.1 is that it does provide
some detail as to the role of the Conference Object Identifier, albeit
not the complete detail. Perhaps to be explicit, we need to say that
it's "discussed in 5.3.1 and defined in the TBD reference". 

3)  In section 8.3 page 35, terminate the line with a full stop. " A
Sidebar is created using the same mechanisms employed for a standard
conference as described in Section 6.1."
[MB] Fixed.  Note, this was on page 36 of my txt version of the doc, but
on page 35 of my printout, thus likely the reason for my confusion about
your first nit above, although I still can't find it. 

BR
Umesh

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

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