From iesg-secretary@ietf.org Fri Jun 3 08:24:38 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 14B5AE070F; Fri, 3 Jun 2011 08:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 1w8b-Ub02oLm; Fri, 3 Jun 2011 08:24:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C39CE06E9; Fri, 3 Jun 2011 08:24:37 -0700 (PDT) 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.55 Message-ID: <20110603152437.32759.93640.idtracker@ietfa.amsl.com> Date: Fri, 03 Jun 2011 08:24:37 -0700 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.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 15:24:38 -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-06-17. 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. This is a second IETF Last Call. At IESG request, an updated IPR disclosure related to this document was filed by Qualcomm Incorporated to clarify the licensing terms vis-a-vis different applications of the technology. See the following link: https://datatracker.ietf.org/ipr/1553/ Because of this updated IPR disclosure, an additional RMT Working Group Last Call was conducted. The only resultant working group email discussion to the revised IPR was that it was an improvement in that it more clearly covered unicast as well as multicast use cases of the technology. The following URL points to the mailing list archive message thread regarding this additional WGLC: http://www.ietf.org/mail-archive/web/rmt/current/msg01547.html Although IPR is in place, this forward error correction technique is just one of several types that the RMT WG has specified and other, unencumbered techniques have been defined. Thus, the RMT WG had previously discussed this matter concluding that it wished to publish this document regardless of the IPR since this new FEC code is one of multiple alternatives that can be used to implement the RMT higher-level protocols, as such the possible IPR covering this does not preclude the unencumbered implementation of the RMT Protocols. The IPR licensing terms presented by Qualcomm appear to be reasonable. 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/ From luby@qualcomm.com Mon Jun 6 17:17:45 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 C891521F85FD for ; Mon, 6 Jun 2011 17:17:45 -0700 (PDT) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 bEUI8zcLZC50 for ; Mon, 6 Jun 2011 17:17:45 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 173A721F85FC for ; Mon, 6 Jun 2011 17:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1307405865; x=1338941865; h=from:to:subject:thread-topic:thread-index:date: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: x-originating-ip:content-type:content-id: content-transfer-encoding:mime-version; z=From:=20"Luby,=20Michael"=20|To:=20Ro d=20Walsh=20,=20"rmt@ietf.org"=20|Subject:=20Re:=20[Rmt]=20FLUTE=20v2 |Thread-Topic:=20[Rmt]=20FLUTE=20v2|Thread-Index:=20Acwkq L68YH7Yh+oZI0S7Eo6bULQXVQ=3D=3D|Date:=20Tue,=207=20Jun=20 2011=2000:17:42=20+0000|Message-ID:=20|In-Reply-To:=20<484630C0-8527-4A25-970A-A5 1739BCCCC3@nokia.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|user-agent:=20Microsoft-Entourage/ 13.9.0.110114|x-originating-ip:=20[10.45.230.6] |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-ID:=20|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=7rqGCxyyi3hbn6+Z31cENRHBLxO9lAnNRpmEoVqnh7g=; b=lXUiRzeojc/M4BxnFzLxkxQpsa3TSf5+fvJT5v8/VqDCgg9U7BtYz/sR toUNuraBy1FH3RZrsDulsmat9Ozx7dmTBA6WJUxysmE7yjccv6phcjgcU vwj2RewMll32yox0PkkEowwZQC3mZBf0W6dggMHUc+Qt4dEXi+xUllUbC c=; X-IronPort-AV: E=McAfee;i="5400,1158,6369"; a="95815965" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine02.qualcomm.com with ESMTP; 06 Jun 2011 17:17:44 -0700 X-IronPort-AV: E=Sophos;i="4.65,326,1304319600"; d="scan'208";a="111397661" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 06 Jun 2011 17:17:44 -0700 Received: from NASANEXHC12.na.qualcomm.com (172.30.39.187) by nasanexhc07.na.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 6 Jun 2011 17:17:44 -0700 Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc12.na.qualcomm.com ([172.30.39.187]) with mapi id 14.01.0270.001; Mon, 6 Jun 2011 17:17:44 -0700 From: "Luby, Michael" To: Rod Walsh , "rmt@ietf.org" Thread-Topic: [Rmt] FLUTE v2 Thread-Index: AcwkqL68YH7Yh+oZI0S7Eo6bULQXVQ== Date: Tue, 7 Jun 2011 00:17:42 +0000 Message-ID: In-Reply-To: <484630C0-8527-4A25-970A-A51739BCCCC3@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.9.0.110114 x-originating-ip: [10.45.230.6] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Rmt] FLUTE v2 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: Tue, 07 Jun 2011 00:17:46 -0000 Hi Rod, Does your email below mean that you agree to change the revised FLUTE to version number to 2 at this point? If so, then I think this would help to move the revised FLUTE on to the next step in the IETF process, since the current draft of the revised FLUTE already has the FLUTE version number set to 2, and thus no changes to the draft would be needed to move the revised FLUTE to the next step, and as far as I know everyone else who has commente= d is on board with making the revised FLUTE be FLUTE version 2 as the practical path out of the possibilities. If you meant something else, I apologize for misinterpreting your email. Best, Mike On 5/9/11 4:39 AM, "Rod Walsh" wrote: > Hi all >=20 > It's pretty clear that as a group and individuals we are short of the ene= rgy > and determination to tie-up every loose thread of the RMT adventure. For = me, > the one and only issue preventing FLUTE staying at the sensible and consi= stent > v1 status was highlight by Mike... >=20 > http://www.ietf.org/mail-archive/web/rmt/current/msg01513.html >=20 > ...running through all the specs and the multitude of related SDO adoptio= ns > takes a lot of footwork and singular dedication. I'm am not in such a pos= ition > to do that nowadays. Even running through the maze of security IDs and RF= Cs to > get FLUTE-SDP finished has taken months to get done on-the-side. >=20 > So unless we have an energetic and enthusiastic spec miner who is willing= to > take on the task Mike pointed out, then I propose we push forward to a v1= .1. >=20 > (just kidding, we should all the way to 1.9 :) >=20 > And thus, with Jani's energy and hard work, I can focus on the finished > flute-SDP (coming any day now). >=20 > Cheers, Rod. From Rod.Walsh@nokia.com Mon Jun 6 23:45:38 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 B3FF411E8081 for ; Mon, 6 Jun 2011 23:45:38 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epQzh4BVim4L for ; Mon, 6 Jun 2011 23:45:37 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 1D93B11E807B for ; Mon, 6 Jun 2011 23:45:35 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p576jR4T009363; Tue, 7 Jun 2011 09:45:34 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Jun 2011 09:45:28 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 7 Jun 2011 08:45:27 +0200 From: To: , Date: Tue, 7 Jun 2011 08:45:25 +0200 Thread-Topic: [Rmt] FLUTE v2 Thread-Index: Acwk3nuq2L7YXho0SdmvifrnPd1ATw== Message-ID: <4DEDC905.6090607@nokia.com> References: In-Reply-To: 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_4DEDC9056090607nokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jun 2011 06:45:28.0153 (UTC) FILETIME=[7CC50C90:01CC24DE] X-Nokia-AV: Clean Subject: Re: [Rmt] FLUTE v2 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: Tue, 07 Jun 2011 06:45:38 -0000 --_000_4DEDC9056090607nokiacom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mike et al. Yes v2. Sensible proposal, let's do that. Now would be a good time to catalogue all (if any) remaining questions RMTe= rs feel are still open, with a view to a June/July WGLC. There are a few open questions (on the RMT list) still hanging, but my own = understanding is that even the changes I do not understand the reasoning fo= r don't actually harm any implementation. So personally, I will not be resu= rrecting any prior threads. Likewise, those active in other SDOs that may be impacted by a standards tr= ack FLUTE would do us all a great favour by drawing attention to the immine= nt WGLC also in the WGs of those SDO and so offer a little extra time (just= before the vacation season) for cross-SDO contentment and harmony. Please = post to the RMT mail list activity on this as it occurs so that we don't in= advertently send redundant messages (and so that we can assume that an SDO = is not yet in the loop where no RMT list email mentions it). Cheers, Rod. On 07/06/2011 03:17, ext Luby, Michael wrote: Hi Rod, Does your email below mean that you agree to change the revised FLUTE to version number to 2 at this point? If so, then I think this would help to move the revised FLUTE on to the next step in the IETF process, since the current draft of the revised FLUTE already has the FLUTE version number set to 2, and thus no changes to the draft would be needed to move the revised FLUTE to the next step, and as far as I know everyone else who has commente= d is on board with making the revised FLUTE be FLUTE version 2 as the practical path out of the possibilities. If you meant something else, I apologize for misinterpreting your email. Best, Mike On 5/9/11 4:39 AM, "Rod Walsh" wrote: > Hi all > > It's pretty clear that as a group and individuals we are short of the ene= rgy > and determination to tie-up every loose thread of the RMT adventure. For = me, > the one and only issue preventing FLUTE staying at the sensible and consi= stent > v1 status was highlight by Mike... > > http://www.ietf.org/mail-archive/web/rmt/current/msg01513.html > > ...running through all the specs and the multitude of related SDO adoptio= ns > takes a lot of footwork and singular dedication. I'm am not in such a pos= ition > to do that nowadays. Even running through the maze of security IDs and RF= Cs to > get FLUTE-SDP finished has taken months to get done on-the-side. > > So unless we have an energetic and enthusiastic spec miner who is willing= to > take on the task Mike pointed out, then I propose we push forward to a v1= .1. > > (just kidding, we should all the way to 1.9 :) > > And thus, with Jani's energy and hard work, I can focus on the finished > flute-SDP (coming any day now). > > Cheers, Rod. _______________________________________________ Rmt mailing list Rmt@ietf.org https://www.ietf.org/mailman/listinfo/rmt --_000_4DEDC9056090607nokiacom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hi Mike et al.

