Re: [Rmt] [Technical Errata Reported] RFC6726 (3870)

Rod Walsh <roderick.walsh@tut.fi> Thu, 23 January 2014 10:02 UTC

Return-Path: <roderick.walsh@tut.fi>
X-Original-To: rmt@ietfa.amsl.com
Delivered-To: rmt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1E91A03CA for <rmt@ietfa.amsl.com>; Thu, 23 Jan 2014 02:02:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.735
X-Spam-Level:
X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxnL3cDZBaUD for <rmt@ietfa.amsl.com>; Thu, 23 Jan 2014 02:02:39 -0800 (PST)
Received: from mail-gw-out1.cc.tut.fi (mail-gw-out1.cc.tut.fi [130.230.160.32]) by ietfa.amsl.com (Postfix) with ESMTP id 547A11A03C5 for <rmt@ietf.org>; Thu, 23 Jan 2014 02:02:38 -0800 (PST)
X-AuditID: 82e6a020-f79a66d000005008-a2-52e0e8bcbf5e
Received: from mail1.tut.fi (mail1.tut.fi [130.230.162.19]) by mail-gw-out1.cc.tut.fi (Symantec Messaging Gateway) with SMTP id AB.12.20488.CB8E0E25; Thu, 23 Jan 2014 12:02:36 +0200 (EET)
Received: from [192.168.0.15] (cpc5-harg4-2-0-cust25.7-1.cable.virginm.net [82.20.6.26]) by mail1.tut.fi (Postfix) with ESMTPSA id 4633340156; Thu, 23 Jan 2014 12:02:35 +0200 (EET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Rod Walsh <roderick.walsh@tut.fi>
In-Reply-To: <20140123065525.A040A7FC39B@rfc-editor.org>
Date: Thu, 23 Jan 2014 10:02:31 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D218720-9E5B-42DD-BC8D-3A5B2E0E6A38@tut.fi>
References: <20140123065525.A040A7FC39B@rfc-editor.org>
To: RFC Errata System <rfc-editor@rfc-editor.org>
X-Mailer: Apple Mail (2.1510)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsXS9GyRsO6eFw+CDL5/5LOYvGYeo8WRCU2s FpOeTmOyeH/+GItF0/6vbBZ3+w4wWyybsofZYtHOs2wW83/OY7foWdXP4sDlsXPWXXaPJUt+ MnlMenGIxaNn51d2j2vPHrF7LJr6jNGjoe0Yq8eUxjbGAI4oLpuU1JzMstQifbsEroyNc14w F7w1rtjV08LSwPhdo4uRk0NCwERi68w9TBC2mMSFe+vZuhi5OIQE9jJKvLg6BcrZwShx+O0y VpAqZgEtiRv/XgJ1cHDwCuhJbP8lBxIWFjCXOLTsLiOIzSagLnHt/wGwck4BC4nNZw6wgNgs AqoS/0/dYweZySzwjFHi3MoPjBAztSWWLXzNDGLzClhK3O+dxgYyXwho6MWJkiBhEQFDiYOL 3rJDHCorcfrcc5YJjAKzkFw0C+GiWUiGLmBkXsUolpuYmaObXq6bX1piqJecrFdSWqKXlrmJ ERwjCxR2ML6cpn+IUYCDUYmHN+HL/SAh1sSy4srcQ4ySHExKorxbHj8IEuJLyk+pzEgszogv Ks1JLT7EKMHBrCTC638DKMebklhZlVqUD5OS5mBREuctFp4VKCSQnliSmp2aWpBaBJOV4eBQ kuDd8RyoUbAoNT21Ii0zpwQhzcTBCTKcB2j4UZAa3uKCxNzizHSI/ClGRSlxXj6QhABIIqM0 D64XlMKCRNikXjGKA70izHsVpIoHmP7gul8BDWYCGrziLNjgkkSElFQD48zlurZ6BqG1m9T+ BDpNZHyy1/nVp0N86Sdn/ou98TJ1UvPRSy/982KtfvouOHZK4fwiY2tJO9s/pySPbWthjJt2 oOxOVMGcWvbPL6RFvUW0eIpUxefNuK5661vHgWvuyfPvRoQ+yLoapbKs4q5MbjSvXUf+I3vf S9UajNsj3lRsnxnNnLlwhRJLcUaioRZzUXEiAITFuec8AwAA
X-Mailman-Approved-At: Thu, 23 Jan 2014 07:06:31 -0800
Cc: toni.paila@gmail.com, rami.lehtonen@teliasonera.com, vincent.roca@inria.fr, mls.ietf@gmail.com, adamson@itd.nrl.navy.mil, rmt@ietf.org, luby@qti.qualcomm.com
Subject: Re: [Rmt] [Technical Errata Reported] RFC6726 (3870)
X-BeenThere: rmt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Reliable Multicast Transport <rmt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmt>, <mailto:rmt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rmt/>
List-Post: <mailto:rmt@ietf.org>
List-Help: <mailto:rmt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 10:02:42 -0000

I'm a bit rusty so jump on me if I write anything stupid:

We wrote FLUTE 2 specifically to maintain maximal backwards compatibility with FLUTE 1 (given the compatibility breakage for LCT, we were prevented from keeping fully compatibility as was the original philosophy). So a FLUTE 2 receiver would be happy with a FLUTE 1 FDT. Meaning that a well made "mutant FLUTE sender" could do what is asked by this errata, even if we specifically don't want the standard to suggest that a FLUTE 2 sender does things the FLUTE 1 way. Thank goodness, we made a careful section "11.  Change Log"! - it pretty much says it all about the changes.

However, what is being asked for is a little broken. RFC 6726 does not promote or suggest the use of FLUTE 1 senders. If you want to use FLUTE 1 senders, you use the experimental and obsolete RFC3926. So if you want to experimentally use the newer updated LCT and ACL with the experimental RFC3926, that's fine - it's experimental but it would not be according to either RFC spec.

If you want a full FLUTE 1 spec added to the FLUTE 2 spec as an option, it kind of goes outside the normal "keep this and the options minimal and simple or you'll not get interoperable interpretations implemented" IETF mantra (and that is a BIG ask). If you want the obsolete RFC3926 to be updated to a new experimental RFC to allow for this, you'd want the normal IETF tao - running code and rough consensus (although running consensus and rough code is an easier start), and a new ID for this small spec modifier (probably to become an informational RFC rather than obsolete experimental or standards track RFC).

So my quick assessment, is that the errata author has not understood what we have tried to accomplish, and wishes to use the specifications in a non-standards way (which is fine for a closed and controlled network but) which we would not want to incorporate into RFC 6726.

If there is a massive groundswell, that I'm not aware of, of implementors specifically wanting to run FLUTE 1 over LCT/ALC 2, it should be straight forward to get the wheels in motion for a new ID/RFC path (which would be remarkably easy to write - mostly copy and paste). Vincent Roca already set a precedent for this with RFC6968 (FCAST) which deviates from FLUTE considerably. This really depends on the volume, motivation and skills of the developers of "deployments that want to use the new functionalities of LCT as defined in RFC5651, but still want to be backward compatible to FLUTE version 1".

Cheers, Rod.




On Jan 23, 2014, at 6:55 AM, RFC Errata System <rfc-editor@rfc-editor.org>; wrote:

> The following errata report has been submitted for RFC6726,
> "FLUTE - File Delivery over Unidirectional Transport".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6726&eid=3870
> 
> --------------------------------------
> Type: Technical
> Reported by: Thomas Stockhammer <stockhammer@nomor.de>;
> 
> Section: 11.1
> 
> Original Text
> -------------
> Incremented the FLUTE protocol version from 1 to 2, due to concerns
>   about backwards compatibility.  For instance, the LCT header changed
>   between RFC 3451 and [RFC5651].  In RFC 3451, the T and R fields of
>   the LCT header indicate the presence of Sender Current Time and
>   Expected Residual Time, respectively.  In [RFC5651], these fields
>   MUST be set to zero and MUST be ignored by receivers (instead, the
>   EXT_TIME Header Extensions can convey this information if needed).
>   Thus, [RFC5651] is not backwards compatible with RFC 3451, even
>   though both use LCT version 1.  FLUTE version 1 as specified in
>   [RFC3926] MUST use RFC 3451.  FLUTE version 2 as specified in this
>   document MUST use [RFC5651].  Therefore, an implementation that
>   relies on [RFC3926] and RFC 3451 will not be backwards compatible
>   with FLUTE as specified in this document.
> 
> Corrected Text
> --------------
> Incremented the FLUTE protocol version from 1 to 2, due to concerns
>   about backwards compatibility.  For instance, the LCT header changed
>   between RFC 3451 and [RFC5651].  In RFC 3451, the T and R fields of
>   the LCT header indicate the presence of Sender Current Time and
>   Expected Residual Time, respectively.  In [RFC5651], these fields
>   MUST be set to zero and MUST be ignored by receivers (instead, the
>   EXT_TIME Header Extensions can convey this information if needed).
>   Thus, [RFC5651] is not backwards compatible with RFC 3451, even
>   though both use LCT version 1.  FLUTE version 1 as specified in
>   [RFC3926] SHOULD use RFC 3451.  FLUTE version 2 as specified in this
>   document MUST use [RFC5651].  Therefore, an implementation that
>   relies on [RFC3926] and RFC 3451 will not be backwards compatible
>   with FLUTE as specified in this document.
> 
> Notes
> -----
> The only change that is requested is to change "FLUTE version 1 as specified in
>   [RFC3926] MUST use RFC 3451." to "FLUTE version 1 as specified in
>   [RFC3926] SHOULD use RFC 3451. " 
> 
> This is done as there are deployments that want to use the new functionalities of LCT as defined in RFC5651, but still want to be backward compatible to FLUTE version 1. The above statement being a must prevents this. However, if there are good reasons to not move to FLUTE version 2 (as this would break backward-compatibility for existing receivers), it should be possible to use FLUTE version 1 on top of LCT RFC5651 in order to use the functionalities in RFC5651, especially the header extensions.
> 
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC6726 (draft-ietf-rmt-flute-revised-16)
> --------------------------------------
> Title               : FLUTE - File Delivery over Unidirectional Transport
> Publication Date    : November 2012
> Author(s)           : T. Paila, R. Walsh, M. Luby, V. Roca, R. Lehtonen
> Category            : PROPOSED STANDARD
> Source              : Reliable Multicast Transport
> Area                : Transport
> Stream              : IETF
> Verifying Party     : IESG