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

[Ballot comment]
(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?

[Ballot discuss]
I'm picking up Peter St Andre's DISCUSS on this, which involves two IANA registration issues:

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

[22 May: Vincent Roca says "Okay. I'm preparing an email for the ietf-types list ASAP."]

2. The IANA Considerations section is missing a registration of the
"urn:ietf:params:xml:ns:fdt" namespace.

[21 May: Vincent Roca notes that IANA made the same comment, and proposes text.]

[Ballot discuss]
#1 cleared

#2 cleared

#3 7.5 calls for IPsec in transport mode as the main security
measure and also automated key management which basically means IKE
- am I reading that right? Does that actually match the use-cases
for FLUTE?  Where's the unidirectional aspect gone?  If this
doesn't match any reasonable FLUTE use-case then don't we end up
with no security in practice? I'm not sure what, if any, change
might be needed, but I'd first like to understand the reality.

[Ballot comment]

(A bunch of these were addressed in -14, I didn't go through 'em though)

- 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?

[Ballot discuss]
#1 cleared

#2 p20 - why Content-MD5? What's that used for? Is there alg
agility? If not, why not (in a standard). If this isn't really
needed or useful then why not just deprecate it for the PS version
of FLUTE or replace it with something else? Section 7 is quite good
btw, but if you do keep Content-MD5 then don't you need to consider
a bad (or spoofed) sender that sends different folks different
(chunks of) files that are MD5 collisions?

#3 7.5 calls for IPsec in transport mode as the main security
measure and also automated key management which basically means IKE
- am I reading that right? Does that actually match the use-cases
for FLUTE?  Where's the unidirectional aspect gone?  If this
doesn't match any reasonable FLUTE use-case then don't we end up
with no security in practice? I'm not sure what, if any, change
might be needed, but I'd first like to understand the reality.

[Ballot comment]
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

[Ballot discuss]
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.

[Ballot comment]
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.

[Ballot discuss]
#1 The IPR situation here appears complex. This obsoletes the
experimental 3296 which has no IPR declarations. A common author
for this and 3926 is an inventor of IPR declared in 2006 on this
document.  Could I get a pointer to where the WG was informed of
and/or considered this?  (Had a quick look, didn't find it.) Is it
(still) the case that 3926 is not considered to require an IPR
declaration but this document does?  Reading section 11, I don't
see much change here so as a result, I'm unclear as to whether the
meta-data for these documents is consistent and considered so by
the WG.

So this may be more of a tools issue perhaps - if the new declaration
supercedes the old then maybe the tools page for the RFC forgets the
old IPR declaration or something. I'll keep the discuss so's we can
figure that out.

  http://datatracker.ietf.org/ipr/731/ is a declaration on RFC 3926 as
  it turns out.

#2 p20 - why Content-MD5? What's that used for? Is there alg
agility? If not, why not (in a standard). If this isn't really
needed or useful then why not just deprecate it for the PS version
of FLUTE or replace it with something else? Section 7 is quite good
btw, but if you do keep Content-MD5 then don't you need to consider
a bad (or spoofed) sender that sends different folks different
(chunks of) files that are MD5 collisions?

#3 7.5 calls for IPsec in transport mode as the main security
measure and also automated key management which basically means IKE
- am I reading that right? Does that actually match the use-cases
for FLUTE?  Where's the unidirectional aspect gone?  If this
doesn't match any reasonable FLUTE use-case then don't we end up
with no security in practice? I'm not sure what, if any, change
might be needed, but I'd first like to understand the reality.

[Ballot comment]
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.

[Ballot discuss]
** Downref: Normative reference to an Informational RFC: RFC 1950
** Downref: Normative reference to an Informational RFC: RFC 1952
** Downref: Normative reference to an Experimental RFC: RFC 3738

None of these appear in the downref registry

[Ballot comment]
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 :-)

Editors, please address these comments from the LC:

-------- Original Message --------
Subject: Re: Last Call:  (FLUTE -
File Delivery over Unidirectional Transport) to Proposed Standard
Date: Mon, 20 Feb 2012 20:49:57 +0100
From: Julian Reschke
To: ietf@ietf.org

On 2012-02-11 01:48, The IESG wrote:

The IESG has received a request from the Reliable Multicast Transport WG
(rmt) to consider the following document:
- 'FLUTE - File Delivery over Unidirectional Transport'
      as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-02-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
...

Here are a few comments, mainly of editorial nature:

Below my review notes; just mechanical checks, and some checks on the
relation to HTTP header fields...:

Section 3:

"File name (usually, this can be concluded from the URI). In the above
example: "file.txt"."

...or the Content-Disposition header field (RFC 6266).

"File type, expressed as MIME media type. In the above example:
"text/plain"."

s/MIME media type/internet media type/


3.4.2:

"Where the MD5 message digest is described, the attribute "Content-MD5"
MUST be used for the purpose as defined in [RFC2616]."

Note that Content-MD5 is gone from HTTPbis.

XML-Schema: I believe the spec should state what to do with invalid
input. Are there extension points (like ignoring unknown elements in
extension namespaces)?

"It is RECOMMENDED that the new attributes applied in the FDT are in the
format of MIME fields and are either defined in the HTTP/1.1
specification [RFC2616] or another well-known specification."

As this is a normative requirement it needs to be clarified what header
fields are used? HTTP? MIME?

Also, well-known is irrelevant, we have a registry for header fields.

8.1:

Actually, what's requested is a URN for the XML namespace
("urn:ietf:params:xml:ns:fdt"). That's fine; I don't think the XML
schema needs to be registered. Otherwise, see
.

8.2:

Has the media type registration been reviewed on ietf-types?

8.3:

You need to define the IANA procedure (see RFC 5226).

Appendix B:

The example contains a schemaLocation with a relative (URI) reference
("ietf-flute-fdt.xsd"). That's misleading, right?


References:

Please cite W3C spec with their full details, like this:



Speaking of which; shouldn't you cite the Second Edition?

[RMT-SIMPLE-AUTH]: this should be cited using the default ID style, in
which case xml2rfc will add the helpful "work-in-progress" label

Should RFC2357 be in the references?

You may want to cite RFC3986 (URI).

Formatting: I note that in-document links haven't been generated using
xml2rfc's linking features; this way references to section numbers can
break easily. I did not check those.

Best regards, Julian

[Ballot discuss]
In 3.4.2, Content-Location MUST be assigned a valid URI. What does "valid" mean in this context. Does it mean anything more than well-formed? In particular, if the URI is in a scheme that has GET semantics, does "valid" mean you can get the document that way? What does an implementation do if it sees a scheme it doesn't understand? (URI comparison is scheme-specific - it would be dangerous to an implementation to assume two URIs meant different things if it doesn't understand the scheme). If all you need is a unique identifier, what's the advantage of allowing arbitrary schemes to provide it?

