Re: [apis] ACTION-128 Drafting Use-Case/Requirements Cross-Reference Table

Hi JC,
Let me try to respond in-line.

Sheau Ng | NBCUniversal | P: +1.609.759.0819

From: JC Verdiť <<>>
Date: Friday, July 26, 2013 5:04 AM
To: Sheau Ng <<>>
Cc: "<>" <<>>
Subject: Re: [apis] ACTION-128 Drafting Use-Case/Requirements Cross-Reference Table

Hi Sheau,

Let's play battleship :)

7-G : 1.5 Device Authentication mechanism  / UC 6 : Tuner control thru web app
IMHO it's X! more than X? It's a tricky point: the device controlling the tuner absolutely needs to be authenticated and granted access, but it's not enough. Even if a device is generally allowed to perform this action it doesn't mean it can do it at this specific time. A good example is when another allowed device is currently connected and interacting with the main screen.

SHEAU> Sounds like we agree.

Which lead to many derivative questions:
- how can we consider a 2nd device is "currently interacting"? e.g. if i change channel, or modify volume. How long before my device is not considered as "locking the main screen"?
- is it, anyway, a good idea to consider this "locking"? but if not, what about two devices interacting at the same time. it can happen with a device in another room, and user unknowingly interacting with the main screen..
- do we want to address this now? Do we want to address this at all?

22-E : 1.20 content protection / UC4:  Content Sharing

I would vote "X"

SHEAU> This makes two of us.

22-F : 1.20 / UC5: Content Search

I would vote "not X": it's a good idea to let people discover content, even if it means they will need to acquire certain rights to view it. I'm confident movie studios would agree with this ;)

SHEAU> My thinking is actually along the line of Parental Control, which unfortunately, isn't one of the Requirements (yet). While Content Search, by definition, should reach as wide a set of content as possible, there needs to be some mechanism to selectively hide some content for various reasons, including the typical need for parental control. I think this may be a case for a new Use Case.

22-H : 1.20 / UC7: Channel Bounded Applications

Not sure what you mean? Is your question "If an app is bounded to a channel, viewing this app implicitely means you have access to the channel" ? If I understood your question correctly, my answer would be "it depends"
- content provider might want to provide protected apps because they're strongly related to the protected content and providing them for free reduces the perceived value of the content
- content provider might also want to provide unprotected apps to tease non-subscribers. These apps would be considered as generic trailers, or informative apps about the protected channel ("what are your benefits if you subscribe", or any other stuff content providers' imagination can birth.
- they might even want to provide both apps: if a user is subscribed, give him app X, if he isn't, give him app Y.

SHEAU> I agree with your statements. In fact, that's the reason I thought UC7 would lead to a Content Protection requirements. According to my understanding,, the UC->Requirements mapping does not mean that all UC must operate with the associated Requirements. It simply says that a particular UC will need the support of a specific function. In this case, the Channel Bounded Applications need Content Protection function support. It does not means all Channel Bounded Applications must use Content Protection.


Ng, Sheau (NBCUniversal) wrote:
Per my action item ACTION-128 to draft a use-case/requirements
cross-reference table on Google Doc:

I have included a few "X?" in red to indicate my questions regarding
possible requirements that pertain to some use cases.


Sheau Ng | NBCUniversal | P: +1.609.759.0819

Received on Friday, 26 July 2013 14:22:37 UTC