Yes v2. Sensible proposal, let's do that.

Now would be a good time to catalogue all (if any) remaining questions RMTers feel are still open, with a view to a June/July WGLC.

There are a few open questions (on the RMT list) still hanging, but my own understanding is that even the changes I do not understand the reasoning for don't actually harm any implementation. So personally, I will not be resurrecting any prior threads.

Likewise, those active in other SDOs that may be impacted by a standards track FLUTE would do us all a great favour by drawing attention to the imminent WGLC also in the WGs of those SDO and so offer a little extra time (just before the vacation season) for cross-SDO contentment and harmony. Please post to the RMT mail list activity on this as it occurs so that we don't inadvertently send redundant messages (and so that we can assume that an SDO is not yet in the loop where no RMT list email mentions it).

Cheers, Rod.



On 07/06/2011 03:17, ext Luby, Michael wrote:
Re: [Rmt] FLUTE v2

Hi Rod,
Does your email below mean that you agree to change the revised FLUTE to
version number to 2 at this point?  If so, then I think this would help to
move the revised FLUTE on to the next step in the IETF process, since the
current draft of the revised FLUTE already has the FLUTE version number set
to 2, and thus no changes to the draft would be needed to move the revised
FLUTE to the next step, and as far as I know everyone else who has commented
is on board with making the revised FLUTE be FLUTE version 2 as the
practical path out of the possibilities.  If you meant something else, I
apologize for misinterpreting your email.
Best, Mike