In the discussion of handling time wraparound, "can determine" seems problematic. How do you have interoperability unless both the receiver and the sender interpret this the same way?

The XML Schema registration (section 8.1) should provide a URI.

The document needs clearer discussion around the reuse of FDT Instance IDs. I hope I've misunderstood a fundamental idea and a simple clarification will address the following questions.

* Is the intent that IDs increment by one again after wraparound? Or once wraparound happens, do you always select the next ID using "the smallest FDT Instance value" (you mean ID value, yes?) "assigned to an expired FDT Instance". If the later, then both the receiver and the sender will have to keep an explicit ordering based on when reassignments were received - in the extreme it would be possible to construct a degenerate case where the ordering ended up completely reversed (...,5,4,3,2,1) by using a set of decreasing expiration times as the ID space is traversed the first time. I realize a sender wouldn't really do that, but it's enough that it only have a couple of elements in the sequence that aren't in increasing order. That should be made clearer, particularly where you talk about the ordering being used (such as when describing the semantics for any two "File" elements declaring the same "Content-Location" but differing "TOI"). It would also help to summarize where the ordering is actually used by the protocol.

* How would a receiver that joined after the sender started reusing IDs know that had happened? If it can't, the consequence is that all receivers have to keep track of what order they received FDTs in from whenever they join.

