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

["Luby, Michael" <[e-mail]>]

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 


On 11/19/10 6:42 AM, "David Harrington" <[e-mail]> wrote:

> 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
> 
>> -----Original Message-----
>> From: Luby, Michael [mailto:[e-mail]]
>> Sent: Thursday, November 18, 2010 7:51 PM
>> To: David Harrington; [e-mail]
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: Mail regarding draft-ietf-rmt-flute-revised
>> 
>> 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
>> 
>> 
>> On 11/1/10 6:47 PM, "David Harrington" <[e-mail]> wrote:
>> 
>>> 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
>>> [e-mail] (preferred for ietf)
>>> [e-mail]
>>> [phone] (cell)
>>> 
>>>> -----Original Message-----
>>>> From: Luby, Michael [mailto:[e-mail]]
>>>> Sent: Saturday, October 30, 2010 8:09 AM
>>>> To: David Harrington; [e-mail]
>>>> Cc: [e-mail]; [e-mail]
>>>> 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" <[e-mail]>
> 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
>>>>> [e-mail] (preferred for ietf)
>>>>> [e-mail]
>>>>> [phone] (cell)
>>>>> 
>>>> 
>>> 
>> 
>