Minutes for CLUE WG @ IETF 88 ============================================ Date(s): Tuesday, Nov 5, 2013, 9:00-11:30, Regency A Friday, Nov 8, 2013, 11:20-13:30, Georgia B Location: Vancouver, BC Chairs: Mary Barnes, Paul Kyzivat Note Takers: - Session 1: Paul Coverdale, Keith Drage, Mary Barnes - Session 2: Brian Rosen, Richard Ejzak Summary: prepared by Mary Barnes Meetecho Recordings: Session1: http://ietf88.conf.meetecho.com/index.php/Recorded_Sessions#CLUE Session2: http://ietf88.conf.meetecho.com/index.php/Recorded_Sessions#CLUE_II Discussion Summary/Conclusions/Action Items: ============================================ WG Status: -------------- - WG milestones have been updated. - Christer agrees to be the editor for the data channel document. - Lorenzo agreed to serve as editor for WG call flows. - There is a detailed schedule available here: http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/WikiStart/Clue-milestones-Nov-2013-v2.xlsx CLUE Protocol: --------------- - Protocol version: it was agreed to have a single field to represent protocol version. - Backwards compatibility: there is concern about whether this should be mandated. Actions: chairs open an issue in the tracker for this one. - Discussion on whether CLUE uses two SCTP connections or multiplex on the the same connection. Action: chairs open an issue to track this one. Schedule an upcoming DT meeting to explore further. - Actions: Authors to update document. Once document is updated, 2 week WG review period, then discuss on design team call. CLUE Signaling: -------------- - Encoding limits: WG still undecided as to whether all the encoding limits can be expressed in SDP or whether they can be signaled in CLUE. Actions: -- Rob: post a note to WG mailing list to trigger more WG discussion. -- Proponents of expressing limits in CLUE should post proposals no later than November 22nd. -- WG: provide feedback on proposals to help WG converge. -- Chairs: schedule this topic for Nov 26th, 2013 DT meeting. - Interoperation with non-CLUE SIP Devices. This needs a lot more consideration. Fundamentally agreed that we can't require new functionality in non-CLUE endpoints. We need to figure out what is good enough. Action: revisit on DT call. Framework: ----------- - Switching: There was unanimous support to add the MCC concept to the framework. Actions: -- Mark to work with Christian in getting proposal incorporated into FW document (proposed deadline Nov 26th) -- Once the document is submitted, we will have at least a one week WG review period and then schedule discussion for the next DT meeting to close on any open issues. (proposed Dec 3rd) - Other open issues: -- Security. Action: Mary to provide text -- Roles. Still no consensus as to whether we need something in the FW. Actions: -- Christian/others in favor of adding something for roles post a proposal on list for additional discussion (deadline Dec 9, 2013). -- WG to discuss on list and try to resolve on DT call on December 17th, 2013 Additional Actions: -- Once the document has been updated to reflect closed issues and switching, we will have a pre-WGLC. -- Rob agreed to do a thorough detailed start to finish review of the document. Others should as well. -- It was suggested to post each issue (other than pure editorial nits) in the document in a separate email thread with an appropriate subject to facilitate tracking. Way Forward: ----------- - Continue with regular design team meetings to progress the solution details. - Schedule an interim late January/early Feb timeframe Action Item summary: -------------------- Chairs: Publish a schedule for design team calls Chairs: Doodle for proposed interim meeting late January/early Feb. Chairs: Open new tickets for action items as identified for each topic ======================================= Mary's Detailed notes (Tuesday, Nov 5): ======================================= Christer: agreed as editor for data channel Lorenzo: agreed as editor for call flows Clarification that related docs are potential dependencies Roni: additional documents. CLUE Protocol Acknowledgements: Rob: notes that these are only around XML. Something else could be wrong - sequencing errors, sender errors Jonathan L: what Paul was talking about is getting a response for a request you haven't sent. Note really applicable. Acks are generally useful - e.g., middle boxes, Do we anticipate acknowledgements will have impact on state machine? Extensions: JL: demux rule assumes you're never going to have a provider to consumer request or consumeer to provide notification. You can't reverse the direction in an extensions? It seems youcould put something in message that you're sending in MC or MP role and not couple to messages. Simon: charts might help to convince you of flexibility Protocol version: Rob: if you support 3.0, then that assumes you support 1.0 and 2.0. Simon: backward compatibility can be an issue. Jonathan: why do we need to list two types of extensions separately? You can do both at the same time. Simon: you might have a generic extension field and put all the extensions you are willing to use. Distinction was made for semantics. JL: if there isn't distinction as to how you respond, then it causes confusion Conclusion: single field. Simon: data model and protocol extensions are easily implementable Rob: concerned about mandating backwards compatibility. simon: if you make an extension and want to be part of standard protocol, an extension is by definition is backwards compatible Issue: do we mandate backwards compatibility? Roni: options issue is due to multiplexing on channel type. Why don't we do two channels? Multiplex on SCTP port then. Rob: that was suggested. But, that ties us to a transport that has two sub-channels. Issue: do we want to use two separate SCTP channels? Action: discuss this on one of the design team calls. Limiting cases: JL: why not send an empty advertisement? then, you can tell the difference between someone not wanting to send versus someone that hasn't gotten around to it. PK: suggest to do both one way or the other (i.e., be consistent - don't send or send "void" Rob: why do you need Re-ADV? Why not just re-issue new CONF? Rob: conflating need for uni directional streams. If we have two channels, then it's easier. Right now overloading ADVs. Mark: agree with Rob. Don't want producer to use info from previous configure to send new advertisements. JL: generalize what Rob said - notion of being able to handle the cases where one sides wants to be provider and another a consumer, this doesn't have to be based on SCTP channels. SHould happen at stream setup and not assumed based on number of ADV and CONF. Need something explicit. Note: Need to revisit this. State Machine (MP): Mark: Once it sends ADV, it must wait for CONF? Thought provider could send new ADV even before receiving CONF. Simon: agree. Action: fix diagrams Cullen: if you add that, you need to add more to draft on how to deal with conflicts, merging, etc. Action: open issue for this Rob: even without this ability, you still have the same issue since we allow multiple CONFs to be sent without an ADV. State Machine (MC): JL: this state machine definitely contradicts earlier statement Conclusion: Update document, discuss on list. Signaling Encoding (Rob) -------------------------- Advantages/disadvantages of proposal: Christer: in general made a decision to use uni-directional m-lines. This seems like an optimization. Can leave for V2. Thinks this is a step back. Rob: we never made a decision. If we use SDP, there's a way to say all this stuff. So, we need something abstract/codec independent or we need to define new language for every codec. Paul: SDP fragments in CLUE message. … Putting this in ADV and reducing O/As is separable from send/receive. JL: 2nd bullet wrt committing resources, if we are assuming Unified, that point goes away. Might be some cases where you'd save O/A but really that's cows out of the barn. Fluffy: can't underestimate the pain of having to re-invent codec-specific language Summary - don't want CLUE to diverge too much from case of I/W with non-clue. What level of detail is required? Can we come up with something abstract - generic language ala framework. Discussion: PK: don't you need codecs to know the encoding Roni: you need some abstract number/units and then you must calculate. That is good enough. PaulC: for interop, need to know what codecs, etc. Rob: you're still going to have SDP. JL: If this is something that needs to be in SDP, then we should add in SDP. No conclusion. Do the call for decision on Friday using a slide. If we have the abstract model, discuss and then do a consensus call. Non-Clue Interop ---------------- JL: agree with contents, but concerned procedurally. ================================================= Paul Coverdale's detailed notes (Tuesday (Nov 5): ================================================== Mary Barnes opened the meeting by noting that the WG milestones have recently updated. The use case informational draft has recently gone to IESG. The Requirements document is in WGLC. She gave an overview of the model for solutions deliverables, the plan is to finish up with a document describing the call flows. As for the detailed status of documents, Christer Holmberg confirmed that he will work on the data channel document. Mary noted related documents being discussed/developed in other WGs, eg MMUSIC, AVTCore, AVTEXT, DISPATCH which may have some impact on CLUE. It was pointed out that we haven’t yet agreed on use of BUNDLE in CLUE, but this should be taken into account. Finally, Mary mentioned that she has put together intermediate dates for milestones on a spreadsheet in the wiki. Simon Pietro Romano remotely gave a presentation on the CLUE protocol which is based on draft-‐presta‐clue‐protocol‐03. There are 4 message types, and each CLUE message inherits the characteristics of the corresponding class: 1. Requests 2. Responses 3. Notifications 4. Acknowledgments Why notifications? Advertisement is not semantically a request, Configure is not semantically a response. Since DTLS/SCTP/UDP is used by CLUE it doesn’t need an ACK, but it was noted that ACKs may still be needed if responses arrive in the wrong order. The Demux rule is straightforward, it based on the message type. Extensions are not currently envisioned in the current protocol spec, but may be required for future expansion. They can be identified by the XML schema. But there was a concern about whether future extensions will still follow the demux rule, since it’s hard to know now what these extensions will consist of. An OPTIONS proposal is necessary for handling version and extensions negotiation, as soon as channel is ready. For CLUE session initiation there are 3 main layers: 1, Establishment 2. Version negotiation 3. Media session description and negotiation Simon gave a walkthrough of the CLUE participant’s state machine, starting with OPTIONS, and a review of the call flows for options and extensions. There was a question of what to do if end-points don’t support all earlier versions (i.e. how to achieve backward compatibility, do we need mandate it?) It was agreed to use one generic extension field for this. It was noted that piggy-backing can be used to send an ACK and CONFIGURE in the same message. Simon noted that there are some limiting cases: 1. How to deal with situations such as both A and B don’t want to send anything 2. Both A and B don’t want to receive any stream. There was no clear conclusion, these points need further discussion. Finally, Simon reviewed the state machine operation of MP and MC. During discussion it was noted that it should be possible to send READV before receiving CONF, some updates are still required. Cullen Jennings pointed out that as the state machine is enhanced, need to carefully consider synchronisation of messages, timing etc. Simon finished by saying that he is looking for feedback in order to update the protocol document. It was confirmed that this is still an individual draft, and will need further update before adopting as a WG draft. Rob Hansen gave a presentation on Expressing encoder limits in CLUE. He started by stating that the current working assumption is that encoding limits will be sent in SDP, but this has not achieved consensus yet. The other alternative is that they could be sent in the CLUE ADVERTISEMENT message. There are advantages and disadvantages to taking this approach. The main motivation is the need to be able to allocate bandwidth effectively Expressing individual encoder limits is done only to let receiver make better decisions on how to allocate resources. But what level of detail is required? can we use generic info? How much detail is enough? If more detail is required, need SDP. This prompted a long discussion on the pros and cons, and can we make a decision now? If not, what more information is needed to make a decision? A show of hands indicated clear support for making a decision this week, and it will be re-visited at the CLUE session on Friday. Christer Holmberg gave a presentation on Non-CLUE interoperability. He defined Non-CLUE as “A device that has not implemented, or does not want to use, the CLUE protocol”. He noted that even when communicating with a non-CLUE device, a CLUE enabled device should be able to provide a good, high-quality, video experience. His suggested approach is to define different media “building blocks” to be sent by a CLUE device as the initial offer, each with different purpose and capabilities – the usage of each building block is optional. This prompted a long discussion on interoperability between CLUE and non CLUE devices in general. It was noted that there is a need to avoid trying to specify general interoperability issues among non-CLUE devices, that aren’t already covered in existing specifications. ============================================== Keith Drage's detailed notes (Tuesday, Nov 5) ============================================== 09:00-09:10 Agenda and Status ----------------------------------------- Presenter: Chairs Note well Milestone updates Model for Solution Deliverables Status Requirements document: Completed WGLC Publication Request submitted IETF Last Call ends on Nov 27, 2013 Use Cases: Completed IETF Last Call on Sept. 26th, 2013 Revision pending Ready for IESG review Framework document (near completion) Mark to discuss remaining open issues including ìswitchingî Data Model: No changes since IETF 87 RTP document: No changes since IETF 87 Individual documents in various stages: - CLUE Protocol document (Leads: Simon/Roberta) Signaling document being populated - one of the last WG deliverables as it provides the "orchestration" of the CLUE protocol with SIP and SDP O/A. (Lead: Rob) - New CLUE Data Channel document proposed for describing clue usage of SCTP/DTLS/UDP. (Lead: Christer) Agreed: Christer will be editor for future data channel document. - Final document will be a a call flows document. (Lead: Lorenzo) Agreed: Lorenzo has agreed to do this. - Related docs being discussed/developed in: MMUSIC: e.g., BUNDLE, draft-even-mmusic-application-token (Monday 9:00-11:30 & Thursday 9:00-11:30) AVTCore: Support of multiple stream docs (Thursday 15:20 ñ 17:20) AVTEXT: e.g., draft-lennox-raiarea-rtp-grouping-taxonomy (Tuesday 14:20 - 15:50) DISPATCH: draft-ejzak-dispatch-webrtc-data-channel-sdpneg (Tuesday 16:10-17:10) Roni drew attention to: http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-03 http://tools.ietf.org/html/draft-westerlund-avtext-rtcp-sdes-srcname-03 CLUE Work Plan and Dependencies Proposed intermediate dates in a spreadsheet on the wiki: http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/WikiStart/Clue-milestones-Nov-2013-v2.xlsx CLUE WG dependency diagram: http://fenron.net/~fenner/ietf/deps/viz/clue.pdf 9:10-10:10 CLUE Protocol ------------------------------------------------------------------------------------------------ draft: draft-presta-clue-protocol-02 Presenter: Simon Pietro Romano Slide 2: Outline Slide 3: Message types Slide 4: Why notifications Slide 5: Why acknowledgements Slide 6: Why acknowledgements Rob Hansen: Asked for additional 5xx type errors to be included. Jonathan Lennox: Do we need to worry about these cases. Thinks acknowledgements are useful from a protocol viewpoint. Do we anticipate that acknowledgements have influence on clue state machine. Presenter: State chart indicates that there are things related to this. Slide 7: Demux rule Slide 8: Extensions Slide 9: Extension examples Keith Drage was prevented by the chairs from making a point on compatibility Slide 10: The OPTIONS proposal Slide 11: CLUE Session initiation Slide 12: CLUE session initation Slide 13: CLUE Participantís state machine Slide 14: OPTIONS Roni: Rob: These proposals ties to transport that has multiple subchannels. Slide 15: Successful establishment of a bidirectional session Slide 16: Limiting cases Jonathan: May have case of don't want to send anything. Paul: What is the reason of sending void conf rather than a conf. Paul: Should really do both one way or do both the other way. Rob: Why do we need the readvertisment request. Why cannot they just issue a reconfiguration message? Rob: If something has changed on my side you should send a new advertisment. Mark Duckworth: Concern about using previous configure messages to define future advertisments. Jonathan Lennox: Should be something that happens at stream setup. Slide 17: MP's State Machine Mark Duckworth: Looks like intent of state machine that one has to receive configure before receives new advertisment. Is there reason for this constraint. Presenter: No. Has to be corrected. Rob Hansen: Will still need to have handling of receiving outdated messages. Slide 18: MC's State Machine Jonathan Lennox: This state machine contradicts that if one does not want anything one does not send an advertisment. Slide 19: Next steps 10:10-10:40 30 CLUE & SDP Signaling ---------------------------------------------------------------------------------------- draft: draft-kyzivat-clue-signaling-05 Presenter: Rob Hansen Slide 2: Encoding limits in SDP Slide 3: Initial O/A (A->B) Slide 4: 2nd O/A (A->B) Slide 5: 3rd O/A (B->A) Slide 6: Encoding limits in CLUE Slide 7: Offer SDP and Advertisment Slide 8: Answer SDP and Configure Slide 9: Advantages/Disadvantages Christer Holmberg: Does not think a few extra offer / answers are a big problem so stick to existign working assumptuon. Roni Even: Does not see the gain so far. Cullen Jennings: Pushback on reinventing codec specific language. Christer Holmberg: Slide 10: Motivation: Why do we need individual encode limits in CLUE? Slide 11: Motivation: Optimal decisions Slide 12: What level of detail is required? Paul Kyzivat: Does not mention anything about what the codecs are. Presenter: The more detail you want the more we should be doing this in SDP. Paul Coverdale: For interoperability each end needs SDP with this information in. Cullen Jennings: Remember you can change SDP if needed. Roni: Hearing so far would prefer SDP. Stefan Wenger: In SDP can represent resolution. But if do this then SDP will grow. Therefore be careful on specifying everything in SDP. Hum to see if we were ready to make a decision. Result: Inconclusive. Paul Coverdale: Does not have the information on the table as to whether these are equal or whether there are real differences. Discussion about whether there should be an ad-hoc discussion before Friday. Suhar?: Stick to SDP. Will make a call for decision on Friday. 10:40-11:00 CLUE & non-CLUE Signaling -------------------------------------------------------------- draft: draft-kyzivat-clue-signaling-05 Presenter: Christer Holmberg Slide 2: Definition Slide 3: Purpose Keith Drage: 2nd bullet does not mean anything - hope we are not using this text in any draft Slide 4: Slide 5: Andrew Allen - Will CLUE device have to provide all these. Presenter: No, if provide any of these this is what it must look like. Slide 6: Paul Coverdale: If device does not support clue, how does it know what to send back? Slide 7: Jonathan: Don't think can define what a non-CLUE device does. Roni: Important thing to decide how the CLue endpoint will respond. Slide 8: No decisions. ============================================================ Brian Rosen's detailed Notes from Etherpad (Friday, Nov 5th) ============================================================ IETF 88 CLUE Minutes for 2nd Session   Brian Rosen Framework- Mark Duckworth Make Standards Track and fix 2119 language Stephan: do we want SHOULD to be recommended or MUST with exceptions Chair: use SHOULD sparingly as MUST with exceptions, don't use lower case should/may Keith: have to explicitly list conditions.  Worry about two parts of the same doc normatively specifying the same thing. Remove computational complexity parm Remove ability of consumer to choose attribute values Remove details of configure after advertisement Multi Content Capture Add MCC as a type of media capture Keith: Add other media types to definition of MCC Hand raise for does WG want to include MCC in Framework, data model and add new signaling? Chairs: Consensus to add it Switched capture approaches for MCC 3 approaches were provided Chairs: Fold what you can into framework, and work on choosing switched capture approaches to the next design team meeting Role Mark proposes to remove it Roni objects Chairs: we'll add an item to the tracker and discuss on the list Paul: we have a use case (telematics) that uses it Mary: might be another way Roni: Ticket 32 covers this Strawman to express encoding limits Rob Hansen Christer: before O/A should we send some info?  If yes, this might be interesting Chairs: How about a humm on whether we are ready to decide today if this is interesting Magnus: what is the meaning of an m-line if we do this? Roni: Because mmusic hasn't decided on bundled, deciding is hard, but we need to decide Christer: need to be clear what an m-line means, whether we do this or not Paul: If you can send a configure and map to a differeny m-line, m-lines don't specify sources Christer: deciding this now doesn't changce decision to use unidirectional m-lines, right Chaires: yes Humm on ready to make a decision now Chairs: clear consensus to not decide now ================================================ Richard Ejzak's detailed Notes (Friday, Nov 8th) ================================================ Agenda presentation CLUE framework (Mark Duckworth) ------------------------------ Changes in -12 version Volunteers to review the document? Stephan Wenger: Send multiple small emails to list rather than one big one. Stephan: regarding 2119 keywords: do we want MAYs and SHOULDs in doc? is explanation needed? Mary: try and use MUST as much as possible; if using SHOULD, include explanation of when it can be ignored. lower case may - use an alternative word. Paul: SHOULD frequently means "optional", so it should be used sparingly Keith: "if condition, MUST" is better because it required careful description of condition Mary: disagree with value of qualified MUST Keith: don't repeat security considerations from body of document. requirements should be testable Martin: this process discussion not interesting to those interested in technical discussion Stephen: it is important to sort out since the co-authors had different views of how to use normative language and it needed to be sorted out Multiple Content Capture (MCC) Jonathan: clarify relationship between MC/MCC and real content Rob Hansen: good approach but clarificaiton needed? Jonathan: Rob Hansen: that is a good explanation; I'll withdraw my comment Christer: capture (MC) can be logical (e.g., current speaker). Mark: but MCC can also be logical Keith: why only discussing audio/video; what about RTT Mark: definition not restricted to certain media types Paul: different combinations of logical/physical MC/MCC are possible. how to explain switching is a separate issue Christer: need a good example to explain this. if have a conf with a lot of rooms, user doesn't necessarily care about the raw sources. Do they need to be included? Mark: discussion of policy attribute to describe these relationships; this is an open issue Rob Hansen: only need to include information if considered useful Jonathan: how to deal with ? Rob Hansen: had discussion on partial updates. need the option to hide detail because lower levels can be arbitrarily large Mark: scenes are comprised of MC/MCCs that may or may not have encodings associated with them Christer: do we need to represent boolean like representations? Mark: can represent a list along with max number that can be simultaneously rendered Jonathan: ? Rob: for MCC proposal 2, should not define how implementations should implement (policy aspects?, synchronization?) Jonathan: re: MCC proposal 3: is it true that the provider must be able ot provide a subset if requested? consumer should be able to say if a future advertisement changes the list of contained captures, continue to send... Rob: there is no wilecard. don't want to resend an MCC just because content has changed Mark: needs to be addressed in text Jonathan: getting the language on what is valid to put in the MCC is tricky. don't want to let someone change order, for example, but want to describe geometry of room consistently. rules for what can change might be difficult. Paul: clearly there are sensible and nonsensical things one can do, but do we need rules? Jonathan: need good "guidance" rather than firm requirements Rob: have descriptions of the different capture scenes, but how do you know which one you're getting at a particular time? Mark: remains an open issue Jonathan: MCC is an important and useful concept, but if it's too hard, could defer it Should we include MCC in the framework? Unanimous agreement to include MCC in the framework and in subsequent documents as necessary. Roni: ? Jonathan: either middlebox or consumer can select what to show Jonathan: ? Ron: capture scenes should have spatial attributes so the receiver knows how to render them Mark: that leads to approach 3 Ron: geometry of original source is not the same as geometry of MCC Jonathan: need to indicate relationship between MCCs. Separately, need to represent spatial relationships between ? Roni: cannot deduce from MCCs in capture scene their spatial relationships to other MCCs in CS Paul: Need multiple folks to work through enough use cases to ensure that we can represent enough Mary: also need to define the scope of what's in the framework Rob: MCC is orthogonal to the switch capture problem Jonathan: for good experience, when there is a switch, need to know how everything has been reassigned to know what to do with a single source Mark: that's easier with a consumer choice mechanism Jonathan: consumer choice adds at least an RTT Roni: took out content attribute from v9 of framework, added role for a more robust mechanism Mark: framework contains something (not role) that replaces content attribute. example might not be completely updated Roni: need machine-readable roles to distinguish between the different streams of information Mark: take it out of the framework (Christian disagrees) Mary: is it fundamental the framework Rob: presentation attribute, view attribute, and role attribute (undefined), that references Christian draft and needs discussion Jonathan: agree to remove role attribute, but need way of correlating capture scenes to entries in a conference event package Mary: that's outside of current scope of group Roni: is it role of endpoint or role of someone in one of the views of the endpoint. it's relevant to the point-to-point case so it's relevant to the group's charter Mary to open up issue in tracker, take it to the list, and set a deadline for resolution. Don't have a solid use case that justifies its inclusion yet. Paul: telemedic use case requires this Mary: not clear that other attributes can't handle that use case Strawman proposal for expressing encoding limits in CLUE (Rob Hansen) --------------------------------------------------------------------- Christer: don't see how this reduces SDP signaling Rob: need sendonly m lines so that the sender can represent its limitations Christer: need unidirectional m lines in many cases Paul: sendrecv vs. sendonly is a separate discussion. May not want to be "hardwired" to have only sendonly, recvonly to be more flexible. Christer: in most cases number of stream is asymmetrical, so unidirectional m lines should be working assumption Jonathan: indexing by codec is worrisome. too many details can't be expressed. Can even work with sendrecv. don't want things special to CLUE Richard: has there been discussion of unspec address in SDP to avoid allocating ICE candidates during negotiation? Rob: may not be necessary with BUNDLE Christer: before offer/answer, is there a need to exchange information? Magnus: difference between encoding and media stream being represented may impact usage (difference between unified plan and CLUE use of SDP) Jonathan: there are good reasons for difference Magnus: suggest working through details of simulcast proposal before making final decision Roni: not bound by unified and should see if a decision can be reached Christer: seem to be mixing things Paul: use of SDP to represent encoding vs. source. Rob: working assumption remains SDP for now More folks hummed that they are not ready to make a decision about use of CLUE to represent encoding. Will answer question no later than December 17. Simon (jabber): he's ready to explore the CLUE option Mary: likely virtual interim late Jan Christer: do we need overhead of an interim rather than just more design team mtgs Mary: design team should only include people actively developing documents Keith: design team should prepare proposals for the working group. virtual interim is easier than f2f Paul: f2f improves focus of participants Keith: can have a series of shorter virtual interims that can be as effective Roni: should prioritize work for design team. have a lot of open issues in documents Paul: can put proposals on Wiki for prioritization Keith: can there be a process to review CLUE docs against the taxonomy Mary: we can do that, but are missing references and dependencies in docs Simon (jabber): inviting the group to Naples Roni: should prioritize issues that are holding up the earliest milestones. the short time scale for the non-SDP encoding issue is inconsistent with this. don't know topics until day before design team calls Mary: ? Keith: can we have tickets for doc reviews against taxonomy? Mary: won't do that