RE: [MMUSIC] TVA comments on the framework and requirements

[[e-mail]]

Hi Jean-Pierre (et al.)
 
<note, this is a "previous email thread deleted" version of the initial reponse since the original exceeded 50K and is currently waiting moderator approval>
 
Sorry for the delay, and thank for your patience.
 
On the data model, the purpose of sharing the data model in MMUSIC is to ensure that this side of the discussion is included in the IMG Framework considerations, even though MMUSIC will only charter IMG delivery protocol work (not "application-specific metadata"). My opinion is that DVB-CMBS and OMA are the prime options for baseline date model standardisation (although there's a strong "crystal-ball" element to this prediction as neither have the final solution at this juncture in time). It is reasonable to exchange ideas and information and develop the data model openly, but it is necessary to understand the the MMUSIC chairs have made it absolutely clear that this is the wrong standards WG to standardise it.
 
(I'm "announcing" this in MMUSIC so those interested are aware that there will be non-IETF - and possibly non-all-access - related work and thus can get involved or ask to be kept up-to-date off-line from MMUSIC)
 
 
On the IMG FW & reqs feedback:
 
Everything's looking good with the extra comments:
 
R2: Trailer booking for instance is not based on the use of a schedule.  It should be possible e.g. to book the recording of a piece of content from a trailer proposed on the website.  Full content would be recorded when ready for streaming (e.g. Unicast following this client request).  The same schemes as for broadcasting should apply to multicast.  I'll try to provide you with some text next week.
 
So you mean that an IMG metadata could describe the trailer booking service where details of how to book are described by the IMG metadata? The IMG system would not be used to do the booking (although possibly to subscribe to a notification or wait for an announcement indicating that the booking service is now available). Do you feel that the the inclusion of this use cases (in the framework) would have a significant impact on the conclusion of the framework or the IMG metadata delivery protocols? I guess your text next week should clarify this.
 
The primary use cases described for IMGs are multicast/multiparty session enablers, so although unicast services could easily be described too, this is not the primary objective of IMG/MMUSIC work.
 
F2: I don't see why you shouldn't list them all.  Each of them is relevant to my comments and to the IMG requirements and framework at one moment or another.  What would be the problem with a more comprehensive list of references?
 
I have never seen an IETF document with such a reference format (it's much more ETSI style). It's much more usual to provide the "boot-strap" reference so that the full documented list can be found. (Technically, only a single reference to the TVA body of work is needed from the document body text as we do not discuss exact particulars of each of the documents). To give an example, for FLUTE [], we could easily give a set of related references, but these would easily be found by first finding the FLUTE specification and then following the subsequent references.
 
e.g.
FLUTE ref option 1:
   [14] T. Paila, "FLUTE - file delivery over unidirectional transport,"
   Internet Draft draft-ietf-rmt-flute-07, Internet Engineering Task
   Force, Dec. 2003.  Work in progress.
 
FLUTE ref option 2:
   [14] <FLUTE - File Delivery over Unidirectional Transport, draft-ietf-rmt-flute-07.txt>
   [??] <RFC 3450 Asynchronous Layered Coding (ALC) Protocol Instantiation> 
   [??] <RFC 3451 Layered Coding Transport (LCT) Building Block> 
   [??] <RFC 3452 Forward Error Correction (FEC) Building Block> 
   [??] <RFC 3453 The Use of Forward Error Correction (FEC) in Reliable Multicast> 
   [??] <Compact Forward Error Correction (FEC) Schemes, draft-ietf-rmt-bb-fec-supp-compact-01.txt>
where the <> implies expanding these out to be formal reference style
 
My opinion is to go with the single concise TVA document reference as it reads easily to IETF-eyes and the remainder of documents are easily found from this. Does this make sense?
 
 
BTW, DVB-GBS begin work on IP transport week 11 (the week after IETF-59), if interested I'd be more than happy to discuss these issues there also (assuming you will not be in South Korea).
 
Cheers, Rod.