Subject: [Rmt] FLUTE revised 12

From: "Luby, Michael" <[email-masked]>
Date: Fri, 4 Feb 2011 07:39:31 -0800

David, Other RMTers,

There is now version 12 of FLUTE revised available as an Internet Draft.  The major change in version 12 compared to version 11 is to change the FLUTE version number from 1 to 2.  This was changed in all the references to the FLUTE version, and there is wording added to Section 3.1 on the requirements around the FLUTE version number in operation for both senders and receivers.  Also, the FLUTE version number is added as an optional parameter in Section  6.  The change log in Section 11 is also updated.  There are also a few grammatical fixes/improvements/clarifications.

I would like to thank Don Gillies for spending the time and enthusiastically getting up to speed on FLUTE (and also ALC and LCT and FEC BB) in a detailed way and helping to carefully craft the changes in this late stage draft, he did a wonderful job (and in the final RFC he should be thanked in the acknowledgements for his contributions).  However,  I take complete responsibility for all errors or issues that are introduced into this version 12 from version 11.  (So, read it over carefully and make sure that it is ok, etc.).

Thanks, Mike

---

From: <[email-masked]>
Date: Sun, 6 Feb 2011 19:52:52 +0100

Hi all

Do we have an answer on the question: why is a non-backwards compatible FDT schema necessarily?

 (I.e. I am concerned that the right path forward might be to discard changes which remove backwards compatibility, and so far we are collectively ignoring this elephant in the room. What did I miss?)

Cheers, Rod.

On 4 Feb 2011, at 17:40, "ext Luby, Michael" <[email-masked]<mailto:[email-masked]>> wrote:

David, Other RMTers,

Thanks, Mike
_______________________________________________
Rmt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rmt

---

From: "Luby, Michael" <[email-masked]>
Date: Sun, 6 Feb 2011 14:30:31 -0800

Hi Rod,
A good place to start is to look at section 11, the change log.  A lot of the changes were across the different specs (ALC & LCT and FEC BB), moving the functionality around from FLUTE to LCT or ALC, etc.  These changes are really difficult to undo the already existing revised RFCs for LCT, ALC and FEC BB.  Also, some XML changes, etc.

What is your main concern with having this be FLUTE version 2 instead of FLUTE version 1?
Best, Mike

On 2/6/11 10:52 AM, "Rod Walsh" <[email-masked]> wrote:

Hi all

Cheers, Rod.

On 4 Feb 2011, at 17:40, "ext Luby, Michael" <[email-masked]> wrote:

David, Other RMTers,

Thanks, Mike
[email-masked]

---

From: Jani Peltotalo <[email-masked]>
Date: Mon, 07 Feb 2011 08:52:58 +0200

Hi Mike,

Rod's main question is why the FDT Instance XML schema is modified. All
other changes are backwards compatible, since LCT and ALC version
numbers are not changed.

An FDT instance according to the old schema can look like below:

<FDT-Instance Expires="3506420475">
   <File TOI="1"
      Content-Location="file:///home/user/RFCs/rfc5775.txt"
      Content-Length="59518"
      Content-MD5="7UxYyGyH2m8csPm2opRDJw=="
      FEC-OTI-FEC-Encoding-ID="0"
      FEC-OTI-Maximum-Source-Block-Length="64"
      FEC-OTI-Encoding-Symbol-Length="1428"/>
</FDT-Instance>

An according to the new schema it is possible to also have other
elements inside FDT-Instance, like below:

<FDT-Instance Expires="3506420475">
   <File TOI="1"
      Content-Location="file:///home/user/RFCs/rfc5775.txt"
      Content-Length="59518"
      Content-MD5="7UxYyGyH2m8csPm2opRDJw=="
      FEC-OTI-FEC-Encoding-ID="0"
      FEC-OTI-Maximum-Source-Block-Length="64"
      FEC-OTI-Encoding-Symbol-Length="1428"/>
   <Some-Extension foo="bar"/>
</FDT-Instance>

