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

["Oscar Novo" <oscar.novo at ericsson.com>]

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 IEFrom xcon-bounces at ietf.org  Fri Jun  6 01:20:49 2008
Return-Path: <xcon-bounces at ietf.org>
X-Original-To: xcon-archive at megatron.ietf.org
Delivered-To: ietfarch-xcon-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id B76353A6AB4;
	Fri,  6 Jun 2008 01:20:49 -0700 (PDT)
X-Original-To: xcon at core3.amsl.com
Delivered-To: xcon at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id EC80E28C1B1
	for <xcon at core3.amsl.com>; Fri,  6 Jun 2008 01:20:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, 
	BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id VZzC1GfXSUQV for <xcon at core3.amsl.com>;
	Fri,  6 Jun 2008 01:20:47 -0700 (PDT)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62])
	by core3.amsl.com (Postfix) with ESMTP id AF4C23A6AB4
	for <xcon at ietf.org>; Fri,  6 Jun 2008 01:20:46 -0700 (PDT)
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	5E9BC214DE; Fri,  6 Jun 2008 10:20:54 +0200 (CEST)
X-AuditID: c1b4fb3e-af99bbb000004ec0-58-4848f3669b6f
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	37CB420986; Fri,  6 Jun 2008 10:20:54 +0200 (CEST)
Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 6 Jun 2008 10:20:53 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 6 Jun 2008 10:20:53 +0200
Message-ID: <A91F30A632473A47B40C18D2B107CA6F05C14632 at esealmw105.eemea.ericsson.se>
In-Reply-To: <F66D7286825402429571678A16C2F5EE037B9207 at zrc2hxm1.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [XCON] WGLC: draft-ietf-xcon-common-data-model-10.txt
Thread-Index: Aci1KcI/CJ5VIqPmSRmB0qP6hcoP8ABkoLKgBBEutKA=
References: <48188FC8.4080909 at nostrum.com> <4829E1DE.8000307 at nostrum.com>
	<F66D7286825402429571678A16C2F5EE037B9207 at zrc2hxm1.corp.nortel.com>
From: "Oscar Novo" <oscar.novo at ericsson.com>
To: "Mary Barnes" <mary.barnes at nortel.com>,
	"XCON-IETF" <xcon at ietf.org>
X-OriginalArrivalTime: 06 Jun 2008 08:20:53.0820 (UTC)
	FILETIME=[3CCA7FC0:01C8C7AE]
X-Brightmail-Tracker: AAAAAA==
Cc: draft-ietf-xcon-common-data-model at tools.ietf.org
Subject: Re: [XCON] WGLC: draft-ietf-xcon-common-data-model-10.txt
X-BeenThere: xcon at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/xcon>
List-Post: <mailto:xcon at ietf.org>
List-Help: <mailto:xcon-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xcon-bounces at ietf.org
Errors-To: xcon-bounces at ietf.org

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. ThisTF. 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
XCON at ietf.org
https://www.ietf.org/mailman/listinfo/xcon


 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
XCON at ietf.org
https://www.ietf.org/mailman/listinfo/xcon