Subject: [XCON] WGLC: draft-ietf-xcon-common-data-model-10.txt

From: "Connolly, Stephen (Stephen)" <[email-masked]>
Date: Thu, 15 May 2008 17:05:27 +0100

Hi,
 
A group of us here at Avaya have a number of comments (with our "Avaya"
hats on) in relation to gaps between this proposed data model and the
Avaya MeetingExchange conferencing application.
 
We are in the process of consolidating our issues and had hoped to have
a response by now.  However, at this stage it looks likely to be
tomorrow before we can get our comments consolidated.
 
I hope tomorrow's late response will be acceptable.
 
-Stephen
_______________________________________________
XCON mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/xcon

---

From: "Connolly, Stephen (Stephen)" <[email-masked]>
Date: Fri, 16 May 2008 16:19:49 +0100

All,
 
Here are our consolidated comments while wearing our "Avaya" hats.
 
pg13, Figure 3 & pg 14, S4.2
*    Where do generic / proprietary conference attributes fit in e.g.
pin-list, recording, billing, call flow type , biometric , data, video ,
annunicator msgs?

pg14, S4.2.1 
*    this assumes only a specific language is available, what about
country variants and fallback e.g. en, en_gb
 
pg 15, S4.2.6 
*    Does this imply a default of false if not specified ? What about
size of sidebars, number of sidebars
 
pg 15, S4.2.7 
*    Does their need to be anything about demand / scheduled / adhoc
(tui)
 
*    Mandate all date times in UTC. It's up to a client application to
convert to / from local time as appropriate. How to handle timezones and
variation in dst rules or is this a problem for the OS and main
userspace runtime library?
 
*    Should there be a way of linking via a uri to the ical object the
base element under conference-time\entry. 
 
*    I'm not familiar enough with ical rfc, but can it specify perpetual
conferences, recurring series with odd exceptions ? Tz / dst changes
that are outside normal rules due to political changes.
 
*    required-participant attribute under mixing-start-offset has no
apparent definitions of the various roles
 
*    can-join-after-offset doesn't mention DTSTART and signed integer
 
*    allowed-extend-mixing-end-offset has no apparent limits on size,
duration , number of extension periods
 
*    Would there be a requirement for accessing current time and tz on
server. How would one handle a distributed / dispersed server
deployment?
 
*    In the Schema, the *-offset elements are dates, while in this
section they are described as integer offsets
 
pg 16, S4.2.8 
*    Must be able to repesent multiple access numbers to same logical
conference e.g. international, toll free, local access for PSTN users.
Howto represent a conference which spans multiple dispersed bridges
 
*    There is only one <conference-password> element.  We have at least
two levels of password and can have multiple passwords for the same
level. How would this be represented?
 
pg17, S4.2.10
*    would S4.2.10 depend on S4.2.11, and is there a way to capture that
dependency
 
*    Does this maximum user count refer to the maximum users supported
by the media mixing servers, or the limit for the conference?
 
*    Is there any way to indicate that the maximum-user-count can be
increased on demand if necessary?
 
pg 18, S4.2.11 
*    No mention of data, whileboarding. Need a way to indicate
bandwidth, preferred audio / image formats.
 
*    What type of <mute> does <mute> provide.  We differentiate two
types of mute: "mute" is a mute that can be applied by a moderator or by
yourself.  It can only be removed by yourself. "silence" is a mute that
can only be applied or removed by a moderator.
 
*    How can other controls be exposed? 
 
pg19, S4.3 
*    Failover scenario - tcp-ip possibly changes
 
pg 19, S4.4 
*    Is this data model only concerned with runtime info? If not need a
way to indicate cancelled, billed, aborted, confirmed and possibly other
states
 
pg 22, S4.6 
*    Presumably user can have multiple roles simultaneously. 
 
pg23, S4.6.3 
*    No definition of roles, format of uris
 
pg 24, S4.6.4 
*    No definition of roles, format of uris
 
pg 24, S4.5.0
*    How are user PINs represented, i.e. the number unique to each user
that allows them to identify themselves via the TUI after entering the
conference password
 
pg 27, S4.6.5.10
*    Can multiple users hold the floor in the same floor at the same
time? Can a user hold multiple floors at the same time? An example of
these would be good.
 
pg28, S4.6.5.10 
*    Data, whiteboarding in the from mixer element
 
pg28, S5 
*    This section duplicates Appendix A., shouldn't the schema be
defined in one location only in order to reduce the posibility of
synchronization errors
 
pg29, conference-description-type
*    Extend to allow multiple conference-password child elements
 
pg33, Conference-floor-policy
*    Should begin with a "c" not a "C"
 
*    Need the ability to have multiple moderator-id's controlling the
floor.