This new FDT Instance will be discarded by the old receivers, since
there is no information what to do with unknown elements. So is there
really need for this extension? In the old schema it is possible to have
private attributes, but not private elements.

BR,
Jani

---

From: <[email-masked]>
Date: Mon, 7 Feb 2011 08:57:52 +0100

Hi Mike

Jani nailed the FDT question. (By definition, flute delivers discrete media objects - files - and so there immeasurable ways to extend FLUTE by using specific mime type files, dedicating TOIs to specific purposes and other out-of-the-scope-of-this-document add-ins. Thus, I guess that modifying the FDT schema in a non backwards compatible manner was an error of process which we need to correct. Otherwise, the RMT achievement of making a single IETF defined multicast file delivery protocol common across all relevant SDOs would be laid to waste, which is clearly against the goal of the RMT revised documents.)

The other essential thing is that, as far as I can work out, all the other flute-revised modifications _are_ backwards compatible. If I didn't miss something, then the undefined extra elements extension feature in FDTs seems insufficient reward to break backwards compatibility.

As for changes upstream (alc/lct), they both remain both backwards compatible and version 1 - right?

Cheers, Rod.

---

From: "Luby, Michael" <[email-masked]>
Date: Mon, 7 Feb 2011 00:21:22 -0800

All,

Here is an example of what I think causes an issue.  The LCT header changed
between RFC3451 and RFC5651.  In RFC3451 there is the T and R fields in bits
12, 13 of the LCT header, that indicates the presence of sender current time
and expected residual time, respectively, in the LCT header.  In RFC5651
these fields MUST be set to zero and MUST be ignored by receivers (and
instead there are EXT_TIME extension headers that can convey this
information). Thus, RFC5651 is not backwards compatible with RFC3451, even
though both have LCT version 1.

FLUTE RFC3926 says to use RFC3451.  FLUTE revised says to use RFC5651.
There are some standards bodies that have specified using FLUTE RFC3926 with
LCT RFC5651, and these standards bodies might be backwards compatible with
using FLUTE revised with LCT5651 in at least this aspect (not sure about
others), but anybody who uses FLUTE RFC3926 with LCT RFC3451 as specified in
FLUTE RFC3926 will not be compatible with FLUTE revised with LCT5651.

There might be other examples as well.

Mike

On 2/6/11 11:57 PM, "Rod Walsh" <[email-masked]> wrote:

> Hi Mike
> 
> Jani nailed the FDT question. (By definition, flute delivers discrete media
> objects - files - and so there immeasurable ways to extend FLUTE by using
> specific mime type files, dedicating TOIs to specific purposes and other
> out-of-the-scope-of-this-document add-ins. Thus, I guess that modifying the
> FDT schema in a non backwards compatible manner was an error of process which
> we need to correct. Otherwise, the RMT achievement of making a single IETF
> defined multicast file delivery protocol common across all relevant SDOs would
> be laid to waste, which is clearly against the goal of the RMT revised
> documents.)
> 
> The other essential thing is that, as far as I can work out, all the other
> flute-revised modifications _are_ backwards compatible. If I didn't miss
> something, then the undefined extra elements extension feature in FDTs seems
> insufficient reward to break backwards compatibility.
> 
>>> A good place to start is to look at section 11, the change log.  A lot of
>>> the changes were across the different specs (ALC & LCT and FEC BB), moving
>>> the functionality around from FLUTE to LCT or ALC, etc.  These changes are
>>> really difficult to undo the already existing revised RFCs for LCT, ALC and
>>> FEC BB.  Also, some XML changes, etc.
>>> 
>>> (I.e. I am concerned that the right path forward might be to discard changes
>>> which remove backwards compatibility, and so far we are collectively
>>> ignoring this elephant in the room. What did I miss?)
>>> 
>>> Cheers, Rod.
>>> 
>>> 
>>> 
>>> There is now version 12 of FLUTE revised available as an Internet Draft.
>>> The major change in version 12 compared to version 11 is to change the FLUTE
>>> version number from 1 to 2.  This was changed in all the references to the
>>> FLUTE version, and there is wording added to Section 3.1 on the requirements
>>> around the FLUTE version number in operation for both senders and receivers.
>>> Also, the FLUTE version number is added as an optional parameter in Section
>>> 6.  The change log in Section 11 is also updated.  There are also a few
>>> grammatical fixes/improvements/clarifications.
>>> 
>>> I would like to thank Don Gillies for spending the time and enthusiastically
>>> getting up to speed on FLUTE (and also ALC and LCT and FEC BB) in a detailed
>>> way and helping to carefully craft the changes in this late stage draft, he
>>> did a wonderful job (and in the final RFC he should be thanked in the
>>> acknowledgements for his contributions).  However,  I take complete
>>> responsibility for all errors or issues that are introduced into this
>>> version 12 from version 11.  (So, read it over carefully and make sure that
>>> it is ok, etc.).
>>> 
>>> Thanks, Mike

