Title: Internet Media Guides Update and Open Issues
1Internet Media Guides Update and Open Issues
- Yuji Nomura, Pekka Luoma, Rod Walsh
- IETF-58, MMUSIC, 14.Nov.2003
2Internet Media Guides Requirements Update
- Yuji Nomura
- IETF-58, MMUSIC, 14.Nov.2003
3draft-ietf-mmusic-img-req
- Current draft-ietf-mmusic-img-req-00.txt
- A lot of changes from previous
- draft-nomura-mmusic-img-requirement-01.txt
(individual submission) - We will submit draft-ietf-mmusic-img-req-01 soon
4draft-ietf-mmusic-img-req-00.txt
- Changes (1/3)
- 1. Introduction
- Background and Motivations (new)
- 3. Problem Statement (new)
- Moved and shortened from old framework draft
- 4. Requirements
- 4.4.2 Support for Intermittent Connectivity
- The system MUST enable IMG receivers with
intermittent access to network resources
5draft-ietf-mmusic-img-req-00.txt
- Changes (2/3)
- 4.4.3 Congestion control
- Internet-friendly congestion control MUST be
provided. - 4.5 IMG Descriptions
- IMG metadata MUST be interoperable regardless of
the transport protocol and network used to get it - IMG metadata MUST be structured to enable
fragmentation (e.g. of the global set of
metadata) - IMG metadata SHOULD support delta syntaxes for
efficient messaging following small changes to
metadata
6draft-ietf-mmusic-img-req-00.txt
- Changes (3/3)
- 5. Security Considerations (many changes)
- IMG Authentication and Integrity
- Privacy
- Access Control for IMGs
- Denial-of-Service attacks
- Replay Attacks
7Next steps and open issues
- For draft-ietf-mmusic-img-req-01.txt
- Numbering requirements
- Modify terminology for consistency
- Clarifications requested
- Many more receivers than senders
- Senders are continually connected (receivers are
not) - Tradeoff between customization and scalability
- WGLC on the horizon
8Internet Media Guides Requirements Update
9Internet Media Guides Framework Update
- Pekka Luoma
- IETF-58, MMUSIC, 14-Nov-2003
10draft-nomura-mmusic-img-framework
- Current draft-nomura-mmusic-img-framework-02.txt
- Previous
- draft-nomura-mmusic-img-framework-01.txt
(individual submission) - We will submit draft-ietf-mmusic-img-framework-00
soon
11draft-nomura-mmusic-img-framework-02
- Changes (1/2)
- 3. Use Cases Requiring IMG Framework
- Content-oriented use cases (new)
- 6. Applicability of Existing Protocols (new)
- New section (requested/agreed in Vienna)
- 6.1 Limitations of Existing Protocols
- 6.2 Existing Protocol Fit to the IMG Framework
Model - 6.3 Outstanding IMG Mechanism Needs
12draft-nomura-mmusic-img-framework-02
- Changes (2/2) 6.3 Outstanding IMG Mechanism
Needs - Multicast Transport Protocol
- Maybe ALC-based
- Usage of Unicast Transport Protocols
- HTTP, SIP events,
- The Metadata Envelope
- New/single term for an existing framework model
concept - Gives independence from transport protocol and
metadata format - Baseline Data Model Specification
- Informative only, not MMUSIC/IETF standardized
13draft-ietf-mmusic-img-framework
- Next steps and open issues (1/3)
- Editorial - clarifications, corrections of typos
- Terminology IMG, IMG metadata, IMG delivery,
- New section for whats in IETF scope - separated
from outstanding IMG needs section - In scope Transport protocols, transfer envelope
- Out of scope Data models, application specific
metadata
14draft-ietf-mmusic-img-framework
- Next steps and open issues (2/3)
- IMG Metadata identifier
- Probably a URI in all cases
- Differences between complete, delta and pointer
- Same id, different data type how to signal
data type? - Different syntax between complete and delta
- IMG metadata can refer to (and possibly locate)
related metadata delivered over other transport
channels and sessions, using the same
locator/identifier as in the metadata envelope - I.e. unify the identifier/locator for both
metadata envelope and IMG metadata (suggestion
for anyone specifying metadata)
15draft-ietf-mmusic-img-framework
- Next steps and open issues (3/3)
- Submit revised version
- WGLC target December
16Internet Media Guides Framework Update
17Internet Media Guides Some Other Technical
Issues
- Rod Walsh
- IETF-58, MMUSIC, 14.Nov.2003
18Design Choices
- Multicast Transport Protocol
- ALC/FLUTE is a very good candidate
- Subscribe (unicast)
- SIP and SIP events
- Metadata Envelope
- a. XML file / wrapper
- b. Header extension of transport protocols
- Allow both methods? Or not?
- Data Types and Channelisation
- Could correlate data type and transport channel,
e.g. pointer-only channel - Could divide delivery over multiple channels
- Multicast multi-layer congestion control usage
- Both unicast and multicast channels could be
employed
19Middlebox Authentication Integrity Issue
- A middlebox may combine, add, modify and remove
metadata - The original sender signature will be invalidated
in some cases - Solutions
- Trusted (by sender) middlebox re-signs using
original authority - Inter-domain trust issues
- Middlebox request to sender for new signing
(post-modification) - Middlebox just signs new and changed metadata
- Requires appropriately small fragmentation of
metadata - Possibly changeable metadata as small fragments,
and stable metadata as large fragments - (most applications we have discussed do not use a
middlebox)
----------
---------- IMG
IMG
Sender ----
----gt Receiver
---------- \ /
---------- \
/ .
\ ----------- / .
. --gtIMG -----
. .
--gtTransceiver \ .
/ ----------- \
---------- /
\ ---------- IMG
/ ----gt IMG
Sender ----
Receiver ----------
----------
20Internet Media Guides Other Technical Issues
21Internet Media Guides Update and Open Issues