[Rmt] [Technical Errata Reported] RFC6726 (3870)
RFC Errata System <rfc-editor@rfc-editor.org> Thu, 23 January 2014 06:55 UTC
Return-Path: <wwwrun@rfc-editor.org>
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 9862A1A022C for <rmt@ietfa.amsl.com>; Wed, 22 Jan 2014 22:55:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.953
X-Spam-Level:
X-Spam-Status: No, score=0.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
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 kubKebOI8TCb for <rmt@ietfa.amsl.com>; Wed, 22 Jan 2014 22:55:28 -0800 (PST)
Received: from rfc-editor.org (unknown [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 062F21A0125 for <rmt@ietf.org>; Wed, 22 Jan 2014 22:55:28 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id A040A7FC39B; Wed, 22 Jan 2014 22:55:25 -0800 (PST)
To: toni.paila@gmail.com, roderick.walsh@tut.fi, luby@qti.qualcomm.com, vincent.roca@inria.fr, rami.lehtonen@teliasonera.com, spencerdawkins.ietf@gmail.com, mls.ietf@gmail.com, adamson@itd.nrl.navy.mil
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20140123065525.A040A7FC39B@rfc-editor.org>
Date: Wed, 22 Jan 2014 22:55:25 -0800
X-Mailman-Approved-At: Thu, 23 Jan 2014 07:06:31 -0800
Cc: rfc-editor@rfc-editor.org, rmt@ietf.org
Subject: [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 06:55:29 -0000
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
- [Rmt] [Technical Errata Reported] RFC6726 (3870) RFC Errata System
- Re: [Rmt] [Technical Errata Reported] RFC6726 (38… Rod Walsh