Subject: [XCON] XCON minutes from IETF 76

From: Richard Barnes <[email-masked]>
Date: Fri, 13 Nov 2009 11:03:36 +0900

Minutes - XCON - IETF76

Summary (prepared by Richard Barnes):

1. Chairs' Introduction
The chairs reviewed the status of the WG's documents.  draft-ietf-xcon- 
common-data-model is in a holding pattern, waiting on CCMP.   There  
were no objections to removing IM- and policy-related milestones from  
the charter.

2. CCMP
  draft-ietf-xcon-ccmp
Simon Romano presented an update on this document.  The latest version  
includes several revisions in response to a review from Richard  
Barnes, all of which were supported by the WG.  Mr. Romano plans to  
take one more round of comments and have a final draft ready in early  
2010.

3. BFCP over UDP
  draft-sandbakken-xcon-bfcp-udp
Alan Johnston presented an update on this document on behalf of Tom  
Kristensen.  Several commenters pointed out that the current draft  
still has many problems that had been called out at previous meetings,  
The draft will not be taken up by the WG at this time.

Raw notes from Martin Thomson follow:
------------------------------------------------------------
Agenda Bash

Agenda was OK

Work Item Status

No discussion

Simon Romano on Conference Control Manipulation Protocol -04 posted  
recently

small but important modifications to the document

better clarity required and some technical issues

document structure was a source of confusion

issue over the scope of application ofthe conference password, does  
the password relate to the entire conference, or each conference URI?   
WG input sought; Mary Barnes noting that the URI encompasses the  
entire (not enough context to make sense of the conclusion -  
conclusion was to make no change)

XSD or RNG?  rbarnes wanted all xcon documents to use the same schema  
mechanism; roni even giving history, following the same path for the  
other document, adding RNG later

updates to confObjs.  Added versioning in the latest update.  if  
modifications are accepted, the server updates the entire object and  
it updates/increments the version.  all server responses will contain  
the version number.  is this OK?  mary barnes notes that this solves  
the problem of working out what version the server is operating on;  
alan johnston agrees this is workable and lightweight

request filtering?  mary notes that this is functionality that was  
desired from the framework, if it is not too hard, add it.

progress: mary thinks it's close to ready; adam roach agrees that it  
would be good to set an aggressive goal, and not even meet at IETF77;  
mary says that a meeting might be needed; simon: call flows are there,  
but they need work to be updated

gonzalo camarillo is waiting on the data model to be completed, what  
is the plan?  alan johnston: the data model is past WGLC;  gonzalo:  
pub-req along with CCMP? answer: yes; alan: maybe we can move  
everything together; general agreement to do that

==Revision of the Binary Floor Control Protocol for unreliable  
transport (Alan Johnston)

Current protocol relies on a TLS/TCP connection, but TCP does not  
always work.

Roni BFCP used where there are two video streams, for instance video  
and presentation.  TCP is problematic, more like problems with SBCs;  
some fallbacks to UDP, some to HTTP; need to create a profile that  
uses UDP as a fallback mode to deal with deployment problems

Roni: this is sometimes used for multipoint

Draft looks at limitations and flow maintenance issues.  Need to look  
at DTLS (for encryption), framing, fragmentation, and versioning.

No action requested by the authors on this document.

RJS feedback: the characterization that this is for NAT/firewall  
traversal needs to be changed to SBC traversal more specifically and  
explicitly; what about congestion safety over UDP?  Please have a look  
at congestion safety here so that we can make sure that this can  
proceed.

Gonzalo: has worked on this in the past, maybe to integrate with  
BFCP.  Problems were raised, but the authors did not respond.  We need  
to enumerate issues and address them.

Roni: this is now more important now that work is being done on this

John Elwell: This is now active again.

Adam Roach: repeating old concerns: this does not address  
interoperability with TCP-based implementations that are already out  
there; this does not work in SIP; needs a mechanism for negotiation or  
fallback; does not want un-interoperable

Gonzalo: the protocol can be fairly lax; needs more than just  
retransmission to ensure reliability

Roni: there are capability negotiations in SDP that could be used to  
address this

Simon: authors on chat have noted that there are some effort to  
address some of the concerns: fragmentation

Gonzalo: is OK to resurrect this, but doesn't like the tactics

Chairs: need to show interest, address issues and do so quickly  
because the WG is winding down

==Other issues

Alan: is there interest in dealing with the policy and IM-related work

Gonzalo: policy was removed from the protocol because it was hard; be  
serious about this if you take this on, don't expect the WG to die

Mary: maybe wrap this up, then see if people want to deal with this,  
then re-charter a new WG or go through DISPATCH for the work if there  
is the will to do so; don't continue in here

Simon: agrees and wants to close down

RBarnes: any objection to removing the milestones from the charter.