From abegen@cisco.com Mon May 10 15:41:47 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 345F33A68E9 for ; Mon, 10 May 2010 15:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.25 X-Spam-Level: X-Spam-Status: No, score=-10.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FftFwCjaSA6D for ; Mon, 10 May 2010 15:41:46 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id A0FEC3A68F2 for ; Mon, 10 May 2010 15:41:45 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwFAJYo6EurRN+J/2dsb2JhbACRYIxEcaIlmWOFFASDQQ X-IronPort-AV: E=Sophos;i="4.53,203,1272844800"; d="scan'208";a="255144401" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 10 May 2010 22:41:34 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o4AMfYcR029892; Mon, 10 May 2010 22:41:35 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 May 2010 15:41:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 May 2010 15:41:34 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540C0F128C@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: upcoming changes in norm requirement in RFC 4756bis: FEC-FR MUST, FEC SHOULD Thread-Index: AcrwWBe7R9+ekMBrQrq0r7UQ0MYWuAAOai/A From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 10 May 2010 22:41:34.0815 (UTC) FILETIME=[F19F3EF0:01CAF091] Cc: Jean-Francois Mule Subject: [Fecframe] FW: upcoming changes in norm requirement in RFC 4756bis: FEC-FR MUST, FEC SHOULD X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 22:41:47 -0000 If there are comments from fecframe, please post them to = mmusic@ietf.org. The latest version is available here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4756bis/ -acbegen -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: Monday, May 10, 2010 11:47 AM To: mmusic@ietf.org Cc: Ali C. Begen (abegen) Subject: upcoming changes in norm requirement in RFC 4756bis: FEC-FR = MUST, FEC SHOULD All, The RFC 4756bis draft = http://tools.ietf.org/html/draft-ietf-mmusic-rfc4756bis-08 obsoletes RFC = 4756.=20 It introduces new grouping semantics (FEC-FR). It also recommends offering the FEC grouping semantics defined in RFC = 4756 for backward compatibility reasons (section 4.5). Based on draft-08 and after a call with Ali, it seems that the intent = is to still recommend supporting the FEC grouping defined in RFC 4756. = Therefore, the plan is to: a) show that FEC is deprecated by updating the IANA registry b) have this in an upcoming new draft (along with some other = clarifications): This document defines the FEC grouping semantics and obsoletes [RFC4756]. Implementations compliant with this document MUST use the = semantics introduced in this document. In addition, implementations are RECOMMENDED to support the "FEC" semantics for backward compatibility reasons. This makes the text clearer. Ali and I believe this is what the text = meant but I just wanted to run this by the WG. Do we have WG consensus on the approach and new text above? Thank you, Jean-Francois MMUSIC WG co-chair From gjshep@gmail.com Tue May 11 10:36:47 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E173B3A6951 for ; Tue, 11 May 2010 10:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNU3qfsltmBE for ; Tue, 11 May 2010 10:36:47 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by core3.amsl.com (Postfix) with ESMTP id CB19F3A6826 for ; Tue, 11 May 2010 10:35:47 -0700 (PDT) Received: by pxi20 with SMTP id 20so2328249pxi.27 for ; Tue, 11 May 2010 10:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:content-type; bh=b0hESq6T/WBrO0MVKHh/PtHaL998DTWQr+fqGWH6LkA=; b=oThTOefj85YVZvItZ0GpLfQSOSKYowE8Wd3iBcm5hQd4o/nADmpeBf4wrrK/AumbAK AieIey84CV03amoMzH0kKuxRNkR+XCY4GOtt5hGegXgmMivTxqlWVGhHeh0W8qpvvgcC ClWyZDX0w4LTjS7yGTRSkgjXW1HTmw1ZLPnpo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=tk0Erf17SqgJ8o92YCmVAnfJVvTb9nGufTMa3Ni/GGhWMuPxXHDMI/iBMJ0LuqBO7M ZbS5IHLkM5zBgScHVVv0/VaqCQXPR6G23aCFyVUlu5zHx2NKqs09/iknq3hMhkDIDDGm sm7NBtiC8DFNEqP6cHKKt3U4rJyAWy7Ay8JO0= MIME-Version: 1.0 Received: by 10.142.121.8 with SMTP id t8mr4253957wfc.273.1273599334111; Tue, 11 May 2010 10:35:34 -0700 (PDT) Received: by 10.142.135.9 with HTTP; Tue, 11 May 2010 10:35:34 -0700 (PDT) Date: Tue, 11 May 2010 10:35:34 -0700 Message-ID: From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Fecframe] WG Last-call: draft-ietf-fecframe-framework-07 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 11 May 2010 17:36:48 -0000 This starts the working group last call for draft-ietf-fecframe-framework-07 http://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ PLEASE read, review, and FEEDBACK to the list promptly, both with issues AND with votes of approval by Monday, May 17th. We cannot move forward without your input. Thank you, Greg (YESI'MSHOUTINGINCAPS) Shepherd From gjshep@gmail.com Tue May 11 11:20:29 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60B0028C1DD for ; Tue, 11 May 2010 11:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.343 X-Spam-Level: X-Spam-Status: No, score=-1.343 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3pBmnYghxDp for ; Tue, 11 May 2010 11:20:28 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 1B09228C26B for ; Tue, 11 May 2010 11:17:42 -0700 (PDT) Received: by pwj2 with SMTP id 2so2693006pwj.31 for ; Tue, 11 May 2010 11:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:content-type; bh=yRI860jOsrZi1zTPQ0n2Z/9P8xpUuikhBc0qJMorTRQ=; b=EX0tfimHqj9BHCfvwb65GHb6EQcweW9lN/120bxPDzc1K55AIW5WBkTjIi3/A4CkA4 RbSxgwYnbFEXU5ycWwT6oy1LKux51zARM1EDHUv5brLAGLk9cKVJR0HmYBTJvB/qGrIy DCxmvFDa8UF5wR5V5tDz3VDoTAJmIZAizj6kg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=lNIsJl6zzC54ajX/Jxxh/obzj0lKrxOK7lVABlryCp/t8XmVZcdsqp696qBnJO3Bg/ h5YXOXUgm18pJSO6JF2QdlVMSxU4LZ8pMh8JjXTegIdT7mYQnLBogOEJuWDnArK5/ZBW BDhe+HjV4ItfLBuYfn2z51OwvNaQXFxcRNfWQ= MIME-Version: 1.0 Received: by 10.142.60.21 with SMTP id i21mr4007266wfa.132.1273601848084; Tue, 11 May 2010 11:17:28 -0700 (PDT) Received: by 10.142.135.9 with HTTP; Tue, 11 May 2010 11:17:28 -0700 (PDT) Date: Tue, 11 May 2010 11:17:28 -0700 Message-ID: From: Greg Shepherd To: iesg-secretary , David Harrington , Eggert Lars , "Ali C. Begen (abegen)" , fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Fecframe] Request for Pub: draft-ietf-fecframe-sdp-elememts-06 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 11 May 2010 18:20:29 -0000 *, The document draft-ietf-fecframe-sdp-elememts-06 is now ready for publication. Please see the Document Shepherd Write-up below. Thanks, Greg --- Document Shepherd Write-up for draft-ietf-fecframe-sdp-elements-06 1.a) The Document Shepherd is Greg Shepherd 1.b) The document has had adequate review both from within and from outside the FECFrame working group. 1.c) There are no concerns regarding the need for additional expanded review. 1.d) There are no specific concerns with this document. 1.e) There is solid WG consensus for this document. 1.f) There is no discontent. 1.g) The only issues with idnits are below. The first to be correct by the RFC Editor upon publication. The later needs to be updated in the document. == Missing Reference: 'RFCXXXX' is mentioned on line 773, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-mmusic-rfc4756bis-07 1.h) References are split between normative and informative. There is one normative reference to a draft from the the FECFrame WG that is also in the process of progressing to last-call: draft-ietf-fecframe-framework-07 There are two other normative references to drafts in the MMUSIC WG that are also in the process of progression to last-call: draft-ietf-mmusic-rfc3388bis-04 draft-ietf-mmusic-rfc4756bis-07 1.i) Section 7.2 provides a list of attribute names which will need to be registered with IANA as per RFC4566. 1.j) The xml code validates correctly 1.k) Technical Summary The document specifies the use of Session Description Protocol (SDP) to describe the parameters required to signal the Forward Error Correction (FEC) Framework Configuration Information between the sender(s) and receiver(s). The document also provides examples that show the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework. 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. Personal Document Shepherd - Greg Shepherd Responsible Area Director - David Harrington (ietfdbh@comcast.net) From orlyp@radvision.com Sat May 15 22:43:54 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 398703A6862 for ; Sat, 15 May 2010 22:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-dcCKAUDJF1 for ; Sat, 15 May 2010 22:43:51 -0700 (PDT) Received: from eframer.radvision.com (rvil-eframer.RADVISION.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id 9AE183A6852 for ; Sat, 15 May 2010 22:43:50 -0700 (PDT) Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id o4G5fh4h009766 for fecframe@ietf.org; Sun, 16 May 2010 08:41:43 +0300 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id o4G5fhru009760; Sun, 16 May 2010 08:41:43 +0300 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" Date: Sun, 16 May 2010 08:43:38 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] WG Last-call: draft-ietf-fecframe-framework-07 Thread-Index: AcrxMIuuawcSBPbSTgmcIu354TaXyADif07A References: From: "Orly Peck" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by eframer.radvision.com id o4G5fhru009760 Subject: Re: [Fecframe] WG Last-call: draft-ietf-fecframe-framework-07 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 May 2010 05:43:54 -0000 I approve. Thanks, Orly. -----Original Message----- From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of Greg Shepherd Sent: Tuesday, May 11, 2010 8:36 PM To: fecframe@ietf.org Subject: [Fecframe] WG Last-call: draft-ietf-fecframe-framework-07 This starts the working group last call for draft-ietf-fecframe-framework-07 http://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ PLEASE read, review, and FEEDBACK to the list promptly, both with issues AND with votes of approval by Monday, May 17th. We cannot move forward without your input. Thank you, Greg (YESI'MSHOUTINGINCAPS) Shepherd _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From gjshep@gmail.com Sun May 16 06:39:16 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 894503A6883 for ; Sun, 16 May 2010 06:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4m14X37R485g for ; Sun, 16 May 2010 06:39:15 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 94D9D3A6827 for ; Sun, 16 May 2010 06:39:15 -0700 (PDT) Received: by pxi19 with SMTP id 19so2375827pxi.31 for ; Sun, 16 May 2010 06:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=xVx99qSS4cmRSDQReeMJtEnGuz9dVzFI62KAQudxoJw=; b=C8SneIFBNaccaOuL3CKA6RTNRSvQO2vb8dv69Jb+6xEbvn/k5zj6otCajoqRjarrOG GftcPAjAHcKNfk9WIkPJ7t3rHu7ukacgwrewXZt6DD0O1vkuWWWeffoLk9pXE5FNYtdv ed5DWNi/OhDePx3TfGHhsYKpbYdqRLyzJBidw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=c3rAyYcO+8/HZrFtDDF9MfQ/Pp3jNNobCjlruTiz2Aa76nM0jB0BoWk/3ScifOzYKj SFZ69lGXWGD1RXePVECo1YXC/TRTz8R9uhO1ywfnI0m5yUPSqOChhvarjnjpsHnPHM0Z AekF7gY6YLB6xohfXJxub6oSeqvZrzskuaUtM= MIME-Version: 1.0 Received: by 10.143.26.3 with SMTP id d3mr2480438wfj.232.1274017144966; Sun, 16 May 2010 06:39:04 -0700 (PDT) Received: by 10.142.188.10 with HTTP; Sun, 16 May 2010 06:39:04 -0700 (PDT) In-Reply-To: References: Date: Sun, 16 May 2010 06:39:04 -0700 Message-ID: From: Greg Shepherd To: Orly Peck Content-Type: text/plain; charset=ISO-8859-1 Cc: fecframe@ietf.org Subject: Re: [Fecframe] WG Last-call: draft-ietf-fecframe-framework-07 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 16 May 2010 13:39:16 -0000 Thanks Orly! Can the rest of you please read and comment asap? Thanks, Greg On Sat, May 15, 2010 at 10:43 PM, Orly Peck wrote: > I approve. > Thanks, > Orly. > > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On > Behalf Of Greg Shepherd > Sent: Tuesday, May 11, 2010 8:36 PM > To: fecframe@ietf.org > Subject: [Fecframe] WG Last-call: draft-ietf-fecframe-framework-07 > > This starts the working group last call for > draft-ietf-fecframe-framework-07 > > http://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ > > PLEASE read, review, and FEEDBACK to the list promptly, both with > issues AND with votes of approval by Monday, May 17th. We cannot move > forward without your input. > > Thank you, > Greg (YESI'MSHOUTINGINCAPS) Shepherd > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > > From vincent.roca@inrialpes.fr Mon May 17 08:57:25 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7D23A6A71 for ; Mon, 17 May 2010 08:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.117 X-Spam-Level: X-Spam-Status: No, score=-4.117 tagged_above=-999 required=5 tests=[AWL=-0.468, BAYES_50=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gc3y7VnSjZGH for ; Mon, 17 May 2010 08:57:24 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id 0592828C148 for ; Mon, 17 May 2010 08:56:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,248,1272837600"; d="scan'208";a="50753073" Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 17 May 2010 17:55:55 +0200 Message-ID: <4BF1670B.5020606@inrialpes.fr> Date: Mon, 17 May 2010 17:55:55 +0200 From: Vincent Roca Organization: INRIA User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: fecframe@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Fecframe] WG Last-call: draft-ietf-fecframe-framework-07 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 15:57:25 -0000 Mark, all, Since I already provided extensive comments on the previous version, I only gave a quick look to version 07. I'm happy with the new definitions (section 2) which are IMHO of utmost importance to harmonize the vocabulary used in all the FECFRAME I-Ds and to clarify the architectural concepts. Therefore I support this version. ** A few easy to fix typos for draft-ietf-fecframe-framework-07: * in section 2 (Definitions): - in definition of "Application protocol", the sentence mentions "protocols" with a final "s", but only provides a single example. Using singular is probably sufficient, otherwise use "protocol(s)". - in definition of "FEC Scheme", I suggest (parenthesis misplacement): "(or in the context of RMT, with the RMT FEC Building Block)." - the 'Encoding symbol' definition appears twice (in the "source symbol" definition the 1st time). - there's an orphan "s" in 'Source Block' definition. BTW, the notion of source block is already defined above. I'd remove it from the general subsection to keep it in the RFC5052 specific part. ** a few additional comments for section 10 (security considerations) - Nothing is said about the possibility of forging the FEC Scheme Specific Information, another way of launching a DoS. - This section refers to "source transport payloads", which is no longer one of the official terms defined in section 2. - If integrity protection is required, I don't think it makes sense to apply it within the "Source Protocol" (application). As you explain, integrity MUST be verified by the receiver ASAP, before launching FEC decoding. Even if the FECFRAME instance is able to check the integrity of source symbols before launching decoding, it will not cover the explicit Source FEC Payload ID (if used) which is a big issue. To summarize: if integrity is a MUST, this MUST be done in lower layers, within the transport or IPsec (or similar) layers. - this section could be improved (it's a little bit light IMHO) but we can also wait for the secdir review. Regards, Vincent From gjshep@gmail.com Tue May 18 10:10:40 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10D333A6A26 for ; Tue, 18 May 2010 10:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixqotX0bdxKZ for ; Tue, 18 May 2010 10:10:38 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8E7813A6895 for ; Tue, 18 May 2010 10:10:37 -0700 (PDT) Received: by iwn42 with SMTP id 42so1915627iwn.31 for ; Tue, 18 May 2010 10:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=3kWpBHWSPH+t/08bDSKCz8Yy1odIJxq9ojNiD2u8Hcg=; b=MTJWxIuheZBm8lD8qDFadDZd7r+BdnausISQ1sceqzFTLkyjY3LpyLcC4hVYlhys5+ kys99ZMOtxFRsoXd/wl+x6PgcJ3A2FYl0MR64nUdHN3ywlXxVTFRhR6IJ3OS+TNEhqYl 2TMOJj986g+BwFEb26CecUJshq8ZMuur5Y9xg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=wZrxgqurP6TVsXkcXI7dx0qltkgGDua7Ip/J112JF9ulNI0FZqWVjf+wi2Q2+eguWM XjCZMJ8PAqZ0T/7G2UxvZNomeJLBAFg2ri32cSGKhqcmpWpBCV6vgVbgFQbwHIB4z2Fx 4/kbjt7A/ghTZHgqnXin04JnX8tpqx14BttHc= MIME-Version: 1.0 Received: by 10.231.169.131 with SMTP id z3mr2245407iby.48.1274202626082; Tue, 18 May 2010 10:10:26 -0700 (PDT) Received: by 10.231.158.7 with HTTP; Tue, 18 May 2010 10:10:25 -0700 (PDT) In-Reply-To: <4BF1670B.5020606@inrialpes.fr> References: <4BF1670B.5020606@inrialpes.fr> Date: Tue, 18 May 2010 10:10:25 -0700 Message-ID: From: Greg Shepherd To: Vincent Roca Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: fecframe@ietf.org Subject: Re: [Fecframe] WG Last-call: draft-ietf-fecframe-framework-07 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 18 May 2010 17:10:40 -0000 Thanks Vincent! Okay, that's two respondents. I can't move this forward without a few more of you responding. Please read and send your notes and/or approval to the list so we can move this to Pub Req ASAP! Thanks, Greg On Mon, May 17, 2010 at 8:55 AM, Vincent Roca w= rote: > Mark, all, > > > Since I already provided extensive comments on the previous version, > I only gave a quick look to version 07. > I'm happy with the new definitions (section 2) which are IMHO of utmost > importance to harmonize the vocabulary used in all the FECFRAME I-Ds > and to clarify the architectural concepts. > > Therefore I support this version. > > > ** A few easy to fix typos for draft-ietf-fecframe-framework-07: > > * in section 2 (Definitions): > > =A0- in definition of "Application protocol", the sentence mentions > =A0"protocols" with a final "s", but only provides a single example. > =A0Using singular is probably sufficient, otherwise use "protocol(s)". > > =A0- in definition of "FEC Scheme", I suggest (parenthesis misplacement): > =A0"(or in the context of RMT, with the RMT FEC Building Block)." > > =A0- the 'Encoding symbol' definition appears twice (in the > =A0"source symbol" definition the 1st time). > > =A0- there's an orphan "s" in 'Source Block' definition. BTW, the > =A0notion of source block is already defined above. I'd remove it > =A0from the general subsection to keep it in the RFC5052 specific > =A0part. > > > ** a few additional comments for section 10 (security considerations) > > =A0- Nothing is said about the possibility of forging the FEC Scheme > =A0Specific Information, another way of launching a DoS. > > =A0- This section refers to "source transport payloads", which is no > =A0longer one of the official terms defined in section 2. > > =A0- If integrity protection is required, I don't think it makes > =A0sense to apply it within the "Source Protocol" (application). > =A0As you explain, integrity MUST be verified by the receiver ASAP, > =A0before launching FEC decoding. Even if the FECFRAME instance is > =A0able to check the integrity of source symbols before launching > =A0decoding, it will not cover the explicit Source FEC Payload ID > =A0(if used) which is a big issue. > =A0To summarize: if integrity is a MUST, this MUST be done in lower > =A0layers, within the =A0transport or IPsec (or similar) layers. > > =A0- this section could be improved (it's a little bit light IMHO) > =A0but we can also wait for the secdir review. > > > Regards, > > =A0 Vincent > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > From watson@qualcomm.com Tue May 25 08:21:26 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 604BB3A7113 for ; Tue, 25 May 2010 08:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-wtrhJk9tOd for ; Tue, 25 May 2010 08:21:24 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 355CB3A6E0E for ; Tue, 25 May 2010 08:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=watson@qualcomm.com; q=dns/txt; s=qcdkim; t=1274800875; x=1306336875; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Watson,=20Mark"=20|To:=20" gjshep@gmail.com"=20|CC:=20Vincent=20Ro ca=20,=20"fecframe@ietf.org" =0D=0A=09|Date:=20Tue,=2025=20May=2020 10=2008:21:13=20-0700|Subject:=20Re:=20[Fecframe]=20WG=20 Last-call:=20draft-ietf-fecframe-framework-07 |Thread-Topic:=20[Fecframe]=20WG=20Last-call:=20draft-iet f-fecframe-framework-07|Thread-Index:=20Acr8Hel0P4AIYQC5R 5Clh8RnOufJ9Q=3D=3D|Message-ID:=20<076565BB-9EFE-464C-8E5 3-43EC6644B0E6@qualcomm.com>|References:=20=0D=0A=20 =0D=0A=20=0D=0A=20<4BF1670B.5020606@inrial pes.fr>=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=VXvz08llV9N/A2iIYVNvdFfwmhJ++MTwzRFr7DG7OdE=; b=H3b8Ol8Zn1WbOUSviNg1BDP4MZkXLeKgBcpAMTG88DZxGxZahfwMgjKq Ej8fo5cpuHimEpYziM2iEkVAJwklh7iFkJ3rE3LdWGGtwMAt6kHOrQcaU jEndIVwwXyJXcneIOLKfNA9dpDQi2ntX9BlzutwA+OZ397cLlOLIDO2un c=; X-IronPort-AV: E=McAfee;i="5400,1158,5992"; a="42472055" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine01.qualcomm.com with ESMTP; 25 May 2010 08:21:15 -0700 X-IronPort-AV: E=Sophos;i="4.53,298,1272870000"; d="scan'208";a="65375159" Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 25 May 2010 08:21:15 -0700 Received: from nasanexhc07.na.qualcomm.com (172.30.39.6) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 25 May 2010 08:21:16 -0700 Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanexhc07.na.qualcomm.com (172.30.39.6) with Microsoft SMTP Server (TLS) id 14.0.689.0; Tue, 25 May 2010 08:21:15 -0700 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Tue, 25 May 2010 08:21:15 -0700 From: "Watson, Mark" To: "gjshep@gmail.com" Date: Tue, 25 May 2010 08:21:13 -0700 Thread-Topic: [Fecframe] WG Last-call: draft-ietf-fecframe-framework-07 Thread-Index: Acr8Hel0P4AIYQC5R5Clh8RnOufJ9Q== Message-ID: <076565BB-9EFE-464C-8E53-43EC6644B0E6@qualcomm.com> References: <4BF1670B.5020606@inrialpes.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] WG Last-call: draft-ietf-fecframe-framework-07 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 15:21:26 -0000 Well, in case it's not obvious - though I guess it is - I agree that this s= hould go forward. ...Mark On May 18, 2010, at 10:10 AM, Greg Shepherd wrote: > Thanks Vincent! >=20 > Okay, that's two respondents. I can't move this forward without a few > more of you responding. Please read and send your notes and/or > approval to the list so we can move this to Pub Req ASAP! >=20 > Thanks, > Greg >=20 > On Mon, May 17, 2010 at 8:55 AM, Vincent Roca = wrote: >> Mark, all, >>=20 >>=20 >> Since I already provided extensive comments on the previous version, >> I only gave a quick look to version 07. >> I'm happy with the new definitions (section 2) which are IMHO of utmost >> importance to harmonize the vocabulary used in all the FECFRAME I-Ds >> and to clarify the architectural concepts. >>=20 >> Therefore I support this version. >>=20 >>=20 >> ** A few easy to fix typos for draft-ietf-fecframe-framework-07: >>=20 >> * in section 2 (Definitions): >>=20 >> - in definition of "Application protocol", the sentence mentions >> "protocols" with a final "s", but only provides a single example. >> Using singular is probably sufficient, otherwise use "protocol(s)". >>=20 >> - in definition of "FEC Scheme", I suggest (parenthesis misplacement): >> "(or in the context of RMT, with the RMT FEC Building Block)." >>=20 >> - the 'Encoding symbol' definition appears twice (in the >> "source symbol" definition the 1st time). >>=20 >> - there's an orphan "s" in 'Source Block' definition. BTW, the >> notion of source block is already defined above. I'd remove it >> from the general subsection to keep it in the RFC5052 specific >> part. >>=20 >>=20 >> ** a few additional comments for section 10 (security considerations) >>=20 >> - Nothing is said about the possibility of forging the FEC Scheme >> Specific Information, another way of launching a DoS. >>=20 >> - This section refers to "source transport payloads", which is no >> longer one of the official terms defined in section 2. >>=20 >> - If integrity protection is required, I don't think it makes >> sense to apply it within the "Source Protocol" (application). >> As you explain, integrity MUST be verified by the receiver ASAP, >> before launching FEC decoding. Even if the FECFRAME instance is >> able to check the integrity of source symbols before launching >> decoding, it will not cover the explicit Source FEC Payload ID >> (if used) which is a big issue. >> To summarize: if integrity is a MUST, this MUST be done in lower >> layers, within the transport or IPsec (or similar) layers. >>=20 >> - this section could be improved (it's a little bit light IMHO) >> but we can also wait for the secdir review. >>=20 >>=20 >> Regards, >>=20 >> Vincent >>=20 >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe >>=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From stockhammer@nomor.de Tue May 25 08:24:28 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FA7D3A6832 for ; Tue, 25 May 2010 08:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+6pP2T7j2e7 for ; Tue, 25 May 2010 08:24:25 -0700 (PDT) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.162]) by core3.amsl.com (Postfix) with ESMTP id 3A4B23A68D8 for ; Tue, 25 May 2010 08:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1274801052; l=3865; 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=FC/2KcFVFfsIR+RPf4ZuhVyHGBU=; b=ZQtlw/MuKRsYH9HCw6Zmkm82AM1SsBmA8xPamwQS05ij7lfrGYQQozvIn9vaB74Akxg 1SSpqjD7YOJ7VKa2DvRu0i2PqV5FSnxVfyhdRdXsxJcwje2x++O6q+lDnwfZLnPTTrD9B SIrfAvcMlse85xFBVi/LV6YAnXE5b8ZH1wo= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFk7RnvKC67oOfpzXZhm8gTfTrVNwqtNCnZw== X-RZG-CLASS-ID: mo00 Received: from [68.245.171.115] (ip-109-85-52-151.web.vodafone.de [109.85.52.151]) by post.strato.de (jimi mo11) (RZmta 23.2) with ESMTP id 000293m4PFO2Qx ; Tue, 25 May 2010 17:24:06 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=windows-1252 From: Thomas Stockhammer In-Reply-To: <076565BB-9EFE-464C-8E53-43EC6644B0E6@qualcomm.com> Date: Tue, 25 May 2010 17:23:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4EEBD313-3F13-4BFF-BBE1-192FFC2A663C@nomor.de> References: <4BF1670B.5020606@inrialpes.fr> <076565BB-9EFE-464C-8E53-43EC6644B0E6@qualcomm.com> To: "Watson, Mark" X-Mailer: Apple Mail (2.1078) Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] WG Last-call: draft-ietf-fecframe-framework-07 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 15:24:28 -0000 Mark, Greg, all I support this version to move forward ... Thomas On May 25, 2010, at 5:21 PM, Watson, Mark wrote: > Well, in case it's not obvious - though I guess it is - I agree that = this should go forward. >=20 > ...Mark >=20 > On May 18, 2010, at 10:10 AM, Greg Shepherd wrote: >=20 >> Thanks Vincent! >>=20 >> Okay, that's two respondents. I can't move this forward without a few >> more of you responding. Please read and send your notes and/or >> approval to the list so we can move this to Pub Req ASAP! >>=20 >> Thanks, >> Greg >>=20 >> On Mon, May 17, 2010 at 8:55 AM, Vincent Roca = wrote: >>> Mark, all, >>>=20 >>>=20 >>> Since I already provided extensive comments on the previous version, >>> I only gave a quick look to version 07. >>> I'm happy with the new definitions (section 2) which are IMHO of = utmost >>> importance to harmonize the vocabulary used in all the FECFRAME I-Ds >>> and to clarify the architectural concepts. >>>=20 >>> Therefore I support this version. >>>=20 >>>=20 >>> ** A few easy to fix typos for draft-ietf-fecframe-framework-07: >>>=20 >>> * in section 2 (Definitions): >>>=20 >>> - in definition of "Application protocol", the sentence mentions >>> "protocols" with a final "s", but only provides a single example. >>> Using singular is probably sufficient, otherwise use "protocol(s)". >>>=20 >>> - in definition of "FEC Scheme", I suggest (parenthesis = misplacement): >>> "(or in the context of RMT, with the RMT FEC Building Block)." >>>=20 >>> - the 'Encoding symbol' definition appears twice (in the >>> "source symbol" definition the 1st time). >>>=20 >>> - there's an orphan "s" in 'Source Block' definition. BTW, the >>> notion of source block is already defined above. I'd remove it >>> from the general subsection to keep it in the RFC5052 specific >>> part. >>>=20 >>>=20 >>> ** a few additional comments for section 10 (security = considerations) >>>=20 >>> - Nothing is said about the possibility of forging the FEC Scheme >>> Specific Information, another way of launching a DoS. >>>=20 >>> - This section refers to "source transport payloads", which is no >>> longer one of the official terms defined in section 2. >>>=20 >>> - If integrity protection is required, I don't think it makes >>> sense to apply it within the "Source Protocol" (application). >>> As you explain, integrity MUST be verified by the receiver ASAP, >>> before launching FEC decoding. Even if the FECFRAME instance is >>> able to check the integrity of source symbols before launching >>> decoding, it will not cover the explicit Source FEC Payload ID >>> (if used) which is a big issue. >>> To summarize: if integrity is a MUST, this MUST be done in lower >>> layers, within the transport or IPsec (or similar) layers. >>>=20 >>> - this section could be improved (it's a little bit light IMHO) >>> but we can also wait for the secdir review. >>>=20 >>>=20 >>> Regards, >>>=20 >>> Vincent >>>=20 >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/fecframe >>>=20 >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe --- 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 gjshep@gmail.com Tue May 25 08:28:27 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A108D3A691B for ; Tue, 25 May 2010 08:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[AWL=-0.716, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdgcHuvnKEsu for ; Tue, 25 May 2010 08:28:25 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C4E0D3A6A53 for ; Tue, 25 May 2010 08:28:25 -0700 (PDT) Received: by iwn42 with SMTP id 42so5080796iwn.31 for ; Tue, 25 May 2010 08:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=RULouEMtVpxL3vm6s0Ag1fVspSao8EdsrKDFtDTb5jY=; b=WImKtrkwNjtXODvr+mIz50mumsZEQqxLflMmeedMceiJKtVK4MwxBGD7V/QsOUuqaO j5v8aBfrhqC4awvHArYvf1yqW+w0tzXUwbJptWW/0Nf+sfabz+a2Mp2ovpdKZn3NN1Pf WOZhLBDXtWwEGvms/7mcVnDfHQbzSXOlg/skQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=BLiOuqZjw6WZ4lQvd7BU8mI64hc+zkWYEWj3YntxOz7cKfrT9l30Zq4/8JFmDLfcWE /Bhl8Dsb/AixeonG0/XkP99DkrZyNnKnrWaxzbxXbpPCEYysQociK0NER915tmuycEkL pnc+jCZOSWmgTYcJHEvvE3uUJ5Fk/Ez0gKkrI= MIME-Version: 1.0 Received: by 10.231.155.18 with SMTP id q18mr23746ibw.44.1274801294279; Tue, 25 May 2010 08:28:14 -0700 (PDT) Received: by 10.231.157.196 with HTTP; Tue, 25 May 2010 08:28:14 -0700 (PDT) In-Reply-To: <4EEBD313-3F13-4BFF-BBE1-192FFC2A663C@nomor.de> References: <4BF1670B.5020606@inrialpes.fr> <076565BB-9EFE-464C-8E53-43EC6644B0E6@qualcomm.com> <4EEBD313-3F13-4BFF-BBE1-192FFC2A663C@nomor.de> Date: Tue, 25 May 2010 08:28:14 -0700 Message-ID: From: Greg Shepherd To: Thomas Stockhammer Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] WG Last-call: draft-ietf-fecframe-framework-07 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 25 May 2010 15:28:27 -0000 Thanks for jumping in here! Okay, I think we have enough feedback now to proceed. I'll post the shepherding doc this week. Greg On Tue, May 25, 2010 at 8:23 AM, Thomas Stockhammer wrote: > Mark, Greg, all > > I support this version to move forward ... > > Thomas > > On May 25, 2010, at 5:21 PM, Watson, Mark wrote: > >> Well, in case it's not obvious - though I guess it is - I agree that thi= s should go forward. >> >> ...Mark >> >> On May 18, 2010, at 10:10 AM, Greg Shepherd wrote: >> >>> Thanks Vincent! >>> >>> Okay, that's two respondents. I can't move this forward without a few >>> more of you responding. Please read and send your notes and/or >>> approval to the list so we can move this to Pub Req ASAP! >>> >>> Thanks, >>> Greg >>> >>> On Mon, May 17, 2010 at 8:55 AM, Vincent Roca wrote: >>>> Mark, all, >>>> >>>> >>>> Since I already provided extensive comments on the previous version, >>>> I only gave a quick look to version 07. >>>> I'm happy with the new definitions (section 2) which are IMHO of utmos= t >>>> importance to harmonize the vocabulary used in all the FECFRAME I-Ds >>>> and to clarify the architectural concepts. >>>> >>>> Therefore I support this version. >>>> >>>> >>>> ** A few easy to fix typos for draft-ietf-fecframe-framework-07: >>>> >>>> * in section 2 (Definitions): >>>> >>>> - in definition of "Application protocol", the sentence mentions >>>> "protocols" with a final "s", but only provides a single example. >>>> Using singular is probably sufficient, otherwise use "protocol(s)". >>>> >>>> - in definition of "FEC Scheme", I suggest (parenthesis misplacement): >>>> "(or in the context of RMT, with the RMT FEC Building Block)." >>>> >>>> - the 'Encoding symbol' definition appears twice (in the >>>> "source symbol" definition the 1st time). >>>> >>>> - there's an orphan "s" in 'Source Block' definition. BTW, the >>>> notion of source block is already defined above. I'd remove it >>>> from the general subsection to keep it in the RFC5052 specific >>>> part. >>>> >>>> >>>> ** a few additional comments for section 10 (security considerations) >>>> >>>> - Nothing is said about the possibility of forging the FEC Scheme >>>> Specific Information, another way of launching a DoS. >>>> >>>> - This section refers to "source transport payloads", which is no >>>> longer one of the official terms defined in section 2. >>>> >>>> - If integrity protection is required, I don't think it makes >>>> sense to apply it within the "Source Protocol" (application). >>>> As you explain, integrity MUST be verified by the receiver ASAP, >>>> before launching FEC decoding. Even if the FECFRAME instance is >>>> able to check the integrity of source symbols before launching >>>> decoding, it will not cover the explicit Source FEC Payload ID >>>> (if used) which is a big issue. >>>> To summarize: if integrity is a MUST, this MUST be done in lower >>>> layers, within the =A0transport or IPsec (or similar) layers. >>>> >>>> - this section could be improved (it's a little bit light IMHO) >>>> but we can also wait for the secdir review. >>>> >>>> >>>> Regards, >>>> >>>> =A0Vincent >>>> >>>> _______________________________________________ >>>> Fecframe mailing list >>>> Fecframe@ietf.org >>>> https://www.ietf.org/mailman/listinfo/fecframe >>>> >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/fecframe >> >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe > > --- > Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 9789= 80 02 || cell +491725702667 || http://www.nomor-research.com > Nomor Research GmbH =A0- =A0Sitz der Gesellschaft: M=FCnchen - Registerge= richt: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 - Gesch=E4fts= f=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. > > > > > From abegen@cisco.com Wed May 26 14:20:51 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758E33A6A13 for ; Wed, 26 May 2010 14:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFHK30jB8eQs for ; Wed, 26 May 2010 14:20:42 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 404213A6A06 for ; Wed, 26 May 2010 14:20:42 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF8t/UurR7Ht/2dsb2JhbACeHXGoFJl9AoURBINC X-IronPort-AV: E=Sophos;i="4.53,306,1272844800"; d="scan'208";a="329732683" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 26 May 2010 21:20:33 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4QLKXwK026717; Wed, 26 May 2010 21:20:33 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 May 2010 14:20:33 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 May 2010 14:20:38 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540C3C1911@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4EEBD313-3F13-4BFF-BBE1-192FFC2A663C@nomor.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] WG Last-call: draft-ietf-fecframe-framework-07 Thread-Index: Acr8Hl/uaz+0TmYbR46V4As8nm8PjQA+sS9Q References: <4BF1670B.5020606@inrialpes.fr><076565BB-9EFE-464C-8E53-43EC6644B0E6@qualcomm.com> <4EEBD313-3F13-4BFF-BBE1-192FFC2A663C@nomor.de> From: "Ali C. Begen (abegen)" To: "Thomas Stockhammer" , "Watson, Mark" X-OriginalArrivalTime: 26 May 2010 21:20:33.0514 (UTC) FILETIME=[46AB94A0:01CAFD19] Cc: fecframe@ietf.org Subject: Re: [Fecframe] WG Last-call: draft-ietf-fecframe-framework-07 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 21:20:51 -0000 Ditto, let's finish this so other drafts can be concluded as well. -acbegen > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Thomas Stockhammer > Sent: Tuesday, May 25, 2010 11:24 AM > To: Watson, Mark > Cc: fecframe@ietf.org > Subject: Re: [Fecframe] WG Last-call: draft-ietf-fecframe-framework-07 >=20 > Mark, Greg, all >=20 > I support this version to move forward ... >=20 > Thomas >=20 > On May 25, 2010, at 5:21 PM, Watson, Mark wrote: >=20 > > Well, in case it's not obvious - though I guess it is - I agree that = this should go forward. > > > > ...Mark > > > > On May 18, 2010, at 10:10 AM, Greg Shepherd wrote: > > > >> Thanks Vincent! > >> > >> Okay, that's two respondents. I can't move this forward without a = few > >> more of you responding. Please read and send your notes and/or > >> approval to the list so we can move this to Pub Req ASAP! > >> > >> Thanks, > >> Greg > >> > >> On Mon, May 17, 2010 at 8:55 AM, Vincent Roca = wrote: > >>> Mark, all, > >>> > >>> > >>> Since I already provided extensive comments on the previous = version, > >>> I only gave a quick look to version 07. > >>> I'm happy with the new definitions (section 2) which are IMHO of = utmost > >>> importance to harmonize the vocabulary used in all the FECFRAME = I-Ds > >>> and to clarify the architectural concepts. > >>> > >>> Therefore I support this version. > >>> > >>> > >>> ** A few easy to fix typos for draft-ietf-fecframe-framework-07: > >>> > >>> * in section 2 (Definitions): > >>> > >>> - in definition of "Application protocol", the sentence mentions > >>> "protocols" with a final "s", but only provides a single example. > >>> Using singular is probably sufficient, otherwise use = "protocol(s)". > >>> > >>> - in definition of "FEC Scheme", I suggest (parenthesis = misplacement): > >>> "(or in the context of RMT, with the RMT FEC Building Block)." > >>> > >>> - the 'Encoding symbol' definition appears twice (in the > >>> "source symbol" definition the 1st time). > >>> > >>> - there's an orphan "s" in 'Source Block' definition. BTW, the > >>> notion of source block is already defined above. I'd remove it > >>> from the general subsection to keep it in the RFC5052 specific > >>> part. > >>> > >>> > >>> ** a few additional comments for section 10 (security = considerations) > >>> > >>> - Nothing is said about the possibility of forging the FEC Scheme > >>> Specific Information, another way of launching a DoS. > >>> > >>> - This section refers to "source transport payloads", which is no > >>> longer one of the official terms defined in section 2. > >>> > >>> - If integrity protection is required, I don't think it makes > >>> sense to apply it within the "Source Protocol" (application). > >>> As you explain, integrity MUST be verified by the receiver ASAP, > >>> before launching FEC decoding. Even if the FECFRAME instance is > >>> able to check the integrity of source symbols before launching > >>> decoding, it will not cover the explicit Source FEC Payload ID > >>> (if used) which is a big issue. > >>> To summarize: if integrity is a MUST, this MUST be done in lower > >>> layers, within the transport or IPsec (or similar) layers. > >>> > >>> - this section could be improved (it's a little bit light IMHO) > >>> but we can also wait for the secdir review. > >>> > >>> > >>> Regards, > >>> > >>> Vincent > >>> > >>> _______________________________________________ > >>> Fecframe mailing list > >>> Fecframe@ietf.org > >>> https://www.ietf.org/mailman/listinfo/fecframe > >>> > >> _______________________________________________ > >> Fecframe mailing list > >> Fecframe@ietf.org > >> https://www.ietf.org/mailman/listinfo/fecframe > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe >=20 > --- > Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 > || http://www.nomor-research.com > Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 > Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf=FChrer: Dr. Thomas = Stockhammer, Dr. Ingo Viering. >=20 >=20 >=20 >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe