From luby@qualcomm.com Mon Jan 24 11:39:25 2011 Return-Path: X-Original-To: rmt@core3.amsl.com Delivered-To: rmt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23C613A6B1F for ; Mon, 24 Jan 2011 11:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9h2x+ncyiWY for ; Mon, 24 Jan 2011 11:39:24 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 2929E3A694A for ; Mon, 24 Jan 2011 11:39:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1295898139; x=1327434139; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:mime-version; z=From:=20"Luby,=20Michael"=20|To:=20"r mt@ietf.org"=20|CC:=20"Luby,=20Michael"=20< luby@qualcomm.com>,=20"Gillies,=20Don"=0D=0A=09|Date:=20Mon,=2024=20Jan=202011=2011:42:16 =20-0800|Subject:=20FLUTE=20revision|Thread-Topic:=20FLUT E=20revision|Thread-Index:=20Acu7/s3bu02S0/6jkUWpHOn8pWpp tA=3D=3D|Message-ID:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|user-agent:=20Mic rosoft-Entourage/13.8.0.101117|acceptlanguage:=20en-US |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"_000_C96316188895lubyqualcommcom_"|MIME-Version:=201 .0; bh=/7PCJfMOc0/mgXVLdkONjHtvuAdRO7+F/nOaV9rF3MU=; b=b3jJ1zC4uBp9OFp8F9zowFL70ztp9+8uGOGmoKbk3eo9dTGoIHbr8vMH mbbGTD3qsba0gwU4Dk4b6pomWP8Spi6zacjvXSRy6lK7r/G8q0o4hmlJH Pj3467EH7zqhIAUS16Os2G7+60lufZvKOXkOvfR7oQZspCWl/Q7EMSqqh c=; X-IronPort-AV: E=McAfee;i="5400,1158,6236"; a="71578615" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 24 Jan 2011 11:42:19 -0800 X-IronPort-AV: E=Sophos;i="4.60,370,1291622400"; d="scan'208,217";a="112253474" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 24 Jan 2011 11:42:19 -0800 Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.3.83.0; Mon, 24 Jan 2011 11:42:19 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Mon, 24 Jan 2011 11:42:18 -0800 From: "Luby, Michael" To: "rmt@ietf.org" Date: Mon, 24 Jan 2011 11:42:16 -0800 Thread-Topic: FLUTE revision Thread-Index: Acu7/s3bu02S0/6jkUWpHOn8pWpptA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C96316188895lubyqualcommcom_" MIME-Version: 1.0 Cc: "Gillies, Don" , "Luby, Michael" Subject: [Rmt] FLUTE revision X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 19:39:25 -0000 --_000_C96316188895lubyqualcommcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear RMTers, We are in the process of revising FLUTE =9611, to produce FLUT= E =9612, and it is clear at this point that the FLUTE version number will t= ransition from 1 to 2. One question that has arisen: Can an FDT instance h= ave a TOI > 0 with an EXT_FDT LCT extension header containing the FDT Insta= nce ID? I think it is and should be restricted to TOI =3D 0 for carrying F= DT instances, but there is some ambiguities in the text here and there that= might be construed to suggest otherwise. Mike --_000_C96316188895lubyqualcommcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable FLUTE revision Dear RMTers, We are in the process of revising FLUTE =9611, to produc= e FLUTE =9612, and it is clear at this point that the FLUTE version number = will transition from 1 to 2.  One question that has arisen: Can an FDT= instance have a TOI > 0 with an EXT_FDT LCT extension header containing= the FDT Instance ID?  I think it is and should be restricted to TOI = =3D 0 for carrying FDT instances, but there is some ambiguities in the text= here and there that might be construed to suggest otherwise.
Mike   --_000_C96316188895lubyqualcommcom_-- From Rod.Walsh@nokia.com Tue Jan 25 00:35:05 2011 Return-Path: X-Original-To: rmt@core3.amsl.com Delivered-To: rmt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98073A6964 for ; Tue, 25 Jan 2011 00:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRAcPpgtSYyg for ; Tue, 25 Jan 2011 00:35:04 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id C3A983A6B85 for ; Tue, 25 Jan 2011 00:35:04 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0P8basJ022199; Tue, 25 Jan 2011 10:38:00 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Jan 2011 10:37:52 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 25 Jan 2011 09:37:52 +0100 From: To: Date: Tue, 25 Jan 2011 09:38:33 +0100 Thread-Topic: [Rmt] FLUTE revision Thread-Index: Acu8aydw0je0qOLaR5WHUKOOaEzpcw== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E2C299B7EFA94149BA48525EB298EA57nokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 25 Jan 2011 08:37:52.0474 (UTC) FILETIME=[27C203A0:01CBBC6B] X-Nokia-AV: Clean Cc: luby@qualcomm.com, dgillies@qualcomm.com, rmt@ietf.org Subject: Re: [Rmt] FLUTE revision X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 08:35:05 -0000 --_000_E2C299B7EFA94149BA48525EB298EA57nokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RkRUIGluc3RhbmNlcyBvbiBUT0lzIG90aGVyIHRoYW4gMCBhcmUgYWxsb3dlZCBieSBkZXNpZ24u IFRoZXJlIGlzIG5vIHJlcXVpcmVtZW50IGZvciBhIG1pbmltYWwgRkxVVEUtb25seSBjbGllbnQg dG8gcGFyc2UgdGhlbSAodGhlcmUgaXMgbm8gYXNzdXJhbmNlIHRoYXQgdGhlIGNsaWVudCB3b3Vs ZCBwYXJzZSBhbGwgdG8gVE9JMCBGRFQgaW5zdGFuY2VzIGVpdGhlcikuIEhvd2V2ZXIsIEZEVGkn cyBtdXN0IGZvbGxvdyB0aGUgRkRUIHJ1bGVzIHJlZ2FyZGxlc3Mgb2YgVE9JIHRoZXkgY29tZSBv biAoZS5nLiBUaGV5IHVzZSB0aGUgc2FtZSAiVE9JIG5hbWVzcGFjZSIgZm9yIHRoZSBGTFVURSBz ZXNzaW9uKS4gIFRoaXMgYWxsb3dzIG1vcmUgZmxleGlibGUgZXh0ZW5zaW9ucyBidWlsdCBvbiB0 b3Agb2YgRkxVVEUuIChUaGUgbW11c2ljIElNRyB3b3JrLCB0aGF0IHNwYXduZWQgdGhlIGZpcnN0 IEZEQUxDIGRyYWZ0LCB3YXMgdG8gdXNlIHRoaXMgbXVsdGktVE9JIGZlYXR1cmUpLg0KDQpEaXNj bGFpbWVyOiBhcG9sb2dpZXMgaWYgSSBtaXN1bmRlcnN0b29kIHRoZSBxdWVzdGlvbiBhcyBJIGRp ZG4ndCBwYXJzZSB0aGUgYml0IG9uICJ3aXRoIGFuIEVYVF9GRFQgTENUIGV4dGVuc2lvbiBoZWFk ZXIgY29udGFpbmluZyB0aGUgRkRUIEluc3RhbmNlIElEIiBhcyBpdCB3b3VsZCByZXF1aXJlIHJl LWRpZ2VzdGluZyB0aGUgc3BlYyBiZWZvcmUgcmVwbHlpbmcuIElmIHRoZSBxdWVzdGlvbiBpcyBs aW1pdGVkIHRvIHRoaXMgY2FzZSB3aXRoIHRoYXQgaGVhZGVyLCBhcmUgdGhlcmUgYW55IHBvc2l0 aXZlIG9yIG5lZ2F0aXZlIGltcGxpY2F0aW9ucyBvZiBleHBsaWNpdGx5IGFsbG93aW5nIG9yIGRp c2FsbG93aW5nIHRoaXM/DQoNCkNoZWVycywgUm9kLg0KDQoNCk9uIDI0IEphbiAyMDExLCBhdCAy MTo0MiwgImV4dCBMdWJ5LCBNaWNoYWVsIiA8bHVieUBxdWFsY29tbS5jb208bWFpbHRvOmx1YnlA cXVhbGNvbW0uY29tPj4gd3JvdGU6DQoNCkRlYXIgUk1UZXJzLCBXZSBhcmUgaW4gdGhlIHByb2Nl c3Mgb2YgcmV2aXNpbmcgRkxVVEUg4oCTMTEsIHRvIHByb2R1Y2UgRkxVVEUg4oCTMTIsIGFuZCBp dCBpcyBjbGVhciBhdCB0aGlzIHBvaW50IHRoYXQgdGhlIEZMVVRFIHZlcnNpb24gbnVtYmVyIHdp bGwgdHJhbnNpdGlvbiBmcm9tIDEgdG8gMi4gIE9uZSBxdWVzdGlvbiB0aGF0IGhhcyBhcmlzZW46 IENhbiBhbiBGRFQgaW5zdGFuY2UgaGF2ZSBhIFRPSSA+IDAgd2l0aCBhbiBFWFRfRkRUIExDVCBl eHRlbnNpb24gaGVhZGVyIGNvbnRhaW5pbmcgdGhlIEZEVCBJbnN0YW5jZSBJRD8gIEkgdGhpbmsg aXQgaXMgYW5kIHNob3VsZCBiZSByZXN0cmljdGVkIHRvIFRPSSA9IDAgZm9yIGNhcnJ5aW5nIEZE VCBpbnN0YW5jZXMsIGJ1dCB0aGVyZSBpcyBzb21lIGFtYmlndWl0aWVzIGluIHRoZSB0ZXh0IGhl cmUgYW5kIHRoZXJlIHRoYXQgbWlnaHQgYmUgY29uc3RydWVkIHRvIHN1Z2dlc3Qgb3RoZXJ3aXNl Lg0KTWlrZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N ClJtdCBtYWlsaW5nIGxpc3QNClJtdEBpZXRmLm9yZzxtYWlsdG86Um10QGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ybXQNCg== --_000_E2C299B7EFA94149BA48525EB298EA57nokiacom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5GRFQgaW5zdGFuY2VzIG9uIFRPSXMg b3RoZXIgdGhhbiAwIGFyZSBhbGxvd2VkIGJ5IGRlc2lnbi4gVGhlcmUgaXMgbm8gcmVxdWlyZW1l bnQgZm9yIGEgbWluaW1hbCBGTFVURS1vbmx5IGNsaWVudCB0byBwYXJzZSB0aGVtICh0aGVyZSBp cyBubyBhc3N1cmFuY2UgdGhhdCB0aGUgY2xpZW50IHdvdWxkIHBhcnNlIGFsbCB0byBUT0kwIEZE VCBpbnN0YW5jZXMgZWl0aGVyKS4gSG93ZXZlciwgRkRUaSdzIG11c3QgZm9sbG93IHRoZSBGRFQg cnVsZXMgcmVnYXJkbGVzcyBvZiBUT0kgdGhleSBjb21lIG9uIChlLmcuIFRoZXkgdXNlIHRoZSBz YW1lICJUT0kgbmFtZXNwYWNlIiBmb3IgdGhlIEZMVVRFIHNlc3Npb24pLiAmbmJzcDtUaGlzIGFs bG93cyBtb3JlIGZsZXhpYmxlIGV4dGVuc2lvbnMgYnVpbHQgb24gdG9wIG9mIEZMVVRFLiAoVGhl IG1tdXNpYyBJTUcgd29yaywgdGhhdCBzcGF3bmVkIHRoZSBmaXJzdCBGREFMQyBkcmFmdCwgd2Fz IHRvIHVzZSB0aGlzIG11bHRpLVRPSSBmZWF0dXJlKS48YnI+PGJyPjwvZGl2PjxkaXY+RGlzY2xh aW1lcjogYXBvbG9naWVzIGlmIEkgbWlzdW5kZXJzdG9vZCB0aGUgcXVlc3Rpb24gYXMgSSBkaWRu J3QgcGFyc2UgdGhlIGJpdCBvbiAiPHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxl PSItd2Via2l0LXRhcC1oaWdobGlnaHQtY29sb3I6IHJnYmEoMjYsIDI2LCAyNiwgMC4yOTI5Njkp OyAtd2Via2l0LWNvbXBvc2l0aW9uLWZpbGwtY29sb3I6IHJnYmEoMTc1LCAxOTIsIDIyNywgMC4y MzA0NjkpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZyYW1lLWNvbG9yOiByZ2JhKDc3LCAxMjgsIDE4 MCwgMC4yMzA0NjkpOyBmb250LXNpemU6IDE1cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBWZXJk YW5hLCBIZWx2ZXRpY2EsIEFyaWFsOyAiPndpdGggYW4gRVhUX0ZEVCBMQ1QgZXh0ZW5zaW9uIGhl YWRlciBjb250YWluaW5nIHRoZSBGRFQgSW5zdGFuY2UgSUQ8L3NwYW4+IiBhcyBpdCB3b3VsZCBy ZXF1aXJlIHJlLWRpZ2VzdGluZyB0aGUgc3BlYyBiZWZvcmUgcmVwbHlpbmcuIElmIHRoZSBxdWVz dGlvbiBpcyBsaW1pdGVkIHRvIHRoaXMgY2FzZSB3aXRoIHRoYXQgaGVhZGVyLCBhcmUgdGhlcmUg YW55IHBvc2l0aXZlIG9yIG5lZ2F0aXZlIGltcGxpY2F0aW9ucyBvZiBleHBsaWNpdGx5IGFsbG93 aW5nIG9yIGRpc2FsbG93aW5nIHRoaXM/PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5DaGVlcnMs IFJvZC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj5PbiAyNCBKYW4gMjAxMSwgYXQgMjE6 NDIsICJleHQgTHVieSwgTWljaGFlbCIgJmx0OzxhIGhyZWY9Im1haWx0bzpsdWJ5QHF1YWxjb21t LmNvbSI+bHVieUBxdWFsY29tbS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxkaXY+ PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj4NCjxmb250IGZhY2U9IkNhbGlicmks IFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+ RGVhciBSTVRlcnMsIFdlIGFyZSBpbiB0aGUgcHJvY2VzcyBvZiByZXZpc2luZyBGTFVURSDigJMx MSwgdG8gcHJvZHVjZSBGTFVURSDigJMxMiwgYW5kIGl0IGlzIGNsZWFyIGF0IHRoaXMgcG9pbnQg dGhhdCB0aGUgRkxVVEUgdmVyc2lvbiBudW1iZXIgd2lsbCB0cmFuc2l0aW9uIGZyb20gMSB0byAy LiAmbmJzcDtPbmUgcXVlc3Rpb24gdGhhdCBoYXMgYXJpc2VuOiBDYW4gYW4gRkRUIGluc3RhbmNl IGhhdmUgYSBUT0kgJmd0OyAwIHdpdGggYW4gRVhUX0ZEVCBMQ1QgZXh0ZW5zaW9uIGhlYWRlciBj b250YWluaW5nIHRoZSBGRFQgSW5zdGFuY2UgSUQ/ICZuYnNwO0kgdGhpbmsgaXQgaXMgYW5kIHNo b3VsZCBiZSByZXN0cmljdGVkIHRvIFRPSSA9IDAgZm9yIGNhcnJ5aW5nIEZEVCBpbnN0YW5jZXMs IGJ1dCB0aGVyZSBpcyBzb21lIGFtYmlndWl0aWVzIGluIHRoZSB0ZXh0IGhlcmUgYW5kIHRoZXJl IHRoYXQgbWlnaHQgYmUgY29uc3RydWVkIHRvIHN1Z2dlc3Qgb3RoZXJ3aXNlLjxicj4NCk1pa2Ug Jm5ic3A7PC9zcGFuPjwvZm9udD4NCg0KDQoNCjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj48ZGl2PjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPC9zcGFuPjxicj48c3Bhbj5SbXQgbWFpbGluZyBsaXN0PC9zcGFuPjxi cj48c3Bhbj48YSBocmVmPSJtYWlsdG86Um10QGlldGYub3JnIj5SbXRAaWV0Zi5vcmc8L2E+PC9z cGFuPjxicj48c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3JtdCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ybXQ8L2E+PC9z cGFuPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --_000_E2C299B7EFA94149BA48525EB298EA57nokiacom_-- From jani.peltotalo@tut.fi Tue Jan 25 00:48:13 2011 Return-Path: X-Original-To: rmt@core3.amsl.com Delivered-To: rmt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CE7F3A6B8A for ; Tue, 25 Jan 2011 00:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHNGUy557mzD for ; Tue, 25 Jan 2011 00:48:12 -0800 (PST) Received: from mail.cs.tut.fi (mail.cs.tut.fi [130.230.4.42]) by core3.amsl.com (Postfix) with ESMTP id 57A303A6B81 for ; Tue, 25 Jan 2011 00:48:12 -0800 (PST) Received: from amavis2.cs.tut.fi (amavis2.cs.tut.fi [130.230.4.70]) by mail.cs.tut.fi (Postfix) with ESMTP id 0674912AF; Tue, 25 Jan 2011 10:51:08 +0200 (EET) Received: from mail.cs.tut.fi ([130.230.4.42]) by amavis2.cs.tut.fi (amavis2.cs.tut.fi [130.230.4.70]) (amavisd-maia, port 10024) with ESMTP id 18034-38; Tue, 25 Jan 2011 10:51:07 +0200 (EET) Received: from [130.230.89.61] (vpn-51.vpn.tut.fi [130.230.89.61]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id D052812AD; Tue, 25 Jan 2011 10:51:06 +0200 (EET) Message-ID: <4D3E8EFB.8000307@tut.fi> Date: Tue, 25 Jan 2011 10:51:07 +0200 From: Jani Peltotalo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: rmt@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.2 Cc: dgillies@qualcomm.com, luby@qualcomm.com Subject: Re: [Rmt] FLUTE revision X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 08:48:13 -0000 Dear RMTers, One side effect of the version number change is problem with ALC and LCT versions. Version number is signalled in the LCT header field and in RFCs 5775 and 5651 (FLUTE revised will be working on top of these RFCs) version number is specified to be 1. So it is not possible to signal FLUTE version 2 and ALC/LCT version 1 in the same header field. BR, Jani > Dear RMTers, We are in the process of revising FLUTE –11, to produce > FLUTE –12, and it is clear at this point that the FLUTE version number > will transition from 1 to 2. One question that has arisen: Can an FDT > instance have a TOI > 0 with an EXT_FDT LCT extension header containing > the FDT Instance ID? I think it is and should be restricted to TOI = 0 > for carrying FDT instances, but there is some ambiguities in the text > here and there that might be construed to suggest otherwise. > Mike > > > > _______________________________________________ > Rmt mailing list > Rmt@ietf.org > https://www.ietf.org/mailman/listinfo/rmt From dgillies@qualcomm.com Tue Jan 25 11:29:47 2011 Return-Path: X-Original-To: rmt@core3.amsl.com Delivered-To: rmt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B80283A6853 for ; Tue, 25 Jan 2011 11:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOqPBbvxfpoN for ; Tue, 25 Jan 2011 11:29:46 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 581573A683B for ; Tue, 25 Jan 2011 11:29:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=dgillies@qualcomm.com; q=dns/txt; s=qcdkim; t=1295983964; x=1327519964; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:mime-version; z=From:=20"Gillies,=20Don"=20|To: =20"Rod.Walsh@nokia.com"=20,=20"Luby ,=20Michael"=0D=0A=09|CC:=20"rmt@ietf. org"=20,=20"Luby,=20Michael"=20|Subject:=20RE:=20[Rmt]=20FLUTE=20revision |Thread-Topic:=20[Rmt]=20FLUTE=20revision|Thread-Index: =20Acu7/s3bu02S0/6jkUWpHOn8pWpptAAr4AyAAAW9ToA=3D|Date: =20Tue,=2025=20Jan=202011=2019:32:43=20+0000|Message-ID: =20|References:=20=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language: =20en-US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |x-originating-ip:=20[172.30.48.1]|Content-Type:=20multip art/alternative=3B=0D=0A=09boundary=3D"_000_C6B80B17C4454 1438510B42A18D01B7A04D1A2nasanexd01gnaqual_" |MIME-Version:=201.0; bh=OL8xiycuuPR1lYODDxUe12fcd4HBy0rz9qNozcJvDhE=; b=e8wKU/5jydG+o+FdNvlv8kFbz9HEKGJb5W35Zcns02a/3w3iS+XTjSSH mdahrwwNcFAncbltN6wxWDhBzcma+bFlqUlNbopzQlYQEi5Li8ozfEM/3 hrl2QmvbdALg01R3OdjcNW102uKviDE7LcI2WXACLEy2yzFeVTZ4fkgcP s=; X-IronPort-AV: E=McAfee;i="5400,1158,6237"; a="71726514" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 25 Jan 2011 11:32:44 -0800 X-IronPort-AV: E=Sophos;i="4.60,374,1291622400"; d="scan'208,217";a="24748220" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 25 Jan 2011 11:32:44 -0800 Received: from NASANEXD01G.na.qualcomm.com ([fe80::c0c6:d0ab:610c:4263]) by nasanexhc05.na.qualcomm.com ([::1]) with mapi id 14.01.0218.012; Tue, 25 Jan 2011 11:32:44 -0800 From: "Gillies, Don" To: "Rod.Walsh@nokia.com" , "Luby, Michael" Thread-Topic: [Rmt] FLUTE revision Thread-Index: Acu7/s3bu02S0/6jkUWpHOn8pWpptAAr4AyAAAW9ToA= Date: Tue, 25 Jan 2011 19:32:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: multipart/alternative; boundary="_000_C6B80B17C44541438510B42A18D01B7A04D1A2nasanexd01gnaqual_" MIME-Version: 1.0 Cc: "Luby, Michael" , "rmt@ietf.org" Subject: Re: [Rmt] FLUTE revision X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 19:29:47 -0000 --_000_C6B80B17C44541438510B42A18D01B7A04D1A2nasanexd01gnaqual_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9kLA0KDQpJbiByZWFkaW5nIHRoZSBzcGVjaWZpY2F0aW9uLCBJIGZvdW5kIGluIHR3byBvciB0 aHJlZSBwbGFjZXMsIHRleHQgdGhhdCBzdWdnZXN0ZWQgdGhhdCBGRFQgVE9JID0gMCBhbmQgRkRU IFRPSSA+IDAgd2VyZSBib3RoIHBvc3NpYmxlLCBhcyBsb25nIGFzIGJvdGggZmlsZXMgd2VyZSBk ZWxpdmVyZWQgdXNpbmcgRkRUIEluc3RhbmNlIGluIHRoZSBFWFRfRkRUIGhlYWRlciBvZiBMQ1Qu DQoNClNvLCBJIGFncmVlIHdpdGggeW91IHRoYXQgdGhpcyBpcyBob3cgdGhlIHByZXNlbnQgc3Bl YyByZWFkcywgVE9JID4gMCBpcyBwb3NzaWJsZSBmb3IgRkRUcy4NCg0KU29tZSBxdWVzdGlvbnMg SSBoYWQsIGhvd2V2ZXIsIHdlcmUgOg0KICAtIHdvdWxkIHRoZXJlIGJlIGEgc2VwYXJhdGUgRkRU IERhdGFiYXNlIGZvciBlYWNoIFRPSSwgb3INCiAgICB3b3VsZCBhbGwgdGhlIGRpZmZlcmVudCBU T0lzIHNoYXJlIHRoZSBzYW1lIEZEVCBEYXRhYmFzZT8NCiAgLSBpcyBpdCByZXF1aXJlZCBhdCBh bGwgdG8gdXNlIFRPSSA9IDAgYmVmb3JlIHVzaW5nIFRPSSA+IDAgPw0KDQpEbyB5b3UgdGhpbmsg d2Ugc2hvdWxkIGFuc3dlcmkgdGhlc2UgcXVlc3Rpb25zIGluIHRoZSBGTFVURSBzcGVjPw0KDQpU aGFua3MsDQoNCi0gRG9uIEdpbGxpZXMNClF1YWxjb21tIEluY29ycG9yYXRlZA0KDQpGcm9tOiBS b2QuV2Fsc2hAbm9raWEuY29tIFttYWlsdG86Um9kLldhbHNoQG5va2lhLmNvbV0NClNlbnQ6IFR1 ZXNkYXksIEphbnVhcnkgMjUsIDIwMTEgMTI6MzkgQU0NClRvOiBMdWJ5LCBNaWNoYWVsDQpDYzog cm10QGlldGYub3JnOyBHaWxsaWVzLCBEb247IEx1YnksIE1pY2hhZWwNClN1YmplY3Q6IFJlOiBb Um10XSBGTFVURSByZXZpc2lvbg0KDQpGRFQgaW5zdGFuY2VzIG9uIFRPSXMgb3RoZXIgdGhhbiAw IGFyZSBhbGxvd2VkIGJ5IGRlc2lnbi4gVGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgZm9yIGEgbWlu aW1hbCBGTFVURS1vbmx5IGNsaWVudCB0byBwYXJzZSB0aGVtICh0aGVyZSBpcyBubyBhc3N1cmFu Y2UgdGhhdCB0aGUgY2xpZW50IHdvdWxkIHBhcnNlIGFsbCB0byBUT0kwIEZEVCBpbnN0YW5jZXMg ZWl0aGVyKS4gSG93ZXZlciwgRkRUaSdzIG11c3QgZm9sbG93IHRoZSBGRFQgcnVsZXMgcmVnYXJk bGVzcyBvZiBUT0kgdGhleSBjb21lIG9uIChlLmcuIFRoZXkgdXNlIHRoZSBzYW1lICJUT0kgbmFt ZXNwYWNlIiBmb3IgdGhlIEZMVVRFIHNlc3Npb24pLiAgVGhpcyBhbGxvd3MgbW9yZSBmbGV4aWJs ZSBleHRlbnNpb25zIGJ1aWx0IG9uIHRvcCBvZiBGTFVURS4gKFRoZSBtbXVzaWMgSU1HIHdvcmss IHRoYXQgc3Bhd25lZCB0aGUgZmlyc3QgRkRBTEMgZHJhZnQsIHdhcyB0byB1c2UgdGhpcyBtdWx0 aS1UT0kgZmVhdHVyZSkuDQpEaXNjbGFpbWVyOiBhcG9sb2dpZXMgaWYgSSBtaXN1bmRlcnN0b29k IHRoZSBxdWVzdGlvbiBhcyBJIGRpZG4ndCBwYXJzZSB0aGUgYml0IG9uICJ3aXRoIGFuIEVYVF9G RFQgTENUIGV4dGVuc2lvbiBoZWFkZXIgY29udGFpbmluZyB0aGUgRkRUIEluc3RhbmNlIElEIiBh cyBpdCB3b3VsZCByZXF1aXJlIHJlLWRpZ2VzdGluZyB0aGUgc3BlYyBiZWZvcmUgcmVwbHlpbmcu IElmIHRoZSBxdWVzdGlvbiBpcyBsaW1pdGVkIHRvIHRoaXMgY2FzZSB3aXRoIHRoYXQgaGVhZGVy LCBhcmUgdGhlcmUgYW55IHBvc2l0aXZlIG9yIG5lZ2F0aXZlIGltcGxpY2F0aW9ucyBvZiBleHBs aWNpdGx5IGFsbG93aW5nIG9yIGRpc2FsbG93aW5nIHRoaXM/DQoNCkNoZWVycywgUm9kLg0KDQoN Ck9uIDI0IEphbiAyMDExLCBhdCAyMTo0MiwgImV4dCBMdWJ5LCBNaWNoYWVsIiA8bHVieUBxdWFs Y29tbS5jb208bWFpbHRvOmx1YnlAcXVhbGNvbW0uY29tPj4gd3JvdGU6DQpEZWFyIFJNVGVycywg V2UgYXJlIGluIHRoZSBwcm9jZXNzIG9mIHJldmlzaW5nIEZMVVRFIOKAkzExLCB0byBwcm9kdWNl IEZMVVRFIOKAkzEyLCBhbmQgaXQgaXMgY2xlYXIgYXQgdGhpcyBwb2ludCB0aGF0IHRoZSBGTFVU RSB2ZXJzaW9uIG51bWJlciB3aWxsIHRyYW5zaXRpb24gZnJvbSAxIHRvIDIuICBPbmUgcXVlc3Rp b24gdGhhdCBoYXMgYXJpc2VuOiBDYW4gYW4gRkRUIGluc3RhbmNlIGhhdmUgYSBUT0kgPiAwIHdp dGggYW4gRVhUX0ZEVCBMQ1QgZXh0ZW5zaW9uIGhlYWRlciBjb250YWluaW5nIHRoZSBGRFQgSW5z dGFuY2UgSUQ/ICBJIHRoaW5rIGl0IGlzIGFuZCBzaG91bGQgYmUgcmVzdHJpY3RlZCB0byBUT0kg PSAwIGZvciBjYXJyeWluZyBGRFQgaW5zdGFuY2VzLCBidXQgdGhlcmUgaXMgc29tZSBhbWJpZ3Vp dGllcyBpbiB0aGUgdGV4dCBoZXJlIGFuZCB0aGVyZSB0aGF0IG1pZ2h0IGJlIGNvbnN0cnVlZCB0 byBzdWdnZXN0IG90aGVyd2lzZS4NCk1pa2UNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpSbXQgbWFpbGluZyBsaXN0DQpSbXRAaWV0Zi5vcmc8bWFpbHRv OlJtdEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm10 DQo= --_000_C6B80B17C44541438510B42A18D01B7A04D1A2nasanexd01gnaqual_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQg MiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmFwcGxlLXN0eWxl LXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Um9kLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SW4gcmVhZGluZyB0aGUgc3BlY2lmaWNhdGlvbiwgSSBmb3VuZCBpbiB0d28gb3Ig dGhyZWUgcGxhY2VzLCB0ZXh0IHRoYXQgc3VnZ2VzdGVkIHRoYXQgRkRUIFRPSSA9IDAgYW5kIEZE VCBUT0kgJmd0OyAwIHdlcmUgYm90aCBwb3NzaWJsZSwgYXMgbG9uZyBhcyBib3RoIGZpbGVzDQog d2VyZSBkZWxpdmVyZWQgdXNpbmcgRkRUIEluc3RhbmNlIGluIHRoZSBFWFRfRkRUIGhlYWRlciBv ZiBMQ1QuJm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U28sIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGlzIGlz IGhvdyB0aGUgcHJlc2VudCBzcGVjIHJlYWRzLA0KPGI+PHU+VE9JICZndDsgMCBpcyBwb3NzaWJs ZSBmb3IgRkRUcy48L3U+PC9iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U29tZSBxdWVzdGlvbnMgSSBoYWQsIGhvd2V2 ZXIsIHdlcmUgOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsgLSB3b3VsZCB0 aGVyZSBiZSBhIHNlcGFyYXRlIEZEVCBEYXRhYmFzZSBmb3IgZWFjaCBUT0ksIG9yPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyB3b3VsZCBhbGwgdGhlIGRp ZmZlcmVudCBUT0lzIHNoYXJlIHRoZSBzYW1lIEZEVCBEYXRhYmFzZT88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7IC0gaXMgaXQgcmVxdWlyZWQgYXQgYWxsIHRvIHVzZSBUT0kg PSAwIGJlZm9yZSB1c2luZyBUT0kgJmd0OyAwID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRvIHlvdSB0aGluayB3ZSBz aG91bGQgYW5zd2VyaSB0aGVzZSBxdWVzdGlvbnMgaW4gdGhlIEZMVVRFIHNwZWM/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4tIERvbiBHaWxsaWVzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlF1YWxjb21tIEluY29ycG9yYXRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFJvZC5XYWxz aEBub2tpYS5jb20gW21haWx0bzpSb2QuV2Fsc2hAbm9raWEuY29tXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IFR1ZXNkYXksIEphbnVhcnkgMjUsIDIwMTEgMTI6MzkgQU08YnI+DQo8Yj5Ubzo8L2I+IEx1 YnksIE1pY2hhZWw8YnI+DQo8Yj5DYzo8L2I+IHJtdEBpZXRmLm9yZzsgR2lsbGllcywgRG9uOyBM dWJ5LCBNaWNoYWVsPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbUm10XSBGTFVURSByZXZpc2lv bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkZEVCBpbnN0YW5jZXMgb24gVE9JcyBvdGhlciB0 aGFuIDAgYXJlIGFsbG93ZWQgYnkgZGVzaWduLiBUaGVyZSBpcyBubyByZXF1aXJlbWVudCBmb3Ig YSBtaW5pbWFsIEZMVVRFLW9ubHkgY2xpZW50IHRvIHBhcnNlIHRoZW0gKHRoZXJlIGlzIG5vIGFz c3VyYW5jZSB0aGF0IHRoZSBjbGllbnQgd291bGQgcGFyc2UgYWxsIHRvIFRPSTAgRkRUIGluc3Rh bmNlcyBlaXRoZXIpLg0KIEhvd2V2ZXIsIEZEVGkncyBtdXN0IGZvbGxvdyB0aGUgRkRUIHJ1bGVz IHJlZ2FyZGxlc3Mgb2YgVE9JIHRoZXkgY29tZSBvbiAoZS5nLiA8c3BhbiBzdHlsZT0iY29sb3I6 cmVkIj4NClRoZXkgdXNlIHRoZSBzYW1lICZxdW90O1RPSSBuYW1lc3BhY2UmcXVvdDsgZm9yIHRo ZSBGTFVURSBzZXNzaW9uPC9zcGFuPikuICZuYnNwO1RoaXMgYWxsb3dzIG1vcmUgZmxleGlibGUg ZXh0ZW5zaW9ucyBidWlsdCBvbiB0b3Agb2YgRkxVVEUuIChUaGUgbW11c2ljIElNRyB3b3JrLCB0 aGF0IHNwYXduZWQgdGhlIGZpcnN0IEZEQUxDIGRyYWZ0LCB3YXMgdG8gdXNlIHRoaXMgbXVsdGkt VE9JIGZlYXR1cmUpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+RGlzY2xhaW1lcjogYXBvbG9naWVzIGlmIEkgbWlzdW5kZXJzdG9vZCB0aGUgcXVl c3Rpb24gYXMgSSBkaWRuJ3QgcGFyc2UgdGhlIGJpdCBvbiAmcXVvdDs8c3BhbiBjbGFzcz0iYXBw bGUtc3R5bGUtc3BhbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij53aXRoIGFuIEVYVF9G RFQgTENUIGV4dGVuc2lvbiBoZWFkZXIgY29udGFpbmluZyB0aGUgRkRUDQogSW5zdGFuY2UgSUQ8 L3NwYW4+PC9zcGFuPiZxdW90OyBhcyBpdCB3b3VsZCByZXF1aXJlIHJlLWRpZ2VzdGluZyB0aGUg c3BlYyBiZWZvcmUgcmVwbHlpbmcuIElmIHRoZSBxdWVzdGlvbiBpcyBsaW1pdGVkIHRvIHRoaXMg Y2FzZSB3aXRoIHRoYXQgaGVhZGVyLCBhcmUgdGhlcmUgYW55IHBvc2l0aXZlIG9yIG5lZ2F0aXZl IGltcGxpY2F0aW9ucyBvZiBleHBsaWNpdGx5IGFsbG93aW5nIG9yIGRpc2FsbG93aW5nIHRoaXM/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNo ZWVycywgUm9kLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIDI0IEphbiAyMDEx LCBhdCAyMTo0MiwgJnF1b3Q7ZXh0IEx1YnksIE1pY2hhZWwmcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpsdWJ5QHF1YWxjb21tLmNvbSI+bHVieUBxdWFsY29tbS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZWFyIFJNVGVycywgV2UgYXJlIGluIHRoZSBwcm9j ZXNzIG9mIHJldmlzaW5nIEZMVVRFIOKAkzExLCB0byBwcm9kdWNlIEZMVVRFIOKAkzEyLCBhbmQg aXQgaXMgY2xlYXIgYXQgdGhpcyBwb2ludCB0aGF0IHRoZSBGTFVURSB2ZXJzaW9uIG51bWJlciB3 aWxsIHRyYW5zaXRpb24gZnJvbSAxIHRvIDIuICZuYnNwO09uZQ0KIHF1ZXN0aW9uIHRoYXQgaGFz IGFyaXNlbjogQ2FuIGFuIEZEVCBpbnN0YW5jZSBoYXZlIGEgVE9JICZndDsgMCB3aXRoIGFuIEVY VF9GRFQgTENUIGV4dGVuc2lvbiBoZWFkZXIgY29udGFpbmluZyB0aGUgRkRUIEluc3RhbmNlIElE PyAmbmJzcDtJIHRoaW5rIGl0IGlzIGFuZCBzaG91bGQgYmUgcmVzdHJpY3RlZCB0byBUT0kgPSAw IGZvciBjYXJyeWluZyBGRFQgaW5zdGFuY2VzLCBidXQgdGhlcmUgaXMgc29tZSBhbWJpZ3VpdGll cyBpbiB0aGUgdGV4dCBoZXJlDQogYW5kIHRoZXJlIHRoYXQgbWlnaHQgYmUgY29uc3RydWVkIHRv IHN1Z2dlc3Qgb3RoZXJ3aXNlLjxicj4NCk1pa2UgJm5ic3A7PC9zcGFuPiA8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpSbXQg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlJtdEBpZXRmLm9yZyI+Um10QGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcm10Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JtdDwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_C6B80B17C44541438510B42A18D01B7A04D1A2nasanexd01gnaqual_-- From luby@qualcomm.com Tue Jan 25 16:40:12 2011 Return-Path: X-Original-To: rmt@core3.amsl.com Delivered-To: rmt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8E523A68F5 for ; Tue, 25 Jan 2011 16:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnSCukVHsKYR for ; Tue, 25 Jan 2011 16:40:11 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id D21833A68B8 for ; Tue, 25 Jan 2011 16:40:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1296002591; x=1327538591; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20"J ani.=20Fi"=20,=20"rmt@ietf.org"=20 |CC:=20"Gillies,=20Don"=20,=20"Luby,=20Michael"=0D=0A=09 |Date:=20Tue,=2025=20Jan=202011=2016:43:08=20-0800 |Subject:=20Re:=20[Rmt]=20FLUTE=20revision|Thread-Topic: =20[Rmt]=20FLUTE=20revision|Thread-Index:=20Acu8bQUkgfl33 6CfQX6/n2AZ/OMpFQAhPr1k|Message-ID:=20|In-Reply-To:=20<4D3E8EFB.8000307@tut.fi> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|user-agent:=20Mic rosoft-Entourage/13.8.0.101117|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=HV9wHx3EE435nEvlfeHP6DG0MPQPkzHAfL4RSSrVHtw=; b=BzTN97OicGTm4ZMgWlfhtLfX2zbifqpV5p9MKMLSsbSKx86bcE54+dAN AuxQ1OiZ0HTlEfF97TW6UXajKgtEBq+LPEXAyuitWsKDobb0WykvPj8uh TZvZrUCYtOp8/72nJjHm0Ihog0fUmQFLRTAsx+h+7CH66Oh6h8VK5f8fy 0=; X-IronPort-AV: E=McAfee;i="5400,1158,6237"; a="71764865" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 25 Jan 2011 16:43:10 -0800 X-IronPort-AV: E=Sophos;i="4.60,374,1291622400"; d="scan'208";a="24846170" Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 25 Jan 2011 16:43:10 -0800 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.3.83.0; Tue, 25 Jan 2011 16:43:10 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Tue, 25 Jan 2011 16:43:07 -0800 From: "Luby, Michael" To: "Jani. Fi" , "rmt@ietf.org" Date: Tue, 25 Jan 2011 16:43:08 -0800 Thread-Topic: [Rmt] FLUTE revision Thread-Index: Acu8bQUkgfl336CfQX6/n2AZ/OMpFQAhPr1k Message-ID: In-Reply-To: <4D3E8EFB.8000307@tut.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Gillies, Don" , "Luby, Michael" Subject: Re: [Rmt] FLUTE revision X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 00:40:13 -0000 Hi Jani, I'm missing where the version of FLUTE must be the same as the version of ALC and LCT. It seems that if we define this specification to be FLUTE version 2, and this FLUTE specification explicitly says that it must be use= d with ALC version 1 as specified in RFC 5775 and that it must be used with LCT version 1 as specified in RFC 5651 then there is no ambiguity, but mayb= e I'm missing something? I think what you are saying is that there is an overloaded field that carries both the FLUTE version and the ALC version an= d the LCT version? If so, can you point to that? Mike On 1/25/11 12:51 AM, "Jani. Fi" wrote: > Dear RMTers, >=20 > One side effect of the version number change is problem with ALC and LCT > versions. Version number is signalled in the LCT header field and in > RFCs 5775 and 5651 (FLUTE revised will be working on top of these RFCs) > version number is specified to be 1. >=20 > So it is not possible to signal FLUTE version 2 and ALC/LCT version 1 in > the same header field. >=20 > BR, > Jani >=20 >> Dear RMTers, We are in the process of revising FLUTE =AD11, to produce >> FLUTE =AD12, and it is clear at this point that the FLUTE version number >> will transition from 1 to 2. One question that has arisen: Can an FDT >> instance have a TOI > 0 with an EXT_FDT LCT extension header containing >> the FDT Instance ID? I think it is and should be restricted to TOI =3D = 0 >> for carrying FDT instances, but there is some ambiguities in the text >> here and there that might be construed to suggest otherwise. >> Mike =20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Rmt mailing list >> Rmt@ietf.org >> https://www.ietf.org/mailman/listinfo/rmt From jani.peltotalo@tut.fi Tue Jan 25 23:00:11 2011 Return-Path: X-Original-To: rmt@core3.amsl.com Delivered-To: rmt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 240DD28C0CE for ; Tue, 25 Jan 2011 23:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6B+6jhsW6Jf for ; Tue, 25 Jan 2011 23:00:09 -0800 (PST) Received: from mail.cs.tut.fi (mail.cs.tut.fi [130.230.4.42]) by core3.amsl.com (Postfix) with ESMTP id A39F53A694D for ; Tue, 25 Jan 2011 23:00:07 -0800 (PST) Received: from amavis1.cs.tut.fi (amavis1.cs.tut.fi [130.230.4.69]) by mail.cs.tut.fi (Postfix) with ESMTP id 26E5B157A; Wed, 26 Jan 2011 09:03:06 +0200 (EET) Received: from mail.cs.tut.fi ([130.230.4.42]) by amavis1.cs.tut.fi (amavis1.cs.tut.fi [130.230.4.69]) (amavisd-maia, port 10024) with ESMTP id 21689-26; Wed, 26 Jan 2011 09:03:05 +0200 (EET) Received: from [130.230.52.207] (icepc023.atm.tut.fi [130.230.52.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id 21BF71579; Wed, 26 Jan 2011 09:03:05 +0200 (EET) Message-ID: <4D3FC721.3070807@tut.fi> Date: Wed, 26 Jan 2011 09:02:57 +0200 From: Jani Peltotalo User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Luby, Michael" References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.2 Cc: "Gillies, Don" , "rmt@ietf.org" Subject: Re: [Rmt] FLUTE revision X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 07:00:11 -0000 Hi Mike, Of course we can/must specify in the text as you mention below. However in the packet only place to signal the version number is LCT version number (V) field: LCT version number (V): 4 bits Indicates the LCT version number. The LCT version number for this specification is 1. In RFC 5775 it is then mentioned: "The version number of ALC specified in this document is 1. The version number field of the LCT header MUST be interpreted as the ALC version number field. This version of ALC implicitly makes use of version 1 of the LCT building block defined in [RFC 5651]." This kind of text is missing from the experimental FLUTE RFC and from the revised FLUTE, but if we want to overload this field with FLUTE version number (as we have done in our implementation based in experimental RFC) to enable receivers to distinguish FLUTE versions 1 and 2, the packet is not anymore align with the ALC and LCT RFCs. It is also possible to leave this field for ALC/LCT version numbers and use for example reserved bits or LCT header extension to signal FLUTE version. All in all, in my opinion it is necessary to signal FLUTE version 2 somewhere in the FLUTE packet to be backwards compatible with the receivers based on the experimental FLUTE RFC. BR, Jani > Hi Jani, > I'm missing where the version of FLUTE must be the same as the version of > ALC and LCT. It seems that if we define this specification to be FLUTE > version 2, and this FLUTE specification explicitly says that it must be used > with ALC version 1 as specified in RFC 5775 and that it must be used with > LCT version 1 as specified in RFC 5651 then there is no ambiguity, but maybe > I'm missing something? I think what you are saying is that there is an > overloaded field that carries both the FLUTE version and the ALC version and > the LCT version? If so, can you point to that? > Mike > > > On 1/25/11 12:51 AM, "Jani. Fi" wrote: > >> Dear RMTers, >> >> One side effect of the version number change is problem with ALC and LCT >> versions. Version number is signalled in the LCT header field and in >> RFCs 5775 and 5651 (FLUTE revised will be working on top of these RFCs) >> version number is specified to be 1. >> >> So it is not possible to signal FLUTE version 2 and ALC/LCT version 1 in >> the same header field. >> >> BR, >> Jani >> >>> Dear RMTers, We are in the process of revising FLUTE ­11, to produce >>> FLUTE ­12, and it is clear at this point that the FLUTE version number >>> will transition from 1 to 2. One question that has arisen: Can an FDT >>> instance have a TOI > 0 with an EXT_FDT LCT extension header containing >>> the FDT Instance ID? I think it is and should be restricted to TOI = 0 >>> for carrying FDT instances, but there is some ambiguities in the text >>> here and there that might be construed to suggest otherwise. >>> Mike >>> >>> >>> >>> _______________________________________________ >>> Rmt mailing list >>> Rmt@ietf.org >>> https://www.ietf.org/mailman/listinfo/rmt > From dgillies@qualcomm.com Tue Jan 25 23:28:41 2011 Return-Path: X-Original-To: rmt@core3.amsl.com Delivered-To: rmt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D0A23A6946 for ; Tue, 25 Jan 2011 23:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsgpJHnqY3YK for ; Tue, 25 Jan 2011 23:28:39 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id B4F883A6939 for ; Tue, 25 Jan 2011 23:28:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=dgillies@qualcomm.com; q=dns/txt; s=qcdkim; t=1296027098; x=1327563098; h=from:to:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:content-transfer-encoding: mime-version; z=From:=20"Gillies,=20Don"=20|To: =20"rmt@ietf.org"=20|Subject:=20RE:=20[Rmt] =20FLUTE=20revision|Thread-Topic:=20[Rmt]=20FLUTE=20revis ion|Thread-Index:=20Acu7/s3bu02S0/6jkUWpHOn8pWpptAAsUGeAA CE/sQAADUPTgAAP619Q|Date:=20Wed,=2026=20Jan=202011=2007:3 1:37=20+0000|Message-ID:=20|References:=20=20<4D3FC721.3070807@tut.fi> |In-Reply-To:=20<4D3FC721.3070807@tut.fi> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|x-originating-ip: =20[172.30.39.5]|Content-Type:=20text/plain=3B=20charset =3D"us-ascii"|Content-Transfer-Encoding:=20quoted-printab le|MIME-Version:=201.0; bh=nmHUK9u+4fguxwvMlXeKjCBKy9CkxPdb8oeZfMHiCwo=; b=T1rsUUvdhWXiPN0N0bBv5g22zPeVkdAA/EnIMl9fey+ZkLOS4aIwG2Hx XIDEDIBeen8efsO0L12whxIrf6GcNX7uwExWAHWK2Zb9t/Pc2WLv9YqJL AX1YKR7Sm8RGkW8ZE7DQCLQJRsRhcoc5SAAeQ2vEWVW0YnPhLmEjiOOjw s=; X-IronPort-AV: E=McAfee;i="5400,1158,6237"; a="72016387" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 25 Jan 2011 23:31:38 -0800 X-IronPort-AV: E=Sophos;i="4.60,378,1291622400"; d="scan'208";a="24930643" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 25 Jan 2011 23:31:38 -0800 Received: from NASANEXD01G.na.qualcomm.com ([fe80::c0c6:d0ab:610c:4263]) by nasanexhc05.na.qualcomm.com ([::1]) with mapi id 14.01.0218.012; Tue, 25 Jan 2011 23:31:38 -0800 From: "Gillies, Don" To: "rmt@ietf.org" Thread-Topic: [Rmt] FLUTE revision Thread-Index: Acu7/s3bu02S0/6jkUWpHOn8pWpptAAsUGeAACE/sQAADUPTgAAP619Q Date: Wed, 26 Jan 2011 07:31:37 +0000 Message-ID: References: <4D3FC721.3070807@tut.fi> In-Reply-To: <4D3FC721.3070807@tut.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Rmt] FLUTE revision X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 07:28:41 -0000 I had one more question about FLUTE FDTs after reading the r12 FLUTE spec. Is it required that the FDT have a table entry for the FDT itself (i.e. sho= uld the FDT be self-describing?) So for a typical flute session does TOI=3D0 have = to appear in the table of attributes? I could not tell if the FDT had to reference itself. Since only TOI and UR= I are=20 required for a file in the FDT, it seems useful to me to have the URI in ca= se I wanted to fetch the latest version of an FDT via unicast. - Don Gillies Qualcomm Incorporated From luby@qualcomm.com Wed Jan 26 00:30:32 2011 Return-Path: X-Original-To: rmt@core3.amsl.com Delivered-To: rmt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22ED23A6967 for ; Wed, 26 Jan 2011 00:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiVVwNrcQsWZ for ; Wed, 26 Jan 2011 00:30:30 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 83DAD3A6958 for ; Wed, 26 Jan 2011 00:30:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1296030810; x=1327566810; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20"J ani.=20Fi"=20|CC:=20"rmt@ietf.org" =20,=20"Gillies,=20Don"=20,=0D=0A=09"Luby,=20Michael"=20 |Date:=20Wed,=2026=20Jan=202011=2000:33:27=20-0800 |Subject:=20Re:=20[Rmt]=20FLUTE=20revision|Thread-Topic: =20[Rmt]=20FLUTE=20revision|Thread-Index:=20Acu9Jxf0r45I4 3ZsQquxIjnPHDPykQADJv7+|Message-ID:=20|In-Reply-To:=20<4D3FC721.3070807@tut.fi> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|user-agent:=20Mic rosoft-Entourage/13.8.0.101117|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=M7waXelAVLU0dN6ZkSKqDOVMn/0dsrY47o2g8CmWGFg=; b=StPN5ovN62MhSchRVanA7cn/4PFHafqmk3vfjMM/iwEwGPY2CF20hvm9 b9KMSd2+/36QnjU6P4yVyNnr3zZazetfFxIjslESx46KiRcRCAAsCfhZT 9w0bwACvOWqpjaDYTw9i8gjocL7XyphjocSKXlDRYUpXtszAEgDTwAV5H Q=; X-IronPort-AV: E=McAfee;i="5400,1158,6237"; a="71806642" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 26 Jan 2011 00:33:30 -0800 X-IronPort-AV: E=Sophos;i="4.60,378,1291622400"; d="scan'208";a="112614849" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 26 Jan 2011 00:33:30 -0800 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.3.83.0; Wed, 26 Jan 2011 00:33:30 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Wed, 26 Jan 2011 00:33:28 -0800 From: "Luby, Michael" To: "Jani. Fi" Date: Wed, 26 Jan 2011 00:33:27 -0800 Thread-Topic: [Rmt] FLUTE revision Thread-Index: Acu9Jxf0r45I43ZsQquxIjnPHDPykQADJv7+ Message-ID: In-Reply-To: <4D3FC721.3070807@tut.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Luby, Michael" , "Gillies, Don" , "rmt@ietf.org" Subject: Re: [Rmt] FLUTE revision X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 08:30:32 -0000 Thanks Jani for bringing this to our attention. We will take a look at this= . The easiest solution off the top of my head is to specify in the FLUTE draf= t that the LCT version number in the LCT header MUST be interpreted as the FLUTE version number field (just like what ALC does when it uses LCT). However, we'll look at it more closely. Best, Mike On 1/25/11 11:02 PM, "Jani. Fi" wrote: > Hi Mike, >=20 > Of course we can/must specify in the text as you mention below. However > in the packet only place to signal the version number is LCT version > number (V) field: >=20 > LCT version number (V): 4 bits >=20 > Indicates the LCT version number. The LCT version number for this > specification is 1. >=20 > In RFC 5775 it is then mentioned: >=20 > "The version number of ALC specified in this document is 1. The version > number field of the LCT header MUST be interpreted as the ALC version > number field. This version of ALC implicitly makes use of version 1 of > the LCT building block defined in [RFC 5651]." >=20 > This kind of text is missing from the experimental FLUTE RFC and from > the revised FLUTE, but if we want to overload this field with FLUTE > version number (as we have done in our implementation based in > experimental RFC) to enable receivers to distinguish FLUTE versions 1 > and 2, the packet is not anymore align with the ALC and LCT RFCs. >=20 > It is also possible to leave this field for ALC/LCT version numbers and > use for example reserved bits or LCT header extension to signal FLUTE > version. All in all, in my opinion it is necessary to signal FLUTE > version 2 somewhere in the FLUTE packet to be backwards compatible with > the receivers based on the experimental FLUTE RFC. >=20 > BR, > Jani >=20 >> Hi Jani, >> I'm missing where the version of FLUTE must be the same as the version o= f >> ALC and LCT. It seems that if we define this specification to be FLUTE >> version 2, and this FLUTE specification explicitly says that it must be = used >> with ALC version 1 as specified in RFC 5775 and that it must be used wit= h >> LCT version 1 as specified in RFC 5651 then there is no ambiguity, but m= aybe >> I'm missing something? I think what you are saying is that there is an >> overloaded field that carries both the FLUTE version and the ALC version= and >> the LCT version? If so, can you point to that? >> Mike >>=20 >>=20 >> On 1/25/11 12:51 AM, "Jani. Fi" wrote: >>=20 >>> Dear RMTers, >>>=20 >>> One side effect of the version number change is problem with ALC and LC= T >>> versions. Version number is signalled in the LCT header field and in >>> RFCs 5775 and 5651 (FLUTE revised will be working on top of these RFCs) >>> version number is specified to be 1. >>>=20 >>> So it is not possible to signal FLUTE version 2 and ALC/LCT version 1 i= n >>> the same header field. >>>=20 >>> BR, >>> Jani >>>=20 >>>> Dear RMTers, We are in the process of revising FLUTE =AD11, to produce >>>> FLUTE =AD12, and it is clear at this point that the FLUTE version numb= er >>>> will transition from 1 to 2. One question that has arisen: Can an FDT >>>> instance have a TOI > 0 with an EXT_FDT LCT extension header containin= g >>>> the FDT Instance ID? I think it is and should be restricted to TOI = =3D 0 >>>> for carrying FDT instances, but there is some ambiguities in the text >>>> here and there that might be construed to suggest otherwise. >>>> Mike =20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Rmt mailing list >>>> Rmt@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rmt >>=20 From luby@qualcomm.com Wed Jan 26 00:41:34 2011 Return-Path: X-Original-To: rmt@core3.amsl.com Delivered-To: rmt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A227E3A6958 for ; Wed, 26 Jan 2011 00:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sy05J4rbUsm for ; Wed, 26 Jan 2011 00:41:33 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 9FEA53A690E for ; Wed, 26 Jan 2011 00:41:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1296031473; x=1327567473; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20"J ani.=20Fi"=20|CC:=20"rmt@ietf.org" =20,=20"Gillies,=20Don"=20,=0D=0A=09"Luby,=20Michael"=20 |Date:=20Wed,=2026=20Jan=202011=2000:44:30=20-0800 |Subject:=20Re:=20[Rmt]=20FLUTE=20revision|Thread-Topic: =20[Rmt]=20FLUTE=20revision|Thread-Index:=20Acu9Jxf0r45I4 3ZsQquxIjnPHDPykQADJv7+AABizFM=3D|Message-ID:=20|In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|user-agent:=20Microsoft-Entourage/ 13.8.0.101117|acceptlanguage:=20en-US|Content-Type:=20tex t/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=rXnQ6WDMUojCUfnyDA3E4SU3YZv6irLh5QtdL8/3ZQQ=; b=TlqmSV4kcCm7Z0KgwtJYXFK777ZjsXGTih/6yEUsAUYDBCMGf2/0QmMV tJLZ6b6C9sKJI9wv19YGX4gQfTEH8VkMotv9t04Z5FmnA5hw6W7BquW9P MVYIGcPF7ioYL8WPnX4nnjLOEuoymghg8ZtaO5h9b+m8tFDTaL0qNmQuj U=; X-IronPort-AV: E=McAfee;i="5400,1158,6237"; a="71807402" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 26 Jan 2011 00:44:33 -0800 X-IronPort-AV: E=Sophos;i="4.60,378,1291622400"; d="scan'208";a="112616347" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 26 Jan 2011 00:44:33 -0800 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhc08.na.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 26 Jan 2011 00:44:33 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Wed, 26 Jan 2011 00:44:32 -0800 From: "Luby, Michael" To: "Jani. Fi" Date: Wed, 26 Jan 2011 00:44:30 -0800 Thread-Topic: [Rmt] FLUTE revision Thread-Index: Acu9Jxf0r45I43ZsQquxIjnPHDPykQADJv7+AABizFM= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Luby, Michael" , "Gillies, Don" , "rmt@ietf.org" Subject: Re: [Rmt] FLUTE revision X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 08:41:34 -0000 Actually, looking at the FLUTE doc, it seems that the only place where the FLUTE version number is carried is in the FDT Instance header EXT_FDT, whic= h is an ALC PI specific LCT header extension, i.e., in EXT_FDT there is a FLUTE version number that MUST be set to 2. If this is correct, then it seems fine that the version number carried in the LCT header is the ALC version number, which is 1. Comments on this? On 1/26/11 12:33 AM, "Luby, Michael" wrote: > Thanks Jani for bringing this to our attention. We will take a look at th= is. > The easiest solution off the top of my head is to specify in the FLUTE dr= aft > that the LCT version number in the LCT header MUST be interpreted as the > FLUTE version number field (just like what ALC does when it uses LCT). > However, we'll look at it more closely. > Best, Mike >=20 >=20 > On 1/25/11 11:02 PM, "Jani. Fi" wrote: >=20 >> Hi Mike, >>=20 >> Of course we can/must specify in the text as you mention below. However >> in the packet only place to signal the version number is LCT version >> number (V) field: >>=20 >> LCT version number (V): 4 bits >>=20 >> Indicates the LCT version number. The LCT version number for this >> specification is 1. >>=20 >> In RFC 5775 it is then mentioned: >>=20 >> "The version number of ALC specified in this document is 1. The version >> number field of the LCT header MUST be interpreted as the ALC version >> number field. This version of ALC implicitly makes use of version 1 of >> the LCT building block defined in [RFC 5651]." >>=20 >> This kind of text is missing from the experimental FLUTE RFC and from >> the revised FLUTE, but if we want to overload this field with FLUTE >> version number (as we have done in our implementation based in >> experimental RFC) to enable receivers to distinguish FLUTE versions 1 >> and 2, the packet is not anymore align with the ALC and LCT RFCs. >>=20 >> It is also possible to leave this field for ALC/LCT version numbers and >> use for example reserved bits or LCT header extension to signal FLUTE >> version. All in all, in my opinion it is necessary to signal FLUTE >> version 2 somewhere in the FLUTE packet to be backwards compatible with >> the receivers based on the experimental FLUTE RFC. >>=20 >> BR, >> Jani >>=20 >>> Hi Jani, >>> I'm missing where the version of FLUTE must be the same as the version = of >>> ALC and LCT. It seems that if we define this specification to be FLUTE >>> version 2, and this FLUTE specification explicitly says that it must be= used >>> with ALC version 1 as specified in RFC 5775 and that it must be used wi= th >>> LCT version 1 as specified in RFC 5651 then there is no ambiguity, but = maybe >>> I'm missing something? I think what you are saying is that there is an >>> overloaded field that carries both the FLUTE version and the ALC versio= n and >>> the LCT version? If so, can you point to that? >>> Mike >>>=20 >>>=20 >>> On 1/25/11 12:51 AM, "Jani. Fi" wrote: >>>=20 >>>> Dear RMTers, >>>>=20 >>>> One side effect of the version number change is problem with ALC and L= CT >>>> versions. Version number is signalled in the LCT header field and in >>>> RFCs 5775 and 5651 (FLUTE revised will be working on top of these RFCs= ) >>>> version number is specified to be 1. >>>>=20 >>>> So it is not possible to signal FLUTE version 2 and ALC/LCT version 1 = in >>>> the same header field. >>>>=20 >>>> BR, >>>> Jani >>>>=20 >>>>> Dear RMTers, We are in the process of revising FLUTE =AD11, to produc= e >>>>> FLUTE =AD12, and it is clear at this point that the FLUTE version num= ber >>>>> will transition from 1 to 2. One question that has arisen: Can an FD= T >>>>> instance have a TOI > 0 with an EXT_FDT LCT extension header containi= ng >>>>> the FDT Instance ID? I think it is and should be restricted to TOI = =3D 0 >>>>> for carrying FDT instances, but there is some ambiguities in the text >>>>> here and there that might be construed to suggest otherwise. >>>>> Mike =20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Rmt mailing list >>>>> Rmt@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rmt >>>=20 >=20 From jani.peltotalo@tut.fi Wed Jan 26 01:17:28 2011 Return-Path: X-Original-To: rmt@core3.amsl.com Delivered-To: rmt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEE4F3A68D7 for ; Wed, 26 Jan 2011 01:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW133x6BqT7Y for ; Wed, 26 Jan 2011 01:17:27 -0800 (PST) Received: from mail.cs.tut.fi (mail.cs.tut.fi [130.230.4.42]) by core3.amsl.com (Postfix) with ESMTP id 708E93A695B for ; Wed, 26 Jan 2011 01:17:26 -0800 (PST) Received: from amavis2.cs.tut.fi (amavis2.cs.tut.fi [130.230.4.70]) by mail.cs.tut.fi (Postfix) with ESMTP id 31524C5D; Wed, 26 Jan 2011 11:20:25 +0200 (EET) Received: from mail.cs.tut.fi ([130.230.4.42]) by amavis2.cs.tut.fi (amavis2.cs.tut.fi [130.230.4.70]) (amavisd-maia, port 10024) with ESMTP id 23173-14-2; Wed, 26 Jan 2011 11:20:24 +0200 (EET) Received: from [130.230.210.81] (hopeahanhikki.tst.cs.tut.fi [130.230.210.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id 26E41C5B; Wed, 26 Jan 2011 11:20:24 +0200 (EET) Message-ID: <4D3FE757.5060904@tut.fi> Date: Wed, 26 Jan 2011 11:20:23 +0200 From: Jani Peltotalo User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Luby, Michael" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.2 Cc: "Gillies, Don" , "rmt@ietf.org" Subject: Re: [Rmt] FLUTE revision X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 09:17:28 -0000 Hi Mike&all, Yes, this is one possibility to signal the FLUTE version for whole FLUTE session. It still have negative influence on FLUTE version 1 receivers, which might buffer quite a lot unnecessary data, if the FDT Instance is not received early enough. BR, Jani > Actually, looking at the FLUTE doc, it seems that the only place where the > FLUTE version number is carried is in the FDT Instance header EXT_FDT, which > is an ALC PI specific LCT header extension, i.e., in EXT_FDT there is a > FLUTE version number that MUST be set to 2. If this is correct, then it > seems fine that the version number carried in the LCT header is the ALC > version number, which is 1. Comments on this? > > > On 1/26/11 12:33 AM, "Luby, Michael" wrote: > >> Thanks Jani for bringing this to our attention. We will take a look at this. >> The easiest solution off the top of my head is to specify in the FLUTE draft >> that the LCT version number in the LCT header MUST be interpreted as the >> FLUTE version number field (just like what ALC does when it uses LCT). >> However, we'll look at it more closely. >> Best, Mike >> >> >> On 1/25/11 11:02 PM, "Jani. Fi" wrote: >> >>> Hi Mike, >>> >>> Of course we can/must specify in the text as you mention below. However >>> in the packet only place to signal the version number is LCT version >>> number (V) field: >>> >>> LCT version number (V): 4 bits >>> >>> Indicates the LCT version number. The LCT version number for this >>> specification is 1. >>> >>> In RFC 5775 it is then mentioned: >>> >>> "The version number of ALC specified in this document is 1. The version >>> number field of the LCT header MUST be interpreted as the ALC version >>> number field. This version of ALC implicitly makes use of version 1 of >>> the LCT building block defined in [RFC 5651]." >>> >>> This kind of text is missing from the experimental FLUTE RFC and from >>> the revised FLUTE, but if we want to overload this field with FLUTE >>> version number (as we have done in our implementation based in >>> experimental RFC) to enable receivers to distinguish FLUTE versions 1 >>> and 2, the packet is not anymore align with the ALC and LCT RFCs. >>> >>> It is also possible to leave this field for ALC/LCT version numbers and >>> use for example reserved bits or LCT header extension to signal FLUTE >>> version. All in all, in my opinion it is necessary to signal FLUTE >>> version 2 somewhere in the FLUTE packet to be backwards compatible with >>> the receivers based on the experimental FLUTE RFC. >>> >>> BR, >>> Jani >>> >>>> Hi Jani, >>>> I'm missing where the version of FLUTE must be the same as the version of >>>> ALC and LCT. It seems that if we define this specification to be FLUTE >>>> version 2, and this FLUTE specification explicitly says that it must be used >>>> with ALC version 1 as specified in RFC 5775 and that it must be used with >>>> LCT version 1 as specified in RFC 5651 then there is no ambiguity, but maybe >>>> I'm missing something? I think what you are saying is that there is an >>>> overloaded field that carries both the FLUTE version and the ALC version and >>>> the LCT version? If so, can you point to that? >>>> Mike >>>> >>>> >>>> On 1/25/11 12:51 AM, "Jani. Fi" wrote: >>>> >>>>> Dear RMTers, >>>>> >>>>> One side effect of the version number change is problem with ALC and LCT >>>>> versions. Version number is signalled in the LCT header field and in >>>>> RFCs 5775 and 5651 (FLUTE revised will be working on top of these RFCs) >>>>> version number is specified to be 1. >>>>> >>>>> So it is not possible to signal FLUTE version 2 and ALC/LCT version 1 in >>>>> the same header field. >>>>> >>>>> BR, >>>>> Jani >>>>> >>>>>> Dear RMTers, We are in the process of revising FLUTE ­11, to produce >>>>>> FLUTE ­12, and it is clear at this point that the FLUTE version number >>>>>> will transition from 1 to 2. One question that has arisen: Can an FDT >>>>>> instance have a TOI > 0 with an EXT_FDT LCT extension header containing >>>>>> the FDT Instance ID? I think it is and should be restricted to TOI = 0 >>>>>> for carrying FDT instances, but there is some ambiguities in the text >>>>>> here and there that might be construed to suggest otherwise. >>>>>> Mike >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rmt mailing list >>>>>> Rmt@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/rmt > From vincent.roca@inrialpes.fr Wed Jan 26 03:08:29 2011 Return-Path: X-Original-To: rmt@core3.amsl.com Delivered-To: rmt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4689D3A69A4 for ; Wed, 26 Jan 2011 03:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.905 X-Spam-Level: X-Spam-Status: No, score=-9.905 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlifarJqG17o for ; Wed, 26 Jan 2011 03:08:24 -0800 (PST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id A6E4E3A69A2 for ; Wed, 26 Jan 2011 03:08:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,379,1291590000"; d="scan'208";a="96761968" Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 26 Jan 2011 12:11:21 +0100 Message-ID: <4D400159.9000004@inrialpes.fr> Date: Wed, 26 Jan 2011 12:11:21 +0100 From: Vincent Roca User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: rmt@ietf.org References: <4D3FE757.5060904@tut.fi> In-Reply-To: <4D3FE757.5060904@tut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Rmt] FLUTE revision X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 11:08:29 -0000 Hello everybody, I have two main comments: 1- I am extremely surprised to see people say that TOIs > 0 is possible for FDTs, as if it was obvious. That's the contrary IMHO. For instance section 3.3 of draft-ietf-rmt-flute-revised-11 says: * The TOI value of '0' MUST be reserved for delivery of FDT Instances. The use of other TOI values for FDT Instances is outside the scope of this specification. There are other sentences that only refer to value 0. For instance, beginning of Section 3.4: "FDT Instances are carried in ALC packets with TOI = 0..." and Figure 1 explicitely mentions TOI = 0. I understand that saying that "TOI 0 MUST be for FDT" is not the same as saying "FDT MUST use TOI 0". However the current specification does not explicitly say that other values must be considered. It only says that is is "out of the scope of this specification" which is different. Said differently, even if I'm co-author and FLUTE/ALC implementer, I never ever realized that the definite test to determine if an incoming packet contains an FDT Instance is the presence of the EXT_FDT rather than TOI=0. So I see a high risk of non-inter operable FLUTE implementations here if we don't clarify in the text the direction we want to choose. BTW, clarifying this point is also a good incentive to move to a version 2! 2- Let's assume we accept TOI > 0 for FDT Instances. If **all** FDT Instances are sent on TOI > 0, a FLUTEv1 receiver that drops such packets (high probability) will never consider any EXT_FDT. Since the FLUTE version number is carried in EXT_FDT only, this receiver has no way to identify that it is a FLUTEv2 session. He will wait forever an FDT Instance on TOI 0. So we need to mandate that, from time to time, a packet containing an EXT_FDT be sent on TOI 0. I'm not sure, but it's may be possible to send an empty FDT Instance to that purpose (e.g. if the senders wants to avoid having to send the same FDT Instance on multiple TOIs) (TBC). Cheers, Vincent > Hi Mike&all, > > Yes, this is one possibility to signal the FLUTE version for whole FLUTE > session. It still have negative influence on FLUTE version 1 receivers, > which might buffer quite a lot unnecessary data, if the FDT Instance is > not received early enough. > > BR, > Jani >> Actually, looking at the FLUTE doc, it seems that the only place where the >> FLUTE version number is carried is in the FDT Instance header EXT_FDT, which >> is an ALC PI specific LCT header extension, i.e., in EXT_FDT there is a >> FLUTE version number that MUST be set to 2. If this is correct, then it >> seems fine that the version number carried in the LCT header is the ALC >> version number, which is 1. Comments on this? >> >> >> On 1/26/11 12:33 AM, "Luby, Michael" wrote: >> >>> Thanks Jani for bringing this to our attention. We will take a look at this. >>> The easiest solution off the top of my head is to specify in the FLUTE draft >>> that the LCT version number in the LCT header MUST be interpreted as the >>> FLUTE version number field (just like what ALC does when it uses LCT). >>> However, we'll look at it more closely. >>> Best, Mike >>> >>> >>> On 1/25/11 11:02 PM, "Jani. Fi" wrote: >>> >>>> Hi Mike, >>>> >>>> Of course we can/must specify in the text as you mention below. However >>>> in the packet only place to signal the version number is LCT version >>>> number (V) field: >>>> >>>> LCT version number (V): 4 bits >>>> >>>> Indicates the LCT version number. The LCT version number for this >>>> specification is 1. >>>> >>>> In RFC 5775 it is then mentioned: >>>> >>>> "The version number of ALC specified in this document is 1. The version >>>> number field of the LCT header MUST be interpreted as the ALC version >>>> number field. This version of ALC implicitly makes use of version 1 of >>>> the LCT building block defined in [RFC 5651]." >>>> >>>> This kind of text is missing from the experimental FLUTE RFC and from >>>> the revised FLUTE, but if we want to overload this field with FLUTE >>>> version number (as we have done in our implementation based in >>>> experimental RFC) to enable receivers to distinguish FLUTE versions 1 >>>> and 2, the packet is not anymore align with the ALC and LCT RFCs. >>>> >>>> It is also possible to leave this field for ALC/LCT version numbers and >>>> use for example reserved bits or LCT header extension to signal FLUTE >>>> version. All in all, in my opinion it is necessary to signal FLUTE >>>> version 2 somewhere in the FLUTE packet to be backwards compatible with >>>> the receivers based on the experimental FLUTE RFC. >>>> >>>> BR, >>>> Jani >>>> >>>>> Hi Jani, >>>>> I'm missing where the version of FLUTE must be the same as the version of >>>>> ALC and LCT. It seems that if we define this specification to be FLUTE >>>>> version 2, and this FLUTE specification explicitly says that it must be used >>>>> with ALC version 1 as specified in RFC 5775 and that it must be used with >>>>> LCT version 1 as specified in RFC 5651 then there is no ambiguity, but maybe >>>>> I'm missing something? I think what you are saying is that there is an >>>>> overloaded field that carries both the FLUTE version and the ALC version and >>>>> the LCT version? If so, can you point to that? >>>>> Mike >>>>> >>>>> >>>>> On 1/25/11 12:51 AM, "Jani. Fi" wrote: >>>>> >>>>>> Dear RMTers, >>>>>> >>>>>> One side effect of the version number change is problem with ALC and LCT >>>>>> versions. Version number is signalled in the LCT header field and in >>>>>> RFCs 5775 and 5651 (FLUTE revised will be working on top of these RFCs) >>>>>> version number is specified to be 1. >>>>>> >>>>>> So it is not possible to signal FLUTE version 2 and ALC/LCT version 1 in >>>>>> the same header field. >>>>>> >>>>>> BR, >>>>>> Jani >>>>>> >>>>>>> Dear RMTers, We are in the process of revising FLUTE ­11, to produce >>>>>>> FLUTE ­12, and it is clear at this point that the FLUTE version number >>>>>>> will transition from 1 to 2. One question that has arisen: Can an FDT >>>>>>> instance have a TOI> 0 with an EXT_FDT LCT extension header containing >>>>>>> the FDT Instance ID? I think it is and should be restricted to TOI = 0 >>>>>>> for carrying FDT instances, but there is some ambiguities in the text >>>>>>> here and there that might be construed to suggest otherwise. >>>>>>> Mike >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rmt mailing list >>>>>>> Rmt@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/rmt > _______________________________________________ > Rmt mailing list > Rmt@ietf.org > https://www.ietf.org/mailman/listinfo/rmt From Rod.Walsh@nokia.com Wed Jan 26 05:28:43 2011 Return-Path: X-Original-To: rmt@core3.amsl.com Delivered-To: rmt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2683A69B3 for ; Wed, 26 Jan 2011 05:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBYmnAR-TE-6 for ; Wed, 26 Jan 2011 05:28:41 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 18F613A699E for ; Wed, 26 Jan 2011 05:28:40 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0QDVcxe014752; Wed, 26 Jan 2011 15:31:40 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Jan 2011 15:31:08 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 26 Jan 2011 14:31:07 +0100 From: To: Date: Wed, 26 Jan 2011 14:31:05 +0100 Thread-Topic: [Rmt] FLUTE revision Thread-Index: Acu9XUmNeplJsmMtRhSvASrsBOid4w== Message-ID: <4D402219.2010907@nokia.com> References: <4D3FE757.5060904@tut.fi> <4D400159.9000004@inrialpes.fr> In-Reply-To: <4D400159.9000004@inrialpes.fr> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4D4022192010907nokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 26 Jan 2011 13:31:08.0338 (UTC) FILETIME=[4A1F8920:01CBBD5D] X-Nokia-AV: Clean Cc: rmt@ietf.org Subject: Re: [Rmt] FLUTE revision X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 13:28:43 -0000 --_000_4D4022192010907nokiacom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Vincent et al. The discussion on multi-TOI FDT use is so historic that my memory is patchy= . It was about the same time as the discussion that, unlike ALC, FLUTE sess= ion signalling doesn't have to indicate that it contains an object because = it will always contain at least one FDT instance on TOI0. Also about the sa= me time as the first discussion that an IANA mimetype for the FDT instances= would be a good idea so FDT parsing had an easy way to detect non-TOI0 FDT= s. Why IANA registration was not included in the existing FLUTE RFC is beyo= nd my recall right now. (I remember we became preoccupied with security cor= ner cases to ensure RFC Editor success, so maybe we were distracted?) The current spec text "beyond the scope" is a pseudonym for "clients are no= t required to parse" to provide minimum interoperability, much the same as = the allowing extensions to the FDT XML without spec'ing them. Of course, there is nuanced sementic difference between "an FDT instance on= TOI!=3D0 contributing, possibly redundantly, to the session control inform= ation" and "a file of FDT mimetype on TOI!=3D0 relevant to some 'out of sco= pe' higher layer application but not contributing to the control informatio= n of the current session". And this could cause an IOP issue (although an F= DT attribute addition would fix that without breaking IOP). Clarifying text= on this wouldn't harm providing we haven't inadvertently sent implementers= in two different directions already. On the subject of version number, I am still very confused. No one has yet = offered a compelling reason for changing it. The headers don't break things= (at least the same version LCT/ALC changes are rolled into FLUTE and obvio= usly shouldn't prompt a flute version increment either). The reason to revi= se the FDT schema hasn't yet been explained. SDOs using the existing flute = will be hurt (or possibly the extra effort performed in the IETF will be re= ndered insignificant/obsolete where the deploying community consensus rejec= ts the change). So why? BTW, the revised FDT schema modifies effective functionality in two ways: i= t allows multiple FDT Instances per FDT Instance (I assume this is an error= ); it allows extensibility by elements as well as by attributes (sounds lik= e a "nice to have" but the gain is considerably less than the SDO disharmon= y pain). (Incidentally, both schema allow from zero file elements per FDT i= nstance, so "empty FDT Instances" are permitted). Cheers, Rod. PS I thought our primary goal with the RMT standards track revisions was to= preserve interoperability and avoid trashing the considerable amount of wo= rk that went into aligning so many SDOs behind a common IETF approach, so i= nteroperability preservation ought to be our default approach to spec text = modifications. On 26/01/2011 13:11, ext Vincent Roca wrote: Hello everybody, I have two main comments: 1- I am extremely surprised to see people say that TOIs > 0 is possible for FDTs, as if it was obvious. That's the contrary IMHO. For instance section 3.3 of draft-ietf-rmt-flute-revised-11 says: * The TOI value of '0' MUST be reserved for delivery of FDT Instances. The use of other TOI values for FDT Instances is outside the scope of this specification. There are other sentences that only refer to value 0. For instance, beginning of Section 3.4: "FDT Instances are carried in ALC packets with TOI =3D 0..." and Figure 1 explicitely mentions TOI =3D 0. I understand that saying that "TOI 0 MUST be for FDT" is not the same as saying "FDT MUST use TOI 0". However the current specification does not explicitly say that other values must be considered. It only says that is is "out of the scope of this specification" which is different. Said differently, even if I'm co-author and FLUTE/ALC implementer, I never ever realized that the definite test to determine if an incoming packet contains an FDT Instance is the presence of the EXT_FDT rather than TOI=3D0. So I see a high risk of non-inter operable FLUTE implementations here if we don't clarify in the text the direction we want to choose. BTW, clarifying this point is also a good incentive to move to a version 2! 2- Let's assume we accept TOI > 0 for FDT Instances. If **all** FDT Instances are sent on TOI > 0, a FLUTEv1 receiver that drops such packets (high probability) will never consider any EXT_FDT. Since the FLUTE version number is carried in EXT_FDT only, this receiver has no way to identify that it is a FLUTEv2 session. He will wait forever an FDT Instance on TOI 0. So we need to mandate that, from time to time, a packet containing an EXT_FDT be sent on TOI 0. I'm not sure, but it's may be possible to send an empty FDT Instance to that purpose (e.g. if the senders wants to avoid having to send the same FDT Instance on multiple TOIs) (TBC). Cheers, Vincent > Hi Mike&all, > > Yes, this is one possibility to signal the FLUTE version for whole FLUTE > session. It still have negative influence on FLUTE version 1 receivers, > which might buffer quite a lot unnecessary data, if the FDT Instance is > not received early enough. > > BR, > Jani >> Actually, looking at the FLUTE doc, it seems that the only place where t= he >> FLUTE version number is carried is in the FDT Instance header EXT_FDT, w= hich >> is an ALC PI specific LCT header extension, i.e., in EXT_FDT there is a >> FLUTE version number that MUST be set to 2. If this is correct, then it >> seems fine that the version number carried in the LCT header is the ALC >> version number, which is 1. Comments on this? >> >> >> On 1/26/11 12:33 AM, "Luby, Michael" wrote: >> >>> Thanks Jani for bringing this to our attention. We will take a look at = this. >>> The easiest solution off the top of my head is to specify in the FLUTE = draft >>> that the LCT version number in the LCT header MUST be interpreted as th= e >>> FLUTE version number field (just like what ALC does when it uses LCT). >>> However, we'll look at it more closely. >>> Best, Mike >>> >>> >>> On 1/25/11 11:02 PM, "Jani. Fi" wrote: >>> >>>> Hi Mike, >>>> >>>> Of course we can/must specify in the text as you mention below. Howeve= r >>>> in the packet only place to signal the version number is LCT version >>>> number (V) field: >>>> >>>> LCT version number (V): 4 bits >>>> >>>> Indicates the LCT version number. The LCT version number for this >>>> specification is 1. >>>> >>>> In RFC 5775 it is then mentioned: >>>> >>>> "The version number of ALC specified in this document is 1. The versio= n >>>> number field of the LCT header MUST be interpreted as the ALC version >>>> number field. This version of ALC implicitly makes use of version 1 of >>>> the LCT building block defined in [RFC 5651]." >>>> >>>> This kind of text is missing from the experimental FLUTE RFC and from >>>> the revised FLUTE, but if we want to overload this field with FLUTE >>>> version number (as we have done in our implementation based in >>>> experimental RFC) to enable receivers to distinguish FLUTE versions 1 >>>> and 2, the packet is not anymore align with the ALC and LCT RFCs. >>>> >>>> It is also possible to leave this field for ALC/LCT version numbers an= d >>>> use for example reserved bits or LCT header extension to signal FLUTE >>>> version. All in all, in my opinion it is necessary to signal FLUTE >>>> version 2 somewhere in the FLUTE packet to be backwards compatible wit= h >>>> the receivers based on the experimental FLUTE RFC. >>>> >>>> BR, >>>> Jani >>>> >>>>> Hi Jani, >>>>> I'm missing where the version of FLUTE must be the same as the versio= n of >>>>> ALC and LCT. It seems that if we define this specification to be FLUT= E >>>>> version 2, and this FLUTE specification explicitly says that it must = be used >>>>> with ALC version 1 as specified in RFC 5775 and that it must be used = with >>>>> LCT version 1 as specified in RFC 5651 then there is no ambiguity, bu= t maybe >>>>> I'm missing something? I think what you are saying is that there is = an >>>>> overloaded field that carries both the FLUTE version and the ALC vers= ion and >>>>> the LCT version? If so, can you point to that? >>>>> Mike >>>>> >>>>> >>>>> On 1/25/11 12:51 AM, "Jani. Fi" wrote: >>>>> >>>>>> Dear RMTers, >>>>>> >>>>>> One side effect of the version number change is problem with ALC and= LCT >>>>>> versions. Version number is signalled in the LCT header field and in >>>>>> RFCs 5775 and 5651 (FLUTE revised will be working on top of these RF= Cs) >>>>>> version number is specified to be 1. >>>>>> >>>>>> So it is not possible to signal FLUTE version 2 and ALC/LCT version = 1 in >>>>>> the same header field. >>>>>> >>>>>> BR, >>>>>> Jani >>>>>> >>>>>>> Dear RMTers, We are in the process of revising FLUTE =AD11, to prod= uce >>>>>>> FLUTE =AD12, and it is clear at this point that the FLUTE version n= umber >>>>>>> will transition from 1 to 2. One question that has arisen: Can an = FDT >>>>>>> instance have a TOI> 0 with an EXT_FDT LCT extension header contai= ning >>>>>>> the FDT Instance ID? I think it is and should be restricted to TOI= =3D 0 >>>>>>> for carrying FDT instances, but there is some ambiguities in the te= xt >>>>>>> here and there that might be construed to suggest otherwise. >>>>>>> Mike >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rmt mailing list >>>>>>> Rmt@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/rmt > _______________________________________________ > Rmt mailing list > Rmt@ietf.org > https://www.ietf.org/mailman/listinfo/rmt _______________________________________________ Rmt mailing list Rmt@ietf.org https://www.ietf.org/mailman/listinfo/rmt --_000_4D4022192010907nokiacom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hi Vincent et al.

The discussion on multi-TOI FDT use is so historic that my memory is patchy. It was about the same time as the discussion that, unlike ALC, FLUTE session signalling doesn't have to indicate that it contains an object because it will always contain at least one FDT instance on TOI0. Also about the same time as the first discussion that an IANA mimetype for the FDT instances would be a good idea so FDT parsing had an easy way to detect non-TOI0 FDTs. Why IANA registration was not included in the existing FLUTE RFC is beyond my recall right now. (I remember we became preoccupied with security corner cases to ensure RFC Editor success, so maybe we were distracted?)

The current spec text "beyond the scope" is a pseudonym for "clients are not required to parse" to provide minimum interoperability, much the same as the allowing extensions to the FDT XML without spec'ing them.

Of course, there is nuanced sementic difference between "an FDT instance on TOI!=3D0 contributing, possibly redundantly, to the session control information" and "a file of FDT mimetype on TOI!=3D0 relevant to some 'out of scope' higher layer application but not contributing to the control information of the current session". And this could cause an IOP issue (although an FDT attribute addition would fix that without breaking IOP). Clarifying text on this wouldn't harm providing we haven't inadvertently sent implementers in two different directions already.

On the subject of version number, I am still very confused. No one has yet offered a compelling reason for changing it. The headers don't break things (at least the same version LCT/ALC changes are rolled into FLUTE and obviously shouldn't prompt a flute version increment either). The reason to revise the FDT schema hasn't yet been explained. SDOs using the existing flute will be hurt (or possibly the extra effort performed in the IETF will be rendered insignificant/obsolete where the deploying community consensus rejects the change). So why?

