FLUTE - File Delivery over Unidirectional Transport
RFC 3926

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

Comment (2004-07-08)
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

Comment (2004-07-08)
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.