On 5/9/11 4:39 AM, "Rod Walsh" <rod.walsh@nokia.com> wrote:

> Hi all
>
> It's pretty clear that as a group and individuals we are short of the energy
> and determination to tie-up every loose thread of the RMT adventure. For me,
> the one and only issue preventing FLUTE staying at the sensible and consistent
> v1 status was highlight by Mike...
>
> http://www.ietf.org/mail-archive/web/rmt/current/msg01513.html=
>
> ...running through all the specs and the multitude of related SDO adoptions
> takes a lot of footwork and singular dedication. I'm am not in such a position
> to do that nowadays. Even running through the maze of security IDs and RFCs to
> get FLUTE-SDP finished has taken months to get done on-the-side.
>
> So unless we have an energetic and enthusiastic spec miner who is willing to
> take on the task Mike pointed out, then I propose we push forward to a v1.1.
>
> (just kidding, we should all the way to 1.9 :)
>
> And thus, with Jani's energy and hard work, I can focus on the finished
> flute-SDP (coming any day now).
>
> Cheers, Rod.

_______________________________________________
Rmt mailing list
Rmt@ietf.org
https://www.= ietf.org/mailman/listinfo/rmt

= --_000_4DEDC9056090607nokiacom_-- From iesg-secretary@ietf.org Mon Jun 20 14:23:07 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 31CE311E81FE; Mon, 20 Jun 2011 14:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 aL9bcUzT2QMU; Mon, 20 Jun 2011 14:23:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDD411E8203; Mon, 20 Jun 2011 14:23:06 -0700 (PDT) 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.55 Message-ID: <20110620212306.26465.15948.idtracker@ietfa.amsl.com> Date: Mon, 20 Jun 2011 14:23:06 -0700 Cc: rmt chair , rmt mailing list , RFC Editor Subject: [Rmt] Protocol Action: 'RaptorQ Forward Error Correction Scheme for Object Delivery' to Proposed Standard (draft-ietf-rmt-bb-fec-raptorq-06.txt) 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: Mon, 20 Jun 2011 21:23:07 -0000 The IESG has approved the following document: - 'RaptorQ Forward Error Correction Scheme for Object Delivery' (draft-ietf-rmt-bb-fec-raptorq-06.txt) as a Proposed Standard This document is the product of the Reliable Multicast Transport Working Group. The IESG contact persons are David Harrington and Wesley Eddy. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-rmt-bb-fec-raptorq/ Technical Summary This document is an optional Building Block usable to fully define an RMT Transport Protocol. It fully-specifies a Forward Error Correction Code, called "RaptorQ", within the guidelines of RFC 5052. It also specifies procedures and packet-header fields, as required by RFC 5052. The combination of this document and RFC 5052 allows the implementation of an interoperable Forward Error Correction scheme usable in the context of an RMT transport protocol (e.g. LCT/ALC or NORM). RaptorQ is a fountain code, i.e., as many encoding symbols as needed can be generated by the encoder on-the-fly from the source symbols of a source block of data. The decoder is able to recover the source block from any set of encoding symbols only generally equal to or occasionally with slightly more in number than the number of source symbols. The RaptorQ code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated Working Group Summary There is consensus in the WG to publish these documents. As a result of the IESG questions and discussions, a further revised IPR statement was filed by Qualcomm Incorporated. See the following link: https://datatracker.ietf.org/ipr/1553/ Because of this updated IPR disclosure, an additional RMT Working Group Last Call was conducted. The only resultant working group email discussion to the revised IPR was that it was an improvement in that it more clearly covered unicast as well as multicast use cases of the technology. The following URL points to the mailing list archive message thread regarding this additional WGLC: http://www.ietf.org/mail-archive/web/rmt/current/msg01547.html It is important to note, as had been described in the earlier publication writeup for this specification that, although IPR is in place, this forward error correction technique is just one of several types that the RMT WG has specified and other, unencumbered techniques have been defined. Thus, the RMT WG had previously discussed this matter concluding that it wished to publish this document regardless of the IPR since this new FEC code is one of multiple alternatives that can be used to implement the RMT higher-level protocols, as such the possible IPR covering this does not preclude the unencumbered implementation of the RMT Protocols. The IPR licensing terms presented by Qualcomm appear to be reasonable. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? The document is similar in content to the prior "Raptor" codec of RFC 5053 and benefits from the development and reviews of that specification. Additionally, an independent implementation was conducted from the version 03 draft and only minor suggestions were made (and were incorporated) by that developer to clarify the document. Personnel Document Shepherd: Brian Adamson (adamson@itd.nrl.navy.mil) Responsible Area Director: David Harrington From ietfdbh@comcast.net Mon Jun 20 20:28:37 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 BC80911E80DF for ; Mon, 20 Jun 2011 20:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 AGEAilJtcXLs for ; Mon, 20 Jun 2011 20:28:37 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9245811E80DB for ; Mon, 20 Jun 2011 20:28:35 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta03.westchester.pa.mail.comcast.net with comcast id yTF81g0031c6gX853TUc9E; Tue, 21 Jun 2011 03:28:36 +0000 Received: from davidPC ([67.189.235.106]) by omta23.westchester.pa.mail.comcast.net with comcast id yTUa1g00m2JQnJT3jTUbtC; Tue, 21 Jun 2011 03:28:35 +0000 From: "David Harrington" To: Date: Mon, 20 Jun 2011 23:28:29 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16807 Thread-Index: Acwvs06GWf9pozxISS+bYvZ0eWCHCQAD+9Hw Subject: [Rmt] FW: [RFC State] has been added to RFC Editor database 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: Tue, 21 Jun 2011 03:28:37 -0000 Congratulations. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) -----Original Message----- From: rfc-editor@rfc-editor.org [mailto:rfc-editor@rfc-editor.org] Sent: Monday, June 20, 2011 9:34 PM To: luby@qualcomm.com; amin.shokrollahi@epfl.ch; watsonm@netflix.com; stockhammer@nomor.de; lminder@qualcomm.com Cc: rmt-ads@tools.ietf.org; rmt-chairs@tools.ietf.org; rfc-editor@rfc-editor.org Subject: [RFC State] has been added to RFC Editor database Author(s), We have received notice that your document draft-ietf-rmt-bb-fec-raptorq-06 has been approved for publication as an RFC. The document has been added to the RFC-Editor queue and you can check the status at ** Note: Please see our News page ** (http://www.rfc-editor.org/news.html) for information regarding the ** transition to the RFC 5378 copyright notice and legends as it ** relates to your document in the RFC Editor queue. If you submitted your XML file using the I-D submission tool, we have already retrieved it. If you did not submit the XML file via the I-D submission tool, or if you have an updated version (e.g., updated contact information), please send us the XML file at this time. Please attach the file as draft-ietf-rmt-bb-fec-raptorq-06.xml, and specify any differences between the approved I-D and the document that the XML produces. If you created this document using -ms nroff, please send us the source file. This should help increase the pace with which documents move through the RFC-Editor queue. Please let us know if you have any questions. Thank you. The RFC-Editor Team