BTW, the revised FDT schema modifies effective functionality in two ways: it allows multiple FDT Instances per FDT Instance (I assume this is an error); it allows extensibility by elements as well as by attributes (sounds like a "nice to have" but the gain is considerably less than the SDO disharmony pain). (Incidentally, both schema allow from zero file elements per FDT instance, so "empty FDT Instances" are permitted).

Cheers, Rod.

PS I thought our primary goal with the RMT standards track revisions was to preserve interoperability and avoid trashing the considerable amount of work that went into aligning so many SDOs behind a common IETF approach, so interoperability preservation ought to be our default approach to spec text modifications.



On 26/01/2011 13:11, ext Vincent Roca wrote:
Re: [Rmt] FLUTE revision

Hello everybody,

I have two main comments:

1- I am extremely surprised to see people say that
TOIs > 0 is possible for FDTs, as if it was obvious.
That's the contrary IMHO. For instance section 3.3 of
draft-ietf-rmt-flute-revised-11 says:

    *  The TOI value of '0' MUST be reserved = for delivery of FDT
       Instances.  The use of = other TOI values for FDT Instances is
       outside the scope of this sp= ecification.

There are other sentences that only refer to value 0.
For instance, beginning of Section 3.4:
      "FDT Instances are carried in ALC = packets with TOI =3D 0..."
