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

From: "Mary Barnes" <[email-masked]>
Date: Thu, 29 Sep 2005 17:35:01 -0500

Dave,
 
Thanks for your eagle-eye review.  Responses embedded below [MB] as to
how I'm incorporating your suggestions into the 
-02 version. 
 
Mary 

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Morgan, Dave
	Sent: Tuesday, July 26, 2005 3:54 PM
	To: [email-masked]
	Subject: [XCON] Comments on draft-ietf-xcon-framework-01.txt

	Mary, Chris, and Orit: 

	The framework-01 doc seems to be in very good shape and
hopefully we can use our time productively next week to close out the
TBDs.  I have several nits and some general comments - more along the
lines of impressions, after reading the document.  Hopefully posting
something to the discussion list will help us start thinking about what
we have to accomplish next week.

	Page 11, Section 4.3.  That fact that we refer to conference
policies but don't include them anywhere in our data model is bothering
me.  You say on page 8:

	   "A Conference Object is of type 'Conference Object Type'
which is 
	   comprised of two distinct components: the 'Common Conference 
	   Information Type' and the 'Conference Template Type', as
illustrated 
	   in Figure 2.  Each of these types is a placeholder for
including 
	   potentially multiple sub-types." 
	You say in 4.3 that policies = rights, permissions and
limitations and that they apply to the Conference Object as a whole.  So
I'm thinking these policies are outside the data model.  Then in
paragraph 3 you state that "The permissions and limits are specified as
an integral part of the Conference Object Type."  In Figures 6, 7, and
8, the conference policies are "attached" to the side of the Conference
Object.  These policies also appear to be cloned!  So I am relieved when
you say:

	 "A more general rule mechanism, beyond the functionality
provided by 
	   the permissions and limits, is an item for future study for
the XCON 
	   WG." 
	We do need to decide if the policies will be part of the
Conference Object, or if the policies will be external to the Conference
Object, but will be able to read/write to the Conference Object.  In
looking at draft-ietf-sipping-conferencing-framework-05.txt there is a
Conference Policy Server explicitly described. 

	[MB] I see why you have concerns, but we did explicitly agree at
the Interim in Jan (and confirmed on the mailing list) that this
framework was not defining a separate Conference Policy server, but
rather having the policies as an integral part of the conference object.
What we're missing is more detailed discussion of that within this
framework document and a good way to show them in the diagram of the
data model, without the implication that they're separate. We have put
in a placeholder for more detailed discussions in a separate document,
but it's clear from your concerns and a similar one raised by Umesh that
this is something that needs resoluton in this document. I'll post a
separate item on the list to discuss this point. 

	Page 21, Section 6.3. In previous discussions (along the lines
of DP4) I believe we tried to distinguish between "Blueprint" and
template so that they mean two different things.  The template
explicitly refers to the Conference Template Type or its' current
parameters.  The "blueprint" is the Conference Object that will be
cloned to create a conference object for reservation.  So I was a bit
uncomfortable when you said (in paragraph 2) "a list of the Conference
Object 'blueprints' (or templates) the system supports."    

	[MB]  Agreed.  I'll remove that text in parenthesis. Related to
this is a general issue on whether we need the two distinct terms
"template" and "blueprint" - we've debated this before and we need to
resolve this.  I'll post a separate email on this. 

	Later on, in paragraph 4, it says: 
	   "The selected blueprint with its default values is copied by
the 
	   client into a newly created Conference  Object, ..." 
	Can we say its "cloned" instead of "copied" by the client.  I'm
not even sure we should specify who exactly is doing the cloning.  It's
probably more likely that the client communicates via CPP to the
Conference Control Server, which clones the parent.   

	[MB] Agreed.  Quite interesting, Oscar made the opposite
comment, but I think by clarifying the terminology overall, based on the
mark-ups I have from Henning and some WG discussion (separate email), we
should be able to resolve this inconsistency. 

	Page 27, Section 7.3. I hope we spend more time discussing (and
agreeing on) the mechanism for CCP next week.  In the first sentence of
this paragraph you say:

	   "The XCON working group charter includes the development of a
protocol 
	   or a set of protocols for controlling the state of a
Conference 
	   Object and for retrieving its state." 
	I would add to that the ability to create and manipulate
