XCON
IETF-59

The following drafts were discussed:

- 
draft-ietf-xcon-conference-scenarios-00.txt - Chairs

  Presented by working group chairs for Nermeen Ismail and Roni Even. Plan to 
submit 01 version for WG last call.

- 
draft-ietf-xcon-floor-control-req-00.txt - Joerg Ott

  Includes some proposed policies that the authors aren't certain about. 
Would like others to comment.

  Cullen Jennings suggested that it is impossible to know with 
certainty who a participant is, and this provides a different way of 
looking at privacy requirements.

  Brian Rosen voiced a requirement for the ability for a floor holder to 
pass the floor - different from automated floor control.

  Dave Lindbergh commented this is focused on parlimentary model. Wanted to 
know if pannel discussion or roundtable is supported. Joerg Ott said this is 
was possible, depending on floor policy.

  Keith Drage requested a better abstract before going to WGLC. Also, said 
there may be need to add floor policy to conference framework. Wants 
clarity on whether floor policy is to be covered by this doc or the 
conference policy requirements.

  The chairs said plan is for WGLC within the next 2-3 weeks.

- draft-ietf-xcon-cpcp-reqs-02.txt - Hisham  Khartabil

  Update of additions/removals. Rohan stated it seemed CPCP is intended for 
humans, but he thought this will only be used by automata. He doesn't 
think he is being understood. He said it should be possible to mark an 
entity that should be hidden, but there may not need to be any  complex 
policy to control this. This is for things that would be annoying to see, 
such as automata like recorders. This policy would affect conference 
policy notifications.

  Eric Burger thought that would be useful *if* those special kinds of 
roles are implemented by regular participants - but that is not the only way 
to implement those functions. Roni Even thought this might be a media 
policy. But Rohan didn't.

  Dave Lindbergh thinks there are different kinds of conferences. For some 
hidden participants are fine, for others not. It may be important for 
security to know if there are hidden participants.

  * There was no concensus. Further discussion to the list.

  There was extensive discussion on the definition of start time and 
end-time. Cullen Jennins argued that the time the first participant 
arrives cannot be the start time, because the start time is inserted in 
policy a priori. Eric disagreed. There seemed to be lack of 
understanding between them.

  Rohan Mahy said there are four parameters, not two: 
cannot-start-before, cannot-continue-after, start-policy, 
end-policy.

  Roni Even said this has nothing to do with resource reservation. Eric 
Burger said this is definitely tied to resource reservation, or else there is 
no point. Cullen thought reservations are way out of scope.

  He said that the following are both important numbers: when mixing can 
begin, when dialouts happen. Suggests not calling it start-time.

  * Some concensus for: don't-mix-before-time, dialout-time.

  Also need policy to say mixing won't happen until key participant 
arrives. Someone also brought up case the dialout doesn't happen until a key 
participant arrives.

  * Cullen and Rohan were asked to send text. (Roni Evan points out that 
dial-out might not happen until a key participant arrives, so the policy 
needs to account for such a case).

  Discusson on conference ends policy. Outcome was conclusion this is tied to 
key participants via some sort of policy.

  Keith Drage requested clarification on where media policy will be 
defined, because this document currently doesn't. Roni Even said this in 
intended to be done in a separate document even though it may be 
realized by same protocol. Keith felt this needs to be clarified because the 
conf framework says that cpcp will include media policy.

  Brian Rosen said there is a need to define Role. More work needed here - 
role is mentioned but not really defined. This relates to anonymity: one 
might not expose identity, but they might want to expose roles.

  * The document will be revised based on the open issues discussed 
above, and then enter a last-call period.

- 
draft-koskelainen-xcon-xcap-cpcp-usage-02.txt - Hisham  Khartabil

  Alan Johnston asked if others felt it was ok to have multiple 
conference URIs for one conference, or whether it would be better to have 
only one plus aliases. Alan thought framework said should be only one. 
Somebody said intent was not to be sip-biased. Hisham didn't think that we 
need a single URI for identification; that there can be several 
different URIs that identify the conference equally.  Brian Rosen said 
these should all be requested aliases while the true uri would be 
assigned and must be a gruu (and consequently not specified in the 
policy). Cullen Jennngs thought that like IM, we may need a special uri 
scheme that isn't bound to any of the protocols.

  Rohan Mahy said that typically there is an address (e.g. phone number) of a 
server plus an access code to enter the conference. In that case that 
isn't a conference uri, but something else. Brian things there may be need 
for extension to carry this address used for conference access.

  Alan indicated that clarification might be necessary about what it would 
mean to have several SIP URIs identifying the same conference.

  There was a long discussion of the suitability of xcap as a 
mechanism for cpcp, what http methods are most suitable for xcap, and 
whose problem it is if xcap is/isn't appropriate for the job.

  Orit Levin proposed splitting the document in two. Keep xml document 
separate from the protocol. Aki thought splitting schema from protocol is a 
bad idea. Brian Rosen didn't want majority of work held up based on 
disagreement over protocol issues. Rohan said work is supposed to apply to 
multiple communities, but sipping community wants to use xcap and we 
shouldn't make it hard to do. He suggested not splitting document, but 
partitioning it so that there is a separate section on application to 
xcap. Orit didn't want to encourage "vandals" to implement this using 
other protocols. She would still prefer to split the document. Jonathan 
said it is normal case that there is a 
mandatory-to-implement protocol to ensure interop, without precluding 
other protocols. Keith Drage said if there are multiple equal 
protocols you should split the document, but if one is special then it 
ought to be in the document. Aki is ok with restructuring the doc, but 
wonders why - he hasn't seen any other transport being proposed. Lisa was in 
favor of splitting because will need something else for xmpp to use this.

  * The chairs attempted to summarize: some sort of cencensus about 
restructions/splitting the document so as to have xcap being *a* way to 
manipulate the document.

  * Alison asked about need for stronger statement regarding role of xcap 
before the next meeting. Wants a statement about it in the 
deliverables, that there will be an xcap transport based proposed 
standard.

  * Took hum of people wanting to take forward work using an xcap usage for 
conference control. Hum was positive.

  * Agreed to take as WG item if document is suitably reorganized. No 
agreement whether that will require a split.

- draft-burger-xcon-mmodels-00.txt - Eric Burger

  Presented in "lecture mode" with questions postponed in order to save 
time. He enumerated three media manipulation models: low level device 
control, application level device control, dynamic device control, and he 
listed pros and cons of each.

  Rohan says this is fear mongering - that low level device control graph 
model doesn't have the problems asserted. Says H.248 is much worse than the 
graph model. He said that Eric hasn't demonstrated that his proposal meets 
the scenarios.

- 
draft-jennings-xcon-media-control-00.txt - Cullen Jennings

  This presented an alternative approach to media control, based on 
templates. Alan Johnston said he liked this approach. Roni Even thought 
model was good, but remains to be seen how many templates are needed. But he 
is concerned whether complex cases can be handled. Brian Rosen 
responded that the issue is whether a small number of templates can 
handle a large number of the cases. If a small number don't cover 
*enough* of the cases then this isn't a good approach. Need to do work to 
verify this.

  Rohan doesn't think we have enough info to move forward. Thinks Eric's 
draft doesn't have enough content. Cullen thinks there is enough so 
people can see how they would build templates for particular cases, but 
Rohan disagreed - said it will break down for hard cases, that there is a 
big problem naming things.

  The chairs took several hums to determine the way forward with this 
work. Four options were offered:

  - flow graph approach: nobody
  - template approach: several
  - both are incorrect: a few
  - don't have enough info - wait: many

  * Consensus determined to be that we should attempt to understand the 
issues better before making a decision.