Last Modified: 2005-10-06
Done | Submit design-space, building-blocks, and guidelines drafts for publication as Informational RFCs | |
Done | Initial Drafts for the following building blocks: negative acknowledgments, forward error correction, a generic signaling mechanism for router assist, and transport protection | |
Done | Submit Initial Drafts for the two protocol instantiations. | |
Done | Submit Initial Draft for Congestion Control | |
Done | Complete building-block drafts WG Last-Call and submit for publication as Proposed Standard | |
Done | Complete building blocks and protocol instantiations for ALC and submit for publication as Experimental RFC | |
Done | WG Decision on whether to pursue the router-assist building block work. These milestones may have to be modified accordingly | |
Done | Submit WEBRC (congestion control building block) for publication as Experimental | |
Done | Submit NACK building block and protocol instantiation for publication as Experimental | |
Done | Evaluate when and how the RMT Experimental specifications will be submitted for publication as Proposed Standard, and update this charter accordingly | |
Sep 2005 | Submit remaining congestion control building blocks (TFMCC, PGMCC) for publication as Experimental | |
Dec 2005 | Submit all the RMT Eperimental Specifications published before July 05 for publication as Proposed Standard | |
Apr 2006 | Submit all remaining RMT Eperimental Specifications for publication as Proposed Standard |
RFC | Status | Title |
---|---|---|
RFC2887 | I | The Reliable Multicast Design Space for Bulk Data Transfer |
RFC3048 | I | Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer |
RFC3269 | I | Author Guidelines for RMT Building Blocks and Protocol Instantiation documents |
RFC3450 | E | Asynchronous Layered Coding protocol instantiation |
RFC3451 | E | Layered Coding Transport (LCT) Building Block |
RFC3452 | E | Forward Error Correction Building Block |
RFC3453 | I | The use of Forward Error Correction in Reliable Multicast |
RFC3695 | E | Compact Forward Error Correction (FEC) Schemes |
RFC3738 | E | Wave and Equation Based Rate Control building block |
RFC3926 | E | FLUTE - File Delivery over Unidirectional Transport |
RFC3940 | E | NACK-Oriented Reliable Multicast Protocol (NORM) |
RFC3941 | E | NACK-Oriented Reliable Multicast (NORM) Building Blocks |
IETF 64 Vancouver, Canada RMT WG Minutes Many thanks to Magnus Westerlund for taking these minutes. Off the Agenda -------------- Allison asked what was happening with SDP flute draft. Magnus: It is being updated and we could expect an update the next few days. Status update ------------- See presentation slides. Moving to Standard Track: Brian Adamson: it would be appropriate to move TMFRC to Standard Track as well, as NORM can use a normative reference to it. TESLA: Vincent Roca: implementation is progressing, but no draft has been submitted yet. A few more weeks than it should be available. Lorenzo: TESLA not on the charter need to start discussion on that topic. So please take this to the list. Moving NORM to Standard Track -- Brian Adamson ----------------------------------------------- draft-ietf-rmt-pi-norm-revised-00 draft-ietf-rmt-bb-norm-revised-00 See presentation slides. Lorenzo: Changes section should be included to help reviewers with noticing what has been changed and reduce the workload of review. Allison: This are the changes and why it should go forward. Section should be called "Changes since RFC XXXX". Some documents need to go together so there are no meaning to send in documents until the dependency are ready. Consensus on the above topic was the following: - all submissions transforming an Experimental into a Standard Tack RFC should contain the following: * a section "Changes since RFCXXXX" * A common note explaining the rationale for moving to Standard Track (this note will be the same in all document a will be drafted soon by the WG). - Dependency order should be enforced in the submission to the IESG (submit dependent documents later). Mark: On the EXT_FTI it is defined by the FEC scheme. Updated FLUTE has changed. Brian: As NORM is not a ALC protocol it defines it in a similar way but do not reference it as it Mark: ALC/LCT registers its own IANA registry, should NORM use the same registry? Lorenzo: Yes, two different registries should be defined. Allison: Write clear instructions to ensure that they are correctly placed in the IANA registry so these ends up under the RMT umbrella. Consensus on header extensions: - establish 2 IANA registries (one for ALC/LCT and one for NORM). - Write clear instructions to accomplish this in both ALC/LCT and NORM, choosing appropriate (hierarchical ?) names for the registries. - all documents that allocate header extensions (for ALC, NORM or both) must contain specific IANA instructions to do so in the "IANA" Section. FLUTE Update -- Stephan Wenger ------------------------------ draft-ietf-rmt-flute-revised-00.txt See presentation slides. Stephan: Changes slides needs to go into the draft. Magnus: Has anyone reviewed the URN used to identify the FDT XML schema. Allison(side note) Needs to go to URN mailing list. Mark: Should reference the FEC BB not the basic FF schemes. Allison: Media type and URN review can happen in parallel in with the WGLC. Send notice to both those mailing lists that can be found under non-WG mailing list at IETF page. FEC BB -- Mark Watson --------------------- draft-ietf-rmt-fec-bb-revised-02 draft-ietf-rmt-bb-fec-basic-schemes-revised-01 draft-ietf-rmt-bb-fec-raptor-object-03 See presentation slides. Lorenzo: Is there a changes section? Mark: IS it ready for going to IESG. Lorenzo: A new WGLC does not seem necessary. Revise and declare intention to submit. Allison: If this doesn't have dependency it is fine to submit it. Only drafts that has dependency shouldn't be submitted until all documents are ready and then sent to IESG as a bunch. basic-schemes Lorenzo: FEC-raptor-object will be sent to IESG as soon as the BB is ready. LCT Revised -- Mark Watson -------------------------- draft-ietf-rmt-bb-lct-revised-01 draft-ietf-rmt-pi-alc-revised-01 See presentation slides. Mark: No comments was received on proposal to RMT and has been implemented. So if you do not agree to the changes then speak up. Lorenzo: IANA notes in FLUTE, ALC needs to have registration of their header extensions. Brian: Then NORM should also define its header extension registry. Allison: IETF Review (replace IETF consensus) is a good level. As this forces review within IETF. Mark: Sounds reasonable Magnus: I think IETF review might be reasonable for header extensions. But what about fully qualified FEC schemes and there requirements? Allison: There are a lot of options on how IANA can handle these things. Long discussion on alternatives. Allison providing some alternatives and Magnus arguing for greater flexibility for IETF external organizations to register things. Some alternatives to IETF specification required was: IETF expert to approve specification required as complement IESG approval of specification required Lorenzo: Alternatives 1. IETF consensus 2. IETF consensus with bypass with publication required and expert review. 3. Something else Lorenzo choice between the first two alternative will go for a 1 week WGLC. Mark: Proposal for IANA rules for LCT header extension: IETF publication required. No comments. Mark: Please report if LCT changes of sender current time field would cause problem. LCT draft is not available due to errors with the publication. TMFCC -- Mark Pullen -------------------- draft-ietf-rmt-bb-tfmcc-05.txt See presentation slides. Mark Pullen (MarkP) Lorenzo: Will a new draft be resubmitted? MarkP: Yes, as soon as deadline for receiving comments has been passed. LDPC -- Vincent Roca -------------------- draft-ietf-rmt-bb-fec-ldpc-00.txt See presentation slides. Mark: Do you mix source and repair symbols? Vincent: No, they will be of only one type. Lorenzo: IS this ready for WGLC? Vincent: No, next version Mark: To achieve good performance it most likely that you need to send source and repair symbol packets in random order. Draft should document the consideration between sending source symbols first, or sending them in random order. Mark: Please remove statement in relation to IPR that are not the standard IETF boiler plate. Lorenzo: Mark is probably correct, will double-check. RS fully specified code -- Vincent Roca --------------------------------------- draft-lacan-rmt-fec-bb-rs-00.txt See presentation slides. Lorenzo: Thanks very much for doing this overdue piece of work. Need to formally accept this as WG item. Vincent, please send a request to the WG mailing list. File Aggregation -- Vincent Roca -------------------------------- draft-neumann-rmt-flute-file-aggregation-02.txt See presentation slides. Mark: TOI question. FLUTE revised has no structure for TOI. Should all text be removed about the TOI in this proposal? Vincent: Yes, seems reasonable. Joerg: Running a FEC scheme over for example a website where certain parts need to change is counter productive. Lorenzo: A Question is if this should be a WG ITem. IT is a bit off charter. Mark: It is useful and should be supported. Joerg: Would you like to get other gains like compression, by doing zip on the files. MArk: The question do you need to expose for the FDT layer that these are separate files? Lorenzo: Please send mail to the list discussing these issues. Timestamp LCT header extension -- Stephan Wenger ------------------------------------------------ draft-jansky-alc-timestamp-extension-00.txt Lorenzo: Why a timestamp and not a long lived identifier? Vincent: What is the goal for this document. Why restricted to a specific protocol and the chosen. Mark: LCT does not have a mechanism to indicate changes, however FLUTE does. So you would only have to listen until the next FDT repetition comes around. Lorenzo: This discussion should be included in the draft. This could apply to norm. Brain: Norm has an instance id that can indicate changes. But it is limited and will wrap. Mark: The LCT header registry is an example. And until that is published we live in the current world. And the WG can publish things without registry request. Lorenzo: please start a thread on the list to decide if this will be a WG document. |