---

From: <[email-masked]>
Date: Mon, 7 Feb 2011 10:04:22 +0100

So there's also a systematic problem with LCT version numbers. Ouch!

The updated EXT_TIME isn't a problem generally (old client from a new server will see that no SCT is set and ignore the new header, new client from an old server will ignore the old header and there would be no new extension included anyway). However, if an instance of LCT demanded that clients/receivers use SCT, then we have a problem. Do we know of any such cases?

I spotted just one SCT reference in old flute, that makes a requirement that is inevitably fulfilled in new flute (FDT expiry > SCT, =0 in new flute). So maybe this is a non-issue for FLUTE.

Did anyone check against the host of SDOs if EXT_TIME use is forbidden, allowed or mandated in their adoption of LCT?

What are the other LCT or ALC same version incompatibilities?

Cheers, Rod.

---

From: "Luby, Michael" <[email-masked]>
Date: Mon, 7 Feb 2011 09:31:39 -0800

Hi Rod,
My team and I tried to track down through all the SDOs whether or not there
is an issue wrt these inconsistencies in the past, and it consumed a lot of
time and was inconclusive, and we don't have the time to keep digging.

There is this potential inconsistency, and possibly others.  Even if these
potential inconsistencies can be "resolved" (by checking every existing SDO
spec and ensuring that they don't use any of the incompatible features of
RFC3926/RFC3451, and then also making sure that SDOs are not in the process
of standardizing on any incompatible features from RFC3926/RFC3451), to
obtain compatibility there would still have to be RMT-wg consensus to remove
a potentially important capability from FLUTE revised to make it backwards
compatibility (remove the feature to allow future extensions to the FDT
instance without having to flip the version yet again, as pointed out by
Jani below).

So, what is the downside of allowing the FLUTE version to be 2?  I haven't
heard anything about that recently.
Best, Mike  

On 2/7/11 1:04 AM, "Rod Walsh" <[email-masked]> wrote:

> The updated EXT_TIME isn't a problem generally (old client from a new server
> will see that no SCT is set and ignore the new header, new client from an old
> server will ignore the old header and there would be no new extension included
> anyway). However, if an instance of LCT demanded that clients/receivers use
> SCT, then we have a problem. Do we know of any such cases?
> 
> I spotted just one SCT reference in old flute, that makes a requirement that
> is inevitably fulfilled in new flute (FDT expiry > SCT, =0 in new flute). So
> maybe this is a non-issue for FLUTE.
> 
> Did anyone check against the host of SDOs if EXT_TIME use is forbidden,
> allowed or mandated in their adoption of LCT?
> 
>>> As for changes upstream (alc/lct), they both remain both backwards
>>> compatible
>>> and version 1 - right?
>>> 
>>> Cheers, Rod.
>>> 
>>> 
>>> 
>>> 
>>> 
>>>>> Do we have an answer on the question: why is a non-backwards compatible
>>>>> FDT
>>>>> schema necessarily?
>>>>>