From brian.adamson@nrl.navy.mil Thu Aug 4 08:31:13 2011 Return-Path: X-Original-To: rmt@ietfa.amsl.com Delivered-To: rmt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B8421F8880; Thu, 4 Aug 2011 08:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndfBYnbRf-+D; Thu, 4 Aug 2011 08:31:13 -0700 (PDT) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietfa.amsl.com (Postfix) with ESMTP id D7AF621F87FA; Thu, 4 Aug 2011 08:31:12 -0700 (PDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id p74FVLY9013653; Thu, 4 Aug 2011 11:31:23 -0400 Received: from macsimus.itd.nrl.navy.mil ([132.250.92.151]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011080411312312281 ; Thu, 04 Aug 2011 11:31:23 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: brian.adamson@nrl.navy.mil In-Reply-To: <4D5BD754.9060507@tut.fi> Date: Thu, 4 Aug 2011 11:30:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D5BD754.9060507@tut.fi> To: rmt@ietf.org, mmusic@ietf.org X-Mailer: Apple Mail (2.1084) Cc: Magnus Westerlund , Rod Walsh , Jani Peltotalo Subject: Re: [Rmt] FLUTE SDP specification X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 15:31:13 -0000 At the last working group meeting in Quebec, I raised the question = regarding the readiness of the FLUTE SDP draft for last call. However, = upon reviewing the RMT Mailing list archive, I found this note from Jani = & Rod which mentions a couple of dangling issues that would be addressed = in an -01 draft. I think the authors were looking for comments from the Working Group on = the -00 draft? At Magnus' suggestion, I have cc'd the MMUSIC mailing list to get their = involvement on this. For their benefit, the history here is that it has = taken some time (years) to finalize the revised FLUTE Proposed Standard = specification and this SDP document was in limbo until that work was = completed. The authors refreshed / renamed the document earlier in the = year and we have reached consensus on the FLUTE specification and it is = ready to move forward so this document (FLUTE SDP) can be finally = finalized as well. best regards, Brian Adamson brian.adamson@nrl.navy.mil On Feb 16, 2011, at 8:55 AM, Jani Peltotalo wrote: > Dear RMTers, >=20 > I just submitted a new version of the FLUTE SDP specification. > Currently, it is available here: >=20 > http://www.ietf.org/staging/draft-ietf-rmt-flute-sdp-00.txt >=20 > We changed the document title to "draft-ietf-rmt-flute-sdp" to reflect > the status as an official working group draft. We have still few open > issues, relating to CC & SEC, but those will be covered in the 01 > version which will then be ready (in our opinion) for WGLC. >=20 > Since there has not been much input from the working group we are > planning to cover CC & SEC mostly as informative annexes. CC will be > based on WEBRC and today we spotted RFCs 4567 and 4568 which might be > usable for SEC. >=20 > Cheers, Jani & Rod > _______________________________________________ > Rmt mailing list > Rmt@ietf.org > https://www.ietf.org/mailman/listinfo/rmt >=20 From wwwrun@rfc-editor.org Fri Aug 12 16:56:39 2011 Return-Path: X-Original-To: rmt@ietfa.amsl.com Delivered-To: rmt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4470A21F8AED; Fri, 12 Aug 2011 16:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.254 X-Spam-Level: X-Spam-Status: No, score=-102.254 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlK7n8TAmBJ7; Fri, 12 Aug 2011 16:56:38 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id CE20221F8AEC; Fri, 12 Aug 2011 16:56:38 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 749B198C233; Fri, 12 Aug 2011 16:57:17 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110812235717.749B198C233@rfc-editor.org> Date: Fri, 12 Aug 2011 16:57:17 -0700 (PDT) Cc: rmt@ietf.org, rfc-editor@rfc-editor.org Subject: [Rmt] RFC 6330 on RaptorQ Forward Error Correction Scheme for Object Delivery X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 23:56:39 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6330 Title: RaptorQ Forward Error Correction Scheme for Object Delivery Author: M. Luby, A. Shokrollahi, M. Watson, T. Stockhammer, L. Minder Status: Standards Track Stream: IETF Date: August 2011 Mailbox: luby@qualcomm.com, amin.shokrollahi@epfl.ch, watsonm@netflix.com, stockhammer@nomor.de, lminder@qualcomm.com Pages: 69 Characters: 169852 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-rmt-bb-fec-raptorq-06.txt URL: http://www.rfc-editor.org/rfc/rfc6330.txt This document describes a Fully-Specified Forward Error Correction (FEC) scheme, corresponding to FEC Encoding ID 6, for the RaptorQ FEC code and its application to reliable delivery of data objects. RaptorQ codes are a new family of codes that provide superior flexibility, support for larger source block sizes, and better coding efficiency than Raptor codes in RFC 5053. RaptorQ is also a fountain code, i.e., as many encoding symbols as needed can be generated on the fly by the encoder from the source symbols of a source block of data. The decoder is able to recover the source block from almost any set of encoding symbols of sufficient cardinality -- in most cases, a set of cardinality equal to the number of source symbols is sufficient; in rare cases, a set of cardinality slightly more than the number of source symbols is required. The RaptorQ code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated. [STANDARDS-TRACK] This document is a product of the Reliable Multicast Transport Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC