Subject: [XCON] Minutes Posted / Milestones Updated

From: Adam Roach <[email-masked]>
Date: Wed, 15 Apr 2009 13:30:05 -0500

[as chair]

Please review the minutes from the San Francisco face-to-face meeting, 
and submit any corrections or amendments you feel are appropriate to the 
chairs:

   http://www.ietf.org/proceedings/09mar/minutes/xcon.txt

Based on modest support for adding a milestone to create a call-flows 
document, we have revised the charter to add one additional deliverable; 
see the final milestone here:

   http://www.ietf.org/html.charters/xcon-charter.html

We have also rescheduled the remaining deliverables to reflect a more 
realistic timeframe, given the additional time taken up by the protocol 
changes from SOAP to REST to the current format.

/a

---

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Thu, 16 Apr 2009 10:25:14 +0100

Hi Folks,
	Is this new callflow doc about CCMP callflows ? If yes, why is
its publication date April 2010 and
the ccmp August 09? I would have thought these end dates should be
alligned...

Here's my 2 cents about the issues highlighted in the 09Mar minutes:-
Use Cases:- 
	There seems to be quiete a bit of time spent around cloning
conferences and managing the behaviour of the subsequently created
conferences, however I am not fully convinced of usefulness of this
feature is. Typically every newly created conference will need a unique
name,passcodes,user list, descriptions etc and would need to be
specified by the client. Using the cloning method, this means two
operations, which is not ideal. I envisage clients using blueprints as
templates, i.e. they retrieve a particular template, make the relevant
changes to it and then send it off in a 
create request. I would like to see some use cases detailed for this
scenario in the CCMP draft.

Atomicity:-
	Regarding multiple users, atomicity does not apply. i.e. you
can't rollback and start removing the newly added users if one user cant
be added to the conference. I think for that specific use case, its best
effort and typically it
should be an asynchronous operation, i.e. the ccmp client should not be
hung waiting on all people to get into the 
Conference and instead it should be be notified as the users arrive into
the conference. 

Notifications:-
	CCMP notifications is yet to be defined/decided. I think xcon
should separate the notification transport
mechanism from the actual content and subscription mechanism. i.e. the
content of the notfications should be no different
for a ccmp client than a sip client, what is different is the transport
protocol used to receive the notifications. 
I think draft-ietf-xcon-event-package-01.txt should be changed to define
the notification format for the data model and then have a separate
section on how to receive these notifications via SIP. The CCMP draft
then can reference this draft for the notification format and would need
to specify how these notications should be received.

Sean

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Adam Roach
Sent: 15 April 2009 19:30
To: XCON-IETF
Cc: Alan Johnston
Subject: [XCON] Minutes Posted / Milestones Updated

[as chair]

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

---

From: Adam Roach <[email-masked]>
Date: Thu, 16 Apr 2009 09:34:26 -0500

[as chair]

> the ccmp August 09? I would have thought these end dates should be

The logic here was that the callflows document depends on the protocol, 
but not the other way around (cf. RFC 3261 and RFC 3665).

That said, we're happy to adjust the schedule according to working group 
consensus (subject to reality checks -- we may require additional people 
to commit to being authors before moving milestones earlier). Does 
anyone else want to weigh in on the timeline?

> I think draft-ietf-xcon-event-package-01.txt should be changed...

draft-ietf-xcon-event-package has been handed off to the IESG for 
publication. We could pull it back if we found a critical flaw. 
Retracting it for anything less would be considered unnecessarily 
disruptive.

/a