IETF 70 RMT Working Group Minutes Chairs: Lorenzo Vicisano, Brian Adamson Tuesday, 4 Dec 2007, 0900-1130 Notes taken by Vincent Roca. ======================================== Doc Status (Lorenzo/Brian) -------------------------- 2 I-D published: RFC5052, RFC5053 2 have almost finished I-D ready for publication: Reed-Solomon and LDPC-* Pending publication request: NORM BB and NORM PI Updated docs: FEC basic schemes, Flute revised, LCT revised, ALC revised Other docs: RMT security discussion, simple authentication (non working group), FLUTE Update ------------ A new security section has been written. This is the only difference W.R.T. previous version. Lorenzo: Ask to the mailing list to see if everybody agrees with the new text. FLUTE IOP -------------- Vincent: this document was meant to facilitate the interoperability tests during the early stage of FLUTE design. No change in the text has been made recently. Lorenzo: send an email to mailing list to see what to do with it. Reed-Solomon FEC BB (Vincent Roca) ---------------------------------- Vincent introduces the changes made in the document after taking into account the feedback obtained from the group and from the IESG. Basically: - one error corrected (max source block algo), max_n algorithm is updated; - new security section added. However, recent comments from the IESG explain that it is not sufficiently focused even if it is well written; Magnus: No need to update the Security section. The document is already accepted as such by the IESG. LDPC FEC BB (Vincent Roca) -------------------------- Vincent introduces the changes made in the document after taking into account the feedback obtained from the group and from the IESG. Basically: - clarified what procedures are mandatory/recommended; - the authors and Radford Neal directly contribute their source code to the IETF as required by the IESG; - new security section; - the scaling of the PRNG result is made mandatory; A new version will be provided soon. The PRNG code will be removed in next version and replaced by an URL to Robin Whittle's site; TESLA for ALC/NORM (Vincent Roca) --------------------------------- Vincent quickly reminds the main changes made in previous version 02 (July 07). The fact that in some circumstances no key is disclosed does not compromise robustness in front of erasures since any key can be used to compute the previously disclosed keys. The current version 03 does not provide any new feature but rather text clarification and an error correction. An implementation is under progress and is currently used to proof check the document. Some preliminary performance results show that TESLA and Group MAC have very similar performance at the sender (and perform two orders of magnitude faster than a digital signature scheme, which is a well known result). The authors believe it is wise to wait until this implementation is finished before asking for a WGLC in the MSEC WG. Simple authentication mechanisms for ALC/NORM (Vincent Roca) ------------------------------------------------------------ Vincent explains the pros/cons of each solution, using the slides already presented at IETF69. It is shown that the Group MAC, digital signature, and TESLA schemes are rather complementary. - A discussion follows on the usefulness of this document. Everybody seems to agree on this point. - Lorenzo outlines that the current document both provides a high level description of the domain and a specification of the format. It is not clear whether this is appropriate or not. - Brian says there's another group working on similar aspects and they will soon contact Vincent. - It is decided not to make it a WG document immediately, but to wait a little bit and to decide then if we need to keep a single document, or if we need to split it into several documents. - It is decided to keep this activity within the RMT WG since it relies on well understood building blocks (which was not the case of TESLA). LCT revised (Mark Watson) ------------------------- - No change since 05 - Issues: currently a new RFC is needed to allocate a new LCT header extension. The proposal is to change it to a "Specification Required", which makes it easier for other standardization organizations to propose extensions. Currently there is one such proposal (case-in-point DVB Content Download service). Lorenzo suggests to split the header extension field into 2 more sub fields, one for those specified by IETF with an RFC, and one for "specification". This solution limits the risks of running out space. Document ready for WGLC. ALC revised (Mark Watson) ------------------------- - No change since 04 A discussion follows on whether we need a detailed security section in ALC or not. Lorenzo suggests that this security section should be updated, perhaps by taking some text from NORM. Document ready for WGLC. FEC basic schemes revised (Mark Watson) ----------------------------------- Mark introduces the possibility to have "FEC scheme specific information" within the basic schemes, so that FEC codes that don't match exactly the FEC OTI can anyway be used. This proposal, sent on the mailing list a few months ago, has been included it in the current version so that everybody sees what it looks like. There is a consensus on this proposal. Document ready for WGLC. Proposed Milestones ------------------- Re-revised proposal of previous drafts. - January 08: submit NORM PI, FEC basic schemes, LCT, ALC, and FLUTE for publication: - March 08: complete/submit RMT security docs WG next steps ------------- * Should the group start to design an alternative to FLUTE? Brian summarizes the situation. Vincent: no problem to have the work re-activated if the group believes there is an interest in doing so and if there are volunteers. A message will be sent on the mailing list.