* Since it's possible for a receiver to miss FDT instances, once wraparound starts it looks like its possible for two different receivers to have a different idea of what's "newer". Does that break anything?

* Currently, receipt of an instance that reuses the id from a non-expired instance SHOULD be considered an error. When would the reciever _NOT_ consider this an error? Why is the document leaving receiver behavior out of scope? This seems to invite interoperability failure in deployed systems.

[Ballot discuss]
DISCUSS

In 3.4.2, Content-Location MUST be assigned a valid URI. What does "valid" mean in this context. Does it mean anything more than well-formed? In particular, if the URI is in a scheme that has GET semantics, does "valid" mean you can get the document that way? What does an implementation do if it sees a scheme it doesn't understand? (URI comparison is scheme-specific - it would be dangerous to an implementation to assume two URIs meant different things if it doesn't understand the scheme). If all you need is a unique identifier, what's the advantage of allowing arbitrary schemes to provide it?

In the discussion of handling time wraparound, "can determine" seems problematic. How do you have interoperability unless both the receiver and the sender interpret this the same way?

The XML Schema registration (section 8.1) should provide a URI.

The document needs clearer discussion around the reuse of FDT Instance IDs. I hope I've misunderstood a fundamental idea and a simple clarification will address the following questions.

* Is the intent that IDs increment by one again after wraparound? Or once wraparound happens, do you always select the next ID using "the smallest FDT Instance value" (you mean ID value, yes?) "assigned to an expired FDT Instance". If the later, then both the receiver and the sender will have to keep an explicit ordering based on when reassignments were received - in the extreme it would be possible to construct a degenerate case where the ordering ended up completely reversed (...,5,4,3,2,1) by using a set of decreasing expiration times as the ID space is traversed the first time. I realize a sender wouldn't really do that, but it's enough that it only have a couple of elements in the sequence that aren't in increasing order. That should be made clearer, particularly where you talk about the ordering being used (such as when describing the semantics for any two "File" elements declaring the same "Content-Location" but differing "TOI"). It would also help to summarize where the ordering is actually used by the protocol.

* How would a receiver that joined after the sender started reusing IDs know that had happened? If it can't, the consequence is that all receivers have to keep track of what order they received FDTs in from whenever they join.

* Since it's possible for a receiver to miss FDT instances, once wraparound starts it looks like its possible for two different receivers to have a different idea of what's "newer". Does that break anything?

* Currently, receipt of an instance that reuses the id from a non-expired instance SHOULD be considered an error. When would the reciever _NOT_ consider this an error? Why is the document leaving receiver behavior out of scope? This seems to invite interoperability failure in deployed systems.

[Ballot comment]
The last paragraph of 3.4.2 says it is RECOMMENDED that new attributes are defined in 2616 or a well-known specification. RECOMMENDED is a synonym for SHOULD. It would help to describe why this isn't REQUIRED in the document.

In the last paragraph of section 3.3 (which talks about using out-of-band mechanisms for communicating attributes associated with files), consider reinforcing that using such an out-of-band mechanism does not make sending FDT instances in the session optional.

The section on Intended Environments claims FLUTE is applicable for non-Internet systems, providing an example, but no support for the claim. Consider editing this to say something less subjective, like "FLUTE has also been adapted for use in other network architectures, such as..." and if possible, provide a reference.

The document never explicitly says when the application/fdt+xml media type gets used.

I'm a little surprised there's not a registry around that already assigns codepoints to encoding (particularly compressing encoiding) algorithms. The closest I could find is  which doesn't establish codepoints. Please consider reconciling with that registry.

NIT: Section 3.1 has a list of rules. Several of the bullets in the list are not actually rules. Consider moving those to an introductory paragraph before the actual rules.