and Figure 1 explicitely mentions TOI =3D 0.

I understand that saying that "TOI 0 MUST be for FDT" is
not the same as saying "FDT MUST use TOI 0". However
the current specification does not explicitly say that other
values must be considered. It only says that is is "out of
the scope of this specification" which is different.

Said differently, even if I'm co-author and FLUTE/ALC
implementer, I never ever realized that the definite test
to determine if an incoming packet contains an FDT
Instance is the presence of the EXT_FDT rather than
TOI=3D0.

So I see a high risk of non-inter operable FLUTE
implementations here if we don't clarify in the text the
direction we want to choose.

BTW, clarifying this point is also a good incentive to move
to a version 2!


2- Let's assume we accept TOI > 0 for FDT Instances.
If **all** FDT Instances are sent on TOI > 0, a FLUTEv1
receiver that drops such packets (high probability) will never consider any EXT_FDT. Since the FLUTE version number is
  carried in EXT_FDT only, this receiver has no way to
identify that it is a FLUTEv2 session. He will wait forever
an FDT Instance on TOI 0.

So we need to mandate that, from time to time, a packet
containing an EXT_FDT be sent on TOI 0.
I'm not sure, but it's may be possible to send an empty
FDT Instance to that purpose (e.g. if the senders wants to
avoid having to send the same FDT Instance on multiple
TOIs) (TBC).

