FLUTE - File Delivery over Unidirectional Transport
RFC 6726

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

(Peter Saint-Andre) Discuss

Discuss (2012-02-29 for -13)
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 http://www.ietf.org/mail-archive/web/ietf-types/current/maillist.html

2. The IANA Considerations section is missing a registration of the "urn:ietf:params:xml:ns:fdt" namespace.
Comment (2012-02-29 for -13)
No email
send info
1. Why does the "Expires" attribute have a datatype of "xs:string"? Given that it is the UTF-8 decimal representation of a 32 bit unsigned integer, "xs:unsignedInt" might be more appropriate.

2. Did you consider assigning a default value for the "Complete" attribute? Presumably it defaults to FALSE, but it would be good to make that clear. (You might also consider mentioning that there are two lexical representations for boolean in W3C XML Schema, '1' or 'true' for TRUE and '0' or 'false' for FALSE.)

3. The terms "MIME field name" and "MIME field body" are never defined. Perhaps a reference to RFC 2045 is in order?

4. Please change "MIME type" and "MIME media type" to "media type".

5. In Section 3.5, you have "due to unexpected network conditions, packets for the FDT Instances MAY be interleaved" -- I think you mean "might", not "MAY".

6. The lack of a mandatory-to-implement integrity protection mechanism in Section 7.2.2 might harm interoperability. The same is true of Section 7.3.3 and Section 7.3.4. It is not completely clear to me whether Section 7.5 fills that gap.

7. Citing RFC 3470 might be appropriate in the security considerations.

(Wesley Eddy) Yes

(David Harrington) Yes

(Martin Stiemerling) Yes

(Jari Arkko) No Objection

(Ron Bonica) (was Discuss, No Objection) No Objection

Comment (2012-02-29)
No email
send info
Also concerned about the IPR situation, but Stephen holds the DISCUSS

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

Comment (2012-02-29 for -13)
No email
send info
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.

(Adrian Farrel) No Objection

Comment (2012-02-29 for -13)
No email
send info
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 :-)

(Stephen Farrell) (was Discuss) No Objection

Comment (2012-06-13 for -15)
No email
send info
(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?

(Russ Housley) No Objection

Comment (2012-03-01 for -13)
No email
send info
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

(Barry Leiba) (was Discuss) No Objection

Comment (2012-06-27)
No email
send info
Version -16 resolves the remaining IANA registration issues.  Good to go, and thanks for working with me on this.

(Dan Romascanu) No Objection

Comment (2012-02-27 for -13)
No email
send info
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.

(Robert Sparks) (was Discuss) No Objection