Re: AD Review: draft-ietf-rmt-flute-revised-11

Hi David et RMT

A partial response (since Jani and I were working on the SDP and managed to cover some of these points)...

Disclaimer: the documents are a result of some wonderful and amazing people doing lots of wonderful and amazing things for (mostly) people other than themselves. No ill feeling is intended in any possible nuance of the following (especially since I would have loved to have sent this 6 months ago, but even now the time is borrowed more from the family than the day job). Any co-authors with high blood pressure and desperation to close this already this month should open a bottle of wine before reading on...

In summary:
a,d,g - new text is better, not harmful and doesn't merit a version number change
b,c - not confident about new text, see comments and questions below
e,f,h - haven't checked properly. For h, probably won't check properly (FLUTE-SDP dependencies, especially hunting down any CC and sec links, already bring the paper mountain to us).

a) The XML schema mandated it to be UTF8 in the experimental, the new FLUTE text merely helps readability for folk in the strange subculture who don't enjoy reading XML. So there's no actual change in practice.

b) (Short version: we should revert to the original algorithm text plus the receiver mandated support). The algorithm is slightly different but does not break either old or new sender or receiver in either case. Note, the new "error" case really doesn't alter receiver behaviour, and the new algorithm allows wrapparound to a !="0" FDT number. However, since it is "is incremented by one for each subsequent FDT Instance" the probablility of x+1 (where x was the lowest expired instance) being also expired shortly after isn't very promising. Both old and new algorithms don't handle this well. Either the new algorithm needs additional text "after the first and subsequent wraparounds, subsequent new FDT instances should use the next higher expired FDT instance number until these are exhausted and then a wraparound is initiated once more" and live with the extra server complexity, or else we should do a reality check: 2^20-1 is a very big number, and any truly extreme server admins who "go for broke" on FDT instance IDs really ought to be responsible enough to configure expiry times that can handle that so that a state of "waiting for the next ID to timeout" won't occur. Based on this reality check, the initial text is more than adequate and the new text doesn't justify the extra complexity. However, the text "Receipt of an FDT Instance that reuses an FDT Instance ID value that is currently used by a non expired FDT Instance SHOULD be considered as an error case." is both harmless and useful and so should be included.

c) Yes, and why does it do this? For the experimental we had this design discussion: although an FDT with all possible files is useful, also an FDT declaring "no new files" is useful (e.g. for recievers which are satisfied that they have the required files from the session being able to free network and local resources dedicated to a multicast group). Given the potential of the aforementioned number 2^20-1, the new definition of an FDT with Complete=true isn't always going to yield beautiful and compact FDTs. Besides, the complete "flag" might be raised when some of the older files will no longer have any transmitted data (e.g. for transient images for program guides). The old meaning of "session additions are complete" makes more sense to me. What do I foolishly miss in rejecting the newer "this is a complete file list" meaning? (BTW, I am not missing the skinny spec approach of MBMS to only use Complete to list all files - but at the time of rel6 specification this profiling was a sensible choice for the application cases under discussion for MBMS. Although skinny specs are good for the IETF too, this case doesn't seem like a good candidate.)

d) The new text is exactly what was intended from the start, and (as far as I know) actual correct behaviour of experiemental senders and receivers. Anyone know otherwise? I was suprised to find in the experimental RFC only this mention "Identifier of the file, expressed as a URI.  This identifier may be globally unique." which is even WEAKENED to "Identifier of the file, expressed as a URI." in the new text! Point being that the URI must be unique to a specific file within the scope of a specific FLUTE session, and new instances of the same URI should be considered replaceable instances of the same functional content item - so we use TOI number order to indicate the version order and assist recievers not wishing to store and present all versions. The only exception to this behaviour is TOI 0 - used by FDT instances which aren't called files in FLUTE parlance and TOI 0 doesn't get a mention in FDT instances. So I suggest that practically, this is not a spec behaviour change and the new text is good and safe.

