Skip to main content

FLUTE - File Delivery over Unidirectional Transport
RFC 6726



(David Harrington)
(Martin Stiemerling)
(Wesley Eddy)

No Objection

(Gonzalo Camarillo)
(Jari Arkko)
(Robert Sparks)
(Stewart Bryant)

Note: This ballot was opened for revision 13 and is now closed.

Peter Saint-Andre Former IESG member
Discuss [Treat as non-blocking comment] (2012-02-29 for -13) Unknown
Other reviewers have expressed many of the concerns I had. Here are a few additional topics I'd like to chat about.

1. Apparently the application/fdt+xml media type was not reviewed on the ietf-types list, per RFC 4288. At least I see no request for a review in the archives at

2. The IANA Considerations section is missing a registration of the "urn:ietf:params:xml:ns:fdt" namespace.
David Harrington Former IESG member
Yes () Unknown

Martin Stiemerling Former IESG member
Yes (for -15) Unknown

Wesley Eddy Former IESG member
Yes (for -13) Unknown

Adrian Farrel Former IESG member
No Objection
No Objection (2012-02-29 for -13) Unknown
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


Seciton 9 ends a little suddenly :-)
Barry Leiba Former IESG member
(was Discuss) No Objection
No Objection (2012-06-27) Unknown
Version -16 resolves the remaining IANA registration issues.  Good to go, and thanks for working with me on this.
Dan Romascanu Former IESG member
No Objection
No Objection (2012-02-27 for -13) Unknown
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.
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -13) Unknown

Jari Arkko Former IESG member
No Objection
No Objection (for -13) Unknown

Ralph Droms Former IESG member
No Objection
No Objection (2012-02-29 for -13) Unknown
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

   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.
Robert Sparks Former IESG member
(was Discuss) No Objection
No Objection (2012-06-13 for -15) Unknown

Ron Bonica Former IESG member
(was Discuss, No Objection) No Objection
No Objection (2012-02-29) Unknown
Also concerned about the IPR situation, but Stephen holds the DISCUSS
Russ Housley Former IESG member
No Objection
No Objection (2012-03-01 for -13) Unknown
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.
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2012-06-13 for -15) Unknown
(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.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

- 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

- 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?
Stewart Bryant Former IESG member
No Objection
No Objection (for -13) Unknown