[Ballot discuss]
#1 The IPR situation here appears complex. This obsoletes the
experimental 3296 which has no IPR declarations. A common author
for this and 3926 is an inventor of IPR declared in 2006 on this
document.  Could I get a pointer to where the WG was informed of
and/or considered this?  (Had a quick look, didn't find it.) Is it
(still) the case that 3926 is not considered to require an IPR
declaration but this document does?  Reading section 11, I don't
see much change here so as a result, I'm unclear as to whether the
meta-data for these documents is consistent and considered so by
the WG.

#2 p20 - why Content-MD5? What's that used for? Is there alg
agility? If not, why not (in a standard). If this isn't really
needed or useful then why not just deprecate it for the PS version
of FLUTE or replace it with something else? Section 7 is quite good
btw, but if you do keep Content-MD5 then don't you need to consider
a bad (or spoofed) sender that sends different folks different
(chunks of) files that are MD5 collisions?

#3 7.5 calls for IPsec in transport mode as the main security
measure and also automated key management which basically means IKE
- am I reading that right? Does that actually match the use-cases
for FLUTE?  Where's the unidirectional aspect gone?  If this
doesn't match any reasonable FLUTE use-case then don't we end up
with no security in practice? I'm not sure what, if any, change
might be needed, but I'd first like to understand the reality.

[Ballot comment]
- 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?

[Ballot comment]
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.

IANA has questions about draft-ietf-rmt-flute-revised-13.txt:

QUESTIONS: This document tells us to make a registration in the IETF XML
schema registry, but doesn't provide the URI. I assume the correct URI
is urn:ietf:params:xml:schema:fdt, since the XML in section 3.4.2 refers
to "urn:ietf:params:xml:ns:fdt." However, the document does not ask us
to make a corresponding "urn:ietf:params:xml:ns:fdt" registration in the
IETF XML ns registry
(http://www.iana.org/assignments/xml-registry/ns.html). Does an ns
registration template need to be added to the IANA Considerations
section? Is "fdt" in fact the name of the schema registration?

ACTION 1:

Upon approval of this document, IANA will make the following IETF XML
schema registration at
http://www.iana.org/assignments/xml-registry/schema.html
with this document as the reference:

Name: fdt (??)
URI: urn:ietf:params:xml:schema:fdt (??)
File: [per section 3.4.2 of this document]


ACTION 2:

Upon approval of this document, IANA will register the following
application media type at
http://www.iana.org/assignments/media-types/application/index.html

fdt+xml [RFC-to-be]


ACTION 3:

Upon approval of this document, IANA will create the following registry
in a new "FLUTE" registry page to be listed under the "Reliable
Multicast Transport (RMT) Parameters" header at
http://www.iana.org/protocols. If this new registry should be placed in
an existing page, or listed under another header, please let us know.

Registry Name: FLUTE Content Encoding Algorithm
Registration Procedures: Specification Required
Reference: [RFC-to-be]

Value Description Reference
0 null [RFC-to-be]
1 ZLIB [RFC1950]
2 DEFLATE [RFC1951]
3 GZIP [RFC1952]
4-255 Unassigned


ACTION 4:

IANA will register the following LCT Header Extension Types at
http://www.iana.org/assignments/lct-header-extensions

192 EXT_FDT LCT [RFC-to-be]
193 EXT_CENC LCT [RFC-to-be]

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (FLUTE - File Delivery over Unidirectional Transport) to Proposed Standard


The IESG has received a request from the Reliable Multicast Transport WG
(rmt) to consider the following document:
- 'FLUTE - File Delivery over Unidirectional Transport'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-02-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines FLUTE, a protocol for the unidirectional
  delivery of files over the Internet, which is particularly suited to
  multicast networks.  The specification builds on Asynchronous Layered
  Coding, the base protocol designed for massively scalable multicast
  distribution.  This document obsoletes RFC3926.

This document contains downrefs:
It creates a registry that includes values for content encoding
algorithms defined in Informational RFCs 1950, 1951, and 1952.
It discusses a potential weakness created by using WEBRC
congestion control, a mandatory to implement algorithm for ALC.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-rmt-flute-revised/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-rmt-flute-revised/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/733/

draft-ietf-rmt-flute-revised-12 AD Followup

1) in Introduction, it says version "may not be"
to avoid confusion, please use might not.
better yet, state whether it is or is not backwards compatible. I can submit this as is, but I expect it will get pushback from other IESG members for being unclear. If there is a lack of  WG consensus on this point, then document that in the shepherd writeup.
2) in 3.1, s/MAY NOT/might not/
3)    "The TOI value of '0' MUST be reserved for delivery of FDT Instances.  The use of other TOI values for FDT Instances is outside the scope of this specification." Shouldn't this specification at least define the range and type of values; are these integer values? If it is not in scope for THIS specification, what specification is it in scope for?
4) This document defines new extensions to LCT and ALC; should this be declared as Updates LCT and ALC?
5) " In any case, both a sender and a receiver can determine to which (136 year) epoch the FDT Instance expiration time value pertains to by choosing the epoch for which the expiration time is closest in time to the current time." Can you provide an example? I find this unclear. I am especially unclear about edge cases, such as for when the expiration time and current time are in different epochs.
6)    "The space of FDT Instance IDs is limited"; where is this space limit specified?
7) "  *  The receiver SHOULD NOT use a received FDT Instance to interpret" - SHOULD implies there are valid reasons nto to comply with this rule. What are the valid exceptions? or should this be a MUST NOT?
8) "should achieve" and "should be delivered"; are these RFC2119 shoulds? if so please capitalize; if not please change the wording.
9) "  Senders SHOULD NOT re-use an FDT Instance ID value that is already in" why not MUST NOT?
"value that is currently used by a non expired FDT Instance SHOULD be considered as an error case." why not MUST?
10) in 3.4, the field SHOULD be ignored. why not MUST?
11) 3.1 says compliant implementations MUST set the flute version to 2; 3.4.1 says something similar.
section 6 says the information is optional. these seem contradictory.