e & f) Correct observation. What was it about the original schema that defied backwards compatible extensibility? (In the original we worked this over and over to ensure forwards extensibility and compatibility - maybe we failed big time?) Jani & I haven't yet spent enough time on this to comment further, but we ought to...

g) Yes, although it doesn't change operation as such and the new text is better for implementers. Old receivers would know that the use of the field is "out of scope" and ought to see a non zero value as significant. Since no other scheme than the 0123 in the new text has appeared, we should not be breaking anything. At the same time it adds useful info and more specific/tight compatibility. So it's a good (not version changing) improvement. The only thing funky is that FLUTE _still_ is making the EXT_CENC definition when, as agreed a long time ago, the header is generally useful to LCT and ALC. But the IANA registration deals with this - so it seems in perfect order.

h) LCT (and thus ALC & FLUTE) changed SCT and ERT header formats potentially breaking "new" receivers getting sessions from "old" senders - see our previous email (point/question 5). In fairness, normal internet nodes will have NTP clock-sync and wireless multicast notes will get broadcast clock sync, and session descriptors will afore warn of session end times, so SCT and ERT are possibly not popular in prior implementations and the problem is likely to be a corner case - but real nevertheless, especially as it allows FLUTE sessions to be totally self contained and only minimally rely on out-of-band systems/control.

h1) I don't know of other problems from the RMT references. I guess this kind of audit was already performed?

h2) [RFC5651] and [RFC.LCT] are both normative references. 10 free beers for the first to spot five differences! ;)

h3) should [RFC.ZLIB], [RFC.DEFLATE], [RFC.GZIP] really be normative? - you can perfectly well understand the spec without reading those, and no unwritten parts of this spec are inherited from them. I suggest moving to informative. (As with my previous email - flame me on IETF Tao as you find appropriate).

Cheers, Rod & Jani

PS I probably mixed the "we" and "I" to a confusing level. Live with it. We will :)


ext David B Harrington wrote:

Hi,

I have concerns that this specification might not be totally backward
compatible with version 1 (RFC3926), and should therefore have a new
revision number.

        a) The expiration time in the FDT instance is now required to
be UTF8, but was not so required in RFC3926

        b) section 3.4.1 describes a different wraparound algorithm
than RFC3926

        c) section 3.4.2 modifies the meaning of "Complete"

        d) section 3.4.2 modifies the meaning of "Content Location"

        e) section 3.4.2 modifies the namespace, and significantly
alters the XML Schema. I think an implementation which is valid using
the schema in RFC3926 would not necessarily validate using the schema
in this draft.

        f) section 3.4.2 modifies the requirement
                   In case the basic FDT XML Schema is extended in
terms of new
   descriptors, for attributes applying to a single file, those MUST
be
   placed within the attributes of the element "File".
to
   In case the basic FDT XML Schema is extended in terms of new
   descriptors (attributes or elements), for descriptors applying to a
   single file, those MUST be placed within the element "File".

        g) section 4 modifies the definition of the CENC field:
   "This field signals the content encoding algorithm used in the FDT
   Instance payload.  The definition of this field is outside the
scope
   of this specification.  Applicable content encoding algorithms
   include, for example, ZLIB [10], DEFLATE [16] and GZIP [17]."
to
   "This field signals the content encoding algorithm used in the FDT
   Instance payload.  This subsection reserves the Content Encoding
   Algorithm values 0, 1, 2 and 3 for null, ZLIB [RFC.ZLIB], DEFLATE
   [RFC.DEFLATE] and GZIP [RFC.GZIP] respectively."

        h) normative references have changed, and it is possible that
those specifications
         have changed such that rfc3926-compliant implementations may
not be compliant
         per this draft.

I didn't spot anything I thought was problematic if the version#
changed.

I do think that this spec is rather loose, and really should be
tightened for interoperability for proposed standard.

David Harrington
[email protected]<mailto:[email protected]>
[email protected]<mailto:[email protected]>
[email protected]<mailto:[email protected]>


_______________________________________________
Rmt mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/rmt

_______________________________________________
Rmt mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rmt