From internet-drafts@ietf.org Mon Oct 10 10:34:52 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF8C21F8C73; Mon, 10 Oct 2011 10:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 XMGc4xW+FoF1; Mon, 10 Oct 2011 10:34:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356DC21F8C6B; Mon, 10 Oct 2011 10:34:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111010173452.14466.11742.idtracker@ietfa.amsl.com> Date: Mon, 10 Oct 2011 10:34:52 -0700 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action: draft-ietf-fecframe-rtp-raptor-05.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 17:34:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the FEC Framework Working Group of the IE= TF. Title : RTP Payload Format for Raptor FEC Author(s) : Mark Watson Thomas Stockhammer Filename : draft-ietf-fecframe-rtp-raptor-05.txt Pages : 22 Date : 2011-10-10 This document specifies an RTP Payload Format for Forward Error Correction repair data produced by the Raptor FEC Schemes. Raptor FEC Schemes are specified for use with the IETF FEC Framework which supports transport of repair data over both UDP and RTP. This document specifies the Payload Format which is required for the use of RTP to carry Raptor repair flows. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-raptor-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-raptor-05.txt From stockhammer@NOMOR.DE Mon Oct 10 10:39:35 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F6A21F8C70 for ; Mon, 10 Oct 2011 10:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 zE6GVq-zWCbZ for ; Mon, 10 Oct 2011 10:39:34 -0700 (PDT) Received: from mo-p00-ob6.rzone.de (mo-p00-ob6.rzone.de [IPv6:2a01:238:20a:202:53f0::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A04821F8C6E for ; Mon, 10 Oct 2011 10:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1318268371; l=4243; s=domk; d=nomor.de; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Content-Type:Mime-Version:Subject:X-RZG-CLASS-ID:X-RZG-AUTH; bh=2r37+Of34L9HZJyU7nqscBf1G6E=; b=bzrkYUU078JEASD5VUqCTsKuTUAJFTxF7+p6nZmtzhWgqHSBbwsvDPyiurvMSmyW5yt gSuyM8BIIvV/Dcenlh0BVOrBFHoVixozoMX9242TbUvb1oYYEht+zjj6Yjj6rIVRxyMy2 E0lLu6Fhfh2OR4BGJ5sk7T0ftd2VglzpjD8= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu1/8loZf+4JHTB1Efz/5cQ= X-RZG-CLASS-ID: mo00 Received: from [192.168.1.10] (188-192-154-28-dynip.superkabel.de [188.192.154.28]) by smtp.strato.de (cohen mo43) (RZmta 26.10 AUTH) with ESMTPA id Q04ea9n9AHIWGS ; Mon, 10 Oct 2011 19:39:26 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Thomas Stockhammer In-Reply-To: <13F059AA83B642759B6FFF44745AB29E@davidPC> Date: Mon, 10 Oct 2011 19:39:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <530C6093-7047-4D6A-86D2-0CCF6C5D00E1@NOMOR.DE> References: <13F059AA83B642759B6FFF44745AB29E@davidPC> To: David Harrington X-Mailer: Apple Mail (2.1244.3) Cc: draft-ietf-fecframe-rtp-raptor@tools.ietf.org, fecframe-chairs@tools.ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] AD Review: draft-ietf-fecframe-rtp-raptor X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 17:39:35 -0000 Dave, all thanks for the comments, please find inline responses. In addition to the comments, the references are separated in normative = and informative. I do think we can move the RTP payload also to WGLC, but thus may have = to happen in AVTCORE. Thanks Thomas > Can you get a revised ID asap? [T] A revised ID is prepared and has been uploaded here = http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-raptor-05.txt > AD Review of draft-ietf-fecframe-rtp-raptor-04: > It would be good to use RFC2119 keywords in active voice - "The = implementer SHOULD > select" (or is it the operator?) rather than "It is RECOMMENDED to = select". > For example, I recommend changing "The (integer) rate SHALL be larger = than 1000". > Whose responsibility is it to enforce this SHALL? MUST implementations > reject values less than 1000? (if implementations don't enforce this, = I don't know > how you'll enforce this SHALL. Which means a user MAY choose a lower = value; > therefore this isn't really a MUST. yada yada yada ... > So you should use active voice to be explicit about whose = responsibility it is to enforce this MUST. (and similar to RFC 3665, = MUST is for implementers; SHOULD is for users). [T] It is the responsibility of the operator to pick a value of 1000 at = least. This has been made clear in the revision. > in 5.1.1, rate definition.=20 > "rate: The RTP timestamp (clock) rate in Hz. The (integer) rate > SHALL be larger than 1000 to provide sufficient resolution to RTCP > operations. However, it is RECOMMENDED to select the rate that matches = the rate of > the protected source RTP stream." The However in this paragraph makes = it > sound like you recommend using the rate that matches (even if it is = below 1000). > I recommend removing the "However,"=20 [T] Done > in 5.1.1, s/shall/SHALL/ [T] Done > "Restrictions on usage: This media type depends on RTP framing, and = hence is only > defined for transfer via RTP [[RFC3550]]. Transport within other = framing protocols > is not defined at this time. " Do we need the "at this time"? Is it = envisioned this > media type will be exteneded for additional framing protocols at a = later time? [T] Yes, this may indeed happen. We have seen similar generalization for = other formats recently, such as the MPEG-2 TS. So it is considered = important to avoid any confusion and make it clear that the registration = is for RTP only. > in 12 s/recommended/RECOMMENDED/, s/may/MAY/g [T] Done > in 8, is Session Announcement Protocol (SAP) [RFC2947] the right = reference? I saw no mention of SAP in 2947. [T] This is indeed wrong, it needs to be RFC2974. Thanks! > in 15.2, rfc2947 seems to refer to the wrong document. I think you > need 2974. [T] See above > in 1, "Repair data flows may be sent directly over a transport = protocol > such as UDP, or they may be encapsulated within RTP." Is RTP the only > protocol that could be used to encapsulate flows? should this be "they = may be > encapsulated within specialized transports for multimedia, such as = RTP"? [T] Agreed! Despite nothing is defined today, it be in the future. I = have changed accordingly. > s/FECs operates/FECs operate/ [T] Done > s/an FEC/a FEC/ [T] Done > Shepherd, Since AVT is the change controller, was this WGLC'd in AVT? [T] No this was not yet done. It would be good to send out the Raptor = schemes for WGLC. Once this is done, I will send out a message to the = AVT list reporting the status of the Raptor schemes and this payload = format and ask if WGLC'd in AVT can be issued. Is this appropriate? Thomas >=20 > Thanks, > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) >=20 --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. From abegen@cisco.com Mon Oct 10 10:43:38 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0A921F8C83 for ; Mon, 10 Oct 2011 10:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 f7KCPtYj4cPr for ; Mon, 10 Oct 2011 10:43:37 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 33AA021F8C81 for ; Mon, 10 Oct 2011 10:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=5226; q=dns/txt; s=iport; t=1318268617; x=1319478217; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Ah+9WAWcKlSAa1cmoH8LqVlk61ht9Uqb2WUz76mxxJg=; b=SQuKgbG3R0ndEtbUprP6P0w2amS1/UObiyfVq3qhd44OIgKSAa4fUJQY o0QWSUYCOqW6ctI7kl5UukANcEWKnmU2j0kfngE6k10SpjTLF16yY3GYH M/9RNoomKJaomzjH9hhdbHO6MTHTmmeSenAgcZQRAdBoJtnKV35VQPZo+ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIAAHwuk06rRDoI/2dsb2JhbABAA5hwjymBBYFTAQEBAQMBAQEPAR0+CwwCAgIBCBEEAQELBhcBBgEaDB8JCAEBBAEJCQgBGYdjmjIBnioChCyCNGEEh32GWgEBhhOEPYxA X-IronPort-AV: E=Sophos;i="4.68,518,1312156800"; d="scan'208";a="6992537" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 10 Oct 2011 17:43:36 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9AHhaIj007297; Mon, 10 Oct 2011 17:43:36 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Oct 2011 10:43:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Oct 2011 10:43:34 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5410097DFA@xmb-sjc-215.amer.cisco.com> In-Reply-To: <530C6093-7047-4D6A-86D2-0CCF6C5D00E1@NOMOR.DE> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] AD Review: draft-ietf-fecframe-rtp-raptor Thread-Index: AcyHc5WAs8eC6AUyTzqYkBTOcyl2wgAAHQVQ References: <13F059AA83B642759B6FFF44745AB29E@davidPC> <530C6093-7047-4D6A-86D2-0CCF6C5D00E1@NOMOR.DE> From: "Ali C. Begen (abegen)" To: "Thomas Stockhammer" , "David Harrington" X-OriginalArrivalTime: 10 Oct 2011 17:43:36.0642 (UTC) FILETIME=[23610A20:01CC8774] Cc: draft-ietf-fecframe-rtp-raptor@tools.ietf.org, fecframe-chairs@tools.ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] AD Review: draft-ietf-fecframe-rtp-raptor X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 17:43:38 -0000 Note that it is not avtcore who should review this draft but it is = payload wg. Also, the controller should be the Payload WG. -acbegen > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Thomas Stockhammer > Sent: Monday, October 10, 2011 1:39 PM > To: David Harrington > Cc: draft-ietf-fecframe-rtp-raptor@tools.ietf.org; = fecframe-chairs@tools.ietf.org; fecframe@ietf.org > Subject: Re: [Fecframe] AD Review: draft-ietf-fecframe-rtp-raptor >=20 > Dave, all >=20 > thanks for the comments, please find inline responses. > In addition to the comments, the references are separated in normative = and informative. >=20 > I do think we can move the RTP payload also to WGLC, but thus may have = to happen in AVTCORE. >=20 > Thanks >=20 > Thomas >=20 > > Can you get a revised ID asap? >=20 > [T] A revised ID is prepared and has been uploaded here = http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-raptor- > 05.txt >=20 > > AD Review of draft-ietf-fecframe-rtp-raptor-04: > > It would be good to use RFC2119 keywords in active voice - "The = implementer SHOULD > > select" (or is it the operator?) rather than "It is RECOMMENDED to = select". > > For example, I recommend changing "The (integer) rate SHALL be = larger than 1000". > > Whose responsibility is it to enforce this SHALL? MUST = implementations > > reject values less than 1000? (if implementations don't enforce = this, I don't know > > how you'll enforce this SHALL. Which means a user MAY choose a lower = value; > > therefore this isn't really a MUST. yada yada yada ... > > So you should use active voice to be explicit about whose = responsibility it is to enforce this MUST. (and similar to RFC 3665, > MUST is for implementers; SHOULD is for users). >=20 > [T] It is the responsibility of the operator to pick a value of 1000 = at least. This has been made clear in the revision. >=20 > > in 5.1.1, rate definition. > > "rate: The RTP timestamp (clock) rate in Hz. The (integer) rate > > SHALL be larger than 1000 to provide sufficient resolution to RTCP > > operations. However, it is RECOMMENDED to select the rate that = matches the rate of > > the protected source RTP stream." The However in this paragraph = makes it > > sound like you recommend using the rate that matches (even if it is = below 1000). > > I recommend removing the "However," >=20 > [T] Done >=20 > > in 5.1.1, s/shall/SHALL/ >=20 > [T] Done >=20 > > "Restrictions on usage: This media type depends on RTP framing, and = hence is only > > defined for transfer via RTP [[RFC3550]]. Transport within other = framing protocols > > is not defined at this time. " Do we need the "at this time"? Is it = envisioned this > > media type will be exteneded for additional framing protocols at a = later time? >=20 > [T] Yes, this may indeed happen. We have seen similar generalization = for other formats recently, such as the MPEG-2 TS. So > it is considered important to avoid any confusion and make it clear = that the registration is for RTP only. >=20 > > in 12 s/recommended/RECOMMENDED/, s/may/MAY/g >=20 > [T] Done >=20 > > in 8, is Session Announcement Protocol (SAP) [RFC2947] the right = reference? I saw no mention of SAP in 2947. >=20 > [T] This is indeed wrong, it needs to be RFC2974. Thanks! >=20 >=20 > > in 15.2, rfc2947 seems to refer to the wrong document. I think you > > need 2974. >=20 > [T] See above >=20 > > in 1, "Repair data flows may be sent directly over a transport = protocol > > such as UDP, or they may be encapsulated within RTP." Is RTP the = only > > protocol that could be used to encapsulate flows? should this be = "they may be > > encapsulated within specialized transports for multimedia, such as = RTP"? >=20 > [T] Agreed! Despite nothing is defined today, it be in the future. I = have changed accordingly. >=20 > > s/FECs operates/FECs operate/ >=20 > [T] Done >=20 > > s/an FEC/a FEC/ >=20 > [T] Done >=20 > > Shepherd, Since AVT is the change controller, was this WGLC'd in = AVT? >=20 > [T] No this was not yet done. It would be good to send out the Raptor = schemes for WGLC. Once this is done, I will send out a > message to the AVT list reporting the status of the Raptor schemes and = this payload format and ask if WGLC'd in AVT can be > issued. Is this appropriate? >=20 > Thomas >=20 > > > > Thanks, > > David Harrington > > Director, IETF Transport Area > > ietfdbh@comcast.net (preferred for ietf) > > dbharrington@huaweisymantec.com > > +1 603 828 1401 (cell) > > >=20 > --- > Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || > http://www.nomor-research.com > Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: > DE238047637 - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo = Viering. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From gjshep@gmail.com Mon Oct 10 10:54:25 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416B921F8C3D for ; Mon, 10 Oct 2011 10:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 Z0J4WxTgNjIe for ; Mon, 10 Oct 2011 10:54:24 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D43BC21F8B25 for ; Mon, 10 Oct 2011 10:54:23 -0700 (PDT) Received: by bkaq10 with SMTP id q10so9683439bka.31 for ; Mon, 10 Oct 2011 10:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=6Pk0Bh59O3eapgqF/08XVUmn6b3CEBsrdPaopwSR6pU=; b=KNOSJXAaYwPjriDm7c8YURuby83nRf9d53uf7vjv6ATTDN105qAxoiHfcfJNAJmXsS qkvAX0FJjGJMJ5icnHRVsBO5uYNpCm92I/6ZPDzbvAhpw8eNEppTIJ8I9Mh9rzRwqZdb 9tV6e1Ru9U8uDvLVCBn5FLEsr5u9QZCA73Aec= MIME-Version: 1.0 Received: by 10.204.140.201 with SMTP id j9mr7190373bku.13.1318269262845; Mon, 10 Oct 2011 10:54:22 -0700 (PDT) Received: by 10.204.56.148 with HTTP; Mon, 10 Oct 2011 10:54:22 -0700 (PDT) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5410097DFA@xmb-sjc-215.amer.cisco.com> References: <13F059AA83B642759B6FFF44745AB29E@davidPC> <530C6093-7047-4D6A-86D2-0CCF6C5D00E1@NOMOR.DE> <04CAD96D4C5A3D48B1919248A8FE0D5410097DFA@xmb-sjc-215.amer.cisco.com> Date: Mon, 10 Oct 2011 10:54:22 -0700 Message-ID: From: Greg Shepherd To: "Ali C. Begen (abegen)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-fecframe-rtp-raptor@tools.ietf.org, fecframe-chairs@tools.ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] AD Review: draft-ietf-fecframe-rtp-raptor X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 17:54:25 -0000 Ali, It's still a FF doc and needs to LC here, but are you saying Payload WG also needs LC rather than just review? Greg On Mon, Oct 10, 2011 at 10:43 AM, Ali C. Begen (abegen) wrote: > Note that it is not avtcore who should review this draft but it is payloa= d wg. Also, the controller should be the Payload WG. > > -acbegen > >> -----Original Message----- >> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Be= half Of Thomas Stockhammer >> Sent: Monday, October 10, 2011 1:39 PM >> To: David Harrington >> Cc: draft-ietf-fecframe-rtp-raptor@tools.ietf.org; fecframe-chairs@tools= .ietf.org; fecframe@ietf.org >> Subject: Re: [Fecframe] AD Review: draft-ietf-fecframe-rtp-raptor >> >> Dave, all >> >> thanks for the comments, please find inline responses. >> In addition to the comments, the references are separated in normative a= nd informative. >> >> I do think we can move the RTP payload also to WGLC, but thus may have t= o happen in AVTCORE. >> >> Thanks >> >> Thomas >> >> > Can you get a revised ID asap? >> >> [T] A revised ID is prepared and has been uploaded here http://www.ietf.= org/internet-drafts/draft-ietf-fecframe-rtp-raptor- >> 05.txt >> >> > AD Review of draft-ietf-fecframe-rtp-raptor-04: >> > It would be good to use RFC2119 keywords in active voice - "The implem= enter SHOULD >> > select" (or is it the operator?) rather than "It is RECOMMENDED to sel= ect". >> > For example, I recommend changing "The (integer) rate SHALL be larger = than 1000". >> > Whose responsibility is it to enforce this SHALL? MUST implementations >> > reject values less than 1000? (if implementations don't enforce this, = I don't know >> > how you'll enforce this SHALL. Which means a user MAY choose a lower v= alue; >> > therefore this isn't really a MUST. yada yada yada ... >> > So you should use active voice to be explicit about whose responsibili= ty it is to enforce this MUST. (and similar to RFC 3665, >> MUST is for implementers; SHOULD is for users). >> >> [T] It is the responsibility of the operator to pick a value of 1000 at = least. This has been made clear in the revision. >> >> > in 5.1.1, rate definition. >> > "rate: The RTP timestamp (clock) rate in Hz. The (integer) rate >> > SHALL be larger than 1000 to provide sufficient resolution to RTCP >> > operations. However, it is RECOMMENDED to select the rate that matches= the rate of >> > the protected source RTP stream." The However in this paragraph makes = it >> > sound like you recommend using the rate that matches (even if it is be= low 1000). >> > I recommend removing the "However," >> >> [T] Done >> >> > in 5.1.1, s/shall/SHALL/ >> >> [T] Done >> >> > "Restrictions on usage: This media type depends on RTP framing, and he= nce is only >> > defined for transfer via RTP [[RFC3550]]. Transport within other frami= ng protocols >> > is not defined at this time. " Do we need the "at this time"? Is it en= visioned this >> > media type will be exteneded for additional framing protocols at a lat= er time? >> >> [T] Yes, this may indeed happen. We have seen similar generalization for= other formats recently, such as the MPEG-2 TS. So >> it is considered =A0important to avoid any confusion and make it clear t= hat the registration is for RTP only. >> >> > in 12 s/recommended/RECOMMENDED/, s/may/MAY/g >> >> [T] Done >> >> > in 8, is Session Announcement Protocol (SAP) [RFC2947] the right refer= ence? I saw no mention of SAP in 2947. >> >> [T] This is indeed wrong, it needs to be RFC2974. Thanks! >> >> >> > in 15.2, rfc2947 seems to refer to the wrong document. I think you >> > need 2974. >> >> [T] See above >> >> > in 1, "Repair data flows may be sent directly over a transport protoco= l >> > such as UDP, or they may be encapsulated within RTP." Is RTP the only >> > protocol that could be used to encapsulate flows? should this be "they= may be >> > encapsulated within specialized transports for multimedia, such as RTP= "? >> >> [T] Agreed! Despite nothing is defined today, it be in the future. I hav= e changed accordingly. >> >> > s/FECs operates/FECs operate/ >> >> [T] Done >> >> > s/an FEC/a FEC/ >> >> [T] Done >> >> > Shepherd, Since AVT is the change controller, was this WGLC'd in AVT? >> >> [T] No this was not yet done. It would be good to send out the Raptor sc= hemes for WGLC. Once this is done, I will send out a >> message to the AVT list reporting the status of the Raptor schemes and t= his payload format and ask if WGLC'd in AVT can be >> issued. Is this appropriate? >> >> Thomas >> >> > >> > Thanks, >> > David Harrington >> > Director, IETF Transport Area >> > ietfdbh@comcast.net (preferred for ietf) >> > dbharrington@huaweisymantec.com >> > +1 603 828 1401 (cell) >> > >> >> --- >> Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 978= 980 02 || cell +491725702667 || >> http://www.nomor-research.com >> Nomor Research GmbH =A0- =A0Sitz der Gesellschaft: M=FCnchen - Registerg= ericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: >> DE238047637 - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Vier= ing. >> >> >> >> >> >> >> >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > From abegen@cisco.com Mon Oct 10 11:12:39 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885E221F8C5A for ; Mon, 10 Oct 2011 11:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 2Qxpi4cnJrlc for ; Mon, 10 Oct 2011 11:12:38 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id E2FC221F8B42 for ; Mon, 10 Oct 2011 11:12:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=6483; q=dns/txt; s=iport; t=1318270348; x=1319479948; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=9K0veUM1fJpkRoWv+iEMRezKW3JnwsByS571oHgLnsQ=; b=mVcw3xq7VNux4Y6J2cvFJ/0AtPLhoDbb4Y2a9udv12reNf0CxYYy9nMX BtPH2WbGf6LkGNXd2WSLYCmsjC3YzbGuVekdCm0BQ+OeBaIBc4rNxyUfd CZGqwv448FWcAlNpGGf+VNJ1V7Z71y++Zqbn7hmmG5Yc75z4sA3nQTA9U I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIAAG80k06rRDoG/2dsb2JhbABAA5hzjymBBYFTAQEBAQIBAQEBDwEdPgsMAgICAQgRBAEBAQoGFwEGARoGBh8JCAEBBAoJCAEZh1wHmisBnioChCyCNGEEh32GWgEBhhOEPYR5h0c X-IronPort-AV: E=Sophos;i="4.68,518,1312156800"; d="scan'208";a="6998829" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 10 Oct 2011 18:12:28 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9AICS7d030866; Mon, 10 Oct 2011 18:12:28 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Oct 2011 11:12:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Oct 2011 11:11:15 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5410097E44@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] AD Review: draft-ietf-fecframe-rtp-raptor Thread-Index: AcyHdaX7zU3ZqdYlQq6dtnOFB1MO8AAAjwMA References: <13F059AA83B642759B6FFF44745AB29E@davidPC><530C6093-7047-4D6A-86D2-0CCF6C5D00E1@NOMOR.DE><04CAD96D4C5A3D48B1919248A8FE0D5410097DFA@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 10 Oct 2011 18:12:28.0524 (UTC) FILETIME=[2BA942C0:01CC8778] Cc: draft-ietf-fecframe-rtp-raptor@tools.ietf.org, fecframe-chairs@tools.ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] AD Review: draft-ietf-fecframe-rtp-raptor X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 18:12:39 -0000 I think LC'ing here is sufficient. But, cc'ing payload@ietf.org would = let them know about this and give the opportunity to review it. At the = end, it is an RTP payload format doc. -acbegen > -----Original Message----- > From: Greg Shepherd [mailto:gjshep@gmail.com] > Sent: Monday, October 10, 2011 1:54 PM > To: Ali C. Begen (abegen) > Cc: Thomas Stockhammer; David Harrington; = draft-ietf-fecframe-rtp-raptor@tools.ietf.org; = fecframe-chairs@tools.ietf.org; > fecframe@ietf.org > Subject: Re: [Fecframe] AD Review: draft-ietf-fecframe-rtp-raptor >=20 > Ali, >=20 > It's still a FF doc and needs to LC here, but are you saying Payload > WG also needs LC rather than just review? >=20 > Greg >=20 > On Mon, Oct 10, 2011 at 10:43 AM, Ali C. Begen (abegen) > wrote: > > Note that it is not avtcore who should review this draft but it is = payload wg. Also, the controller should be the Payload WG. > > > > -acbegen > > > >> -----Original Message----- > >> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] = On Behalf Of Thomas Stockhammer > >> Sent: Monday, October 10, 2011 1:39 PM > >> To: David Harrington > >> Cc: draft-ietf-fecframe-rtp-raptor@tools.ietf.org; = fecframe-chairs@tools.ietf.org; fecframe@ietf.org > >> Subject: Re: [Fecframe] AD Review: draft-ietf-fecframe-rtp-raptor > >> > >> Dave, all > >> > >> thanks for the comments, please find inline responses. > >> In addition to the comments, the references are separated in = normative and informative. > >> > >> I do think we can move the RTP payload also to WGLC, but thus may = have to happen in AVTCORE. > >> > >> Thanks > >> > >> Thomas > >> > >> > Can you get a revised ID asap? > >> > >> [T] A revised ID is prepared and has been uploaded here = http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp- > raptor- > >> 05.txt > >> > >> > AD Review of draft-ietf-fecframe-rtp-raptor-04: > >> > It would be good to use RFC2119 keywords in active voice - "The = implementer SHOULD > >> > select" (or is it the operator?) rather than "It is RECOMMENDED = to select". > >> > For example, I recommend changing "The (integer) rate SHALL be = larger than 1000". > >> > Whose responsibility is it to enforce this SHALL? MUST = implementations > >> > reject values less than 1000? (if implementations don't enforce = this, I don't know > >> > how you'll enforce this SHALL. Which means a user MAY choose a = lower value; > >> > therefore this isn't really a MUST. yada yada yada ... > >> > So you should use active voice to be explicit about whose = responsibility it is to enforce this MUST. (and similar to RFC > 3665, > >> MUST is for implementers; SHOULD is for users). > >> > >> [T] It is the responsibility of the operator to pick a value of = 1000 at least. This has been made clear in the revision. > >> > >> > in 5.1.1, rate definition. > >> > "rate: The RTP timestamp (clock) rate in Hz. The (integer) rate > >> > SHALL be larger than 1000 to provide sufficient resolution to = RTCP > >> > operations. However, it is RECOMMENDED to select the rate that = matches the rate of > >> > the protected source RTP stream." The However in this paragraph = makes it > >> > sound like you recommend using the rate that matches (even if it = is below 1000). > >> > I recommend removing the "However," > >> > >> [T] Done > >> > >> > in 5.1.1, s/shall/SHALL/ > >> > >> [T] Done > >> > >> > "Restrictions on usage: This media type depends on RTP framing, = and hence is only > >> > defined for transfer via RTP [[RFC3550]]. Transport within other = framing protocols > >> > is not defined at this time. " Do we need the "at this time"? Is = it envisioned this > >> > media type will be exteneded for additional framing protocols at = a later time? > >> > >> [T] Yes, this may indeed happen. We have seen similar = generalization for other formats recently, such as the MPEG-2 TS. > So > >> it is considered =A0important to avoid any confusion and make it = clear that the registration is for RTP only. > >> > >> > in 12 s/recommended/RECOMMENDED/, s/may/MAY/g > >> > >> [T] Done > >> > >> > in 8, is Session Announcement Protocol (SAP) [RFC2947] the right = reference? I saw no mention of SAP in 2947. > >> > >> [T] This is indeed wrong, it needs to be RFC2974. Thanks! > >> > >> > >> > in 15.2, rfc2947 seems to refer to the wrong document. I think = you > >> > need 2974. > >> > >> [T] See above > >> > >> > in 1, "Repair data flows may be sent directly over a transport = protocol > >> > such as UDP, or they may be encapsulated within RTP." Is RTP the = only > >> > protocol that could be used to encapsulate flows? should this be = "they may be > >> > encapsulated within specialized transports for multimedia, such = as RTP"? > >> > >> [T] Agreed! Despite nothing is defined today, it be in the future. = I have changed accordingly. > >> > >> > s/FECs operates/FECs operate/ > >> > >> [T] Done > >> > >> > s/an FEC/a FEC/ > >> > >> [T] Done > >> > >> > Shepherd, Since AVT is the change controller, was this WGLC'd in = AVT? > >> > >> [T] No this was not yet done. It would be good to send out the = Raptor schemes for WGLC. Once this is done, I will send out > a > >> message to the AVT list reporting the status of the Raptor schemes = and this payload format and ask if WGLC'd in AVT can > be > >> issued. Is this appropriate? > >> > >> Thomas > >> > >> > > >> > Thanks, > >> > David Harrington > >> > Director, IETF Transport Area > >> > ietfdbh@comcast.net (preferred for ietf) > >> > dbharrington@huaweisymantec.com > >> > +1 603 828 1401 (cell) > >> > > >> > >> --- > >> Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 = 89 978980 02 || cell +491725702667 || > >> http://www.nomor-research.com > >> Nomor Research GmbH =A0- =A0Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: > >> DE238047637 - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo = Viering. > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Fecframe mailing list > >> Fecframe@ietf.org > >> https://www.ietf.org/mailman/listinfo/fecframe > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe > > From gjshep@gmail.com Mon Oct 10 13:03:23 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6090B21F8C17; Mon, 10 Oct 2011 13:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 yhqmnWwzbeUA; Mon, 10 Oct 2011 13:03:23 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 72E8E21F8BE7; Mon, 10 Oct 2011 13:03:22 -0700 (PDT) Received: by bkaq10 with SMTP id q10so9803433bka.31 for ; Mon, 10 Oct 2011 13:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=ELOZPE0XyNa14ZGfHudpGpDFVJXy9EqDPvYz0ApYt1s=; b=E5t9Il+3GG1SLaIwxcytr70No9e6ILb73EmLZpHZTmqH2hcJZidSn1pbjK5p6nb2zU h7nV0KLUOvdSq3COe3ta5E0A4lQhhwAARFljHr34W769psj8NcZ6M+H8kNEP0jewJS4u 7lWasgyBQTaUsfCANX4Ve1wJAcisbDcIm5vxE= MIME-Version: 1.0 Received: by 10.204.136.12 with SMTP id p12mr7248960bkt.26.1318277001435; Mon, 10 Oct 2011 13:03:21 -0700 (PDT) Received: by 10.204.56.148 with HTTP; Mon, 10 Oct 2011 13:03:21 -0700 (PDT) Date: Mon, 10 Oct 2011 13:03:21 -0700 Message-ID: From: Greg Shepherd To: fecframe@ietf.org, payload@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Fecframe] LC draft-ietf-fecframe-rtp-raptor-05.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 20:03:23 -0000 Please read, review, comment - a comment of support is also helpful - ASAP. This WG is very close to being finished and this is one of the few last bits. http://www.ietf.org/id/draft-ietf-fecframe-rtp-raptor-05.txt Thanks!, Greg From gjshep@gmail.com Mon Oct 10 13:05:11 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1E521F8C17 for ; Mon, 10 Oct 2011 13:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 0MA2FBuRbi3n for ; Mon, 10 Oct 2011 13:05:11 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 29F3621F8BE7 for ; Mon, 10 Oct 2011 13:05:10 -0700 (PDT) Received: by bkaq10 with SMTP id q10so9805180bka.31 for ; Mon, 10 Oct 2011 13:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=bSAPUF8egTfB8UEL2TM0mcnEYj2SwI4Pt7trYfShX+4=; b=wiiFwAoKBvhWfQ5mr0IhjaA5fPF6dg6Zv2VbuvTbNbNRiKyn73E2+w4Qn7lXn9aCrU KLKmi6EaxlYx70M/Hgh5g8oFJfVKBm5gBIWQ4dlSmV/sA5Hfs0ElGsHJ2jSlpE09bvXe IyYtx3sHshFW8zzzKwFBR060dGqeK4ANw3/GE= MIME-Version: 1.0 Received: by 10.204.152.205 with SMTP id h13mr7323811bkw.91.1318277110155; Mon, 10 Oct 2011 13:05:10 -0700 (PDT) Received: by 10.204.56.148 with HTTP; Mon, 10 Oct 2011 13:05:10 -0700 (PDT) Date: Mon, 10 Oct 2011 13:05:10 -0700 Message-ID: From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Fecframe] WG LC draft-ietf-fecframe-raptor-05 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 20:05:12 -0000 Please read, review and comment - even comments of support please. We're close here folks.. http://tools.ietf.org/html/draft-ietf-fecframe-raptor-05 Thanks!, Greg From ietfdbh@comcast.net Mon Oct 10 17:03:19 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7470121F8C39 for ; Mon, 10 Oct 2011 17:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 sCQsMOShbR+Z for ; Mon, 10 Oct 2011 17:03:18 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 8396321F8BAA for ; Mon, 10 Oct 2011 17:03:18 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta15.westchester.pa.mail.comcast.net with comcast id j5wY1h0051wpRvQ5FC3KmK; Tue, 11 Oct 2011 00:03:19 +0000 Received: from davidPC ([67.189.235.106]) by omta18.westchester.pa.mail.comcast.net with comcast id jC2s1h00b2JQnJT3eC2tHS; Tue, 11 Oct 2011 00:02:54 +0000 From: "David Harrington" To: "'Ali C. Begen \(abegen\)'" , References: <13F059AA83B642759B6FFF44745AB29E@davidPC><530C6093-7047-4D6A-86D2-0CCF6C5D00E1@NOMOR.DE><04CAD96D4C5A3D48B1919248A8FE0D5410097DFA@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D5410097E44@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5410097E44@xmb-sjc-215.amer.cisco.com> Date: Mon, 10 Oct 2011 20:02:30 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcyHdaX7zU3ZqdYlQq6dtnOFB1MO8AAAjwMAAAxAGRA= X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Cc: draft-ietf-fecframe-rtp-raptor@tools.ietf.org, fecframe-chairs@tools.ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] AD Review: draft-ietf-fecframe-rtp-raptor X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 00:03:19 -0000 I recommend sending them an explicit email asking for review during WGLC.=20 We aren't bound by their comments, any more than anybody else's comments, but it would be good to get their feedback. dbh > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > Sent: Monday, October 10, 2011 2:11 PM > To: gjshep@gmail.com > Cc: Thomas Stockhammer; David Harrington;=20 > draft-ietf-fecframe-rtp-raptor@tools.ietf.org;=20 > fecframe-chairs@tools.ietf.org; fecframe@ietf.org > Subject: RE: [Fecframe] AD Review: draft-ietf-fecframe-rtp-raptor >=20 > I think LC'ing here is sufficient. But, cc'ing=20 > payload@ietf.org would let them know about this and give the=20 > opportunity to review it. At the end, it is an RTP payload format doc. >=20 > -acbegen >=20 > > -----Original Message----- > > From: Greg Shepherd [mailto:gjshep@gmail.com] > > Sent: Monday, October 10, 2011 1:54 PM > > To: Ali C. Begen (abegen) > > Cc: Thomas Stockhammer; David Harrington;=20 > draft-ietf-fecframe-rtp-raptor@tools.ietf.org;=20 > fecframe-chairs@tools.ietf.org; > > fecframe@ietf.org > > Subject: Re: [Fecframe] AD Review: draft-ietf-fecframe-rtp-raptor > >=20 > > Ali, > >=20 > > It's still a FF doc and needs to LC here, but are you saying Payload > > WG also needs LC rather than just review? > >=20 > > Greg > >=20 > > On Mon, Oct 10, 2011 at 10:43 AM, Ali C. Begen (abegen) > > wrote: > > > Note that it is not avtcore who should review this draft=20 > but it is payload wg. Also, the controller should be the Payload WG. > > > > > > -acbegen > > > > > >> -----Original Message----- > > >> From: fecframe-bounces@ietf.org=20 > [mailto:fecframe-bounces@ietf.org] On Behalf Of Thomas Stockhammer > > >> Sent: Monday, October 10, 2011 1:39 PM > > >> To: David Harrington > > >> Cc: draft-ietf-fecframe-rtp-raptor@tools.ietf.org;=20 > fecframe-chairs@tools.ietf.org; fecframe@ietf.org > > >> Subject: Re: [Fecframe] AD Review: draft-ietf-fecframe-rtp-raptor > > >> > > >> Dave, all > > >> > > >> thanks for the comments, please find inline responses. > > >> In addition to the comments, the references are=20 > separated in normative and informative. > > >> > > >> I do think we can move the RTP payload also to WGLC, but=20 > thus may have to happen in AVTCORE. > > >> > > >> Thanks > > >> > > >> Thomas > > >> > > >> > Can you get a revised ID asap? > > >> > > >> [T] A revised ID is prepared and has been uploaded here=20 > http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp- > > raptor- > > >> 05.txt > > >> > > >> > AD Review of draft-ietf-fecframe-rtp-raptor-04: > > >> > It would be good to use RFC2119 keywords in active=20 > voice - "The implementer SHOULD > > >> > select" (or is it the operator?) rather than "It is=20 > RECOMMENDED to select". > > >> > For example, I recommend changing "The (integer) rate=20 > SHALL be larger than 1000". > > >> > Whose responsibility is it to enforce this SHALL? MUST=20 > implementations > > >> > reject values less than 1000? (if implementations=20 > don't enforce this, I don't know > > >> > how you'll enforce this SHALL. Which means a user MAY=20 > choose a lower value; > > >> > therefore this isn't really a MUST. yada yada yada ... > > >> > So you should use active voice to be explicit about=20 > whose responsibility it is to enforce this MUST. (and similar to RFC > > 3665, > > >> MUST is for implementers; SHOULD is for users). > > >> > > >> [T] It is the responsibility of the operator to pick a=20 > value of 1000 at least. This has been made clear in the revision. > > >> > > >> > in 5.1.1, rate definition. > > >> > "rate: The RTP timestamp (clock) rate in Hz. The (integer) rate > > >> > SHALL be larger than 1000 to provide sufficient=20 > resolution to RTCP > > >> > operations. However, it is RECOMMENDED to select the=20 > rate that matches the rate of > > >> > the protected source RTP stream." The However in this=20 > paragraph makes it > > >> > sound like you recommend using the rate that matches=20 > (even if it is below 1000). > > >> > I recommend removing the "However," > > >> > > >> [T] Done > > >> > > >> > in 5.1.1, s/shall/SHALL/ > > >> > > >> [T] Done > > >> > > >> > "Restrictions on usage: This media type depends on RTP=20 > framing, and hence is only > > >> > defined for transfer via RTP [[RFC3550]]. Transport=20 > within other framing protocols > > >> > is not defined at this time. " Do we need the "at this=20 > time"? Is it envisioned this > > >> > media type will be exteneded for additional framing=20 > protocols at a later time? > > >> > > >> [T] Yes, this may indeed happen. We have seen similar=20 > generalization for other formats recently, such as the MPEG-2 TS. > > So > > >> it is considered =A0important to avoid any confusion and=20 > make it clear that the registration is for RTP only. > > >> > > >> > in 12 s/recommended/RECOMMENDED/, s/may/MAY/g > > >> > > >> [T] Done > > >> > > >> > in 8, is Session Announcement Protocol (SAP) [RFC2947]=20 > the right reference? I saw no mention of SAP in 2947. > > >> > > >> [T] This is indeed wrong, it needs to be RFC2974. Thanks! > > >> > > >> > > >> > in 15.2, rfc2947 seems to refer to the wrong document.=20 > I think you > > >> > need 2974. > > >> > > >> [T] See above > > >> > > >> > in 1, "Repair data flows may be sent directly over a=20 > transport protocol > > >> > such as UDP, or they may be encapsulated within RTP."=20 > Is RTP the only > > >> > protocol that could be used to encapsulate flows?=20 > should this be "they may be > > >> > encapsulated within specialized transports for=20 > multimedia, such as RTP"? > > >> > > >> [T] Agreed! Despite nothing is defined today, it be in=20 > the future. I have changed accordingly. > > >> > > >> > s/FECs operates/FECs operate/ > > >> > > >> [T] Done > > >> > > >> > s/an FEC/a FEC/ > > >> > > >> [T] Done > > >> > > >> > Shepherd, Since AVT is the change controller, was this=20 > WGLC'd in AVT? > > >> > > >> [T] No this was not yet done. It would be good to send=20 > out the Raptor schemes for WGLC. Once this is done, I will send out > > a > > >> message to the AVT list reporting the status of the=20 > Raptor schemes and this payload format and ask if WGLC'd in AVT can > > be > > >> issued. Is this appropriate? > > >> > > >> Thomas > > >> > > >> > > > >> > Thanks, > > >> > David Harrington > > >> > Director, IETF Transport Area > > >> > ietfdbh@comcast.net (preferred for ietf) > > >> > dbharrington@huaweisymantec.com > > >> > +1 603 828 1401 (cell) > > >> > > > >> > > >> --- > > >> Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de ||=20 > phone +49 89 978980 02 || cell +491725702667 || > > >> http://www.nomor-research.com > > >> Nomor Research GmbH =A0- =A0Sitz der Gesellschaft: M=FCnchen -=20 > Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: > > >> DE238047637 - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer,=20 > Dr. Ingo Viering. > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> Fecframe mailing list > > >> Fecframe@ietf.org > > >> https://www.ietf.org/mailman/listinfo/fecframe > > > _______________________________________________ > > > Fecframe mailing list > > > Fecframe@ietf.org > > > https://www.ietf.org/mailman/listinfo/fecframe > > > >=20 From wwwrun@rfc-editor.org Fri Oct 14 18:37:52 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3431F21F8CF1; Fri, 14 Oct 2011 18:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.261 X-Spam-Level: X-Spam-Status: No, score=-102.261 tagged_above=-999 required=5 tests=[AWL=-0.261, 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 tVePTp3q0KKy; Fri, 14 Oct 2011 18:37:51 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id ABCEC21F8CED; Fri, 14 Oct 2011 18:37:51 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6442F98C28C; Fri, 14 Oct 2011 18:37:51 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111015013751.6442F98C28C@rfc-editor.org> Date: Fri, 14 Oct 2011 18:37:51 -0700 (PDT) Cc: fecframe@ietf.org, rfc-editor@rfc-editor.org Subject: [Fecframe] RFC 6363 on Forward Error Correction (FEC) Framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 01:37:52 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6363 Title: Forward Error Correction (FEC) Framework Author: M. Watson, A. Begen, V. Roca Status: Standards Track Stream: IETF Date: October 2011 Mailbox: watsonm@netflix.com, abegen@cisco.com, vincent.roca@inria.fr Pages: 42 Characters: 98725 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-fecframe-framework-15.txt URL: http://www.rfc-editor.org/rfc/rfc6363.txt This document describes a framework for using Forward Error Correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content Delivery Protocols that provide FEC for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC scheme (and associated FEC codes) that is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined that are not specific to a particular FEC scheme, and FEC schemes can be defined that are not specific to a particular Content Delivery Protocol. [STANDARDS-TRACK] This document is a product of the FEC Framework 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 From wwwrun@rfc-editor.org Fri Oct 14 18:38:06 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727FC21F8CFD; Fri, 14 Oct 2011 18:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.788 X-Spam-Level: X-Spam-Status: No, score=-101.788 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, 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 Z4NJ58lMrK-O; Fri, 14 Oct 2011 18:38:05 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id 4102121F8D0B; Fri, 14 Oct 2011 18:38:05 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3381298C294; Fri, 14 Oct 2011 18:38:05 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111015013805.3381298C294@rfc-editor.org> Date: Fri, 14 Oct 2011 18:38:05 -0700 (PDT) Cc: fecframe@ietf.org, rfc-editor@rfc-editor.org Subject: [Fecframe] RFC 6364 on Session Description Protocol Elements for the Forward Error Correction (FEC) Framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 01:38:06 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6364 Title: Session Description Protocol Elements for the Forward Error Correction (FEC) Framework Author: A. Begen Status: Standards Track Stream: IETF Date: October 2011 Mailbox: abegen@cisco.com Pages: 18 Characters: 36160 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-fecframe-sdp-elements-11.txt URL: http://www.rfc-editor.org/rfc/rfc6364.txt This document specifies the use of the Session Description Protocol (SDP) to describe the parameters required to signal the Forward Error Correction (FEC) Framework Configuration Information between the sender(s) and receiver(s). This document also provides examples that show the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework. [STANDARDS-TRACK] This document is a product of the FEC Framework 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 From abegen@cisco.com Mon Oct 17 08:18:22 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327E421F8CBC; Mon, 17 Oct 2011 08:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=3.100, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] 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 WTBrtq+Hko1z; Mon, 17 Oct 2011 08:18:21 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id BF9EA21F8CA5; Mon, 17 Oct 2011 08:18:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1105; q=dns/txt; s=iport; t=1318864701; x=1320074301; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=RKGKSS+XS7+7gXR+L7D5VnQugBAxjITf/JYz+rZ/h0M=; b=ThoHDBpwmlYcL4Mc9K991eO9gifc0YXx8SMWI2DeE2MG+oSqHkQUBF/7 gUaIsQEX8VmpmIbeGiJZ7gWBAhatX8Vu4NX6ZkINxPdqjGA7jJlBI39+s RUAZYk2A8QkFGNuqYe+knkDpE2vlsNCS4SwxfHekTmL8UT3tj1SuvUinc s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBANdFnE6rRDoG/2dsb2JhbABDmUaPI4EFgW4BAQEEAQEBDwEdPhcEAgEIEQQBAQsGFwEGASYfCQgBAQQBEggBGYdllzgBnlKHJ2EEiAKRKoxE X-IronPort-AV: E=Sophos;i="4.69,359,1315180800"; d="scan'208";a="8204703" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 17 Oct 2011 15:17:56 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9HFHuv2028688; Mon, 17 Oct 2011 15:17:56 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 08:17:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Oct 2011 08:17:13 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D541013EC57@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] LC draft-ietf-fecframe-rtp-raptor-05.txt Thread-Index: AcyHrG6S77S8QfE9TqKIuf0qsa8OiwFKGlRQ References: From: "Ali C. Begen (abegen)" To: , , X-OriginalArrivalTime: 17 Oct 2011 15:17:56.0860 (UTC) FILETIME=[F2F463C0:01CC8CDF] Subject: Re: [Fecframe] [payload] LC draft-ietf-fecframe-rtp-raptor-05.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 15:18:22 -0000 Minor comments: - The framework draft was published as RFC 6363, the citation should be = updated. - 2119 keywords should not be used in the intro section. Just make them = small letters. - Provide some example apps in the registration section (Applications = that use this media type: is empty) - Controller should be PAYLOAD WG not AVT.=20 - I-D.ietf-fecframe-sdp-elements is also RFC 6364 now. -acbegen > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On = Behalf Of Greg Shepherd > Sent: Monday, October 10, 2011 4:03 PM > To: fecframe@ietf.org; payload@ietf.org > Subject: [payload] LC draft-ietf-fecframe-rtp-raptor-05.txt >=20 > Please read, review, comment - a comment of support is also helpful - > ASAP. This WG is very close to being finished and this is one of the > few last bits. >=20 > http://www.ietf.org/id/draft-ietf-fecframe-rtp-raptor-05.txt >=20 > Thanks!, > Greg > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From iesg-secretary@ietf.org Tue Oct 18 14:40:22 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D571F0C5C; Tue, 18 Oct 2011 14:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, 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 r8M3M+8od+Tt; Tue, 18 Oct 2011 14:40:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09B321F8B8D; Tue, 18 Oct 2011 14:40:21 -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.60 Message-ID: <20111018214021.22060.61351.idtracker@ietfa.amsl.com> Date: Tue, 18 Oct 2011 14:40:21 -0700 Cc: fecframe@ietf.org Subject: [Fecframe] Last Call: (Methods to convey FEC Framework Configuration Information) to Experimental RFC X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 21:40:22 -0000 The IESG has received a request from the FEC Framework WG (fecframe) to consider the following document: - 'Methods to convey FEC Framework Configuration Information' as an Experimental RFC 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-11-01. 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. Abstract FEC Framework document [FECARCH] defines the FEC Framework Configuration Information necessary for the FEC framework operation. This document describes how to use existing signaling protocols to determine and dynamically communicate the Configuration information between sender(s) and receiver(s). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-fecframe-config-signaling/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-fecframe-config-signaling/ No IPR declarations have been submitted directly on this I-D. From martin.ellis@gmail.com Wed Oct 19 02:36:00 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E15521F8B07 for ; Wed, 19 Oct 2011 02:36:00 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQv3+NDU4Dd4 for ; Wed, 19 Oct 2011 02:35:59 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACF521F8B29 for ; Wed, 19 Oct 2011 02:35:59 -0700 (PDT) Received: by wwe6 with SMTP id 6so1508663wwe.13 for ; Wed, 19 Oct 2011 02:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0z8tfm84jwDfQe0QRJL8BsqnmP8VT9+B84la5RkLkJI=; b=rmuKbzJQ1bXFvKTdHLdDS4aTUId1BZqp/uvGnaVtsJYxdYLlQ0CdtxodOMSvubVkHF 0n0gBefnrhk8EyviZUsJdPRwuscZ9I6BoMinDJSYmfxBcOjgAWItNLN9xyU6NtvcEmad fVoTs3FCjR6/bmMR0kqY+kGZscosP2CR6mqpU= Received: by 10.216.137.36 with SMTP id x36mr2345248wei.41.1319016956121; Wed, 19 Oct 2011 02:35:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.73.149 with HTTP; Wed, 19 Oct 2011 02:35:36 -0700 (PDT) In-Reply-To: References: From: Martin Ellis Date: Wed, 19 Oct 2011 10:35:36 +0100 Message-ID: To: gjshep@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: fecframe@ietf.org Subject: Re: [Fecframe] WGLC draft-ietf-fecframe-ldpc-00 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 09:36:00 -0000 I've read this document, and I had just a couple of comments: - The last 2 paragraphs of section 4.2 discuss a max_rt parameter, which restricts the ADU block size for the real-time constraints of a particular application. Would it be appropriate to give an example here? (this also applies to the simple-rs draft). - In section 7.1, some specific numbers are given on levels of overhead required to reduce residual loss rates. Are these results based on the [Matsuzono10] reference? If so, I think it would be better to say so explicitly (and briefly mention the assumptions made in that study; i.e., uniform random packet loss). Cheers, Martin On 14 September 2011 15:17, Greg Shepherd wrote: > http://datatracker.ietf.org/doc/draft-ietf-fecframe-ldpc/ > > ..and another WGLC. Please read and provide feedback so we can close > the group before Taipei and give David something to brag about. ;-) > > Thanks!, > Greg > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > From iesg-secretary@ietf.org Thu Oct 20 06:47:16 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF4721F8B5D; Thu, 20 Oct 2011 06:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, 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 9Tj+5GEuAXNx; Thu, 20 Oct 2011 06:47:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C41221F86DD; Thu, 20 Oct 2011 06:47:16 -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.61 Message-ID: <20111020134716.20244.40862.idtracker@ietfa.amsl.com> Date: Thu, 20 Oct 2011 06:47:16 -0700 Cc: fecframe@ietf.org Subject: [Fecframe] Last Call: (RTP Payload Format for Raptor FEC) to Proposed Standard X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 13:47:16 -0000 The IESG has received a request from the FEC Framework WG (fecframe) to consider the following document: - 'RTP Payload Format for Raptor FEC' 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-11-03. 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. Abstract This document specifies an RTP Payload Format for Forward Error Correction repair data produced by the Raptor FEC Schemes. Raptor FEC Schemes are specified for use with the IETF FEC Framework which supports transport of repair data over both UDP and RTP. This document specifies the Payload Format which is required for the use of RTP to carry Raptor repair flows. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-fecframe-rtp-raptor/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-fecframe-rtp-raptor/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Thu Oct 20 06:50:21 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB2521F8BF6; Thu, 20 Oct 2011 06:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.279 X-Spam-Level: X-Spam-Status: No, score=-101.279 tagged_above=-999 required=5 tests=[AWL=-1.189, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 kMJ6MdeZqx7H; Thu, 20 Oct 2011 06:50:19 -0700 (PDT) Received: from mx04.secom.co.jp (mx04.secom.co.jp [61.114.178.251]) by ietfa.amsl.com (Postfix) with ESMTP id A6A8821F8B49; Thu, 20 Oct 2011 06:50:18 -0700 (PDT) Received: from unknown (HELO mldsit04.intra.secom.co.jp) ([172.21.1.41]) by mx04.secom.co.jp with SMTP; 20 Oct 2011 22:50:15 +0900 Received: from (unknown [10.1.3.137]) by mldsit04.intra.secom.co.jp with smtp id 4770_753a_70510b74_fb22_11e0_b31c_00219b8ebd91; Thu, 20 Oct 2011 22:50:15 +0900 Received: from exc01.SECOM.corp ([10.1.3.136]) by exc02.SECOM.corp with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Oct 2011 22:50:15 +0900 thread-index: AcyPLzFva5BmVBeMRyWZRMkE9e8D/w== Received: from mail pickup service by exc01.SECOM.corp with Microsoft SMTPSVC; Thu, 20 Oct 2011 22:50:14 +0900 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 Received: from mldsit04.intra.secom.co.jp ([10.1.200.7]) by exc01.SECOM.corp with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Oct 2011 22:48:20 +0900 Received: from (unknown [172.21.1.33]) by mldsit04.intra.secom.co.jp with smtp id 4775_31ab_2a1c1284_fb22_11e0_b31c_00219b8ebd91; Thu, 20 Oct 2011 22:48:20 +0900 Received: from post.secomtrust.net (HELO post01.secomtrust.net) ([61.114.189.120]) by mx03.secom.co.jp with ESMTP; 20 Oct 2011 22:48:20 +0900 Received: from iron01.secomtrust.net (imss01 [10.3.4.41]) by post01.secomtrust.net (Postfix) with ESMTP id C037A636D for ; Thu, 20 Oct 2011 22:48:20 +0900 (JST) Received: from 61-114-188-202.secomtrust.net (HELO guard02v.secomtrust.net) ([61.114.188.202]) by iron01v.secomtrust.net with ESMTP; 20 Oct 2011 22:48:20 +0900 Received: from mail.soc.secomtrust.net (mail.soc.secomtrust.net [61.114.178.86]) by guard02v.secomtrust.net (Postfix) with SMTP id B0F7CE232C for ; Thu, 20 Oct 2011 22:48:20 +0900 (JST) Received: (qmail 12232 invoked by uid 400); 20 Oct 2011 13:48:20 -0000 Delivered-To: main-shimaoka@scanned.soc.secomtrust.net Received: (qmail 12230 invoked from network); 20 Oct 2011 13:48:20 -0000 Received: from unknown (HELO post03.secomtrust.net) (61.114.189.120) by ksdc0043 with SMTP; 20 Oct 2011 13:48:20 -0000 Received: from iron02.secomtrust.net (imss03 [10.3.4.43]) by post03.secomtrust.net (Postfix) with ESMTP id 770231404B7 for ; Thu, 20 Oct 2011 22:48:20 +0900 (JST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4CAG4moE4MFjoekmdsb2JhbABDqRYiAQEBAQkLCwcSJ4FwBgEBNwYBAQQKHgsBAgMBAgYCQAUDCAMBGwgfFxMFiAOjC4QMAY5FB4gpiAeEIYdckXc Received: from mail.ietf.org ([12.22.58.30]) by iron02.secomtrust.net with ESMTP; 20 Oct 2011 22:48:18 +0900 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4BA321F8B48; Thu, 20 Oct 2011 06:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1319118439; bh=9cHSOOjpI3leaV82Wfvdjmtj7tV6u7JjTJwvZRC7Njc=; h=MIME-Version:From:To:Subject:Message-ID:Date:Cc:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=Gqh1M++IzaqJ338lM2Zil/DVjYeNn3AhjnJvXbMaDsX+UnVhZhtYl5pudtKZdoMVX P9o/m89VxOsmbPFez19MpOLo+ujyhXt47AiIv11edvp3seSG+HIa7YZOhNQXsJhmfe 5hZXD3bJ3koH78eV9B7tTVruuzdOegmrRTqqQxuk= X-Original-To: ietf-announce@ietfa.amsl.com Delivered-To: ietf-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF4721F8B5D; Thu, 20 Oct 2011 06:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 9Tj+5GEuAXNx; Thu, 20 Oct 2011 06:47:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C41221F86DD; Thu, 20 Oct 2011 06:47:16 -0700 (PDT) MIME-Version: 1.0 From: "The IESG" To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111020134716.20244.40862.idtracker@ietfa.amsl.com> Date: Thu, 20 Oct 2011 06:47:16 -0700 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: Errors-To: ietf-announce-bounces@ietf.org X-OriginalArrivalTime: 20 Oct 2011 13:48:20.0772 (UTC) FILETIME=[EDCBB640:01CC8F2E] Cc: fecframe@ietf.org Subject: [Fecframe] Last Call: (RTP PayloadFormat for Raptor FEC) to Proposed Standard X-BeenThere: fecframe@ietf.org Reply-To: ietf@ietf.org List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 13:50:21 -0000 The IESG has received a request from the FEC Framework WG (fecframe) to consider the following document: - 'RTP Payload Format for Raptor FEC' 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-11-03. 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. Abstract This document specifies an RTP Payload Format for Forward Error Correction repair data produced by the Raptor FEC Schemes. Raptor FEC Schemes are specified for use with the IETF FEC Framework which supports transport of repair data over both UDP and RTP. This document specifies the Payload Format which is required for the use of RTP to carry Raptor repair flows. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-fecframe-rtp-raptor/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-fecframe-rtp-raptor/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From vincent.roca@inrialpes.fr Tue Oct 25 00:27:53 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7C721F8AFE; Tue, 25 Oct 2011 00:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 lznkVp7p3G9m; Tue, 25 Oct 2011 00:27:53 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id D628321F8AFC; Tue, 25 Oct 2011 00:27:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.69,403,1315173600"; d="scan'208";a="125738542" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 25 Oct 2011 09:27:50 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Vincent Roca In-Reply-To: <20111020134716.20244.40862.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2011 09:27:50 +0200 Content-Transfer-Encoding: 7bit Message-Id: <3D4BEDE3-3F17-49CC-A28C-B4FCAF3C4626@inrialpes.fr> References: <20111020134716.20244.40862.idtracker@ietfa.amsl.com> To: ietf@ietf.org X-Mailer: Apple Mail (2.1084) Cc: fecframe@ietf.org Subject: Re: [Fecframe] Last Call: (RTP Payload Format for Raptor FEC) to Proposed Standard X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 07:27:54 -0000 Hi everybody, I've already mentioned this point in March 18th, this year, in the FECFrame list. Unless I missed some key sentence, I have the feeling that this I-D **leaves implicit** the strong requirement that there must not be any RTP packet loss (or reordering) before reaching the Fecframe encoder, i.e. that the RTP Sequence Numbers used to identify source symbols in the FEC block are always in sequence. This is a key requirement that MUST be clearly stated rather than being left implicit. I haven't checked carefully in draft-ietf-fecframe-raptor-05, but sections 8.2.2. and 8.2.4. in this I-D do not seem to be more explicit on this point. This requirement, that is specific to situations where RTP source packets are left unchanged, and some solutions to mitigate it, have already been discussed on the list and guidelines have been added in RFC6363: 10.2. Operational and Management Recommendations [...] 5. Management of Communication Issues before Reaching the Sending FECFRAME Instance: Cheers, Vincent On Oct. 20, 2011, 15:47, The IESG wrote: > > The IESG has received a request from the FEC Framework WG (fecframe) to > consider the following document: > - 'RTP Payload Format for Raptor FEC' > 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-11-03. 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. > > Abstract > > > This document specifies an RTP Payload Format for Forward Error > Correction repair data produced by the Raptor FEC Schemes. Raptor > FEC Schemes are specified for use with the IETF FEC Framework which > supports transport of repair data over both UDP and RTP. This > document specifies the Payload Format which is required for the use > of RTP to carry Raptor repair flows. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-fecframe-rtp-raptor/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-fecframe-rtp-raptor/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From vincent.roca@inrialpes.fr Tue Oct 25 00:38:42 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E859021F8B62 for ; Tue, 25 Oct 2011 00:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 6uOgDpS5vUdu for ; Tue, 25 Oct 2011 00:38:42 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id 866D221F8B5A for ; Tue, 25 Oct 2011 00:38:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.69,403,1315173600"; d="scan'208";a="125740446" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 25 Oct 2011 09:38:40 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Vincent Roca In-Reply-To: Date: Tue, 25 Oct 2011 09:38:40 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: Martin Ellis X-Mailer: Apple Mail (2.1084) Cc: fecframe@ietf.org Subject: Re: [Fecframe] WGLC draft-ietf-fecframe-ldpc-00 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 07:38:43 -0000 Hello Martin, > I've read this document, and I had just a couple of comments: > > - The last 2 paragraphs of section 4.2 discuss a max_rt parameter, > which restricts the ADU block size for the real-time constraints of a > particular application. Would it be appropriate to give an example > here? (this also applies to the simple-rs draft). Good idea. We'll do that in next version of both I-Ds. > - In section 7.1, some specific numbers are given on levels of > overhead required to reduce residual loss rates. Are these results > based on the [Matsuzono10] reference? If so, I think it would be > better to say so explicitly (and briefly mention the assumptions made > in that study; i.e., uniform random packet loss). No, these results come from an evaluation of the LDPC-Staircase codes, using a dedicated simulator. However they give an idea of what performance (in terms of erasure recovery) can be expected for real use-cases if these codes are correctly used. We'll clarify this. Thanks for the feedback. Cheers, Vincent From internet-drafts@ietf.org Mon Oct 31 11:52:57 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1EE31F0CCD; Mon, 31 Oct 2011 11:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, 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 Vua-ltk+7Oz0; Mon, 31 Oct 2011 11:52:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2901F0C7D; Mon, 31 Oct 2011 11:52:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031185257.4096.648.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 11:52:57 -0700 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action: draft-ietf-fecframe-pseudo-cdp-02.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 18:52:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the FEC Framework Working Group of the IE= TF. Title : Pseudo Content Delivery Protocol (CDP) for Protecting Mu= ltiple Source Flows in FEC Framework Author(s) : Ulas C. Kozat Ali Begen Filename : draft-ietf-fecframe-pseudo-cdp-02.txt Pages : 11 Date : 2011-10-31 This document provides a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows based on the FEC Framework and the Session Description Protocol (SDP) elements defined for the framework. The purpose of the document is not to provide a full-pledged protocol, but to show how the defined framework and SDP elements can be combined together to design a CDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-pseudo-cdp-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-fecframe-pseudo-cdp-02.txt From abegen@cisco.com Mon Oct 31 11:57:47 2011 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59141F0C8C for ; Mon, 31 Oct 2011 11:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.942 X-Spam-Level: X-Spam-Status: No, score=-4.942 tagged_above=-999 required=5 tests=[AWL=1.657, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 LanXPVQ8gIOQ for ; Mon, 31 Oct 2011 11:57:47 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 56A4C1F0C7D for ; Mon, 31 Oct 2011 11:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=2272; q=dns/txt; s=iport; t=1320087467; x=1321297067; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=oMr18Oqs8VA5ENJ7nEuvBlb6j9Xw5clDUbMu+EbiYCc=; b=Bn7sjP1XM+WtUw9DfWoL4ouuJtU8mSyWjSPro5oDkcqFwNIQgVwoWDcD x8xt1I3O66yVGYrSPmk71+bWxvjZevdk2Ee25qViVUE8aMXjJr1Vy5iZg D2psYF2bBKf0IGpTHEhsdtL8G9AkWQQa1keQU0WQKcNWnj3bUVfbnTWxL A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMBACPvrk6rRDoG/2dsb2JhbABDhHeUbEOOCoEFgQWBcgEBAQEDEgEQDQRDAgwEAgEIEQQBAQMCBgYXAQICAgEBRAcBAQUDAQEEEwgah2iVSgGMSpFtBIEwhj4zYQSIBpE+jEk X-IronPort-AV: E=Sophos;i="4.69,433,1315180800"; d="scan'208";a="10246776" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 31 Oct 2011 18:57:47 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9VIvlIE031848; Mon, 31 Oct 2011 18:57:47 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 11:57:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 31 Oct 2011 11:56:47 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D541030600D@xmb-sjc-215.amer.cisco.com> In-Reply-To: <20111031185257.4096.66939.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-fecframe-pseudo-cdp-02.txt Thread-Index: AcyX/k/qNnTdcLUmSZGY4AufdoDHKAAACb9g References: <20111031185257.4096.66939.idtracker@ietfa.amsl.com> From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 31 Oct 2011 18:57:47.0258 (UTC) FILETIME=[FAD3E5A0:01CC97FE] Cc: kozat@docomolabs-usa.com Subject: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-pseudo-cdp-02.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 18:57:47 -0000 SGkgZXZlcnlvbmUsDQoNClRoaXMgd2FzIGEgZG9jdW1lbnQgd2UgZnJvemUgZWFybGllciB0byB3 YWl0IGZvciB0aGUgZnJhbWV3b3JrIHRvIGJlIGZpbmFsaXplZCBhbmQgcHVibGlzaGVkLiBOb3cg aXMgdGhlIHRpbWUgdG8gYnJpbmcgaXQgYmFjayB0byBmZWNmcmFtZS4gTm90ZSB0aGF0IHRoZSBk b2N1bWVudCBpcyBpbmZvcm1hdGlvbmFsIGFuZCBhaW1zIHRvIGV4cGxhaW4gaG93IHNvbWUgY29t cGxpY2F0ZWQgc2NlbmFyaW9zIGNhbiBiZSBhY2hpZXZlZCBpbiBmcmFtZXdvcmsuDQoNClRoZSBk b2N1bWVudCBpcyByZWFkeSBmb3IgcmV2aWV3IGFuZCBldmVudHVhbCBXR0xDIGluIG91ciBvcGlu aW9uLg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWZlY2Zy YW1lLXBzZXVkby1jZHAvIA0KDQpUaGFua3MuDQotYWNiZWdlbg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgT2N0b2JlciAzMSwgMjAxMSAyOjUz IFBNDQpUbzogQWxpIEMuIEJlZ2VuIChhYmVnZW4pDQpDYzoga296YXRAZG9jb21vbGFicy11c2Eu Y29tOyBBbGkgQy4gQmVnZW4gKGFiZWdlbikNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtaWV0Zi1mZWNmcmFtZS1wc2V1ZG8tY2RwLTAyLnR4dA0KDQpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1mZWNmcmFtZS1wc2V1ZG8tY2RwLTAyLnR4dCBoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEFsaSBCZWdlbiBhbmQgcG9zdGVkIHRvIHRo ZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtaWV0Zi1mZWNmcmFtZS1wc2V1 ZG8tY2RwDQpSZXZpc2lvbjoJIDAyDQpUaXRsZToJCSBQc2V1ZG8gQ29udGVudCBEZWxpdmVyeSBQ cm90b2NvbCAoQ0RQKSBmb3IgUHJvdGVjdGluZyBNdWx0aXBsZSBTb3VyY2UgRmxvd3MgaW4gRkVD IEZyYW1ld29yaw0KQ3JlYXRpb24gZGF0ZToJIDIwMTEtMTAtMzENCldHIElEOgkJIGZlY2ZyYW1l DQpOdW1iZXIgb2YgcGFnZXM6IDExDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBwcm92 aWRlcyBhIHBzZXVkbyBDb250ZW50IERlbGl2ZXJ5IFByb3RvY29sIChDRFApIHRvDQogICBwcm90 ZWN0IG11bHRpcGxlIHNvdXJjZSBmbG93cyB3aXRoIG9uZSBvciBtb3JlIHJlcGFpciBmbG93cyBi YXNlZCBvbg0KICAgdGhlIEZFQyBGcmFtZXdvcmsgYW5kIHRoZSBTZXNzaW9uIERlc2NyaXB0aW9u IFByb3RvY29sIChTRFApIGVsZW1lbnRzDQogICBkZWZpbmVkIGZvciB0aGUgZnJhbWV3b3JrLiAg VGhlIHB1cnBvc2Ugb2YgdGhlIGRvY3VtZW50IGlzIG5vdCB0bw0KICAgcHJvdmlkZSBhIGZ1bGwt cGxlZGdlZCBwcm90b2NvbCwgYnV0IHRvIHNob3cgaG93IHRoZSBkZWZpbmVkDQogICBmcmFtZXdv cmsgYW5kIFNEUCBlbGVtZW50cyBjYW4gYmUgY29tYmluZWQgdG9nZXRoZXIgdG8gZGVzaWduIGEg Q0RQLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJp YXQNCg==