Comment:
1) 1.1.4 missing period at end of sentence.
2) references are out of date, because I took so long to followup. idnits tools can help identify the needed updates.
3) LCT needs expansion on first use
4) in 3.2, is unmapped TOI handlng described elsewhere, such as in LCT or ALC?
I think the IESG could push back on why isn't this an error with a defined response by the receiver. It would help if the text was explicit about the handling, or explained why the situation could occur in compliant implementations.
5) s/may be lost/might be lost/

General agreement within IESG is that a new version# is needed since the new draft is not backwards compatible with the experimental specs.

If you want to keep the same version#, we will need to make a convincing argument.
"People already implemented from the internet draft" is not likely to be convincing.

I haven't gotten any response to my questions (below).
These are questions that other IESG members have asked.
Please provide answers to these questions.

dbh

> -----Original Message-----
> From: rmt-bounces@ietf.org [mailto:rmt-bounces@ietf.org] On Behalf Of
> David B Harrington
> Sent: Thursday, June 10, 2010 4:32 PM
> To: 'Watson, Mark'
> Cc: rmt@ietf.org
> Subject: Re: [Rmt] AD Review: draft-ietf-rmt-flute-revised-11
>
> Hi,
>
> see draft-ietf-rmt-flute-revised-11, section 1, paragraph 1,
sentence
> 2:
> "This specification is backwards compatible with the previous
> experimental version defined in
>    [RFC3926]."
>
> If backwards compatibility is NOT a goal, then you should state
that.
>
> Question: is the Experimental version deployed in real-world networks
> and products? Is it normatively referenced in other standards?
> Question: if both the Experimental and this specification are deployed
> in the same network, will they work interoperably?
> will they interfere with each other?
>
> dbh

IANA questions/comments:

Upon approval of this document, IANA will perform the following actions.

ACTION 1:

make the following assignment in the registry "IETF XML Registry",
sub-registry "Schema" located at
http://www.iana.org/assignments/xml-registry/schema.html

ID URI Filename Reference
--- ------------------------------ -------- --------------------------
fdt urn:ietf:params:xml:schema:fdt fdt [RFC-rmt-flute-revised-10]

The schema will be extracted from Section 3.4.2 between the keywords
"BEGIN" and "END".

QUESTION: the schema definition in section 3.4.2 assumes the following
namespace: urn:ietf:params:xml:schema:fdt. However, the IETF XML
registry for namespaces currently does not include that assignment.
Should IANA also registers that namespace? If so, please provide the
appropriate template.


ACTION 2:

make the following assignment in the "Application Media Types" registry
at http://www.iana.org/assignments/media-types/application.

fdt+xml [RFC-rmt-flute-revised-10]


