Subject: [clue] Minutes: Design Team meeting today (Feb. 11th) @ 10am Central

From: Mary Barnes <[email-masked]>
Date: Tue, 12 Feb 2013 14:06:28 -0600

Hi all,

Thanks for the great attendance on the call and the efficient use of
time (33 minutes;)  Below are my notes and action items captured
yesterday.

Attendees (in random order):  Mary Barnes, Paul Kyzivat, Andy
Pepperell, Jonathan Lennox, Rob Hansen, Simon Pietro-Romano, Roberta
Presta, Roni Even and Stephan Wenger

Recording:
https://ietf.webex.com/ietf/ldr.php?AT=pb&SP=MC&rID=10397547&rKey=ccd6b3f68b6c2ec8

0) We had some discussion of the IETF-86 agenda.
- Jonathan noted that CLUE is opposite RMCAT.  [Action: Mary.
Follow-up with ADs on re-arranging agenda.  Status:

-  It was noted that MMUSIC looks to have about 4 hours of meeting
time, which is good.  Mary suggested Jonathan/Roni request agenda time
for  draft-even-mmusic-multiple-streams-01.txt. Even though it's not
fully baked, CLUE really needs to start feeding our requirements and
solution proposals into that WG.

1) Feedback on RTCWEB/MMUSIC interim meeting.

- A sense of the room was taken with regards to whether the work in
MMUSIC should consider CLUE requirements.  The results indicated a
fairly rough split, so the way forward at this time in MMUSIC is for
CLUE requirements to be considered.  [Action: CLUE WG. Review the
requirements in this presentation and decide whether they suffice or
whether we have additional requirements.
http://www.ietf.org/proceedings/interim/2013/02/05/rtcweb/slides/slides-interim-2013-rtcweb-1-10.pdf]
AFAIK, they are not yet in draft form.

- There remains a fair amount of debate with regards to the basic
signaling model.   Jonathan suggested that what CLUE might need is
similar to Cullen's proposal B in the presentation above.

-  Jonathan noted that the big relation is with regards to the RTP
mapping as discussed in draft-even-clue-rtp-mapping.

- We discussed whether the RTCWEB SDP usage really needs to match the
CLUE SDP usage.   It was noted that an interworking function is
necessary regardless as it's clear that the RTCWEB SDP usage will not
likely interact well with a "legacy" SIP client.

- Terminology:  It was noted that RTCWEB is using different
terminology with regards to a model for multi-stream/video
conferencing.  We *really* need to agree on some terminology in the
cases where we really are talking about the same things.  This came up
in Justin's presentation:
http://www.ietf.org/proceedings/interim/2013/02/05/rtcweb/slides/slides-interim-2013-rtcweb-1-7.pdf
[Action: Mary. Contact Justin with regards to working on common
terminology.  Note: this re-enforces the need for the CLUE FW document
to be less solution specific and to have a more high level description
of the CLUE FW model. ]

- Note: one other important item that wasn't mentioned on the call is
that there was a fair amount of discussion with regards to the data
channel signaling.  Since CLUE was planning to piggyback on the
solution for SCTP, we need to pay attention to the issues/solution
proposals that RTCWEB is discussing:
http://www.ietf.org/proceedings/interim/2013/02/05/rtcweb/slides/slides-interim-2013-rtcweb-1-9.pdf

2) Plans and document status for IETF-86:
- FW. Stephan noted that a major clean-up is underway.  At a minimum
they will mark what should go in other docs and remove what is already
in other documents.  It would be good if any changes based on
Christian's comments could be incorporated:
http://www.ietf.org/mail-archive/web/clue/current/msg02329.html
[Action: FW authors and WG participants.  Review and respond to these
comments so we can get consensus on what to incorporate into the
revised FW document.

- Signaling:  http://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling/
Paul has made a first pass and Roberta has added some material.  This
really needs to be beefed up before the meeting.  Rob noted that he
has content to add. Paul also does.  [Note: he has the current dibs on
the document].  The model should be that folks send an email to the
list that they are currently editing. I would like to suggest that
once the doc is claimed that the changes are submitted within 24 hours
(and no later than 48) so folks have time to get their changes in.
Folks can create their text offline and then cut and paste into
appropriate sections when they get the document.  It is a working
document and folks should add relevant Editor's notes and
comments/questions (it would be useful to put these in brackets or use
some notation to highlight these).

- @IETF-86.  Since we have some time between the CLUE WG sessions
(Monday afternoon - Thursday morning), it would be good to get a room
and schedule time for a CLUE DT meeting to ensure we make the most of
the f2f time.  [Action: WG participants/contributors.  Send conflicts
to chairs so we can find a day/time.]