From ietfdbh@comcast.net Tue Feb 21 05:38:09 2012 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 4905121F87DA for ; Tue, 21 Feb 2012 05:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.23 X-Spam-Level: X-Spam-Status: No, score=-102.23 tagged_above=-999 required=5 tests=[AWL=0.369, 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 hLCfadiQ-1pD for ; Tue, 21 Feb 2012 05:38:08 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id EFF8D21F87D6 for ; Tue, 21 Feb 2012 05:38:07 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta12.westchester.pa.mail.comcast.net with comcast id cdEg1i0051c6gX85Cde833; Tue, 21 Feb 2012 13:38:08 +0000 Received: from [192.168.1.33] ([71.233.85.150]) by omta23.westchester.pa.mail.comcast.net with comcast id cddj1i0203Ecudz3jddwfg; Tue, 21 Feb 2012 13:38:08 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 21 Feb 2012 08:37:41 -0500 From: David Harrington To: "Rajiv Asati (rajiva)" , Greg Shepherd , Message-ID: Thread-Topic: [Fecframe] IESG Eval followup: config-signaling anf rtp-raptor In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C0729E347@XMB-RCD-111.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Fecframe] IESG Eval followup: config-signaling anf 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, 21 Feb 2012 13:38:09 -0000 Hi Rajiv, Can you get a new revision published as Informational please? Here is an issue you really need to address in the document: "To make this actionable I suggest you work out very clearly what the purpose of the document is and capture that both in the Abstract and the Introduction. It would also help if you clearly defined what *you* mean by a signaling protocol because people at different layers of the stack have very different understandings of the term." There are a number of other discusses that need to be addressed. If you get a revision to me by the end of February, I can run it through the system again and hopefully get it into the RFC Editor before I step down as AD in March. You really don't want to start over with a new AD. Thanks, -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 1/20/12 12:46 PM, "Rajiv Asati (rajiva)" wrote: >Informational is fine. > >Cheers, >Rajiv > >> -----Original Message----- >> From: Greg Shepherd [mailto:gjshep@gmail.com] >> Sent: Friday, November 04, 2011 10:30 AM >> To: Rajiv Asati (rajiva); fecframe@ietf.org >> Subject: Fwd: IESG Eval followup: config-signaling anf rtp-raptor >> >> *, >> >> There are a few things holding up the config-sig draft, but the one we >> need to help with is: >> >> MUST this doc progress as experimental, or is there WG consensus to >> move it to informational? >> >> Please reply promptly to the list. >> >> Thanks!, >> Greg >> >> >> ---------- Forwarded message ---------- >> From: David Harrington >> Date: Fri, Nov 4, 2011 at 7:23 AM >> Subject: IESG Eval followup: config-signaling anf rtp-raptor >> To: gjshep@gmail.com >> Cc: draft-ietf-fecframe-config-signaling@tools.ietf.org, >> draft-ietf-fecframe-rtp-raptor@tools.ietf.org >> >> >> Hi, >> >> The IESG reviewed the config signaling and rtp-raptor drafts. >> We have work to do. >> >> config-signaling: >> 1) Can we publish this as Informational? >> Is that a problem for any cross-SDO work? >> If this is published as Informational, then compliance is no >> longer appropriate - you don't comply to an Informational document. so >> the RFC2119 keywords should disappear. >> >> 2) Ask the WG which version of GDOI is supposed to be used? See Sean's >> Comments. >> >> 3) The document needs a good rewrite, especialy the Abstract and >> Introduction. There are Discusses and Comments from many that the >> document doesn't describe its purpose. This must be clairified. >> >> 4) There are Discusses and Comments from multiple ADs that must be >> addressed: >> Ron: just remove the reference; I don't know if you want to carry any >> information from that expired mboned doc into this doc. >> Adrian: clarify what is considered a signaling protocol in this doc >> Gonzalo: no RFC2119 keywords in the Introduction (so normative text >> must be moved) >> Jari: internal references (are you using xml2rfc? they have ways to >> keep that in sync for you) >> clarify how you expect this to be used re: SDP, XML, etc. >> Russ: Gen-ART review >> Sean: "MAY encrypt" >> MUST is for implementers - see RFC 3365 - unless this is >> Informational. >> GDOI - explain how to use this. Clarify which version. >> Stephen: "MAY encrypt" => "SHOULD encrypt using PGP or CMS"? >> GDOI - how to use to manage keys? >> Pete: If Informational, then you can ignore his comment; If >> Experimental, then describe the experiment. >> Robert: new versus copied requirements; point to the existing rules >> rather than copying them here. >> The #2 comment is critical - are implementers supposed to >> choose from one of these protocols >> (i.e., these are the only ones allowed in a compliant >> Experimental implementation?) >> >> rpt-raptor: >> 1) A registration request must be sent to ietf-types@iana.org to >> register the types, per section 5.1 of RFC 4288. The registration >> template needs to be filled in >> >> 2) There are discusses from Sean, Pete, Robert and Stephen that must >> be addressed, and Comments from Russ (the Gen-ART review) that should >> be addressed in a Revised ID. I think the usage of RFC2119 keywords is >> acceptable, but might be improved. Please read and **consider** Pete's >> comments on RFC2119 usage, and then do what you think is right. >> >> Please get these Revised IDs done asap so I can send them off to the >> RFC Editor. >> >> David Harrington >> Director, IETF Transport Area >> ietfdbh@comcast.net (preferred for ietf) >> dbharrington@huaweisymantec.com >> +1 603 828 1401 (cell) >_______________________________________________ >Fecframe mailing list >Fecframe@ietf.org >https://www.ietf.org/mailman/listinfo/fecframe From rajiva@cisco.com Tue Feb 21 14:45:19 2012 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 8049911E80DC for ; Tue, 21 Feb 2012 14:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.008 X-Spam-Level: X-Spam-Status: No, score=-9.008 tagged_above=-999 required=5 tests=[AWL=1.591, BAYES_00=-2.599, 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 ZCTGlRHDYtEt for ; Tue, 21 Feb 2012 14:45:18 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6294721F87D4 for ; Tue, 21 Feb 2012 14:45:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=6799; q=dns/txt; s=iport; t=1329864318; x=1331073918; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=FSW1Oc8B91APUWK6tiITXzn9EW+UpCxRiKggQTTYma4=; b=PGnrPbmNcYAtNON5ew+3dbfWJIneB/D9g6V1VNt7kEdcRZjIsjVeYA1G c6QuN1B5JL3Zc2S60rOAvpYMFbrULLjOzqVLq3WTuu8Ux2p5DvbAqxYhk B7JTxGldso9VetL2psZxTpBOT0H1vGnJPnUEEt7/vRaXlhvQNtOb/SPZw g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowAAB8eRE+tJV2a/2dsb2JhbABAA6BWkWyBB4FzAQEBBAEBAQ8BHQo0FwQCAQgOAwMBAQEBCgYXAQYBIAYfCQgBAQQBEggah2eZHgGfFASIfIJ6AwkDBAcJDIROAwwKBgqCQGMEiE+YAId1 X-IronPort-AV: E=Sophos;i="4.73,460,1325462400"; d="scan'208";a="60748362" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 21 Feb 2012 22:45:18 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1LMjHg8020420; Tue, 21 Feb 2012 22:45:17 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 16:45:17 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Feb 2012 16:45:16 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C0778D2D6@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] IESG Eval followup: config-signaling anf rtp-raptor Thread-Index: AczwngwEjAJ6P3cYT4S3fA4F56keLgARlBtw References: <067E6CE33034954AAC05C9EC85E2577C0729E347@XMB-RCD-111.cisco.com> From: "Rajiv Asati (rajiva)" To: "David Harrington" , "Greg Shepherd" , X-OriginalArrivalTime: 21 Feb 2012 22:45:17.0797 (UTC) FILETIME=[7BDC9950:01CCF0EA] Subject: Re: [Fecframe] IESG Eval followup: config-signaling anf 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, 21 Feb 2012 22:45:19 -0000 Hi David, I have updated the document in accordance with the comments received so far, and submitted the -07 version for us to make progress. =09 1. Adrian Farrel: Comment (2011-11-03)::=3D Updated the abstract and Introduction section. 2. Gonzalo Camarillo: Comment (2011-11-03)::=3D Removed the normative language. 3. Jari Arkko: Comment (2011-11-03) ::=3D Corrected the sections referencing and updated the Introduction 4. Ron Bonica: Discuss (2011-11-02) ::=3D Removed the reference to that expired draft. 5. Russ Housley: Comment (2011-11-03)::=3D All accepted. Updated the relevant text. 6. Stephen Farrell: Comment (2011-11-01::=3D Cryptography meant encryption. Removed it as well as GDOI, and mentioned PGP. 7. Wesley Eddy: Discuss (2011-10-26) ::=3D Changed to Informational. 8. Pete Resnick: Discuss (2011-11-02) ::=3D Changed to Informational. 9. Robert Sparks: Discuss (2011-11-02)::=3D1. Added a para in section = 5.1 to clarify this. 2. Not a complete list. 10. Robert Sparks: Comment (2011-11-02)::=3D Changed to Informational. 11. Sean Turner: Discuss (2011-11-02)::=3D Yes. Added PGP preference. 12. Sean Turner: Comment (2011-11-02)::=3D Yes, meant to say encryption. Removed cryptography and references to GDOI altogether. Cheers, Rajiv =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Tuesday, February 21, 2012 8:38 AM > To: Rajiv Asati (rajiva); Greg Shepherd; fecframe@ietf.org > Subject: Re: [Fecframe] IESG Eval followup: config-signaling anf rtp-raptor >=20 > Hi Rajiv, >=20 > Can you get a new revision published as Informational please? >=20 > Here is an issue you really need to address in the document: > "To make this actionable I suggest you work out very clearly what the > purpose of > the document is and capture that both in the Abstract and the > Introduction. It > would also help if you clearly defined what *you* mean by a signaling > protocol > because people at different layers of the stack have very different > understandings of the term." >=20 > There are a number of other discusses that need to be addressed. >=20 > If you get a revision to me by the end of February, I can run it through > the system again and hopefully get it into the RFC Editor before I step > down as AD in March. You really don't want to start over with a new AD. >=20 > Thanks, >=20 > -- > David Harrington > Director, Transport Area > Internet Engineering Task Force (IETF) > Ietfdbh@comcast.net > +1-603-828-1401 >=20 >=20 >=20 >=20 >=20 > On 1/20/12 12:46 PM, "Rajiv Asati (rajiva)" wrote: >=20 > >Informational is fine. > > > >Cheers, > >Rajiv > > > >> -----Original Message----- > >> From: Greg Shepherd [mailto:gjshep@gmail.com] > >> Sent: Friday, November 04, 2011 10:30 AM > >> To: Rajiv Asati (rajiva); fecframe@ietf.org > >> Subject: Fwd: IESG Eval followup: config-signaling anf rtp-raptor > >> > >> *, > >> > >> There are a few things holding up the config-sig draft, but the one we > >> need to help with is: > >> > >> MUST this doc progress as experimental, or is there WG consensus to > >> move it to informational? > >> > >> Please reply promptly to the list. > >> > >> Thanks!, > >> Greg > >> > >> > >> ---------- Forwarded message ---------- > >> From: David Harrington > >> Date: Fri, Nov 4, 2011 at 7:23 AM > >> Subject: IESG Eval followup: config-signaling anf rtp-raptor > >> To: gjshep@gmail.com > >> Cc: draft-ietf-fecframe-config-signaling@tools.ietf.org, > >> draft-ietf-fecframe-rtp-raptor@tools.ietf.org > >> > >> > >> Hi, > >> > >> The IESG reviewed the config signaling and rtp-raptor drafts. > >> We have work to do. > >> > >> config-signaling: > >> 1) Can we publish this as Informational? > >> Is that a problem for any cross-SDO work? > >> If this is published as Informational, then compliance is no > >> longer appropriate - you don't comply to an Informational document. so > >> the RFC2119 keywords should disappear. > >> > >> 2) Ask the WG which version of GDOI is supposed to be used? See Sean's > >> Comments. > >> > >> 3) The document needs a good rewrite, especialy the Abstract and > >> Introduction. There are Discusses and Comments from many that the > >> document doesn't describe its purpose. This must be clairified. > >> > >> 4) There are Discusses and Comments from multiple ADs that must be > >> addressed: > >> Ron: just remove the reference; I don't know if you want to carry any > >> information from that expired mboned doc into this doc. > >> Adrian: clarify what is considered a signaling protocol in this doc > >> Gonzalo: no RFC2119 keywords in the Introduction (so normative text > >> must be moved) > >> Jari: internal references (are you using xml2rfc? they have ways to > >> keep that in sync for you) > >> clarify how you expect this to be used re: SDP, XML, etc. > >> Russ: Gen-ART review > >> Sean: "MAY encrypt" > >> MUST is for implementers - see RFC 3365 - unless this is > >> Informational. > >> GDOI - explain how to use this. Clarify which version. > >> Stephen: "MAY encrypt" =3D> "SHOULD encrypt using PGP or CMS"? > >> GDOI - how to use to manage keys? > >> Pete: If Informational, then you can ignore his comment; If > >> Experimental, then describe the experiment. > >> Robert: new versus copied requirements; point to the existing rules > >> rather than copying them here. > >> The #2 comment is critical - are implementers supposed to > >> choose from one of these protocols > >> (i.e., these are the only ones allowed in a compliant > >> Experimental implementation?) > >> > >> rpt-raptor: > >> 1) A registration request must be sent to ietf-types@iana.org to > >> register the types, per section 5.1 of RFC 4288. The registration > >> template needs to be filled in > >> > >> 2) There are discusses from Sean, Pete, Robert and Stephen that must > >> be addressed, and Comments from Russ (the Gen-ART review) that should > >> be addressed in a Revised ID. I think the usage of RFC2119 keywords is > >> acceptable, but might be improved. Please read and **consider** Pete's > >> comments on RFC2119 usage, and then do what you think is right. > >> > >> Please get these Revised IDs done asap so I can send them off to the > >> RFC Editor. > >> > >> David Harrington > >> Director, IETF Transport Area > >> ietfdbh@comcast.net (preferred for ietf) > >> dbharrington@huaweisymantec.com > >> +1 603 828 1401 (cell) > >_______________________________________________ > >Fecframe mailing list > >Fecframe@ietf.org > >https://www.ietf.org/mailman/listinfo/fecframe >=20 From internet-drafts@ietf.org Tue Feb 21 14:55:45 2012 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 991AA11E80F5; Tue, 21 Feb 2012 14:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 8cs5IHk4xUPO; Tue, 21 Feb 2012 14:55:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD7011E80EE; Tue, 21 Feb 2012 14:55:22 -0800 (PST) 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.64p2 Message-ID: <20120221225522.2224.85312.idtracker@ietfa.amsl.com> Date: Tue, 21 Feb 2012 14:55:22 -0800 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action: draft-ietf-fecframe-config-signaling-07.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: Tue, 21 Feb 2012 22:55:45 -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 : Methods to convey FEC Framework Configuration Information Author(s) : Rajiv Asati Filename : draft-ietf-fecframe-config-signaling-07.txt Pages : 17 Date : 2012-02-21 FEC Framework document [RFC6363] defines the FEC Framework Configuration Information necessary for the FEC framework operation. This document describes using existing signaling protocols such as Session Announcement Protocol (SAP), Session Initiation Protocol (SIP), Real Time Stream Protocol (RTSP) etc. to determine and dynamically communicate the Configuration information between sender(s) and receiver(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-config-signaling-07= .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-config-signaling-07.= txt From ietfdbh@comcast.net Wed Feb 22 04:40:19 2012 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 E4AF121F86F9 for ; Wed, 22 Feb 2012 04:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.21 X-Spam-Level: X-Spam-Status: No, score=-102.21 tagged_above=-999 required=5 tests=[AWL=0.389, 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 3hD7mtsapWyx for ; Wed, 22 Feb 2012 04:40:14 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 989E321F85C2 for ; Wed, 22 Feb 2012 04:40:14 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta10.westchester.pa.mail.comcast.net with comcast id d0J51i00227AodY5A0gFv3; Wed, 22 Feb 2012 12:40:15 +0000 Received: from [192.168.1.33] ([71.233.85.150]) by omta19.westchester.pa.mail.comcast.net with comcast id d0gC1i00T3Ecudz3f0gC3j; Wed, 22 Feb 2012 12:40:15 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Wed, 22 Feb 2012 07:40:09 -0500 From: David Harrington To: "Rajiv Asati (rajiva)" , Greg Shepherd , Message-ID: Thread-Topic: [Fecframe] IESG Eval followup: config-signaling anf rtp-raptor In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C0778D2D6@XMB-RCD-111.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Fecframe] IESG Eval followup: config-signaling anf 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: Wed, 22 Feb 2012 12:40:20 -0000 Thank you. I'll follow-up. -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 2/21/12 5:45 PM, "Rajiv Asati (rajiva)" wrote: >Hi David, > >I have updated the document in accordance with the comments received so >far, and submitted the -07 version for us to make progress. > >1. Adrian Farrel: Comment (2011-11-03)::= Updated the abstract and >Introduction section. >2. Gonzalo Camarillo: Comment (2011-11-03)::= Removed the normative >language. >3. Jari Arkko: Comment (2011-11-03) ::= Corrected the sections >referencing and updated the Introduction >4. Ron Bonica: Discuss (2011-11-02) ::= Removed the reference to that >expired draft. >5. Russ Housley: Comment (2011-11-03)::= All accepted. Updated the >relevant text. >6. Stephen Farrell: Comment (2011-11-01::= Cryptography meant >encryption. Removed it as well as GDOI, and mentioned PGP. >7. Wesley Eddy: Discuss (2011-10-26) ::= Changed to Informational. >8. Pete Resnick: Discuss (2011-11-02) ::= Changed to Informational. >9. Robert Sparks: Discuss (2011-11-02)::=1. Added a para in section 5.1 >to clarify this. 2. Not a complete list. >10. Robert Sparks: Comment (2011-11-02)::= Changed to Informational. >11. Sean Turner: Discuss (2011-11-02)::= Yes. Added PGP preference. >12. Sean Turner: Comment (2011-11-02)::= Yes, meant to say encryption. >Removed cryptography and references to GDOI altogether. > >Cheers, >Rajiv > >> -----Original Message----- >> From: David Harrington [mailto:ietfdbh@comcast.net] >> Sent: Tuesday, February 21, 2012 8:38 AM >> To: Rajiv Asati (rajiva); Greg Shepherd; fecframe@ietf.org >> Subject: Re: [Fecframe] IESG Eval followup: config-signaling anf >rtp-raptor >> >> Hi Rajiv, >> >> Can you get a new revision published as Informational please? >> >> Here is an issue you really need to address in the document: >> "To make this actionable I suggest you work out very clearly what the >> purpose of >> the document is and capture that both in the Abstract and the >> Introduction. It >> would also help if you clearly defined what *you* mean by a signaling >> protocol >> because people at different layers of the stack have very different >> understandings of the term." >> >> There are a number of other discusses that need to be addressed. >> >> If you get a revision to me by the end of February, I can run it >through >> the system again and hopefully get it into the RFC Editor before I >step >> down as AD in March. You really don't want to start over with a new >AD. >> >> Thanks, >> >> -- >> David Harrington >> Director, Transport Area >> Internet Engineering Task Force (IETF) >> Ietfdbh@comcast.net >> +1-603-828-1401 >> >> >> >> >> >> On 1/20/12 12:46 PM, "Rajiv Asati (rajiva)" wrote: >> >> >Informational is fine. >> > >> >Cheers, >> >Rajiv >> > >> >> -----Original Message----- >> >> From: Greg Shepherd [mailto:gjshep@gmail.com] >> >> Sent: Friday, November 04, 2011 10:30 AM >> >> To: Rajiv Asati (rajiva); fecframe@ietf.org >> >> Subject: Fwd: IESG Eval followup: config-signaling anf rtp-raptor >> >> >> >> *, >> >> >> >> There are a few things holding up the config-sig draft, but the one >we >> >> need to help with is: >> >> >> >> MUST this doc progress as experimental, or is there WG consensus to >> >> move it to informational? >> >> >> >> Please reply promptly to the list. >> >> >> >> Thanks!, >> >> Greg >> >> >> >> >> >> ---------- Forwarded message ---------- >> >> From: David Harrington >> >> Date: Fri, Nov 4, 2011 at 7:23 AM >> >> Subject: IESG Eval followup: config-signaling anf rtp-raptor >> >> To: gjshep@gmail.com >> >> Cc: draft-ietf-fecframe-config-signaling@tools.ietf.org, >> >> draft-ietf-fecframe-rtp-raptor@tools.ietf.org >> >> >> >> >> >> Hi, >> >> >> >> The IESG reviewed the config signaling and rtp-raptor drafts. >> >> We have work to do. >> >> >> >> config-signaling: >> >> 1) Can we publish this as Informational? >> >> Is that a problem for any cross-SDO work? >> >> If this is published as Informational, then compliance is no >> >> longer appropriate - you don't comply to an Informational document. >so >> >> the RFC2119 keywords should disappear. >> >> >> >> 2) Ask the WG which version of GDOI is supposed to be used? See >Sean's >> >> Comments. >> >> >> >> 3) The document needs a good rewrite, especialy the Abstract and >> >> Introduction. There are Discusses and Comments from many that the >> >> document doesn't describe its purpose. This must be clairified. >> >> >> >> 4) There are Discusses and Comments from multiple ADs that must be >> >> addressed: >> >> Ron: just remove the reference; I don't know if you want to carry >any >> >> information from that expired mboned doc into this doc. >> >> Adrian: clarify what is considered a signaling protocol in this doc >> >> Gonzalo: no RFC2119 keywords in the Introduction (so normative text >> >> must be moved) >> >> Jari: internal references (are you using xml2rfc? they have ways to >> >> keep that in sync for you) >> >> clarify how you expect this to be used re: SDP, XML, etc. >> >> Russ: Gen-ART review >> >> Sean: "MAY encrypt" >> >> MUST is for implementers - see RFC 3365 - unless this is >> >> Informational. >> >> GDOI - explain how to use this. Clarify which version. >> >> Stephen: "MAY encrypt" => "SHOULD encrypt using PGP or CMS"? >> >> GDOI - how to use to manage keys? >> >> Pete: If Informational, then you can ignore his comment; If >> >> Experimental, then describe the experiment. >> >> Robert: new versus copied requirements; point to the existing rules >> >> rather than copying them here. >> >> The #2 comment is critical - are implementers supposed to >> >> choose from one of these protocols >> >> (i.e., these are the only ones allowed in a compliant >> >> Experimental implementation?) >> >> >> >> rpt-raptor: >> >> 1) A registration request must be sent to ietf-types@iana.org to >> >> register the types, per section 5.1 of RFC 4288. The registration >> >> template needs to be filled in >> >> >> >> 2) There are discusses from Sean, Pete, Robert and Stephen that >must >> >> be addressed, and Comments from Russ (the Gen-ART review) that >should >> >> be addressed in a Revised ID. I think the usage of RFC2119 keywords >is >> >> acceptable, but might be improved. Please read and **consider** >Pete's >> >> comments on RFC2119 usage, and then do what you think is right. >> >> >> >> Please get these Revised IDs done asap so I can send them off to >the >> >> RFC Editor. >> >> >> >> David Harrington >> >> Director, IETF Transport Area >> >> ietfdbh@comcast.net (preferred for ietf) >> >> dbharrington@huaweisymantec.com >> >> +1 603 828 1401 (cell) >> >_______________________________________________ >> >Fecframe mailing list >> >Fecframe@ietf.org >> >https://www.ietf.org/mailman/listinfo/fecframe >> > From internet-drafts@ietf.org Fri Feb 24 05:27:32 2012 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 6A99221F8748; Fri, 24 Feb 2012 05:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 KNNsBZQaY8Ln; Fri, 24 Feb 2012 05:27:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A79921F862F; Fri, 24 Feb 2012 05:27:32 -0800 (PST) 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.64p2 Message-ID: <20120224132732.15074.26725.idtracker@ietfa.amsl.com> Date: Fri, 24 Feb 2012 05:27:32 -0800 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action: draft-ietf-fecframe-rtp-raptor-07.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: Fri, 24 Feb 2012 13:27:32 -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 Michael Luby Filename : draft-ietf-fecframe-rtp-raptor-07.txt Pages : 25 Date : 2012-02-24 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-07.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-07.txt From stockhammer@nomor.de Fri Feb 24 05:35:47 2012 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 20BB521F86E3 for ; Fri, 24 Feb 2012 05:35:47 -0800 (PST) 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 EfPlx4pg92FX for ; Fri, 24 Feb 2012 05:35:45 -0800 (PST) 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 CCC6921F879D for ; Fri, 24 Feb 2012 05:35:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330090540; l=6466; 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=QrprUo6T87gsdGarr99WuqAOhi8=; b=jMnCiUuB9966U/TO+1Ez6sVQLr/1wzHEvzYKVXhwdzBflq8yS8Lm62OJVFQx9xxxmvq NAlBMXfs5chiWphjRdbZwJlnpOIVnlTlFEQw62I26BfVLGv23Gn2kh/UaQtRu0TZWgjmq lXQ4xwXXuIHUxD0qLdQaqV0Yoe8Np6N2AT0= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu13+UwGfuMVAY1fXI1g9SU= X-RZG-CLASS-ID: mo00 Received: from [10.4.192.49] ([93.104.202.244]) by smtp.strato.de (jimi mo41) (RZmta 27.7 AUTH) with ESMTPA id i01f80o1OCdslE ; Fri, 24 Feb 2012 14:35:23 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Thomas Stockhammer In-Reply-To: <965B818A89DA4E01B31C55CDC3294861@davidPC> Date: Fri, 24 Feb 2012 14:35:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <46031464-78F5-4B08-B0C4-9A59CFAF8E5D@nomor.de> References: <20111029191259.724.29067.idtracker@ietfa.amsl.com> <843F8E40A07840AFA61B3C3944F5D7FA@davidPC> <4EB2356B.1060801@qualcomm.com> <4ED049F2.2030306@qualcomm.com> <6FF946CE-A73E-42E6-A582-505D9AF0B01E@nomor.de> <1F1244790E67477DBA4BDBD8491B999A@davidPC> <965B818A89DA4E01B31C55CDC3294861@davidPC> To: David B Harrington , Pete Resnick X-Mailer: Apple Mail (2.1257) Cc: fecframe-chairs@tools.ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] Pete Resnick's Discuss on draft-ietf-fecframe-rtp-raptor-05: (withDISCUSS and COMMENT) 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: Fri, 24 Feb 2012 13:35:47 -0000 Dave, Pete, I have uploaded a new version. = http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-raptor-07.txt Inline how the comments had been addressed: > In section 10.3, please consider explaining when you would not follow > "SHOULD be sent in a separate RTP session" - give guidance on when a > single > session is appropriate. Likewise, why is using CNAME to associate the > sessions > only a MAY? Unless there are strong reasons to define and use an > alternative > mechanism, this would be better off as a MUST. [T] This has been changed as follows: "If the repair RTP session is sent in a separate RTP session the two = sessions MUST be associated using RTCP CNAME." The association of repair and source RTP session is not part of the RTCP = usage, so this recommendation is removed. The choice of whether running this in the same session of in separate = session is really deployment specific.=20 However, if they are in different sessions, then for association the = usage of the same RTCP CNAME is mandated. > and update the document to not use RFC2119 langauge in the template > section. [T] This addresses the DISCUSS from Pete. The new text does not include = any RFC2119 language. "The default value of this parameter (when it does not appear = explicitly) is 'A'." Please let me know if this covers all the remaining concerns. Thanks Thomas >=20 > Once we hear from avtcore, you can cut a new revision. >=20 > thanks, > dbh >=20 >=20 >> -----Original Message----- >> From: David Harrington [mailto:ietfdbh@comcast.net]=20 >> Sent: Monday, December 05, 2011 10:49 PM >> To: 'Thomas Stockhammer' >> Cc: fecframe-chairs@tools.ietf.org >> Subject: RE: Pete Resnick's Discuss on=20 >> draft-ietf-fecframe-rtp-raptor-05: (withDISCUSS and COMMENT) >>=20 >> Hi, >>=20 >> Please change the text in the template sections to not use RFC2119 >> language.=20 >> Pete suggests: >> "The default value of this parameter (when it does not appear >> explicitly) is 'A'." >> I think that is sufficiently clear. >>=20 >> You can make sure the text elsewhere shows this "A" default is a >> normative requirement, using rfc2119 language. >>=20 >> Please publish another revision with this fix, so we can move > forward. >>=20 >> I have asked Robert to check the current revision and clear if he is >> satisfied; you might want to wait a couple days to see if he wants > any >> further changes made. >>=20 >> Thanks, >> David Harrington >> Director, IETF Transport Area >> ietfdbh@comcast.net (preferred for ietf) >> dbharrington@huaweisymantec.com >> +1 603 828 1401 (cell) >>=20 >>> -----Original Message----- >>> From: Thomas Stockhammer [mailto:stockhammer@nomor.de]=20 >>> Sent: Monday, November 28, 2011 1:12 AM >>> To: Pete Resnick >>> Cc: draft-ietf-fecframe-rtp-raptor@tools.ietf.org;=20 >>> fecframe-chairs@tools.ietf.org; David Harrington; 'The IESG' >>> Subject: Re: Pete Resnick's Discuss on=20 >>> draft-ietf-fecframe-rtp-raptor-05: (withDISCUSS and COMMENT) >>>=20 >>> Pete, >>>=20 >>> inline comments on the comments resolution =85 >>>=20 >>>>>>>> Specific problems: >>>>>>>>=20 >>>>>>>> Section 3: "MAY" is not appropriate here. You're not > defining >>>>>>>> a protocol option; you're saying that repair packets can be >>>>>>>> generated. >>>>>>>>=20 >>>>> [T] To avoid the may here it says now: >>>>> "The Raptor and RaptorQ codes are efficient block-based=20 >>> fountain codes, meaning that from any group of source packets=20 >>> (or 'source block') an one can generate an arbitrary number=20 >>> of repair packets." >>>>>=20 >>>>=20 >>>> Works for me (though there seems to be a typo in=20 >>>=20 >>> [T] Thanks! Typo fixed! >>>=20 >>>>=20 >>>>>> I must say that, try though I might, I can't understand=20 >>> how an implementer might choose to decide that a marker bit=20 >>> of 0 means last packet and 1 means otherwise. That one sounds=20 >>> like a definition of the bit, not anything that can be an=20 >>> implementation choice that requires a 2119 requirement. >>>>>>=20 >>>>> [T] I understand the comment from Pete that this may also=20 >>> be interpreted as a definition. But still it is expected that=20 >>> the bit is set accordingly and the implementation can write=20 >>> code to identify the last packet in the source block and set=20 >>> the marker bit to 1. So I would prefer to stick with the SHALL > here. >>>>>=20 >>>>=20 >>>> I still disagree, but it sounds like I'm "in the rough"=20 >>> part of the consensus. :-) >>>=20 >>> [T] See other discussion, I am still trying to understand the=20 >>> exact issue. >>>=20 >>>>> I don't think you can use this payload format for anything=20 >>> different than Raptor and RaptorQ, at least this is not=20 >>> considered. It is also the case that different media codecs=20 >>> generally each defines different payload formats unless the=20 >>> payload formats are generic. I would assume the same applies=20 >>> here and this is mostly because we know that it works with=20 >>> Raptor and RaptorQ, but we do not know if it works with=20 >>> anything different. >>>>>=20 >>>>> I left the second "SHALL" because this is what an=20 >>> implementor is expected to do. To create an RTP payload that=20 >>> contains FEC Repair Payloads. >>>>>=20 >>>>=20 >>>> (*Shrug*) I don't think it's necessary. >>>=20 >>> [T] Still not sure what would be the appropriate text then?=20 >>> Is it not mandated that the implementor implements the=20 >>> normative parts of the two docs? >>>=20 >>> Thomas >>>=20 >>> --- >>> Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone=20 >>> +49 89 978980 02 || cell +491725702667 ||=20 >>> http://www.nomor-research.com >>> Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen -=20 >>> Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID:=20 >>> DE238047637 - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr.=20 >>> Ingo Viering. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >=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 internet-drafts@ietf.org Fri Feb 24 14:42:15 2012 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 80E8821F8755; Fri, 24 Feb 2012 14:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 5P1gQ7LQ-iql; Fri, 24 Feb 2012 14:42:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D9621F873A; Fri, 24 Feb 2012 14:42:13 -0800 (PST) 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.64p2 Message-ID: <20120224224213.9715.95620.idtracker@ietfa.amsl.com> Date: Fri, 24 Feb 2012 14:42:13 -0800 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action: draft-ietf-fecframe-raptor-08.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: Fri, 24 Feb 2012 22:42:15 -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 : Raptor FEC Schemes for FECFRAME Author(s) : Mark Watson Thomas Stockhammer Michael Luby Filename : draft-ietf-fecframe-raptor-08.txt Pages : 22 Date : 2012-02-24 This document describes Fully-Specified Forward Error Correction (FEC) Schemes for the Raptor and RaptorQ codes and their application to reliable delivery of media streams in the context of FEC Framework. The Raptor and RaptorQ codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. The Raptor and RaptorQ codes offer close to optimal protection against arbitrary packet losses at a low computational complexity. Six FEC Schemes are defined, two for protection of arbitrary packet flows, two that are optimised for small source blocks and another two for protection of a single flow that already contains a sequence number. Repair data may be sent over arbitrary datagram transport (e.g. UDP) or using RTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-raptor-08.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-raptor-08.txt From stockhammer@nomor.de Fri Feb 24 14:43:32 2012 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 7322721F8744 for ; Fri, 24 Feb 2012 14:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_17=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 M+zTQN-xV37J for ; Fri, 24 Feb 2012 14:43:31 -0800 (PST) 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 C950621F873A for ; Fri, 24 Feb 2012 14:43:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330123403; l=9141; 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=hG4tmzuerGvcp6GFpN26eHaYBUI=; b=cfPedBweKw8Jeg1ZpdF+2w6g+oVtdPzV9JRzfqoIeZ4MvDeql78Fo5Fau8qvStxOaO0 wC7Ym3E1LGBCWhkiQaNwnfYhDzK5iqBI+SEYvs2CgHVdhtiVIUoCdZci6PHhpij/7wFiK hFEnmw59gibxez08zGDYGaxAV/ODQ8vxA3E= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu1/8loZf+4JHTB1Efz/7Ks9 X-RZG-CLASS-ID: mo00 Received: from [192.168.1.4] (188-192-154-212-dynip.superkabel.de [188.192.154.212]) by smtp.strato.de (cohen mo35) (RZmta 27.7 DYNA|AUTH) with ESMTPA id a03d42o1OLrZ9f ; Fri, 24 Feb 2012 23:43:05 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Thomas Stockhammer In-Reply-To: <4D77BA6BE9584BEA8AA3114C03CB834A@davidPC> Date: Fri, 24 Feb 2012 23:43:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D77BA6BE9584BEA8AA3114C03CB834A@davidPC> To: David Harrington X-Mailer: Apple Mail (2.1257) Cc: draft-ietf-fecframe-raptor@tools.ietf.org, fecframe-chairs@tools.ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] AD review draft-ietf-fecframe-raptor-07 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: Fri, 24 Feb 2012 22:43:32 -0000 Dave, all, great comments! Thanks! a new draft has been submitted addressing the comments as document = inline. http://www.ietf.org/internet-drafts/draft-ietf-fecframe-raptor-08.txt > A slightly modified copy provided here:=20 > > AD review draft-ietf-fecframe-raptor >=20 > I have a number of concerns, mostly editorial. Please address these in > the > document and publish an updated ID. We are still waiting for the > updated IPR > disclosures from Qualcomm. It would be good if they were done against > the new > revision. >=20 > 3) It is unclear whether the definitions here are the normative > definitions, or > whether they are normatively defined elsewhere. I recommend a minor > change: > /This document uses the following definitions./This document uses the > following definitions from [RFC6363]./ > /This document uses the following abbreviations/This document uses the > following abbreviations from [RFC6363]/ [T] The definitions and abbreviations are normatively and in addition to = RFC6363. The new text is: "This document uses definitions that apply to FEC Framework in general = as defined in RFC6363. In addition, this document uses the following = definitions:" and the same for abbreviations > 4) this document and rtp-raptor share common introduction, but the > text differs > slightly. To make sure there are no inconsistencies that might impact > interpretation and interoperability, please use consistent wording in > both > documents. [T] The wording in the latest draft has been updated in the common = parts. > 5)no security considerations specific to this document have been > identified. I > hope you mean no security vulnerabilities specific to these FEC > schemes have > been identified. please fix. > in 9, /No security considerations/No security vulnerabilities/+ [T] done > 6) in 1, s/sends the repair packet(s) along with the source packets/ > sends the repair packets and the source packets/ >=20 > I recommend taking the first sentence of the next paragraph and move > it into > this bullet (what the sender must do). >=20 > Then take the remaining sentences in that paragraph (what the receiver > should > do) and make them a bullet. [T] done > 7) in 1 s/if referred to/is referred to/ [T] done > 8) in 2, you mention MBMSTS and dvbts as reference tokens. These are > acronyms. > Please spell them out on first use. [T] done > 9) for all acronyms, please expand on first usage. e,g,. SPI. [T] SPI was added to the acronyms. Further checking for acronyms done. > 10) in 6.2.1.1, 7.2.1.1, and 8.2.1.1, you say XXX and YYY as assigned > by IANA. > But aren't there actually 6 different values to be considered? please > use 6 > different variables for the RFC Editor to modify to the six > iana-assigned > values. New names are - XXX(RFC5053-ARBITRARY) - XXX(RFC6330-ARBITRARY) - XXX(RFC5053-OPTIMISED) - XXX(RFC6330-OPTIMISED) - XXX(RFC5053-SINGLE) - XXX(RFC6330-SINGLE) > 11) in figure 1, you use a P-bit, which could be confused with > P=3Dpadding. Since > it represents the format, why not use a bit identified by something > that isn't > already used in FEC documentation? > If the payload ID format name is signaled by P=3D0 or P=3D1, and = neither > "A" nor "B" > fit into a bit, then why not call them format 0 (where P-bit=3D0) and > format 1 > (where Pbit=3D1)? or simply say in the text "when P=3D=3D0" or "P=3D=3D1= " or "P > is false" > or "P is true"? why introduce an extra set of variable names to keep > track of? [T] Despite this may be a good idea, this signaling is also used in = other documents and it would be confusing to rename and change syntax = and semantics now. I would only apply this if it is really considered a = bug. =20 > 12) in 6.2.1.2 you say maximum source block size is known as Kmax, but > in 7.3.2, > you use MSBL in your calculations. and elsewhere you use SBL for > source block > length. Why even bother mentioning Kmax if MSBL works fine? [T] I understand the confusion, but MSBL and Kmax are different. MSBL is = a restriction for this scheme. Kmax is a restriction for the codes = itself in RFC5053 and RFC6330. The text has been updated accordingly.=20 > 13) in 5, ADUI[i] is the concatenation of FLRP, but the text has them > in RLFP > order. Any reason to not be consistent? If the terms were in > alphabetic order or > something, I'd understand. If the order is important for calculation > order, then > why not concatenate them in the same order? [T] The order has been changed on the text. > 14) in 6.2.1.2, "of the above" - I'm not sure what thing "the above" > refers to. > Please be more specific. [T] It is now explicitly referred to "FEC Scheme Specific Information" > 15) is the payload ID format identifier the same as the P-bit? Is the > format > signaled in the FEC Framework Configuration Information (section > 6.2.2) the same > as the P-bit? [T] Yes, this is more explicit now. > 16) 6.2.2 defines two formats, but never explains why two formats are > needed.=20 [T] This explanation is added to section 6.2.2: "The two formats enable different use cases. Format A is appropriate in = case the stream has many typically smaller source blocks and Format B is = applicable if the stream has fewer large source blocks each with many = encoding symbols." > 17) 6.2.3, undef figure 5, whcih depicts format B, you have text that > says "for > format A, it is of size 16 bits. [T] Done! It is 8 bit and format B > 18) in 6.2.3, it says "the interpretation ... is defined by the FEC > Code > Specification. Where do I find the FEC Code specification? [T] Reference is now made to RFC 5053 and 6330. >=20 > 19) In 6.3.1, is "transport payload length" the length of the UDP or > RST packet? > or the length of the ADU payload? I tried to check this where l[i] is > defined, > but it said the scheme would tell me. [T] It is the ADU! This is clarified. > 20) the sentence conistruction in 6.3.3 is a little hard to parse; > could this be > rewritten? It might be a lot easier throughout the document if you > reduced the > "Raptor as defined in [RFC5052]" to just "Raptor [RFC5052]". [T] Done > For this particular paragraph, it might be better as: > "When using Raptor [RFC5053], ESI is calculated per [RFC5053] section > 5.3.2. > When using RaptorQ [I-D...], ESI is calculated per [I-D...] section > 4.4.2." [T] Done >=20 > It might be even easier if you used mneumonic references for Raptor > and RaptorQ: > When using [Raptor], ESI is calculated as per [Raptor] section 5.3.2. > When using [RaptorQ], ESI is calculated as per [RaptorQ] section > 4.4.2. [T] Done > 21) in 7.2.x.x, you have extra spaces and missing spaces. [T] Done > 22) in 8.1.3, the order of elements is ISN/ESI/SBL for format A, but > ISN/SBL/ESI > for format B; why not use a consistent order of elements, e.g. make > format B > ISN/ESI/SBL to match format A? [T] Done > 23) in 8.2.1, why does the SBN wrap occur at 65535 and 255? In section > 6 and 7, > this is constrained by the SBN field size. But section 8 uses ISN, not > SBN, and > ISN for both formats is 16 bit, so why the constraint? [T] Correct, I have removed this sentence as it does not apply there. >=20 > 24) in 8.2.2, parentheses would help differentiate I+(LB/LP)-1 from > I+LB/(LP-1). [T] Done > 25) Can LP ever be 0?=20 [T] No > 26) Can this ever yield a negative number? I=3D0, (LB/LP)=3D0? [T] Good question. The question is more if there can be cases where no = packets are included in the source block. or is LB always greater LP. This is added as a condition: The Source Block Length LB MUST be chosen = such that it is at least as large as the largest Source Packet = Information Length LP. > 27) are there any congestion control issues specific to these schemes? [T] No > 28) in 12, it says "this document registers three values ...", then > proceeds to > enumerate 6 values. [T] changed to 6 > should the even numbered ones be described as "the RaptorQ FEC scheme > for ..."? > rather than "the Raptor FEC scheme for ..., using raptorQ"? [T] changed! Great spotting! > 29) acknowldedgements - did anybody do a thorough review of the later > revisions > of the draft? [T] Yes, someone was added. > 30) id-nits shows some date-specific issues that need updating.=20 [T] Checked and updated > >=20 > 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 iesg-secretary@ietf.org Fri Feb 24 17:05:14 2012 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 5308321E801C; Fri, 24 Feb 2012 17:05:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 kvx9Gc4gwJUP; Fri, 24 Feb 2012 17:05:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2440C21E8027; Fri, 24 Feb 2012 17:05:13 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120225010513.7473.97428.idtracker@ietfa.amsl.com> Date: Fri, 24 Feb 2012 17:05:13 -0800 Cc: fecframe chair , fecframe mailing list , RFC Editor Subject: [Fecframe] Protocol Action: 'RTP Payload Format for Raptor FEC' to Proposed Standard (draft-ietf-fecframe-rtp-raptor-07.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: Sat, 25 Feb 2012 01:05:14 -0000 The IESG has approved the following document: - 'RTP Payload Format for Raptor FEC' (draft-ietf-fecframe-rtp-raptor-07.txt) as a Proposed Standard This document is the product of the FEC Framework 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-fecframe-rtp-raptor/ Technical Summary This document specifies an RTP payload format for Forward Error Correction / (FEC) 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. Working Group Summary There were no seriously contentious issues during the WG process. IETF Last Call ends 11/3, the requested date for a telechat. If there are substantive comments during IETF LC, I will push this to a later telechat. Document Quality The Working Group feedback covered both the quality of the document itself as well as the technical issues with the content of the document. Personnel Document Shepherd - Greg Shepherd Responsible Area Director - David Harrington RFC Editor Note 1) references need updating; fecframe-framework and fecframe-sdp-elements have been published. 2) in the Introduction s/MAY/might/g 3) in multiple places, the Controller should be the PAYLOAD WG rather than the AVT WG 4) some examples will be provided for "applications that use ..." From internet-drafts@ietf.org Sat Feb 25 20:49:36 2012 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 ACBFE21F857A; Sat, 25 Feb 2012 20:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 1k9rJf-xTEaS; Sat, 25 Feb 2012 20:49:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFBA21F856A; Sat, 25 Feb 2012 20:49:36 -0800 (PST) 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: 4.00 Message-ID: <20120226044936.22893.90567.idtracker@ietfa.amsl.com> Date: Sat, 25 Feb 2012 20:49:36 -0800 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action: draft-ietf-fecframe-config-signaling-08.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: Sun, 26 Feb 2012 04:49:36 -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 : Methods to convey FEC Framework Configuration Information Author(s) : Rajiv Asati Filename : draft-ietf-fecframe-config-signaling-08.txt Pages : 17 Date : 2012-02-25 FEC Framework document [RFC6363] defines the FEC Framework Configuration Information necessary for the FEC framework operation. This document describes how to use signaling protocols such as Session Announcement Protocol (SAP), Session Initiation Protocol (SIP), Real Time Stream Protocol (RTSP) etc. for determining and communicating the Configuration information between sender(s) and receiver(s). This document doesn't define any new signaling protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-config-signaling-08= .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-config-signaling-08.= txt From gjshep@gmail.com Mon Feb 27 12:28:43 2012 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 7FABA21F8794 for ; Mon, 27 Feb 2012 12:28:43 -0800 (PST) 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 70RmjBJaYn+7 for ; Mon, 27 Feb 2012 12:28:43 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C3FA421F86F9 for ; Mon, 27 Feb 2012 12:28:42 -0800 (PST) Received: by bkuw5 with SMTP id w5so912890bku.31 for ; Mon, 27 Feb 2012 12:28:41 -0800 (PST) Received-SPF: pass (google.com: domain of gjshep@gmail.com designates 10.205.119.136 as permitted sender) client-ip=10.205.119.136; Authentication-Results: mr.google.com; spf=pass (google.com: domain of gjshep@gmail.com designates 10.205.119.136 as permitted sender) smtp.mail=gjshep@gmail.com; dkim=pass header.i=gjshep@gmail.com Received: from mr.google.com ([10.205.119.136]) by 10.205.119.136 with SMTP id fu8mr7714083bkc.10.1330374521972 (num_hops = 1); Mon, 27 Feb 2012 12:28:41 -0800 (PST) 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=+tZsZrFCOz7/HH6EAxN+TscHWvbHMGO3pkZgCD+WX60=; b=QOUgA743wekyl42wUau3kCv/V2VRcSHFwyO5TNgdQuOMacAu37VCDv/zv/dVpDI0ay zkj454zqCXm6BxzW8xEGUWUDjkhna9OTq+GVsNlsrMoIWrYN+58y86/wmRY54BLMtrdQ gulQnepxnrYrcl2IIzt6ZXQ11U3UZdUBEsWkU= MIME-Version: 1.0 Received: by 10.205.119.136 with SMTP id fu8mr6171691bkc.10.1330374521903; Mon, 27 Feb 2012 12:28:41 -0800 (PST) Received: by 10.205.26.201 with HTTP; Mon, 27 Feb 2012 12:28:41 -0800 (PST) Date: Mon, 27 Feb 2012 12:28:41 -0800 Message-ID: From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Fecframe] draft-ietf-fecframe-pseudo-cdp WGLC 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, 27 Feb 2012 20:28:43 -0000 This starts a 2 week WGLC for Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in FEC Framework, draft-ietf-fecframe-pseudo-cdp-02: https://datatracker.ietf.org/doc/draft-ietf-fecframe-pseudo-cdp/ Please read and respond to the list. Thanks, Greg From gjshep@gmail.com Wed Feb 29 05:25:08 2012 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 2EE7D21F865C for ; Wed, 29 Feb 2012 05:25:08 -0800 (PST) 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 7hDgjVhS8zGK for ; Wed, 29 Feb 2012 05:25:07 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD6021F864B for ; Wed, 29 Feb 2012 05:25:07 -0800 (PST) Received: by bkuw5 with SMTP id w5so2828197bku.31 for ; Wed, 29 Feb 2012 05:25:04 -0800 (PST) Received-SPF: pass (google.com: domain of gjshep@gmail.com designates 10.204.133.204 as permitted sender) client-ip=10.204.133.204; Authentication-Results: mr.google.com; spf=pass (google.com: domain of gjshep@gmail.com designates 10.204.133.204 as permitted sender) smtp.mail=gjshep@gmail.com; dkim=pass header.i=gjshep@gmail.com Received: from mr.google.com ([10.204.133.204]) by 10.204.133.204 with SMTP id g12mr162053bkt.64.1330521904011 (num_hops = 1); Wed, 29 Feb 2012 05:25:04 -0800 (PST) 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=CT3M75Fu9BIcyCJnXbeQr3TLSRNMo6d55B8RyBo80q4=; b=PidAA6XfqOoD31OCoIQHxcYg9/izF/l05lAnTNJcuGdmengA/Wb0+RhWmDLQsr+vr6 RXlBIeqVfLv3zdo4seSBwY7rn3STUlv+SAxfiOHkto9xf3YOCLq1kFwKOi5vZ0Z/wlDj cUWGMSxe4KtPaZ2A1evZWOpDH9uJLIohkN+8E= MIME-Version: 1.0 Received: by 10.204.133.204 with SMTP id g12mr134295bkt.64.1330521903858; Wed, 29 Feb 2012 05:25:03 -0800 (PST) Received: by 10.205.26.201 with HTTP; Wed, 29 Feb 2012 05:25:03 -0800 (PST) Date: Wed, 29 Feb 2012 05:25:03 -0800 Message-ID: From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Fecframe] WGLC draft-ietf-fecframe-ldpc-01 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: Wed, 29 Feb 2012 13:25:08 -0000 This starts a two week timer for WGLC of draft-ietf-fecframe-ldpc-01. Please read and respond to the list. http://datatracker.ietf.org/doc/draft-ietf-fecframe-ldpc/ Thanks, Greg From gjshep@gmail.com Wed Feb 29 05:26:18 2012 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 CD35D21F8659 for ; Wed, 29 Feb 2012 05:26:18 -0800 (PST) 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 Q0ETeE4t2sE7 for ; Wed, 29 Feb 2012 05:26:18 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 28C8A21F865C for ; Wed, 29 Feb 2012 05:26:17 -0800 (PST) Received: by bkuw5 with SMTP id w5so2829748bku.31 for ; Wed, 29 Feb 2012 05:26:17 -0800 (PST) Received-SPF: pass (google.com: domain of gjshep@gmail.com designates 10.204.154.133 as permitted sender) client-ip=10.204.154.133; Authentication-Results: mr.google.com; spf=pass (google.com: domain of gjshep@gmail.com designates 10.204.154.133 as permitted sender) smtp.mail=gjshep@gmail.com; dkim=pass header.i=gjshep@gmail.com Received: from mr.google.com ([10.204.154.133]) by 10.204.154.133 with SMTP id o5mr131347bkw.100.1330521977373 (num_hops = 1); Wed, 29 Feb 2012 05:26:17 -0800 (PST) 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=xBlAxeMa7Zy2gndxSo+p+sB9TDEs//LgkD6lfLXC5UU=; b=Wj6kk9WXYhIBucxcZlUn++0x7C3tTv+g8K9nVhhs4PQCQSQsDvzVNJpNBy2e6Gq41d oyqJTh84OhJ1C8uSiAMLvBH1Qv4CfsgjhBBlj84RqD4NHs/ikwJzWKq7trUQAIHml0EI a/EEoh919EH3rd/tteTwGLPzbRsZcwENrKRR8= MIME-Version: 1.0 Received: by 10.204.154.133 with SMTP id o5mr108847bkw.100.1330521977296; Wed, 29 Feb 2012 05:26:17 -0800 (PST) Received: by 10.205.26.201 with HTTP; Wed, 29 Feb 2012 05:26:17 -0800 (PST) Date: Wed, 29 Feb 2012 05:26:17 -0800 Message-ID: From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Fecframe] WGLC draft-ietf-fecframe-simple-rs-02 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: Wed, 29 Feb 2012 13:26:18 -0000 This starts a two week timer for WGLC of draft-ietf-fecframe-simple-rs-02. Please read and respond to the list. http://datatracker.ietf.org/doc/draft-ietf-fecframe-simple-rs/ Thanks, Greg