Cheers,

    Vincent

> Hi Mike&all,
>
> Yes, this is one possibility to signal the FLUTE version for whole FLUTE
> session. It still have negative influence on FLUTE version 1 receivers,
> which might buffer quite a lot unnecessary data, if the FDT Instance is
> not received early enough.
>
> BR,
> Jani
>> Actually, looking at the FLUTE doc, it seems that the only place where the
>> FLUTE version number is carried is in the FDT Instance header EXT_FDT, which
>> is an ALC PI specific LCT header extension, i.e., in EXT_FDT there is a
>> FLUTE version number that MUST be set to 2.  If thi= s is correct, then it
>> seems fine that the version number carried in the LCT header is the ALC
>> version number, which is 1.  Comments on this?
>>
>>
>> On 1/26/11 12:33 AM, "Luby, Michael"<luby@qualcomm.com>  wrote:
>>
>>> Thanks Jani for bringing this to our attention. We will take a look at this.
>>> The easiest solution off the top of my head is to specify in the FLUTE draft
>>> that the LCT version number in the LCT header MUST be interpreted as the
>>> FLUTE version number field (just like what ALC does when it uses LCT).
>>> However, we'll look at it more closely.
>>> Best, Mike
>>>
>>>
>>> On 1/25/11 11:02 PM, "Jani. Fi"<jani.peltotalo@tut.fi>  wrote:
>>>
>>>> Hi Mike,
>>>>
>>>> Of course we can/must specify in the text as you mention below. However
>>>> in the packet only place to signal the version number is LCT version
>>>> number (V) field:
>>>>
>>>> LCT version number (V): 4 bits
>>>>
>>>> Indicates the LCT version number.  The LCT version number for this
>>>> specification is 1.
>>>>
>>>> In RFC 5775 it is then mentioned:
>>>>
>>>> "The version number of ALC specified in this document is 1. The version
>>>> number field of the LCT header MUST be interpreted as the ALC version
>>>> number field. This version of ALC implicitly makes use of version 1 of
>>>> the LCT building block defined in [RFC 5651]."
>>>>
>>>> This kind of text is missing from the experimental FLUTE RFC and from
>>>> the revised FLUTE, but if we want to overload this field with FLUTE
>>>> version number (as we have done in our implementation based in
>>>> experimental RFC) to enable receivers to distinguish FLUTE versions 1
>>>> and 2, the packet is not anymore align with the ALC and LCT RFCs.
>>>>
>>>> It is also possible to leave this field for ALC/LCT version numbers and
>>>> use for example reserved bits or LCT header extension to signal FLUTE
>>>> version. All in all, in my opinion it is necessary to signal FLUTE
>>>> version 2 somewhere in the FLUTE packet to be backwards compatible with
>>>> the receivers based on the experimental FLUTE RFC.
>>>>
>>>> BR,
>>>> Jani
>>>>
>>>>> Hi Jani,
>>>>> I'm missing where the version of FLUTE must be the same as the version of
>>>>> ALC and LCT. It seems that if we define this specification to be FLUTE
>>>>> version 2, and this FLUTE specification explicitly says that it must be used
>>>>> with ALC version 1 as specified in RFC 5775 and that it must be used with
>>>>> LCT version 1 as specified in RFC 5651 then there is no ambiguity, but maybe
>>>>> I'm missing something?  I think what yo= u are saying is that there is an
>>>>> overloaded field that carries both the FLUTE version and the ALC version and
>>>>> the LCT version?  If so, can you point = to that?
>>>>> Mike
>>>>>
>>>>>
>>>>> On 1/25/11 12:51 AM, "Jani. Fi"<jani.peltotalo@tut.fi>  wrote:
>>>>>
>>>>>> Dear RMTers,
>>>>>>
>>>>>> One side effect of the version number change is problem with ALC and LCT
>>>>>> versions. Version number is signalled in the LCT header field and in
>>>>>> RFCs 5775 and 5651 (FLUTE revised will be working on top of these RFCs)
>>>>>> version number is specified to be 1.
>>>>>>
>>>>>> So it is not possible to signal FLUTE version 2 and ALC/LCT version 1 in
>>>>>> the same header field.
>>>>>>
>>>>>> BR,
>>>>>> Jani
>>>>>>
>>>>>>> Dear RMTers, We are in the process of revising FLUTE ­11, to produce
>>>>>>> FLUTE ­12, and it is clear at this point that the FLUTE version number
>>>>>>> will transition from 1 to 2.  O= ne question that has arisen: Can an FDT
>>>>>>> instance have a TOI>  0 with an EXT_FDT LCT extension header containing
>>>>>>> the FDT Instance ID?  I think i= t is and should be restricted to TOI =3D 0
>>>>>>> for carrying FDT instances, but there is some ambiguities in the text
>>>>>>> here and there that might be construed to suggest otherwise.
>>>>>>> Mike
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Rmt mailing list
>>>>>>> Rmt@ietf.org
>>>>>>> https://www.= ietf.org/mailman/listinfo/rmt
> _______________________________________________
> Rmt mailing list
> Rmt@ietf.org
> https://www.= ietf.org/mailman/listinfo/rmt
_______________________________________________
Rmt mailing list
Rmt@ietf.org
https://www.= ietf.org/mailman/listinfo/rmt

