FG IPTV-C-1010e.doc

151
-1

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
151
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

FG IPTV-C-1010e.doc

  1. 1. INTERNATIONAL TELECOMMUNICATION UNION FOCUS GROUP ON IPTV TELECOMMUNICATION FG IPTV-C-1010 STANDARDIZATION SECTOR STUDY PERIOD 2005-2008 English only WG(s): 1 7th FG IPTV meeting: Qawra, St Paul’s Bay, Malta, 11-18 December 2007 CONTRIBUTION Source: ETRI Title: Comment and Proposed modification on Working Document: Working Document: IPTV Services Requirements 1 Abstract In the current FG IPTV-DOC-0147 “Working Document: IPTV Services Requirements”, there is a sub-part containing not-related items to the title. This contribution identifies this point and proposes modification to it. 2 Proposed changes to FG IPTV-DOC-0147 We propose to modify the specified sub-part of the section, 6.3.2 Content protection in the document, FG-IPV-DOC-0147 as following proposed change 6.3.2 Content protection - Scrambling algorithm options Proposed change Proposal and reason We propose to modify the following 2 parts: All requirements except first one in the part of Scrambling algorithm Architecture options options is related interoperability • The IPTV architecture can optionally support the function between Service Protection inclusion of content tracing information. This and Content Protection of the IPTV content tracing information can optionally contain architecture. They are NOT related the operator ID, content owner ID, IPTV terminal scrambling algorithm option. So it device ID, and other information. is proposed to move them to the part of Architecture options. Scrambling algorithm options • Scrambling algorithms for IPTV can optionally apply cryptographic algorithms of different strength to different content types. • The IPTV architecture is prohibited from precluding support for service and content protection interoperability where only authorized user(s) or device(s) are allowed to use the IPTV content, even Contact: Kisong Yoon, Yeonjeong Jeong, Dowon Nam Tel: +82-42-860-4992 (ETRI) Fax: +82-42-860-6699 Hogab Kang, Taehyun Kim. (DRM inside) Email: {ksyoon,yjjeong,dwnam}@etri.re.kr Korea {hgkang, thkim}@drminside.com Attention: This is a document submitted to the work of ITU-T and is intended for use by the participants to the activities of ITU-T's Focus Group on IPTV, and their respective staff and collaborators in their ITU-related work. It is made publicly available for information purposes but shall not be redistributed without the prior written consent of ITU. Copyright on this document is owned by the author, unless otherwise mentioned. This document is not an ITU-T Recommendation, an ITU publication, or part thereof.
  2. 2. -2- FG IPTV-C-1010 after content is transferred to another security system. • The IPTV architecture is prohibited from precluding support for service and content protection interoperability so as to keep identification information to identify IPTV content consistently, no matter which identification schemes are used and no matter to which security system the content is transferred to. • The IPTV architecture is prohibited from precluding support for service and content protection interoperability so as to not reduce the level of security when content is transferred to another security system • The IPTV architecture is prohibited from precluding support for service and content protection interoperability so as to allow only trusted devices. • The IPTV architecture is prohibited from precluding support for service and content protection interoperability so as to provide a secure environment for exchanging service and content protection interoperability data (e.g. authentication information, metadata, key information, etc). • The IPTV architecture is prohibited from precluding support for service and content protection interoperability such that interoperability is not dependent on specific software or hardware. • The IPTV architecture is prohibited from requiring a service and content protection mechanism of either side to be openly specified to achieve interoperability. • The IPTV architecture is prohibited from precluding support for service and content protection interoperability which is flexible and extensible to support various business models • The IPTV architecture is prohibited from precluding support for service and content protection interoperability among multiple security systems which use different security mechanisms, respectively, where the purpose is to support the seamless time-shifting service (subscribers can store the content and retrieve it later) and place-shifting service (subscribers can see the content anywhere) although the security mechanisms are different. • The IPTV architecture is prohibited from precluding support for service and content protection interoperability so as to maintain transparency to
  3. 3. -3- FG IPTV-C-1010 users. • The IPTV architecture is prohibited from precluding support for multiple content and service protection mechanisms regardless of specific hardware or software requirements. into the following 2 parts: Architecture options • The IPTV architecture can optionally support the inclusion of content tracing information. This content tracing information can optionally contain the operator ID, content owner ID, IPTV terminal device ID, and other information. • The IPTV architecture is prohibited from precluding support for service and content protection interoperability where only authorized user(s) or device(s) are allowed to use the IPTV content, even after content is transferred to another security system. • The IPTV architecture is prohibited from precluding support for service and content protection interoperability so as to keep identification information to identify IPTV content consistently, no matter which identification schemes are used and no matter to which security system the content is transferred to. • The IPTV architecture is prohibited from precluding support for service and content protection interoperability so as to not reduce the level of security when content is transferred to another security system • The IPTV architecture is prohibited from precluding support for service and content protection interoperability so as to allow only trusted devices. • The IPTV architecture is prohibited from precluding support for service and content protection interoperability so as to provide a secure environment for exchanging service and content protection interoperability data (e.g. authentication information, metadata, key information, etc). • The IPTV architecture is prohibited from precluding support for service and content protection interoperability such that interoperability is not dependent on specific software or hardware. • The IPTV architecture is prohibited from requiring a service and content protection mechanism of either
  4. 4. -4- FG IPTV-C-1010 side to be openly specified to achieve interoperability. • The IPTV architecture is prohibited from precluding support for service and content protection interoperability which is flexible and extensible to support various business models • The IPTV architecture is prohibited from precluding support for service and content protection interoperability among multiple security systems which use different security mechanisms, respectively, where the purpose is to support the seamless time-shifting service (subscribers can store the content and retrieve it later) and place-shifting service (subscribers can see the content anywhere) although the security mechanisms are different. • The IPTV architecture is prohibited from precluding support for service and content protection interoperability so as to maintain transparency to users. • The IPTV architecture is prohibited from precluding support for multiple content and service protection mechanisms regardless of specific hardware or software requirements. Scrambling algorithm options • Scrambling algorithms for IPTV can optionally apply cryptographic algorithms of different strength to different content types. ___________________

×