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.