ACTION 3:

create the following registry at
http://www.iana.org/assignments/TBD.

Registry name: FLUTE Content Encoding Algorithms
Registration Procedure: Specification Required

Value Description
0 null
1 ZLIB
2 DEFLATE
3 GZIP
4-255 Unassigned

Document Shepherd Write-Up for "draft-ietf-rmt-flute-revised-06" intended for
publication in the "Proposed Standard" category.

This writeup complies with RFC 4858


  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Document Shepherd is Brian Adamson, who has personally reviewed this
version of the document and believes it is ready for forwarding to the
IESG for publication. 

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document had adequate review by key WG members.  The document has been
reviewed by multiple WG members and has been updated to reflect their
comments.  There are no unresolved issues.  The Experimental RFC3926 upon
which this revision is based was thoroughly reviewed. 

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

No additional reviews needed.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

Nokia Corporation has filed an IPR statement (see
  for the specific statement.  The  RMT
working grouphttps://datatracker.ietf.org/ipr/733/ has discussed this IPR
statement.  There is considerable  interest in the FLUTE specification and is
being applied commercially.  The specification provides a reference application
of the RMT ALC and LCT protocols.  The RMT working group has consensus that
this specification should be  published regardless of the IPR claim.
Additionally, the working group is considering a draft "FCAST" specification
that provides a lighter-weight, more tightly scoped application use case than
the FLUTE specification and should be free of IPR claims.  The FCAST
specification could provide an IPR-free alternative to FLUTE for some
applications.s


  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

This document represent a solid consensus of the RMT WG.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No discontent of significant concern have been raised about this
document.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

The Document Shepherd has personally verified that the document satisfies all
ID nits.

"draft-ietf-rmt-flute-revised-06" is intended for publication in the
"Proposed Standard" category.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The document splits its references into normative and
informative. The normative references are in RFC published status.
There are no downward references.

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

The IANA consideration section exists.  The IANA requirements are clearly
described.  All assignment requests are in compliance with RFC2434 and the
appropriate IETF actions are specified.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

The documents contains no section written in formal language.

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

          Working Group Summary
            Was there anything in the WG process that is worth noting?
            For example, was there controversy about particular points
            or were there decisions where the consensus was
            particularly rough?

          Document Quality
            Are there existing implementations of the protocol?  Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?  If
            there was a MIB Doctor, Media Type, or other Expert Review,
            what was its course (briefly)?  In the case of a Media Type
            Review, on what date was the request posted?

          Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?  If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are .'

Document Announcement Write-Up for draft-ietf-rmt-flute-revised-06 follows.

Technical Summary

  This document specifies an application-layer protocol to support File
  delivery over Unidirectional Transport (FLUTE) suitable for Reliable
  Multicast Transport (RMT) and other uses. The specification builds on the
  Asynchronous Layered Coding (ALC) protocol specification, the base protocol
  designed for massively scalable multicast distribution.  ALC defines
  transport of arbitrary binary objects.  The FLUTE specification specifies
  mechanisms for signaling and mapping the properties of file objects to
  concepts of ALC in a way that allows receivers to assign those parameters
  for received objects.  Although this specification frequently makes use of
  multicast addressing as an example, the techniques are similarly applicable
  for use with unicast addressing.

Working Group Summary

    There is consensus in the WG to publish this documents.

Document Quality

    The document is of high quality and has been subject to extensive review in
    its Internet Draft and Experimental RFC forms.  The revised draft
    represents a modest set of changes from the original Experimental RFC
    3926.  These changes are clearly described in the document.

    Open source implementations of the FLUTE application are available and
    considerable experience in using this protocol has been accumulated. The
    protocol has been adopted by the Digital Video Broadcasting (DVB) industry
    consortium for content delivery.

    The content of this document was already reviewed and approved for
    publication as experimental RFC 3926. This document contains some
    technical modifications to that specification that are consistent with
    revisions to the suite of RMT experimental protocols that are
    being moved forward as IETF "Proposed Standard" documents.

Personnel

    Brian Adamson is the Document Shepherd.
    Magnus Westerlund is the Responsible Area Director.