Subject: Re: [Rmt] Mail regarding draft-ietf-rmt-flute-revised

From: "David Harrington" <[email-masked]>
Date: Tue, 2 Nov 2010 09:47:14 +0800

Hi,

The IESG has reviewed the changes made, found them to be not
backwards-compatible, and reached consensus that a new version is
called for.

I would like to see the WG make progress on this draft soon.

David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

> -----Original Message-----
> From: Luby, Michael [mailto:[email-masked]] 
> Sent: Saturday, October 30, 2010 8:09 AM
> To: David Harrington; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Mail regarding draft-ietf-rmt-flute-revised
> 
> Hi David, 
> Yes, you are correct, this should be pushed forward.  I think the
only
> remaining issue is whether the FLUTE version number should be 
> incremented
> due to backwards compatibility issues, or some argumentation 
> saying that a
> version increment is not necessary because the backwards
compatibility
> issues are not there or not significant enough to justify.  
> Is there any
> consensus on this final issue at this time?  Anybody want to provide
> argumentation that we can justifiably keep this as version 1 
> (same as the
> deprecated RFC3926), or should we just go along with the IESG 
> request to
> make this Version 2?   We need to push this forward and 
> complete the work.
> Mike
> 
> 
> 
> 
> On 9/13/10 3:53 PM, "David Harrington" <[email-masked]> wrote:
> 
> > Hi,
> > 
> > Where are we with this document?
> > I asked for an updated version number back in July.
> > I'm not seeing much discussion on the ML.
> > When can I expect a new revision that addresses the backwards
> > compatibility issue?
> > 
> > David Harrington
> > Director, IETF Transport Area
> > [email-masked] (preferred for ietf)
> > [email-masked]
> > +1 603 828 1401 (cell)
> > 
>

---

From: "Luby, Michael" <[email-masked]>
Date: Tue, 2 Nov 2010 14:59:46 -0700

Ok, so what I'm doing is preparing a FLUTE revision 12, with the only change
being that the version is incremented from 1 to 2 and saying it may not be
backwards compatible with version 1, whereas previously it said it was
backwards compatible and kept it as version 1.

One question: since we are changing the version number, should this be
reflected in the title of the document, i.e., instead of being:

"FLUTE - File Delivery over Unidirectional Transport"

Should it now be something like:

"FLUTE - File Delivery over Unidirectional Transport - Version 2"

?

Also, there is no opportunity to upload a new draft until November 8, due to
the current IETF meeting.
Mike

---

From: "Luby, Michael" <[email-masked]>
Date: Thu, 18 Nov 2010 16:50:39 -0800

Since there hasn't been much response on this, except for a couple of
inquiries asking whether or not we really need to increment the FLUTE
revision number, I've asked a colleague to look into the FLUTE backwards
compatibility/version number issue in more detail, to look at how the other
SDOs that reference and use FLUTE RFC 3926, to help resolve this once and
for all.

Thanks, Mike Luby

---

From: "David Harrington" <[email-masked]>
Date: Fri, 19 Nov 2010 09:42:05 -0500

Hi,

Given the number of changes that are not backwards compatible, I see
little chance that you'll get this through IESG approval without a
change of version number.

It will presumably be more expensive for implementers to undo all the
incompatible changes than to increment the version number.

I'm not sure what your colleague is going to look into that could make
a difference in this apparently simple tradeoff. 

dbh

> Sent: Thursday, November 18, 2010 7:51 PM

---

From: "Luby, Michael" <[email-masked]>
Date: Fri, 19 Nov 2010 10:22:16 -0800

Hi David,

You may be right, but I think it is worth checking since some SDOs may not
be happy with a version increment, so at least we can say we tried.  For
example, if you look at LCT, the version number there remained the same
between RFC 3451 and RFC 5651, even though the T and R flags in the LCT
header were deprecated.  This could potentially have caused a backwards
compatibility issue, because implementors of RFC 5651 would not be able to
understand the LCT from an RFC 3451 implementation that used the T and R
flags (since they signaled the presence of additional fields in the LCT
header), but we checked at the time and all of the SDOs didn't use the T and
R flags, and in the meantime all of the subsequent SDOs have adopted the LCT
5651 (these SDOs refer to the FLUTE RFC 3926 that will be obsoleted by the
new FLUTE and also the new LCT 5651), so there is no issue going forward.

Mike