Requirements for Internet Media Guides (IMGs)
draft-ietf-mmusic-img-req-08

Gen-ART review from: Spencer Dawkins
Date: 18 januari 2005

I reviewed this specification for Harald as a General Area Review Team
assignment.

This specification is roughly on the right track for Informational
RFC, but seems to carve out a very ambitious scope (scaling to large
numbers of receivers while providing notifications when an IMG has
changed and requiring support for reliable transfers of IMGs) - I
believe it would be a better document if some environments were NOT
supported...

Spencer

1 Introduction

1.1 Background and Motivation

  channel addresses). This peers well with the DVB Organization's

This acronym should be expanded, and there should be a reference, too.

  Furthermore, any Internet host can be a sender of content and thus an
  IMG sender. Some of the content sources and sinks may only be
  connected to the Internet sporadically. Also, a single human user may
  use many different devices to access metadata. Thus, we envision that
  IMG metadata can be sent and received by, among others, by cellular
  phones, PDA (Personal Digital Assistant), personal computer,
  streaming video server, set-top box, video camera, and DVR (Digital
  Video Recorder) and that they be carried across arbitrary types of
  link layers, including bandwidth-constrained mobile networks.
  However, generally we expect IMG Senders to be well-connected hosts.

The above paragraph seems self-contradictory (can IMG senders be
intermittently connected?)

3 Problem Statement

  These are mostly overcome by the XML-based SDPng, which is intended

this sentence should include a reference to [6], right?

4 Use Cases Requiring IMGs

4.1 Connectivity-based Use Cases

4.1.1 IP Datacast to a Wireless Receiver

  There are two main classes of receiver in this use case: fixed
  mains-powered; and mobile battery-powered. Both of these are affected

"mains-powered" may be technically correct, but seems awkward here.

  by radio phenomena and so robust, or error-resilient, delivery is
  important. Carouselled metadata transfer provides a base level of

I don't understand what "carouselled" means in this paragraph (it's
used more than once).

  robustness for an IP datacast based announcement system, although the
  design of carouselled transfer should enable battery-powered
  receivers to go through periods of sleep to extend their operational
  time between charges. Insertion of Forward Error Correction (FEC)
  data into metadata announcements improves error resilience, and
  reordering (interleaving) data blocks further increases tolerance to
  burst errors.

  In some cases the receiver may be multi-access, such that it is
  capable of bi-directional communications. This enables a multitude of

I don't think "multi-access" usually has this meaning.

  Thus, essential IMG features in this case include: robust
  unidirectional delivery (with optional levels of reliability
  including "plug-in FEC") which implies easily identifiable

I'm confused because of references to "FEC" in what seems obviously an
application-layer protocol.

  segmentation of delivery data to enable FEC, carousel, interleaving
  and other schemes possible; effective identification of metadata sets
  (probably uniquely) to enable more efficient use of multicast and
  unicast retrieval over multiple access systems regardless of the
  parts of metadata and application specific extensions in use;
  prioritization of metadata, which can (for instance) be achieved by
  spreading it between channels and allocating/distributing bandwidth
  accordingly.


4.1.3 Broadband Always-on Fixed Internet Connection

  Broadband enables rich media services, which are increasingly
  bandwidth hungry. Thus backbone operators may prefer multicast
  communications to reduce overall congestion, if they have the
  equipment and configuration to support this.

This seems conjectural!

5.3 Customized IMGs

  REQ CUS-1: The system MUST allow delivery of customized IMG metadata.

  The IMG receiver may require a subset of all the IMG metadata
  available according to their preferences (type of content, media
  description, appropriate age group, etc.) and configuration.

  The IMG receiver might send its preferences in the IMG operations
  which can specify user specific IMG metadata to be delivered. These
  preferences could consist of filtering rules. When receiving these
  messages, the IMG sender might respond appropriate messages carrying

"respond with appropriate"?

  a subset of IMG metadata which matches the IMG receiver's
  preferences.

5.4.1 Managing Consistency


  REQ REL-2: Since IMG metadata can change at any time, IMG receivers
  SHOULD be notified of such changes.

This seems inconsistent given discussion about scalability to large
numbers of receivers.

5.4.2 Reliable Message Exchange

  REQ REL-4: An IMG transport protocol MUST support reliable message
  exchange.

But the next paragraph seems to relax this MUST?

  The extent to which this could result in 100% error free delivery to
  100% of IMG receivers is a statistical characteristic of the
  protocols used. Usage of reliable IMG delivery mechanisms is expected
  to depend on the extent to which underlying networks provide
  reliability and, conversely, introduce errors. Note, some deployments
  of IMG transport protocols may not aim to provide perfect reception
  to all IMG receivers in all possible cases.

6.3 Access Control for IMGs
  REQ ACC-6: It SHOULD be possible for IMG transceiver to impose
  different authorization requirements.

??? "different" in what sense?

  REQ ACC-7: It MAY be possible for IMG senders to require certain
  authorization that cannot be overridden by intermediaries.

??? I'm not sure what "overridden" means - provided? forged?

6.4 Denial-of-Service attacks

  REQ DOS-2: It SHOULD be possible to prevent DoS attacks that build up
  session state in IMG entities to exhaust their resources.

This should probably be "avoid DoS attacks", as in the next
requirement, not "prevent".

6.5 Replay Attacks

  REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on
  the IMG operations.

  The level of threat from replay attacks varies very much depending on
  system scale and how well defined or open it is. Thus mitigating
  relay attacks may lead to different solutions for different systems,

The previous sentence should be "mitigating rePlay attacks", shouldn't it?

[Ballot comment]
Reviewed by Spencer Dawkins, Gen-ART

He has a number of comments (copied to document log), but none that I see as warranting blocking the document for that reason alone.

[Ballot comment]
I'm concerned that the potential roles of intermediaries are under-specified here.
In the introduction, the document says:

  Finally, with many potential senders and receivers, different types
  of networks, and presumably numerous service providers, IMG metadata
  may need to be combined, split, filtered, augmented, modified, etc.,
  on their way from the sender(s) to the receiver(s) to provide the
  ultimate user with a suitable selection of multimedia services
  according to her preferences, subscriptions, location, context (e.g.
  devices, access networks), etc.

The Security Considerations section does have some mention of
the role of intermediaries, e.g.

  REQ AUT-5: It MUST be possible to separate or combine individually
  authenticated pieces of IMG metadata (e.g. in an IMG transceiver)

but the general mechanisms by which the receiver, sender, and intermediaries
interact does not seem to have generated sufficient requirements to ensure
that later protocol work will succeed.

I've had a short side discussion with Jon on this, and I agree that this could
be specified in a separate document, if that's the way the WG wants to tackle
things.