Document: draft-ietf-mmusic-img-req-07.txt 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?