= --_000_4D4022192010907nokiacom_-- From luby@qualcomm.com Wed Jan 26 09:01:21 2011 Return-Path: X-Original-To: rmt@core3.amsl.com Delivered-To: rmt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38E043A6905 for ; Wed, 26 Jan 2011 09:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.269 X-Spam-Level: X-Spam-Status: No, score=-106.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flamCeQ7V1zT for ; Wed, 26 Jan 2011 09:01:19 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id B87913A6800 for ; Wed, 26 Jan 2011 09:01:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1296061460; x=1327597460; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20"J ani.=20Fi"=20|CC:=20"rmt@ietf.org" =20,=20"Gillies,=20Don"=20,=0D=0A=09"Luby,=20Michael"=20 |Date:=20Wed,=2026=20Jan=202011=2009:04:17=20-0800 |Subject:=20Re:=20[Rmt]=20FLUTE=20revision|Thread-Topic: =20[Rmt]=20FLUTE=20revision|Thread-Index:=20Acu9OkaMTVf7p ILoRoKIuPQcXclUAAAQMo3Z|Message-ID:=20|In-Reply-To:=20<4D3FE757.5060904@tut.fi> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|user-agent:=20Mic rosoft-Entourage/13.8.0.101117|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=tg1dzT42MeGPe28M0C//LuMkuU7mBJMrZLEdS4j8f9E=; b=v146vjzIX1g9rLhO2sU/ULF+8UDniLaN6mV5B7g6EoJOZ8i0ChVXJGpk 0qopMKDkD26NFNpVafPeKpKlnlkwEag6rEFURGxbDc7lG7+C9nKnwU+YL W9o4SPxZ3zBtPIZUtey2figysi/LL4Hz19GOTfMDApBL55XpVlFSLXO95 A=; X-IronPort-AV: E=McAfee;i="5400,1158,6238"; a="71848831" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 26 Jan 2011 09:04:19 -0800 X-IronPort-AV: E=Sophos;i="4.60,380,1291622400"; d="scan'208";a="25150421" Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 26 Jan 2011 09:04:19 -0800 Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.3.83.0; Wed, 26 Jan 2011 09:04:19 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Wed, 26 Jan 2011 09:04:18 -0800 From: "Luby, Michael" To: "Jani. Fi" Date: Wed, 26 Jan 2011 09:04:17 -0800 Thread-Topic: [Rmt] FLUTE revision Thread-Index: Acu9OkaMTVf7pILoRoKIuPQcXclUAAAQMo3Z Message-ID: In-Reply-To: <4D3FE757.5060904@tut.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Luby, Michael" , "Gillies, Don" , "rmt@ietf.org" Subject: Re: [Rmt] FLUTE revision X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 17:01:21 -0000 Hi Jani, I guess you are thinking that the FLUTE version 1 receivers might buffer data for files and then when they get the FDT that is for the new FLUTE spe= c the receivers realize that they don't support FLUTE version 2 and have to discard all of this data because they don't know what to do with it? If that is the concern, there is advice in the FLUTE specification that recommends that the FDT instances should be sent before the actual data for the file, and that FDTs should be sent with higher reliability than the fil= e data. There is stronger and clearer wording on this in the current FLUTE draft than in RFC 3926, but there is wording on this in the RFC 3926 as well, e.g.,"It is RECOMMENDED that FDT Instance that contains the file description entry for a file is sent prior to the sending of the described file within a file delivery session." Maybe I got this wrong? Best, Mike On 1/26/11 1:20 AM, "Jani. Fi" wrote: > Hi Mike&all, >=20 > Yes, this is one possibility to signal the FLUTE version for whole FLUTE > session. It still have negative influence on FLUTE version 1 receivers, > which might buffer quite a lot unnecessary data, if the FDT Instance is > not received early enough. >=20 > BR, > Jani >> Actually, looking at the FLUTE doc, it seems that the only place where t= he >> FLUTE version number is carried is in the FDT Instance header EXT_FDT, w= hich >> is an ALC PI specific LCT header extension, i.e., in EXT_FDT there is a >> FLUTE version number that MUST be set to 2. If this is correct, then it >> seems fine that the version number carried in the LCT header is the ALC >> version number, which is 1. Comments on this? >>=20 >>=20 >> On 1/26/11 12:33 AM, "Luby, Michael" wrote: >>=20 >>> Thanks Jani for bringing this to our attention. We will take a look at = this. >>> The easiest solution off the top of my head is to specify in the FLUTE = draft >>> that the LCT version number in the LCT header MUST be interpreted as th= e >>> FLUTE version number field (just like what ALC does when it uses LCT). >>> However, we'll look at it more closely. >>> Best, Mike >>>=20 >>>=20 >>> On 1/25/11 11:02 PM, "Jani. Fi" wrote: >>>=20 >>>> Hi Mike, >>>>=20 >>>> Of course we can/must specify in the text as you mention below. Howeve= r >>>> in the packet only place to signal the version number is LCT version >>>> number (V) field: >>>>=20 >>>> LCT version number (V): 4 bits >>>>=20 >>>> Indicates the LCT version number. The LCT version number for this >>>> specification is 1. >>>>=20 >>>> In RFC 5775 it is then mentioned: >>>>=20 >>>> "The version number of ALC specified in this document is 1. The versio= n >>>> number field of the LCT header MUST be interpreted as the ALC version >>>> number field. This version of ALC implicitly makes use of version 1 of >>>> the LCT building block defined in [RFC 5651]." >>>>=20 >>>> This kind of text is missing from the experimental FLUTE RFC and from >>>> the revised FLUTE, but if we want to overload this field with FLUTE >>>> version number (as we have done in our implementation based in >>>> experimental RFC) to enable receivers to distinguish FLUTE versions 1 >>>> and 2, the packet is not anymore align with the ALC and LCT RFCs. >>>>=20 >>>> It is also possible to leave this field for ALC/LCT version numbers an= d >>>> use for example reserved bits or LCT header extension to signal FLUTE >>>> version. All in all, in my opinion it is necessary to signal FLUTE >>>> version 2 somewhere in the FLUTE packet to be backwards compatible wit= h >>>> the receivers based on the experimental FLUTE RFC. >>>>=20 >>>> BR, >>>> Jani >>>>=20 >>>>> Hi Jani, >>>>> I'm missing where the version of FLUTE must be the same as the versio= n of >>>>> ALC and LCT. It seems that if we define this specification to be FLUT= E >>>>> version 2, and this FLUTE specification explicitly says that it must = be >>>>> used >>>>> with ALC version 1 as specified in RFC 5775 and that it must be used = with >>>>> LCT version 1 as specified in RFC 5651 then there is no ambiguity, bu= t >>>>> maybe >>>>> I'm missing something? I think what you are saying is that there is = an >>>>> overloaded field that carries both the FLUTE version and the ALC vers= ion >>>>> and >>>>> the LCT version? If so, can you point to that? >>>>> Mike >>>>>=20 >>>>>=20 >>>>> On 1/25/11 12:51 AM, "Jani. Fi" wrote: >>>>>=20 >>>>>> Dear RMTers, >>>>>>=20 >>>>>> One side effect of the version number change is problem with ALC and= LCT >>>>>> versions. Version number is signalled in the LCT header field and in >>>>>> RFCs 5775 and 5651 (FLUTE revised will be working on top of these RF= Cs) >>>>>> version number is specified to be 1. >>>>>>=20 >>>>>> So it is not possible to signal FLUTE version 2 and ALC/LCT version = 1 in >>>>>> the same header field. >>>>>>=20 >>>>>> BR, >>>>>> Jani >>>>>>=20 >>>>>>> Dear RMTers, We are in the process of revising FLUTE =AD11, to prod= uce >>>>>>> FLUTE =AD12, and it is clear at this point that the FLUTE version n= umber >>>>>>> will transition from 1 to 2. One question that has arisen: Can an = FDT >>>>>>> instance have a TOI > 0 with an EXT_FDT LCT extension header contai= ning >>>>>>> the FDT Instance ID? I think it is and should be restricted to TOI= =3D 0 >>>>>>> for carrying FDT instances, but there is some ambiguities in the te= xt >>>>>>> here and there that might be construed to suggest otherwise. >>>>>>> Mike =20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Rmt mailing list >>>>>>> Rmt@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/rmt >>=20 From ietfdbh@comcast.net Wed Jan 26 09:36:07 2011 Return-Path: X-Original-To: rmt@core3.amsl.com Delivered-To: rmt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B93333A69BB for ; Wed, 26 Jan 2011 09:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.627 X-Spam-Level: X-Spam-Status: No, score=-102.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0md+tyQONcH for ; Wed, 26 Jan 2011 09:36:06 -0800 (PST) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by core3.amsl.com (Postfix) with ESMTP id C0AB93A69B9 for ; Wed, 26 Jan 2011 09:36:06 -0800 (PST) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta11.emeryville.ca.mail.comcast.net with comcast id 0Heg1g00A1zF43QABHf7tt; Wed, 26 Jan 2011 17:39:08 +0000 Received: from davidPC ([67.189.235.106]) by omta24.emeryville.ca.mail.comcast.net with comcast id 0Hf41g00o2JQnJT8kHf6vK; Wed, 26 Jan 2011 17:39:07 +0000 From: "David Harrington" To: Date: Wed, 26 Jan 2011 12:38:44 -0500 Message-ID: <82907E2B03694680B9B26B5667506A5C@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acu9f+DC/U8ei3EtRyy3t1WxpX8b3g== X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Subject: [Rmt] AD review: draft-ietf-rmt-bb-fec-raptorq-04 X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 17:36:07 -0000 Hi, I have reviewed this draft and have the follwoing comments: Technical and process concerns: 1) This document includes linear algebraic calculations, and I have not done linear algeabra since college, so I am asking for expert review. 2) in section 7, IANA actually performs assignments, not this document. This would be better rephrased as IANA is requested to assign a value under the ietf:rmt:fec: encoding name-space to "RaptorQ Code", preferably the value 6. Editorial: I found the English parts of this document well-written, but it might benefit from a few editorial changes. 1) In 4.4.1.2, the third paragraph starts with the statement that function partition takes input parameters I and J. But this text doesn't describe what those two values represent. The second sentnece decsribes the purpose of Partition. It would be easier on the reader to state the purpose before showing the processing. i.e., put the second and third sentences before the first sentence. 2) in 4.4.2, the text "Otherwise, only whole symbols MUST be included." (So if otherwise is false - the last block is NOT a partial block - then the requirement for whole blocks does not apply?) I think this is slightly ambiguous, and might be better stated as "Otherwise, the packet MUST contain only whole symbols" 3) in 5.1.1, LT is defined by self-reference. If somebody doesn't what LT menas, they probably don't what an LT neighbor is. 4) section 5 defines variables and functions that are used in earlier sections. It would seem to make sense to move section 5.1 forward so the definition preceded the usage, i.e prior to section 3. 5) section 5.2 talks about a pseudo-random generator. Is this consistent with other IETF uses of pseudo-random, e.g., in the SEC area? In SEC, there are serious consequences of random or pseudo-random numbers being predictable. Are there any serious consequences of these numbers being predictable? 6) in 5.3.3.3, a number of terms are used before being defined nearby: LDPC and HDPC and PI, for example. I recommend that on first use, it be treated as "Low Density Parity Check (LDPC)" 7) While terms like LDPC are defined in the terminolgy section, if a reader doesn't know what a Low Density Parity Check is, this definition is not helpful. I would be good if the terminology section had pointers to informative references. 8) in 5.3.3.3, "evaluate to zero" using what types of mechanisms? I recommend this section describe what readers are expected to know before reading this, such as a basic understanding of linear algebra. The recommendation could be in the Introduction if so desired. 9) in 5.3.3.4, s/inSection/in Section/ 10) in 5.4.2.1, s/in Sections Section 5.3/in Section 5.3/ -- check this 11) I had a bit of difficulty parsing the sentence "Furthermore, for each such encoding symbol it is assumed that the number and set of intermediate symbols whose sum is equal to the encoding symbol is passed to the decoder." If I parse it correcetly, should this be "the number and set ... are passed"? Why are you assuming? Is this not definitive? 12) in 5.8, s/generated generated/generated/ David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) From iesg-secretary@ietf.org Wed Jan 26 15:16:59 2011 Return-Path: X-Original-To: rmt@core3.amsl.com Delivered-To: rmt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCEF428C0DE; Wed, 26 Jan 2011 15:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USO5-WqCWUfK; Wed, 26 Jan 2011 15:16:59 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 229063A68AF; Wed, 26 Jan 2011 15:16:59 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110126231659.8099.31801.idtracker@localhost> Date: Wed, 26 Jan 2011 15:16:59 -0800 Cc: rmt@ietf.org Subject: [Rmt] Last Call: (RaptorQ Forward Error Correction Scheme for Object Delivery) to Proposed Standard X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 23:16:59 -0000 The IESG has received a request from the Reliable Multicast Transport WG (rmt) to consider the following document: - 'RaptorQ Forward Error Correction Scheme for Object Delivery' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-02-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-rmt-bb-fec-raptorq/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-rmt-bb-fec-raptorq/ The following IPR Declarations may be related to this I-D: /ipr/615/ /ipr/618/ /ipr/702/ /ipr/734/ /ipr/1292/ From ietfdbh@comcast.net Wed Jan 26 15:38:03 2011 Return-Path: X-Original-To: rmt@core3.amsl.com Delivered-To: rmt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBF873A68C0 for ; Wed, 26 Jan 2011 15:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.625 X-Spam-Level: X-Spam-Status: No, score=-102.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPkCz9+16BfW for ; Wed, 26 Jan 2011 15:38:02 -0800 (PST) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id D98013A68BC for ; Wed, 26 Jan 2011 15:38:02 -0800 (PST) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta04.emeryville.ca.mail.comcast.net with comcast id 0Pba1g0050EPchoA4Ph42A; Wed, 26 Jan 2011 23:41:04 +0000 Received: from davidPC ([67.189.235.106]) by omta01.emeryville.ca.mail.comcast.net with comcast id 0Ph21g00u2JQnJT8MPh32F; Wed, 26 Jan 2011 23:41:04 +0000 From: "David Harrington" To: "'David Harrington'" , References: <82907E2B03694680B9B26B5667506A5C@davidPC> In-Reply-To: <82907E2B03694680B9B26B5667506A5C@davidPC> Date: Wed, 26 Jan 2011 18:40:41 -0500 Message-ID: <9B2A556E45CE499B999128559B9CDCAB@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acu9f+DC/U8ei3EtRyy3t1WxpX8b3gAJ2VPQ X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Subject: Re: [Rmt] AD review: draft-ietf-rmt-bb-fec-raptorq-04 X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 23:38:04 -0000 Hi, The next step will be to start an IETF Last call on the document. I have started the LC On point #1, I am asking for a tsvdir volunteer to review the math portions. This is a process point that I will oversee. The WG needs do nothing on this point. The expert review can be done at the same time as IETF LC. For all the rest of my points, these are purely editorial changes. Save these editorial changes and treat them as LC comments. i.e., a new revision is not needed at this time. We will want a new revision after IETF LC to address these and other comments. dbh > -----Original Message----- > From: rmt-bounces@ietf.org [mailto:rmt-bounces@ietf.org] On > Behalf Of David Harrington > Sent: Wednesday, January 26, 2011 12:39 PM > To: rmt@ietf.org > Subject: [Rmt] AD review: draft-ietf-rmt-bb-fec-raptorq-04 > > Hi, > > I have reviewed this draft and have the follwoing comments: > > Technical and process concerns: > 1) This document includes linear algebraic calculations, and I have > not done linear algeabra since college, so I am asking for expert > review. > 2) in section 7, IANA actually performs assignments, not this > document. This would be better rephrased as IANA is requested to > assign a value under the ietf:rmt:fec: encoding name-space to "RaptorQ > Code", preferably the value 6. > > Editorial: > I found the English parts of this document well-written, but it might > benefit from a few editorial changes. > 1) In 4.4.1.2, the third paragraph starts with the statement that > function partition takes input parameters I and J. But this text > doesn't describe what those two values represent. The second sentnece > decsribes the purpose of Partition. It would be easier on the reader > to state the purpose before showing the processing. i.e., put the > second and third sentences before the first sentence. > 2) in 4.4.2, the text "Otherwise, only whole symbols MUST be > included." (So if otherwise is false - the last block is NOT a partial > block - then the requirement for whole blocks does not apply?) I think > this is slightly ambiguous, and might be better stated as "Otherwise, > the packet MUST contain only whole symbols" > 3) in 5.1.1, LT is defined by self-reference. If somebody doesn't what > LT menas, they probably don't what an LT neighbor is. > 4) section 5 defines variables and functions that are used in earlier > sections. It would seem to make sense to move section 5.1 forward so > the definition preceded the usage, i.e prior to section 3. > 5) section 5.2 talks about a pseudo-random generator. Is this > consistent with other IETF uses of pseudo-random, e.g., in the SEC > area? In SEC, there are serious consequences of random or > pseudo-random numbers being predictable. Are there any serious > consequences of these numbers being predictable? > 6) in 5.3.3.3, a number of terms are used before being defined nearby: > LDPC and HDPC and PI, for example. I recommend that on first use, it > be treated as "Low Density Parity Check (LDPC)" > 7) While terms like LDPC are defined in the terminolgy section, if a > reader doesn't know what a Low Density Parity Check is, this > definition is not helpful. I would be good if the terminology section > had pointers to informative references. > 8) in 5.3.3.3, "evaluate to zero" using what types of mechanisms? I > recommend this section describe what readers are expected to know > before reading this, such as a basic understanding of linear algebra. > The recommendation could be in the Introduction if so desired. > 9) in 5.3.3.4, s/inSection/in Section/ > 10) in 5.4.2.1, s/in Sections Section 5.3/in Section 5.3/ -- check > this > 11) I had a bit of difficulty parsing the sentence "Furthermore, for > each such encoding symbol it is assumed that the number and set of > intermediate symbols whose sum is equal to the encoding symbol is > passed to the decoder." If I parse it correcetly, should this be "the > number and set ... are passed"? Why are you assuming? Is this not > definitive? > 12) in 5.8, s/generated generated/generated/ > > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) > > _______________________________________________ > Rmt mailing list > Rmt@ietf.org > https://www.ietf.org/mailman/listinfo/rmt > From jani.peltotalo@tut.fi Wed Jan 26 23:00:50 2011 Return-Path: X-Original-To: rmt@core3.amsl.com Delivered-To: rmt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE6393A6B00 for ; Wed, 26 Jan 2011 23:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTBP5jVVy1va for ; Wed, 26 Jan 2011 23:00:48 -0800 (PST) Received: from mail.cs.tut.fi (mail.cs.tut.fi [130.230.4.42]) by core3.amsl.com (Postfix) with ESMTP id 497553A6937 for ; Wed, 26 Jan 2011 23:00:47 -0800 (PST) Received: from amavis2.cs.tut.fi (amavis2.cs.tut.fi [130.230.4.70]) by mail.cs.tut.fi (Postfix) with ESMTP id D360D5BC; Thu, 27 Jan 2011 09:03:48 +0200 (EET) Received: from mail.cs.tut.fi ([130.230.4.42]) by amavis2.cs.tut.fi (amavis2.cs.tut.fi [130.230.4.70]) (amavisd-maia, port 10024) with ESMTP id 12481-15; Thu, 27 Jan 2011 09:03:47 +0200 (EET) Received: from [130.230.52.207] (icepc023.atm.tut.fi [130.230.52.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id C203C5BB; Thu, 27 Jan 2011 09:03:47 +0200 (EET) Message-ID: <4D4118C2.3090805@tut.fi> Date: Thu, 27 Jan 2011 09:03:30 +0200 From: Jani Peltotalo User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Luby, Michael" References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.2 Cc: "Gillies, Don" , "rmt@ietf.org" Subject: Re: [Rmt] FLUTE revision X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 07:00:51 -0000 Hi Mike, You are right if there are no late-joiners and/or the first FDT Instance is not lost. In the revised-11 draft there is indeed better wording: "It is RECOMMENDED that an FDT Instance that contains the file description entry for a file is sent prior to the sending of the described file within a file delivery session. This recommendation is intended to minimize the amount of file data which may be received by receivers in advance of the FDT Instance containing the entry for a file (such data must either be speculatively buffered or discarded). Note that this possibility cannot be completely eliminated since the first transmission of FDT data may be lost." However, receiver will buffer at most that data which will be sent between two FDT Instances and FDT Instance interval is of course an implementation level issue. On the other hand, if the version number is in every packet, FLUTE version 1 receiver will not buffer FLUTE version 2 packets at all. BR, Jani > Hi Jani, > > I guess you are thinking that the FLUTE version 1 receivers might buffer > data for files and then when they get the FDT that is for the new FLUTE spec > the receivers realize that they don't support FLUTE version 2 and have to > discard all of this data because they don't know what to do with it? If > that is the concern, there is advice in the FLUTE specification that > recommends that the FDT instances should be sent before the actual data for > the file, and that FDTs should be sent with higher reliability than the file > data. There is stronger and clearer wording on this in the current FLUTE > draft than in RFC 3926, but there is wording on this in the RFC 3926 as > well, e.g.,"It is RECOMMENDED that FDT Instance that contains the file > description entry for a file is sent prior to the sending of the described > file within a file delivery session." > > Maybe I got this wrong? > Best, Mike > > > On 1/26/11 1:20 AM, "Jani. Fi" wrote: > >> Hi Mike&all, >> >> Yes, this is one possibility to signal the FLUTE version for whole FLUTE >> session. It still have negative influence on FLUTE version 1 receivers, >> which might buffer quite a lot unnecessary data, if the FDT Instance is >> not received early enough. >> >> BR, >> Jani >>> Actually, looking at the FLUTE doc, it seems that the only place where the >>> FLUTE version number is carried is in the FDT Instance header EXT_FDT, which >>> is an ALC PI specific LCT header extension, i.e., in EXT_FDT there is a >>> FLUTE version number that MUST be set to 2. If this is correct, then it >>> seems fine that the version number carried in the LCT header is the ALC >>> version number, which is 1. Comments on this? >>> >>> >>> On 1/26/11 12:33 AM, "Luby, Michael" wrote: >>> >>>> Thanks Jani for bringing this to our attention. We will take a look at this. >>>> The easiest solution off the top of my head is to specify in the FLUTE draft >>>> that the LCT version number in the LCT header MUST be interpreted as the >>>> FLUTE version number field (just like what ALC does when it uses LCT). >>>> However, we'll look at it more closely. >>>> Best, Mike >>>> >>>> >>>> On 1/25/11 11:02 PM, "Jani. Fi" wrote: >>>> >>>>> Hi Mike, >>>>> >>>>> Of course we can/must specify in the text as you mention below. However >>>>> in the packet only place to signal the version number is LCT version >>>>> number (V) field: >>>>> >>>>> LCT version number (V): 4 bits >>>>> >>>>> Indicates the LCT version number. The LCT version number for this >>>>> specification is 1. >>>>> >>>>> In RFC 5775 it is then mentioned: >>>>> >>>>> "The version number of ALC specified in this document is 1. The version >>>>> number field of the LCT header MUST be interpreted as the ALC version >>>>> number field. This version of ALC implicitly makes use of version 1 of >>>>> the LCT building block defined in [RFC 5651]." >>>>> >>>>> This kind of text is missing from the experimental FLUTE RFC and from >>>>> the revised FLUTE, but if we want to overload this field with FLUTE >>>>> version number (as we have done in our implementation based in >>>>> experimental RFC) to enable receivers to distinguish FLUTE versions 1 >>>>> and 2, the packet is not anymore align with the ALC and LCT RFCs. >>>>> >>>>> It is also possible to leave this field for ALC/LCT version numbers and >>>>> use for example reserved bits or LCT header extension to signal FLUTE >>>>> version. All in all, in my opinion it is necessary to signal FLUTE >>>>> version 2 somewhere in the FLUTE packet to be backwards compatible with >>>>> the receivers based on the experimental FLUTE RFC. >>>>> >>>>> BR, >>>>> Jani >>>>> >>>>>> Hi Jani, >>>>>> I'm missing where the version of FLUTE must be the same as the version of >>>>>> ALC and LCT. It seems that if we define this specification to be FLUTE >>>>>> version 2, and this FLUTE specification explicitly says that it must be >>>>>> used >>>>>> with ALC version 1 as specified in RFC 5775 and that it must be used with >>>>>> LCT version 1 as specified in RFC 5651 then there is no ambiguity, but >>>>>> maybe >>>>>> I'm missing something? I think what you are saying is that there is an >>>>>> overloaded field that carries both the FLUTE version and the ALC version >>>>>> and >>>>>> the LCT version? If so, can you point to that? >>>>>> Mike >>>>>> >>>>>> >>>>>> On 1/25/11 12:51 AM, "Jani. Fi" wrote: >>>>>> >>>>>>> Dear RMTers, >>>>>>> >>>>>>> One side effect of the version number change is problem with ALC and LCT >>>>>>> versions. Version number is signalled in the LCT header field and in >>>>>>> RFCs 5775 and 5651 (FLUTE revised will be working on top of these RFCs) >>>>>>> version number is specified to be 1. >>>>>>> >>>>>>> So it is not possible to signal FLUTE version 2 and ALC/LCT version 1 in >>>>>>> the same header field. >>>>>>> >>>>>>> BR, >>>>>>> Jani >>>>>>> >>>>>>>> Dear RMTers, We are in the process of revising FLUTE ­11, to produce >>>>>>>> FLUTE ­12, and it is clear at this point that the FLUTE version number >>>>>>>> will transition from 1 to 2. One question that has arisen: Can an FDT >>>>>>>> instance have a TOI > 0 with an EXT_FDT LCT extension header containing >>>>>>>> the FDT Instance ID? I think it is and should be restricted to TOI = 0 >>>>>>>> for carrying FDT instances, but there is some ambiguities in the text >>>>>>>> here and there that might be construed to suggest otherwise. >>>>>>>> Mike >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Rmt mailing list >>>>>>>> Rmt@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/rmt >>> >