FLUTE - File Delivery over Unidirectional Transport
draft-ietf-rmt-flute-revised-16

I have no objection to the publication of this document.

Thank you for the substantial description of the changes since RFC 3926
which made review considerably easier. I think you might find the need
to consolidate the description of the changes which is currently
incrementl such tat when more than one change was made to a section
over time, it appears in the log more than once. This means that it is
currently necessary to read the whole log before understanding what has
changed.

---

Seciton 9 ends a little suddenly :-)

Version -16 resolves the remaining IANA registration issues.  Good to go, and thanks for working with me on this.

Is there any companion document that explains the operational model and the manageability aspects related to the deployment of this protocol? If such a document exists it would be worth at least to include a reference to it in this document, in the absence of a operational and manageability considerations section.

I have one very minor editorial comment.  The document uses "packet"
throughout, sometimes without qualification and sometimes with
qualification; e.g., "ALC/LCT packet."  For the most part, the type of
packet can be deduced from the context.  However, in section 3.3, it
wasn't clear to me if "packet" referred to ALC, transport or IP
packet: 

   If an FDT Instance is longer than one packet
   payload in length, it is RECOMMENDED that an FEC code that provides
   protection against loss be used for delivering this FDT Instance.

There may be one or two other instances of "packet," e.g., in section
7, discussing "per-packet" security, that are similarly unclear.
 
This use of "packet" seemed a little confusing (although the meaning
is probably clear):

   FLUTE is compatible with both IPv4 or IPv6 as no part of the packet
   is IP version specific.

Also concerned about the IPR situation, but Stephen holds the DISCUSS

Francis Dupont provided a Gen-ART Review of -13 on 29-Feb-2012.  We
  understand that an updated version is in the works.  Please consider
  the comments in this Gen-ART Review while making the updates.

  http://www.ietf.org/mail-archive/web/gen-art/current/msg07240.html

(A bunch of these were addressed in -14, I didn't go through 'em though;
-15 may be even better:-)

- What was the experiment for 3926 that has now concluded
indicating that this document should be on the standards track?
I'd like to have known. (A reference to something or short
paragraph would have been fine.)

- The introductory material isn't very clear to this reader.  I'd
suggest adding text like the intro from [1] and/or adding
references to that or similar papers that introduce the protocol.
([1] was just the first thing that I found that seemed to have
that, I'm sure there are many others, and maybe better ones, but
its intro helped me.)

   [1] http://mad.cs.tut.fi/doc/Analysis_of_the_FLUTE_Data_Carousel_presentation.pdf

- 1.1.3 - "works with all types of networks" - academic training
tells me to always question all absolute statements like that all
the time:-) Is it really true? How do you know? Would acoustic
underwater networks or 6lowpans be counterexamples?  (Section 3.4
implies a requirement for UDP as well.) I think you need references
or an argument, or (most likely) to weaken the claim, e.g. via
s/all/many/

- p10 - is it clear (enough) what's meant by a temporary IP
address? Not a big deal but not sure its the right term.

- p15: I don't get what this means really: "If the receiver does
not understand the FEC Encoding ID in a FDT Instance, the receiver
MUST NOT decode the associated FDT." It sounds like decoding and
not decoding all at once.

- s3.3: I've not parsed this out fully but the 2119 lanaguage here
seems a tad loose - if this section were to avoid 2119 language and
just be an intro, would that be better? (That might be a lot of
work though, so just consider this a suggestion.)

- why is this the case in 3.4.1? "Sender behavior when all the FDT
Instance IDs are used by non expired FEC Instances is outside the
scope of this specification and left to individual implementations
of FLUTE." Seems like that'd create interop problems - why not?
Similarly, the receiver behaviour being out of scope also seems
wrong.

- 7.3.4 RECOMMENDS that receivers identify themselves in case they
mess up congestion control. Is that reasonable? It doesn't seem so
since this doesn't define how to do that.  I'd say weaken that and
say that if receivers are known then you might be able to catch
them messing up the CC scheme.

- Is section 11 intended to remain in the RFC?