I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-rmt-flute-revised-10
Reviewer: Ben Campbell
Review Date: 2010-02-10
IETF LC End Date: 2010-02-10
IESG Telechat date: (if known)
Summary: This draft is almost ready for publication as a proposed standard.
However, I have some comments that should be addressed first.
Note: The last call notice asked for comments about normative downrefs to RFCs
1950, 1952, and 3738. I think those references are appropriate in this context.
Major issues:
-- This version of FLUTE has the same version number as in the previous,
experimental version. Is this version intended to be backwards compatible with
the previous one? If so, some words to that effect would be helpful. If not,
then the authors should consider incrementing the version number.
Minor issues:
-- section 1.1.3. first paragraph: "Any additional..."
Any additional? Can you be more specific?
-- section 3, 3rd bullet item:
I think there are enough exceptions to MIME types being inferable from file
extensions that it is best not to suggest that you can.
-- section 3, last paragraph:
The draft needs to say something about the order of layering between security
coding, content encoding, etc are sufficiently specified. For example, if I
want to encypt a file at the file level, and also compress it, should I encrypt
it first, then compress it. etc?
-- section 3.3, 5th bullet item:
Why is this not a MUST? Can you mention some example(s) of whereat might it be
reasonable for the sender send a file before the FDT that describes it?
-- section 3.3, 7th bullet:
How can they determine the epoch? I assume that this would be based on the fact
that expirations more than 136 years away are nonsensical, but it would be best
to say this explicitly.
-- section 3.3, 2nd paragraph from end:
It would be nice if you could offer more guidance than that. Is there anything
you can reference that would help an implementer think about how much
"reliability" is appropriate for different circumstances? Are there knobs that
an implementer should expose so an implementation can be adapted to the
circumstances of its use?
-- section 3.4.1, last paragraph:
I'm concerned about making reuse of an instance ID of an unexpired FDT out of
scope. What happens if the sender and receiver handle this differently? Does it
not introduce interop problems? (e.g. the sender assumes the new FDT replaces
the old one and the receiver ignores the new one since the old one is still
valid?)
-- section 3.4.2, paragraph 5:
Can you offer some guidance on what sort of URI schemes would make sense here?
For example, I can see "http", "file", etc. But would "mailto", "sip", etc make
sense?
-- section 3.4.2, first bullet:
I think the sender should always explicitly state the MIME type. Don't leave
this to the receiver to infer from the file name.
-- section 3.4.2, 2nd bullet:
Do you need normative statements about when content encoding must be described?
What does it mean if you don't describe it?
-- section 3.4.2, schema definition:
Do you mean for Expires to be a "string" type rather than a numeric type?
-- section 3.4.2, last paragraph:
Is there a requirement to use name spaces to scope any extensions?
It's not clear to me how the FDT is layered over packets, when you have more
than one packet for an FDT instance. Do you have a separate, well-formed XML
document for each packet, or one XML document that is split among packets? I
assume the second, but it would be best to be explicit.
-- section 5, first paragraph:
Is there any reason a sender would choose one method over another? Is there a
reason EXT_FTI is insufficient by itself?
-- section 7.5, 1st paragraph: "anti-replay services SHALL be used,"
Does the "SHALL be used" conflict with the first sentence in this paragraph,
which says "mandatory to implement but not necessarily to use"?
-- section 8, general:
Should EXT_FDT, EXT_CENC, and the encoding algorithms from EXT_CENC be
registered somewhere?
*** Nits/editorial comments:
section 1, 2nd and 3rd bullet list entries:
s/signalling/signaling
-- Section 1.1.1:
Please expand LCT on first mention.
-- section 1.1.4, 2nd paragraph:
Please expand WEBRC on first use.
-- section 3, first bullet list entry:
Do you really mean to say "may be globally unique"? I'm not objecting to it, it
just seems an odd thing to call out with strength less than SHOULD or MUST.
-- section 3, 4th bullet list entry:
s/bytes/octets
-- section 3.2, 4th paragraph from end: " An object that
is delivered within the ALC session, but not described in the FDT..."
Pedantic nit: you mean objects other than the FDT itself that are not described
in the FDT, right?
-- section 3.2, 3rd paragraph from end: "Any FDT Instance can be equal to, a
subset of, a
superset of, or complement any other FDT Instance."
I'm not sure I understand the previous sentence. Should I take this to mean
that an FDT can not overlap another, since that would not be equal, a superset,
a subset, or a complement? Or do you mean to say that any combination is okay?
-- section 3.3, 2nd paragraph after bullet list:
I find it a bit confusing to include a normative statement in an "example".
-- section 3,3, 3rd and 4th paragraphs from end: (starting with "The way FDT
Instances are transmitted...")
The last two paragraphs seem vaguely redundant to me. I think it's a lot of
words around saying that FDTs should be sent reliably, which was already said
in the paragraph prior to the previous 2. It might help to separate out the
normative statement about using FEC if there is more than one packet in an FDT.
-- section 3.3, last paragraph:
Am I correct in assuming that the most basic attributes must still be sent in
the FDT, even if other attributes are out-of-band?
-- section 3.4.2, first sentence after schema definition: "Any valid FDT
Instance must use the above XML Schema."
Was that meant to be normative?
-- section 3.5, 2nd paragraph : "... packets for
the FDT Instances MAY be interleaved."
I don't think you mean a normative MAY there, since you are describing
something that may happen, rather than something an implementation MAY do on
purpose.
-- section 7.1, last paragraph: " We finally
provide recommendations in Section 7.5."
There appear to be recommendations in some of the prior sections as well.
-- section 7.5, general:
Please avoid references of the form "in the sense of [23]." This makes the
reader flip to the references section to find out what you are talking about.
It's better to say "…in the sense of [mnemonic-reference]", and best to say "…
in the sense of <name>[reference]"
-- section 8.3.1, 1st and 2nd paragraph:
I'm confused--has IANA already established this, or does this document define
it?
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf