From internet-drafts@ietf.org Thu Jun 9 07:19: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 B509311E809A; Thu, 9 Jun 2011 07:19:39 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3fMV6cGkXmA; Thu, 9 Jun 2011 07:19:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDAA11E808B; Thu, 9 Jun 2011 07:19:39 -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.55 Message-ID: <20110609141939.31966.26746.idtracker@ietfa.amsl.com> Date: Thu, 09 Jun 2011 07:19:39 -0700 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action: draft-ietf-fecframe-framework-15.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: Thu, 09 Jun 2011 14:19:39 -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 : Forward Error Correction (FEC) Framework Author(s) : Mark Watson Ali Begen Vincent Roca Filename : draft-ietf-fecframe-framework-15.txt Pages : 48 Date : 2011-06-09 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) which is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined which are not specific to a particular FEC scheme, and FEC schemes can be defined which are not specific to a particular Content Delivery Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-framework-15.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-framework-15.txt From vincent.roca@inrialpes.fr Thu Jun 9 07:23:46 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 026A311E80D2 for ; Thu, 9 Jun 2011 07:23:45 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXo+WNUpJCs5 for ; Thu, 9 Jun 2011 07:23:45 -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 BCACB11E80BA for ; Thu, 9 Jun 2011 07:23:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,341,1304287200"; d="scan'208";a="110815014" Received: from ral077r.vpn.inria.fr ([128.93.178.77]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 09 Jun 2011 16:23:42 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Vincent Roca In-Reply-To: <51848545-92E4-4230-A91D-18FC76CACD21@inrialpes.fr> Date: Thu, 9 Jun 2011 16:23:41 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <04CAD96D4C5A3D48B1919248A8FE0D540E6BFF29@xmb-sjc-215.amer.cisco.com> <6E6DD3D6F41C47A58CF034019CFBC63B@davidPC> <04CAD96D4C5A3D48B1919248A8FE0D540F0A7516@xmb-sjc-215.amer.cisco.com> <51848545-92E4-4230-A91D-18FC76CACD21@inrialpes.fr> To: David Harrington X-Mailer: Apple Mail (2.1084) Cc: fecframe@ietf.org Subject: Re: [Fecframe] FEC Framework DISCUSSes (was RE: Ops/Management Cons. text for fecframe) 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: Thu, 09 Jun 2011 14:23:46 -0000 David, all, We've just submitted a new -15 version that implements all the changed discussed last month. Cheers, Ali and Vincent NB: we've also been obliged to shorten certain lines of the figures (IDnits was complaining) From ietfdbh@comcast.net Tue Jun 14 10:26: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 8198811E8176 for ; Tue, 14 Jun 2011 10:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hG+nx4m3dAtu for ; Tue, 14 Jun 2011 10:26:05 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by ietfa.amsl.com (Postfix) with ESMTP id C4CDF11E8161 for ; Tue, 14 Jun 2011 10:26:05 -0700 (PDT) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta01.emeryville.ca.mail.comcast.net with comcast id vrvC1g0051u4NiLA1tS4S5; Tue, 14 Jun 2011 17:26:04 +0000 Received: from davidPC ([67.189.235.106]) by omta21.emeryville.ca.mail.comcast.net with comcast id vtRZ1g00Q2JQnJT8htRaX4; Tue, 14 Jun 2011 17:25:34 +0000 From: "David Harrington" To: Date: Tue, 14 Jun 2011 13:25:54 -0400 Message-ID: <3A9F1635A18F4A889D85B49EBCBCA331@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16776 Thread-index: AcwquB1U7vXF+rmpTd+bbfJ8R1GK+g== Subject: [Fecframe] Second Last Call for draft-ietf-fecframe-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: Tue, 14 Jun 2011 17:26:06 -0000 Hi, I have initiated a one-week second IETF last call on draft-ietf-fecframe-framework-15. The document underwent significant changes following AD and IESG review. Thanks go to the editors for the hard work involved in updating the draft. I believe all discusses are met by the new revision, but since many changes involved RFC2119 language, I want the community to have a chance to review the changes. The Last Call announcement should come out today or tomorrow on the IETF Discussion list. Please make any substantive comments following the directions in the announcement. Thanks, David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) From iesg-secretary@ietf.org Tue Jun 14 10:32:31 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 4196E11E818C; Tue, 14 Jun 2011 10:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZe6ytxV-Ckt; Tue, 14 Jun 2011 10:32:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA7111E813B; Tue, 14 Jun 2011 10:32:30 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110614173230.7027.2108.idtracker@ietfa.amsl.com> Date: Tue, 14 Jun 2011 10:32:30 -0700 Cc: fecframe@ietf.org Subject: [Fecframe] Last Call: (Forward Error Correction (FEC) Framework) 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: Tue, 14 Jun 2011 17:32:31 -0000 The IESG has received a request from the FEC Framework WG (fecframe) to consider the following document: - 'Forward Error Correction (FEC) Framework' as a Proposed Standard The IESG reviewed this draft and requested substantial changes. This is a second Last Call, running for one week, to ensure the community has an opportunity to review the changes. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-22. 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 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) which is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined which are not specific to a particular FEC scheme, and FEC schemes can be defined which are not specific to a particular Content Delivery Protocol. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ No IPR declarations have been submitted directly on this I-D. From ietfdbh@comcast.net Tue Jun 14 16:25:58 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 E6E3C11E80DF for ; Tue, 14 Jun 2011 16:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-R4ZgDXwk+U for ; Tue, 14 Jun 2011 16:25:57 -0700 (PDT) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by ietfa.amsl.com (Postfix) with ESMTP id AD334228009 for ; Tue, 14 Jun 2011 16:25:57 -0700 (PDT) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta04.emeryville.ca.mail.comcast.net with comcast id vzJo1g00316AWCUA4zRvUJ; Tue, 14 Jun 2011 23:25:55 +0000 Received: from davidPC ([67.189.235.106]) by omta06.emeryville.ca.mail.comcast.net with comcast id vzRq1g0172JQnJT8SzRtLF; Tue, 14 Jun 2011 23:25:54 +0000 From: "David Harrington" To: Date: Tue, 14 Jun 2011 19:25:42 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16776 Thread-index: Acwq6mDxIEr5gEpsTC+B267OV0N9fg== Cc: fecframe@ietf.org Subject: [Fecframe] frameowrk ops and mgmt 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, 14 Jun 2011 23:25:59 -0000 Hi, I don't know why, but I never received the message sent by Vincent on 5/18. I am pretty satisfied with the latest rev. Vincent raised some questions. Here is my thinking on these, preceded by DBH> > 3) * syslog is standardized in RFC 5424, so we probably need to refer to this RFC, and similarly we need to refer to RFC 3411 for SNMP. Since implementing/using one of these protocols is RECOMMENDED, these references should go to the Normative References section (both are Standards Track documents, so there's no downward ref issue here). DBH> I think informative is fine. The recommendation is to use standard protocols, and syslog and snmp are just examples of standardized protocols. Having this recommendation increases the likelihood that implementers will choose one of these examples, increasing the likelihood of interoperability. * Is that sufficient to increase the probability that independent products interoperate? No, we need to go a bit further and define SNMP notification/syslog message formats. So the followup should be to start defining a MIB... Unless the implementer chooses an in-band, RTCP based, approach, which already includes useful information from the FECFRAME point of view. DBH> The WG has argued that the use cases are so varied that a single solution wouldn't work. You guys are the experts on this environment, so I need to accept that such is the case. But, I don't buy into the argument that ops and mgmt is out of scope as a result. Some environments can use in-band mechanisms such as RTCP; that's great. Some environments are better suited to out-of-band. Network management applications that work with syslog and/or snmp typically support proprietary data models as well as standard data models. So an operator can use their existing syslog and/or snmp tools to access provided feedback, even if the provided mib objects or syslog messages are proprietary. Would I rather see some standardization of the data models? sure, because that would be even better for operators. But if the environments really are that different, then it may not be possible to have one MIB module to represent them all. Maybe we need multiple MIB modules to support multiple use cases. At least with the recommendation of using standardized mgmt protocols, such as syslog or snmp, it is more likely that implementers will develop MIB modules and/or syslog messages that operators can access, rather than providing nothing. * We RECOMMEND two different out-of-band solutions, which creates interoperability risks. DBH> There are different types of interoperability. Management often has a different perspective on interoperability than lower-layer protocols. Operators use a variety of tools to monitor/manage their networks. Which tools they use depends on the task they are trying to perform (and what's available). An operator might use syslog to monitor logged information, maybe to determine the cause of a fault on a device. An operator might use SNMP to monitor their whole network, using an NMS with pretty colored icons of devices, etc., because SNMP is good for periodic polling of statistics (and testing reachability). SNMP can also be used as a troubleshooting tool, because it gives access to information (when provided) such as configuration parameters. It's a good state-query tool. SNMP notifications can be used to alert operators to significant events. Each of these tools can be useful to operators, but an operator can only use it if implementers support them in their implementations. As an operator, what I most care about is that the information is provided somehow so I can monitor the system and debug network problems using available tools - even if I have to write the tools. * As I understand, mappings exist between the syslog/SNMP solution: RFC 5675 explains how to map SNMP notifications to syslog messages, while RFC 5676 discusses the opposite mapping. I don't know if these mappings are common or not, but this may also increase the probability that different products interoperate. So we can perhaps add a third sentence: When required, a mapping mechanism between the syslog and SNMP reporting mechanisms COULD be used, as described in [RFC5675] and [RFC5676]. DBH> I'm OK with this text, even though I think it is unnecessary. Whether an implementation provides the information I need as a MIB or syslog messages or via a web server on the device is less important than having the information available somehow. Operators frequently use shell scripts to customize their management. It is certainly helpful if the access mechanism is standardized, such as syslog or snmp or http/html, since a variety of available tools support these standardized mechanisms. And many syslog or snmp tools have command-line versions available that work well with shell scripting. The ability to integrate with existing shell-scripted in-house tools and with other applications is where using standardized management **protocols** is really helpful to operators. * So the followup should be to start defining a MIB... DBH> A standardized data model for the information can certainly be helpful, so an operator can do direct comparison across devices to uncover anomalies. But different environments (including different vendor designs of devices, or different use cases) may demand different data models. Sometimes it takes experience with a new technology to understand the best way to model it and manage it. There are good reasons why many standard MIB modules never get implemented - often a proprietary model can better model the specific device or use case. It is common for NMS applications to model their network using databases, often based on an open source implementation like MySQL, or a commercial database like Oracle. Then they have a mapping table between OIDs and their database objects. They use SNMP to query the standard or proprietary MIB object by OID, extract the value, and then store the value in a field in their own database format, translating the type if necessary. It really doesn't matter to many NMS applications whether the MIB module is standard or proprietary as long as they know the vendor-specific OID to query for a particular piece of information, and how to massage the value to fit their database model. And operators can write scripts to massage the information from command line tools into the format they want. The benefit of standard data models to operators is they wouldn't necessarily need to write a script for each new device model if more devices used standard MIBs; the published documentation for standard MIBs tends to be better, more up-to-date, and more publicly available than those for proprietary MIBs; and more off-the-shelf applications already support the standard MIBs. (The same is true to varying degrees for syslog and other standard protocols, whether IETF or not.) David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) From ietfdbh@comcast.net Wed Jun 15 06:32:15 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 F30AB11E8135 for ; Wed, 15 Jun 2011 06:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eg-Ixq3lU2y for ; Wed, 15 Jun 2011 06:32:14 -0700 (PDT) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by ietfa.amsl.com (Postfix) with ESMTP id 72B9D11E8126 for ; Wed, 15 Jun 2011 06:32:14 -0700 (PDT) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta11.emeryville.ca.mail.comcast.net with comcast id wCwS1g0061u4NiLABDYCyu; Wed, 15 Jun 2011 13:32:12 +0000 Received: from davidPC ([67.189.235.106]) by omta21.emeryville.ca.mail.comcast.net with comcast id wDXX1g00B2JQnJT8hDXdQY; Wed, 15 Jun 2011 13:31:40 +0000 From: "David Harrington" To: , "'Transport Directorate'" Date: Wed, 15 Jun 2011 09:31:53 -0400 Message-ID: <74597C0D9E6240B093FC18D88F27F846@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16776 Thread-index: AcwquRXNER3LevDoQf+0FcjfPZqa0QAp3LPw Subject: [Fecframe] FW: Last Call: (Forward Error Correction (FEC) Framework) 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: Wed, 15 Jun 2011 13:32:15 -0000 -----Original Message----- From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of The IESG Sent: Tuesday, June 14, 2011 1:33 PM To: IETF-Announce Cc: fecframe@ietf.org Subject: [Fecframe] Last Call: (Forward Error Correction (FEC) Framework) to Proposed Standard The IESG has received a request from the FEC Framework WG (fecframe) to consider the following document: - 'Forward Error Correction (FEC) Framework' as a Proposed Standard The IESG reviewed this draft and requested substantial changes. This is a second Last Call, running for one week, to ensure the community has an opportunity to review the changes. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-22. 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 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) which is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined which are not specific to a particular FEC scheme, and FEC schemes can be defined which are not specific to a particular Content Delivery Protocol. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ 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 ietfdbh@comcast.net Thu Jun 23 15:04: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 9904721F859B for ; Thu, 23 Jun 2011 15:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-BgHI0Gc1z7 for ; Thu, 23 Jun 2011 15:04:35 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id E908C21F859E for ; Thu, 23 Jun 2011 15:04:34 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta08.westchester.pa.mail.comcast.net with comcast id zZzW1g0011uE5Es58a4bq8; Thu, 23 Jun 2011 22:04:35 +0000 Received: from davidPC ([67.189.235.106]) by omta16.westchester.pa.mail.comcast.net with comcast id za4Y1g00D2JQnJT3ca4Ydx; Thu, 23 Jun 2011 22:04:33 +0000 From: "David Harrington" To: "'IESG Secretary'" Date: Thu, 23 Jun 2011 18:04:31 -0400 Message-ID: <37A1884EA51141D49AF56124986EED37@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16807 Thread-Index: Acwx8YcxFO1QqNnkQ5KV3EJm0gH3mQ== Cc: fecframe@ietf.org Subject: [Fecframe] Approved: draft-ietf-fecframe-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: Thu, 23 Jun 2011 22:04:35 -0000 Hi, This draft is approved. Thanks, David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) From iesg-secretary@ietf.org Fri Jun 24 09:52:33 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 AD65711E8163; Fri, 24 Jun 2011 09:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CE0muJJBzJZL; Fri, 24 Jun 2011 09:52:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CE711E8164; Fri, 24 Jun 2011 09:52:32 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110624165232.14388.51893.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2011 09:52:32 -0700 Cc: fecframe chair , fecframe mailing list , RFC Editor Subject: [Fecframe] Protocol Action: 'Forward Error Correction (FEC) Framework' to Proposed Standard (draft-ietf-fecframe-framework-15.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 Jun 2011 16:52:34 -0000 The IESG has approved the following document: - 'Forward Error Correction (FEC) Framework' (draft-ietf-fecframe-framework-15.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-framework/ Technical Summary 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 Forward Error Correction to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. Working Group Summary There were no seriously contentious issues during the WG process. 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 'The IANA Expert for the registries in this document is Ali C. Begen [abegen@cisco.com]