conference parameters, in fact any parameters of the Conference Object
Type.  Section 7.3.5 (SOAP), paragraph 3 states it fairly well:

	    " _____ is proposed as the mechanism for object content
manipulation and 
	   state retrieval for the XCON data (model)."  

	[MB] Agreed.  I'll reword similar to what you suggest. 

	Page 31, Section 7.4. I would agree with bullet 5, the
discussion related to BFCP is still too detailed.  In particular the
lengthy authentication paragraph which ends this section is not
necessary as authentication and security should be covered in Section
10. 

	[MB] I agree; this isn't consistent with security discussions in
the rest of the document and I've worked this into section 10. 

	Page 37, Section 9.  After reading this section on the
relationship between the SIPPING and XCON frameworks, I had to ask
myself why we don't supersede the SIPPING framework [9].  I glanced at
draft-ietf-sipping-conferencing-framework-05.txt (posted on May 27th)
and even with a quick read I can see there are some significant
differences as noted here.  We can probably tolerate some differences
because these are just framework docs.  But shouldn't the respective
authors attempt to iron out the major differences? 

	[MB]  Both the sipping-conferencing-framework and this XCON FW
match in terms of the protocol and other normative aspects that are
required for SIP based conferencing.  So, although, the high level
models don't match (e.g. Policy models),  the XCON FW does not change
any of the fundamental SIP based protocol aspects.  I think we have to
view this situation as "water under the bridge".  Ideally, it would have
been nice to have a single framework, but clearly having two separate
documents was the right decision since the SIPPING documents are in the
RFC Editor's Queue, thus providing stability to developers and other
SDOs with dependencies on those docs and from a process perspective,
it's not possible to make significant changes to those docs.   We did
decide way long ago that the SIPPING conferencing framework was not the
ideal starting point for the XCON FW (i.e. I think we have agreed as a
WG  that there is a reason for the differences, but I'll let the chairs
step in if that's not so).    Certainly, we'd love this document to not
be too far behind the SIPPING docs in getting published, so that
developer's have a common baseline for the more advanced functionality
that this FW enables, while still being compatible with what they've
developed for SIP.  If this concept isn't clear in the text, we need to
make sure that it is. 

	Page 39, Section 10. At the end of the Security Consideration
section there's a discussion of hidden and anonymous parties.  I would
like to request that call recording be added to the last sentence so
that it reads:

	  " 'Hidden' status is often used by robot participants of a
conference, for example for call  
	     recording, and is also used in many call center
conferencing situations."  

	[MB] Agreed.

	Thanks 

	NITs   

	1. Page 6, Section 3, paragraph 5, ends with unmatched
parenthesis  

	 [MB] Replaced that sentence with the following:

	 "  A Conference Object is accessible using the protocols,
identified  in Figure 1."

	2. Page 13, Section 5.3, paragraph 3, "stages are addressing
using CCP" should read "addressed"   [MB] Fixed. 
	3. Page 17, Section 5.4, Figure 5 should be titled "Conference
User Identifier Mapping" [MB] Fixed. 
	4. Page 18, Section 6.1, Figure 6 is described but not
explicitly referenced in Section 6.1  [MB] Added a paragraph and deleted
the sentence referencing future XCON specs.

	5. Page 30, Section 7.4, bullets are not numbered in sequence
[MB] Fixed by removing and rearranging the notes (4 moved to 1st
paragraph, where any such discussion would need to be and have moved the
security discussion to section 10.  I think this section is no longer so
overloaded or detailed and that any remaining changes would be based on
changes earlier in the doc that might ripple down to this section (eg.
identifiers). 

	6. Page 36, Section 8.3, paragraph 3, ends with unmatched
parenthesis    [MB] Fixed. 
	7. Page 39, Section 10, paragraph 7, "to enter a PIN makes is
fairly hard" should read "makes it" [MB] Fixed.

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

	David P. Morgan, PhD 
	VP, Architecture & Planning 
	Fidelity Investments Systems Company - Telecom 
	Phone:  617 563-2178 
	Fax:      617 385 2122 
	Mailing: 82 Devonshire St, MZ V8C 
	            Boston, MA 02109-3614 
	Office:   245 Summer Street, 8th Floor 

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