FLUTE - File Delivery over Unidirectional Transport
Note: This ballot was opened for revision 07 and is now closed.
( Allison Mankin ) (was Discuss, Yes) Yes
( Harald Alvestrand ) No Objection
Comment (2004-02-04 for -)
From Gen-ART reviewer John Loughney: It seems that this document is in good shape. It is well written. Security Considersations seems to be quite thorough. Boiler plate is in good order. I would recommend the following changes: Fairly important: ================= 1) The draft needs a terminology section. FEC, Asynchronous Layered Coding, would be good to define. FEC should be expanded on its first use as well. 2) Section 1.1.3, 2nd paragraph, last line: Thus, the inherent raw scalability of FLUTE is unlimited. This seems unsubstantiated, I would suggest deleting this line. less important: ============== 1) Odd formatting between UDP layer & Default LCT header in section 3.4: | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Default LCT header (with TOI = 0) | (I thought I was seeing double at first ...) I ran out of time to really pick at the document thoroughly, but otherwise the document seems in good order.
( Steven Bellovin ) (was Discuss) No Objection
( Ned Freed ) No Objection
( Ted Hardie ) (was Discuss) No Objection
( Scott Hollenbeck ) No Objection
Write-up is missing.
( Russ Housley ) No Objection
Comment (2004-02-05 for -)
The security considerations begin with: > > The same security consideration that apply to ALC and to the LCT, FEC > and the congestion control building block used in conjunction with > FLUTE also apply to FLUTE. > Pointers to the documents that contain the appropriate security considerations would be very helpful. Please give the 'Statement of Intent' portion of the Introduction a subsection number. Please spell out FEC the first time it is used. Please use 'example.com' instead of 'ex.com' Please change 'SMIME' to 'S/MIME' Please change 'Trojan horse' to 'Trojan Horse'
( Margaret Wasserman ) No Objection
( Bert Wijnen ) No Objection
( Alex Zinin ) No Objection
Draft: draft-ietf-rmt-flute-08 Reviewer: Scott W Brim Date: 8 July 2004 This draft is ready for publication as an Experimental RFC. I'd go with "no objection". It's internally consistent. I can't tell if it's a good match to actual requirements, or if there is a better match, and the security scenario is a little disturbing, but that all just means it's a good match for Experimental.