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

From: "Oscar Novo" <[email-masked]>
Date: Fri, 6 Jun 2008 10:20:53 +0200

Hi Mary,

Thanks for your comments. Inline you have my answer as a [ON] 

Cheers,

Oscar

------------------------------------------------------------------------
-------------------------------------------------------------

I have reviewed the diff of the -10 against the last version I reviewed
in detail (-08) and have just one general question,  a few comments and
one nit. Overall, I think the document is ready to progress.

Regards,
Mary.   

Question:
----------
I did have one general question as to whether this version incorporates
the additional media fields that were identified by the MEDIACTRL folks?

[ON] I discussed privately with Scott McGlashan about these changes in
the last IETF. This fields were identified and I sent to the mailing
list the decision to get consensus. You can check from the XCON archives
my email sent it on 28 Mar 2008.  

Comments:
---------

S4 and S5: While working on the details for the protocol, I realized we
need a couple more elements added to <conference-description> including
an element to reflect if this conference is a "parent" and/or a "child"
and the "parent" of a "child" conference and the "child"ren of the
"parent" conferences  and whether the "child" is "independent" from the
"parent".   I think we can do that by defining the following:  
- "parent" element that can hold the XCON-URI for the parent and a
boolean as to whether the child is "independent" of the parent. 
- "child" attribute that contains a set of XCON-URIs, one for each child
obviously. 

[ON] I think to add elements for the protocol is to act rashly at this
moment. The protocol is under discussion and still is too early to take
thing for granted. I would recommend to extend the data model if it's
needed later on in a more stable phase. Note, as well, the sidebars
elements define the subconferences in a conference.

S4.1/p13, 3rd sentence. For some reason, it is no longer clear to me why
we wouldn't want "state" and "version" as part of the <conference-info>,
as XCON will also support notifications, if I understand this sentence
correctly:
   "Note that the
   <conference-info> element does not have the attributes 'state' and
   'version' defined in [RFC4575] for this element because these
   attributes only applies to notification mechanisms."
   (also note the NIT in that sentence below)

[ON] The data model only defines the information in the conference.
However, RFC 4575 not only define the information in a conference but
the elements used in the notification mechanism as well. The "state" and
"version" elements are used for notifications, consequently, they are
not defined as part of the conference information in the data model.   

S.4.6.5/p24, 3rd sentence. Same point as above wrt "state". 
   
[ON] Ditto

Nits:
-----

S4.1/p13, 3rd sentence: "applies" -> "apply" 

[ON] Thanks, I'll fix that typo. 
_______________________________________________
XCON mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/xcon

---

From: "Oscar Novo" <[email-masked]>
Date: Fri, 6 Jun 2008 10:20:26 +0200

Hi guys,
 
Thank you very much for you comments and sorry for my late reply. I've
been on holidays all this time. Comments inline as [ON]
 
Cheers,
 
Oscar

________________________________

From: Connolly, Stephen (Stephen) [mailto:[email-masked]] 
Sent: 16. toukokuuta 2008 18:20
To: XCON-IETF
Cc: [email-masked]; Johnston, Alan B
(Alan)
Subject: Re: [XCON] WGLC: draft-ietf-xcon-common-data-model-10.txt

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?
 
[ON] The data model is extensible. Proprietary elements can be added in
future extensions. Check section 6 of the draft.

pg14, S4.2.1 
*    this assumes only a specific language is available, what about
country variants and fallback e.g. en, en_gb 
 
[ON] The language datatype accepts strings that are conforming with
RFC3066bis and RFC4646 and these drafts accepts country variants and
many other possibilities. I recommend you to check these RFC. 
 
pg 15, S4.2.6 
*    Does this imply a default of false if not specified ?  
 
[ON] This is up to local policy.
 
 What about size of sidebars, number of sidebars 
 
[ON] We decided to leave this information out of the data model. Always
is possible to add it in some extensions.
 
pg 15, S4.2.7 
*    Does their need to be anything about demand / scheduled / adhoc
(tui) 
 
[ON] Possible to add it in some extensions if you need it.
 
*    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? 
 
[ON] The data model only defines the information in a conference. How to
handle this information is up to every implementor.
 
*    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. 
 
[ON] I recommend you to check RFC 2445. 
 
*    required-participant attribute under mixing-start-offset has no
apparent definitions of the various roles 
 
[ON] The definitions of the roles is out of scope of this document.
 
*    can-join-after-offset doesn't mention DTSTART and signed integer 
 
[ON] It's similar to <must-join-before-offset> but I'll add it to make
it clear. 
 
*    allowed-extend-mixing-end-offset has no apparent limits on size,
duration , number of extension periods 
 
[ON] it's open to future extensions
 
*    Would there be a requirement for accessing current time and tz on
server. How would one handle a distributed / dispersed server
deployment?
 
[ON] this is out of scope of this document. 
 
*    In the Schema, the *-offset elements are dates, while in this
section they are described as integer offsets 
 
[ON] I'll fix that in the text.  
 
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
 
[ON] We already discussed that in IETF-69 and the WG consensus was to
have one element type. 
 
*    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? 
 
[ON] I'll extend the schema to accept this case. 
 
pg17, S4.2.10
*    would S4.2.10 depend on S4.2.11, and is there a way to capture that
dependency 
 
[ON] up to the implementor. 
 
*    Does this maximum user count refer to the maximum users supported
by the media mixing servers, or the limit for the conference?
 
[ON] The maximum users allowed to join the conference. 
 
*    Is there any way to indicate that the maximum-user-count can be
increased on demand if necessary? 
 
[ON] not now but you could extend it later. 
 
pg 18, S4.2.11 
*    No mention of data, whileboarding. Need a way to indicate
bandwidth, preferred audio / image formats. 
 
[ON] the data model only defined basic media: audio and video. 
 
*    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.
 
[ON] this element only describes the cease of audio but it does not
differentiate who has the right to applied or remove it. 
 
*    How can other controls be exposed?   
 
pg19, S4.3 
*    Failover scenario - tcp-ip possibly changes 
 
[ON] I don't understand what's the problem here 
 
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 
 
[ON] check the <locked> and <active> elements, section 4.4.3 and 4.4.4
 
pg 22, S4.6 
*    Presumably user can have multiple roles simultaneously.  
 
[ON] are you talking about 4.6.5.4 section? Section 4.6 doesn't defined
any role. 
 
pg23, S4.6.3 
*    No definition of roles, format of uris 
 
[ON] i'll add them in the text.
 
pg 24, S4.6.4 
*    No definition of roles, format of uris 
 
[ON] idem 
 
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 
 
[ON] up to the implementor.
 
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.
 
[ON] check RFC4582 for this questions.
 
pg28, S4.6.5.10 
*    Data, whiteboarding in the from mixer element 
 
[ON] the data model only defined basic media: audio and video. 
 
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 
 
[ON] One schema is generated using the other. That's a WG consensus to
make it more understandable for the reader. The possibility of
synchronization errors are minimal.

pg29, conference-description-type
*    Extend to allow multiple conference-password child elements 
 
[ON]  I'll add this in the schema.
 
pg33, Conference-floor-policy
*    Should begin with a "c" not a "C" 
 
[ON] It's only a tag element in the schema but I can modify it.

*    Need the ability to have multiple moderator-id's controlling the
floor.
 
[ON] I can add this in the schema.
_______________________________________________
XCON mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/xcon