Subject: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-01

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Mon, 14 Mar 2011 01:45:24 -0700

Folks, 
I just posted an updated version of the requirements draft, based on the comments I got - both on the mailing list and offlist. The changes are primarily trying to make things clearer and clean up redundancy. A iist of the changes follows below.

Thanks,
Allyn

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Monday, March 14, 2011 1:36 AM
To: Allyn Romanow (allyn)
Subject: New Version Notification for draft-romanow-clue-telepresence-requirements-01 

A new version of I-D, draft-romanow-clue-telepresence-requirements-01.txt has been successfully submitted by Allyn Romanow and posted to the IETF repository.

Filename:	 draft-romanow-clue-telepresence-requirements
Revision:	 01
Title:		 Requirements for Telepresence Multi-Streams
Creation_date:	 2011-03-14
WG ID:		 Independent Submission
Number_of_pages: 10

Abstract:
This document discusses the problems, assumptions, and requirements
for handling multiple media streams to enable Telepresence
interoperability.  Definitions are also covered here as well.

The IETF Secretariat.

--
DEFNs – pulled “room”, as per comment by Jim Cole. Unnecessary, just use endpoint.

Deleted source placement, as per Jim Cole’s suggestion. update layout with his text.

Region – added that the sender defines the region.  I agree with Jim Cole’s comment that region should be better defined. It is an important concept for the model, a draft of which will come out shortly.  Let’s update the region definition in light of that later.

Source selection. Jim Cole suggested should be replaced by an extended definition of mixing to include multistream.  Discussions of mixing seem also to include how to use SSRC and CSRC fields. It would premature for us at this point to make those kinds of solution-based assumptions. So, I propose waiting a bit to fix this.  We can discuss.

Video composite - Same as above. Liked the improvement, but suggest wait. 

Delete assumption 9 
Offlist comment suggested that SDP can signal the range of resolutions. In any case, I believe this is a generally held assumption about decoders, and it probably is not necessary here. 

REqmt 1 – changed “spatial” information to “layout” information, which is more accurate and hopefully more understandable.

Reqmt 3 – deleted, redundant. Covered in reqmt 7 which is more general

Reqmt 4. Added more description to a receiver asking for streams from a sender – in response to comment from Jim Cole and an offline comment

Reqmt  6. Deleted support for Baseline 264. This is more of a profile specification, not part of protocol. 

Reqmt 11 – deleted. Based on offline comment, it’s more of a solution than a requirement.

Reqmt 12 deleted. More of a solution than a requirement, offline comment

Reqmt 13 – agree that it seems related to dynamically coming and going streams. Moved it.

Reqmt 14 – merged into Reqmt 1. It was redundant.

Reqmt 15. Merged into Reqmt 2 about support for dynamic behavior of streams. Part was also more about solution than requirement, removed.

Reqmt 16. Moved to subset of #2, and removed some as it was more of a solution than requirement. Offline comment

Reqmt 17 – deleted. Same as 18