FLUTE - File Delivery over Unidirectional Transport
Note: This ballot was opened for revision 08 and is now closed.Search Mailarchive
(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
(Margaret Cullen) 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'
(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.