Subject: [clue] IETF#80: Notes

From: Christer Holmberg <[email-masked]>
Date: Thu, 31 Mar 2011 11:08:38 +0200

Hi,

Below are my notes from the CLUE WG session.

Regards,

Christer

-------------

USE-CASES:

Presenter: Peter Musgrave
Draft: draft-romanow-clue-telepresence-use-cases-01.txt

Abstract:

- Peter presented the types of use-cases currently described in the draft.

Discussions:

- There was a discussion about whether floor control was within the scope of CLUE. It was indicated that there are other working groups working on general mechanism, not only applicable to CLUE, that might be usable.

- There was a discussion whether the use-cases should be structured in a different way, e.g. centralized vs peer-to-peer.

- There was a discussion that the current use-cases might need to be split into additional use-cases.

Action points:

- Need to more clearly define the difference between a heteregenous use-case a assymetric use-cases, pointing out that an heteregenous client migth not understand the new features, protocol elements etc defined in CLUE.

- Additional use-cases will be provided, as the current ones seemed to be showing certain deployed scenarios.

- The terminology in the document needs to be clear and well defined, so that everyone has the same understanding.

Poll:

- Willing to review and contribute to the document: 20+ individuals

Hum:

- Adopt the use-case document: Room concensus, no objection

RQUIREMENTS

Presenter: Allyn Romanow
Draft: draft-romanow-clue-telepresence-requirements-01.txt

Abstract:

- Allyn presented the assumptions and requirements currently presented in the draft.

Discussions (assumptions):

- For the assumptions, it was indicated that some of them probably belong to the WG charter, or to the problem statement description of the WG. Some of the assumptions will be removed, and the text associated with those assumptions might be moved elsewhere.

- It was commented that entities have control of what is sent, but that we can not make assumptions that receivers will render streams in a particular way. Rather, endpoints need to get enough information about the streams in order to be able to render them in a good way.

Discussions (requirements):

- There was a general comment that every requirement should be written in a consistant way, indicating what the solution/system needs to support.
- REQS-1: The requirement shall be split into separate requirements for stream relationship and sender/receiver capabilitites
- REQS-1: The note shall either be removed, or moved into a separate requirement
- REQs-3: The requirement shall be split into separate requirements
- REQS-4: Clarify what type of synchronization is meant. Time synchronization.
- REQS-5: The "arbitrary" terminology is unclear, and that the WG should not try to to come up with maximum number of capture devices etc.
- REQS-6: Needs to clarify exactly what is negotiatied/re-negotiated
- REQs-7: Only first part of requirement is needed. The rest should be covered in the definitions section.