From ietfdbh@comcast.net Fri Oct 1 20:40: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 11EC93A6C30 for ; Fri, 1 Oct 2010 20:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.313 X-Spam-Level: X-Spam-Status: No, score=-102.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, 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 xnfDeR9-Zw2j for ; Fri, 1 Oct 2010 20:40:49 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 37E763A6C24 for ; Fri, 1 Oct 2010 20:40:49 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta02.westchester.pa.mail.comcast.net with comcast id Dedh1f0071ap0As52fhf61; Sat, 02 Oct 2010 03:41:39 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta22.westchester.pa.mail.comcast.net with comcast id Dfhe1f00G2JQnJT3ifheo5; Sat, 02 Oct 2010 03:41:39 +0000 From: "David Harrington" To: , "'TSV Dir'" References: <20100827154930.23394.79420.idtracker@localhost><04CAD96D4C5A3D48B1919248A8FE0D540D39EB01@xmb-sjc-215.amer.cisco.com> Date: Fri, 1 Oct 2010 23:39:25 -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.00.2900.5994 Thread-index: ActhzFP1FVdTT7ckQ4WL6hHo4fy9GAAFfT8A In-Reply-To: Cc: fecframe-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [Fecframe] [IANA #394228] RE: Last Call: (Session DescriptionProtocol (SDP) Elements for FEC Framework) to Proposed Standard 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: Sat, 02 Oct 2010 03:40:51 -0000 Hi fecframe, I didn't like this much when I did my AD review and I still don't. I think this puts tremendous load on IANA to do this for us automatically for every current and future registration. Can we please design a different approach to FEC registration. I think there must be a simpler manner to do this. TSVDIR, can you suggest a better approach for this? David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On > Behalf Of Amanda Baber via RT > Sent: Friday, October 01, 2010 8:53 PM > Cc: fecframe-chairs@tools.ietf.org; abegen@cisco.com; iesg@ietf.org > Subject: [IANA #394228] RE: Last > Call: (Session > DescriptionProtocol (SDP) Elements for FEC Framework) to > Proposed Standard > > Hi Ali, > > Just to make sure we understand what you're asking for: you > want this document to modify the registration procedures for > the proto registry to be modified so that for every current > and future registration -- RTP/AVP, vat, TCP, et al. -- IANA > would also automatically register FEC/RTP/AVP, FEC/vat, > FEC/TCP, and so on? > > This sounds like a decision for the ADs. We're able do this > -- we'd just have to insert a note in the registry > instructing ourselves to do it -- but we can't think of any > other registries that behave this way. > > Thanks, > > Amanda > IANA > > On Thu Sep 23 19:55:01 2010, abegen@cisco.com wrote: > > Hi Amanda, > > > > We cleared the earlier issues with this draft. However, during the > > IESG review something came up. This is about section 4.1. In > > addition to registering UDP/FEC, we also need several other > > registrations for FEC/ for the proto's listed in the SDP > > registry. I wonder how we can do this effectively. A shortcut > > maybe? > > > > I am probably pushing the limit here. But I wonder whether we could > > define something here so that when a new proto is > registered in the > > future, FEC/ can also be automatically registered based on > > this draft. > > > > I am about to revise this draft. I would appreciate if you > could tell > > me what I should put in section 8.1 regarding the above. > > > > Thanks in advance. > > > > -acbegen > > > > > -----Original Message----- > > > From: Amanda Baber via RT [mailto:drafts-lastcall@iana.org] > > > Sent: Friday, September 10, 2010 3:05 PM > > > Cc: Ali C. Begen (abegen); fecframe-chairs@tools.ietf.org; > > iesg@ietf.org > > > Subject: [IANA #386944] Last Call: > elements-08.txt> (Session Description Protocol (SDP) Elements for > > > FEC Framework) to Proposed Standard > > > > > > IESG: > > > > > > IANA has reviewed > draft-ietf-fecframe-sdp-elements-08.txt, which is > > > currently in Last Call, and has the following comments: > > > > > > IANA has questions about this document. > > > > > > IANA understands that, upon approval of this document, > there are two > > > IANA Actions that need to be completed. > > > > > > First, in the proto type subregistry of the Session Description > > Protocol > > > (SDP) Parameters located at: > > > > > > http://www.iana.org/assignments/sdp-parameters > > > > > > a single new value is to be registered: > > > > > > Type SDP Name Reference > > > ----- ---------- ----------- > > > proto UDP/FEC [RFC-to-be] > > > > > > Second, in one of the att-field subregistries of the Session > > Description > > > Protocol (SDP) Parameters located at: > > > > > > http://www.iana.org/assignments/sdp-parameters > > > > > > three new attribute names are to be added as follows: > > > > > > SDP Attribute ("att-field"): > > > Attribute name: fec-source-flow > > > Long form: Pointer to FEC Source Flow Type of name: > att-field Type > > > of attribute: Media level Subject to charset: No > > > Purpose: Provide parameters for an FEC source flow > > > Reference: [RFC-to-be] > > > Values: See [RFC-to-be] > > > > > > SDP Attribute ("att-field"): > > > Attribute name: fec-repair-flow > > > Long form: Pointer to FEC Repair Flow Type of name: > att-field Type > > > of attribute: Media level Subject to charset: No > > > Purpose: Provide parameters for an FEC repair flow > > > Reference: [RFC-to-be] > > > Values: See [RFC-to-be] > > > > > > SDP Attribute ("att-field"): > > > Attribute name: repair-window > > > Long form: Pointer to FEC Repair Window Type of name: > att-field Type > > > of attribute: Media level Subject to charset: No > > > Purpose: Indicate the size of the repair window > > > Reference: [RFC-to-be] > > > Values: See [RFC-to-be] > > > > > > IANA has a question about these registrations. There are four att- > > field > > > registries: one for session level attributes, one for both session > > and > > > media level attributes, one for media level attributes > only, one for > > > source level, and a final one for attributes for unknown levels. > > Which > > > of these subregistries are these three attribute names to be added > > to? > > > > > > After clarification, IANA understands that these are the only > > actions > > > required upon approval of the document. > > > > > > Thanks, > > > > > > Amanda Baber > > > IANA > > > > > > On Fri Aug 27 15:50:26 2010, noreply@ietf.org wrote: > > > > > > > > The IESG has received a request from the FEC Framework WG > > (fecframe) to > > > > consider the following document: > > > > - 'Session Description Protocol (SDP) Elements for FEC > Framework' > > > > as a > Proposed Standard > > > > > > > > The IESG plans to make a decision in the next few weeks, and > > solicits > > > > final comments on this action. Please send substantive > comments to > > the > > > > ietf@ietf.org mailing lists by 2010-09-10. > 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. > > > > > > > > The file can be obtained via > > > > > https://datatracker.ietf.org/doc/draft-ietf-fecframe-sdp-elements/ > > > > > > > > IESG discussion can be tracked via > > > > > https://datatracker.ietf.org/doc/draft-ietf-fecframe-sdp-elements/ > > > > > > > > > > > > No IPR declarations were found that appear related to this I-D. > > > > > > > > > > > > > > > > > From abegen@cisco.com Fri Oct 1 20:47:39 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 AC8643A6DEF; Fri, 1 Oct 2010 20:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.551 X-Spam-Level: X-Spam-Status: No, score=-10.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 b35Ai9ncwJDg; Fri, 1 Oct 2010 20:47:38 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1D9A23A6BF1; Fri, 1 Oct 2010 20:47:38 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAItIpkyrR7Hu/2dsb2JhbACiP3GqSJwighhzgjkEhFGIcw X-IronPort-AV: E=Sophos;i="4.57,270,1283731200"; d="scan'208";a="598022527" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 02 Oct 2010 03:48:27 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o923mRUM016491; Sat, 2 Oct 2010 03:48:27 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Oct 2010 20:48:27 -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: Fri, 1 Oct 2010 20:48:08 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D4FA7CE@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] [IANA #394228] RE: LastCall: (SessionDescriptionProtocol (SDP) Elements for FEC Framework) toProposed Standard Thread-Index: ActhzFP1FVdTT7ckQ4WL6hHo4fy9GAAFfT8AAAB0rSA= References: <20100827154930.23394.79420.idtracker@localhost><04CAD96D4C5A3D48B1919248A8FE0D540D39EB01@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: "David Harrington" , , "TSV Dir" X-OriginalArrivalTime: 02 Oct 2010 03:48:27.0744 (UTC) FILETIME=[AC113E00:01CB61E4] Cc: fecframe-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [Fecframe] [IANA #394228] RE: LastCall: (SessionDescriptionProtocol (SDP) Elements for FEC Framework) toProposed Standard 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: Sat, 02 Oct 2010 03:47:39 -0000 One alternative is to register the ones we care about now, and if a new = protocol is defined in the future and then later someone wants to use it = as a source flow in the fec framework, then, they register it with IANA. = In other words, the registration stays "on demand". One way or another, the flows of the modified source packets have to be = described in the SDP. So, a transport protocol identifier is required. -acbegen > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of David Harrington > Sent: Friday, October 01, 2010 11:39 PM > To: fecframe@ietf.org; 'TSV Dir' > Cc: fecframe-chairs@tools.ietf.org; iesg@ietf.org > Subject: Re: [Fecframe] [IANA #394228] RE: = LastCall: = (SessionDescriptionProtocol > (SDP) Elements for FEC Framework) toProposed Standard >=20 > Hi fecframe, >=20 > I didn't like this much when I did my AD review and I still don't. > I think this puts tremendous load on IANA to do this for us > automatically for every current and future registration. > Can we please design a different approach to FEC registration. > I think there must be a simpler manner to do this. >=20 > TSVDIR, can you suggest a better approach for this? >=20 > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) >=20 > > -----Original Message----- > > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On > > Behalf Of Amanda Baber via RT > > Sent: Friday, October 01, 2010 8:53 PM > > Cc: fecframe-chairs@tools.ietf.org; abegen@cisco.com; iesg@ietf.org > > Subject: [IANA #394228] RE: Last > > Call: (Session > > DescriptionProtocol (SDP) Elements for FEC Framework) to > > Proposed Standard > > > > Hi Ali, > > > > Just to make sure we understand what you're asking for: you > > want this document to modify the registration procedures for > > the proto registry to be modified so that for every current > > and future registration -- RTP/AVP, vat, TCP, et al. -- IANA > > would also automatically register FEC/RTP/AVP, FEC/vat, > > FEC/TCP, and so on? > > > > This sounds like a decision for the ADs. We're able do this > > -- we'd just have to insert a note in the registry > > instructing ourselves to do it -- but we can't think of any > > other registries that behave this way. > > > > Thanks, > > > > Amanda > > IANA > > > > On Thu Sep 23 19:55:01 2010, abegen@cisco.com wrote: > > > Hi Amanda, > > > > > > We cleared the earlier issues with this draft. However, during the > > > IESG review something came up. This is about section 4.1. In > > > addition to registering UDP/FEC, we also need several other > > > registrations for FEC/ for the proto's listed in the SDP > > > registry. I wonder how we can do this effectively. A shortcut > > > maybe? > > > > > > I am probably pushing the limit here. But I wonder whether we > could > > > define something here so that when a new proto is > > registered in the > > > future, FEC/ can also be automatically registered based > on > > > this draft. > > > > > > I am about to revise this draft. I would appreciate if you > > could tell > > > me what I should put in section 8.1 regarding the above. > > > > > > Thanks in advance. > > > > > > -acbegen > > > > > > > -----Original Message----- > > > > From: Amanda Baber via RT [mailto:drafts-lastcall@iana.org] > > > > Sent: Friday, September 10, 2010 3:05 PM > > > > Cc: Ali C. Begen (abegen); fecframe-chairs@tools.ietf.org; > > > iesg@ietf.org > > > > Subject: [IANA #386944] Last Call: > > elements-08.txt> (Session Description Protocol (SDP) Elements > for > > > > FEC Framework) to Proposed Standard > > > > > > > > IESG: > > > > > > > > IANA has reviewed > > draft-ietf-fecframe-sdp-elements-08.txt, which is > > > > currently in Last Call, and has the following comments: > > > > > > > > IANA has questions about this document. > > > > > > > > IANA understands that, upon approval of this document, > > there are two > > > > IANA Actions that need to be completed. > > > > > > > > First, in the proto type subregistry of the Session Description > > > Protocol > > > > (SDP) Parameters located at: > > > > > > > > http://www.iana.org/assignments/sdp-parameters > > > > > > > > a single new value is to be registered: > > > > > > > > Type SDP Name Reference > > > > ----- ---------- ----------- > > > > proto UDP/FEC [RFC-to-be] > > > > > > > > Second, in one of the att-field subregistries of the Session > > > Description > > > > Protocol (SDP) Parameters located at: > > > > > > > > http://www.iana.org/assignments/sdp-parameters > > > > > > > > three new attribute names are to be added as follows: > > > > > > > > SDP Attribute ("att-field"): > > > > Attribute name: fec-source-flow > > > > Long form: Pointer to FEC Source Flow Type of name: > > att-field Type > > > > of attribute: Media level Subject to charset: No > > > > Purpose: Provide parameters for an FEC source flow > > > > Reference: [RFC-to-be] > > > > Values: See [RFC-to-be] > > > > > > > > SDP Attribute ("att-field"): > > > > Attribute name: fec-repair-flow > > > > Long form: Pointer to FEC Repair Flow Type of name: > > att-field Type > > > > of attribute: Media level Subject to charset: No > > > > Purpose: Provide parameters for an FEC repair flow > > > > Reference: [RFC-to-be] > > > > Values: See [RFC-to-be] > > > > > > > > SDP Attribute ("att-field"): > > > > Attribute name: repair-window > > > > Long form: Pointer to FEC Repair Window Type of name: > > att-field Type > > > > of attribute: Media level Subject to charset: No > > > > Purpose: Indicate the size of the repair window > > > > Reference: [RFC-to-be] > > > > Values: See [RFC-to-be] > > > > > > > > IANA has a question about these registrations. There are four > att- > > > field > > > > registries: one for session level attributes, one for both > session > > > and > > > > media level attributes, one for media level attributes > > only, one for > > > > source level, and a final one for attributes for unknown levels. > > > Which > > > > of these subregistries are these three attribute names to be > added > > > to? > > > > > > > > After clarification, IANA understands that these are the only > > > actions > > > > required upon approval of the document. > > > > > > > > Thanks, > > > > > > > > Amanda Baber > > > > IANA > > > > > > > > On Fri Aug 27 15:50:26 2010, noreply@ietf.org wrote: > > > > > > > > > > The IESG has received a request from the FEC Framework WG > > > (fecframe) to > > > > > consider the following document: > > > > > - 'Session Description Protocol (SDP) Elements for FEC > > Framework' > > > > > as a > > Proposed Standard > > > > > > > > > > The IESG plans to make a decision in the next few weeks, and > > > solicits > > > > > final comments on this action. Please send substantive > > comments to > > > the > > > > > ietf@ietf.org mailing lists by 2010-09-10. > > 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. > > > > > > > > > > The file can be obtained via > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-fecframe-sdp-elements/ > > > > > > > > > > IESG discussion can be tracked via > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-fecframe-sdp-elements/ > > > > > > > > > > > > > > > No IPR declarations were found that appear related to this > I-D. > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From ietfdbh@comcast.net Fri Oct 1 21:54:48 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 9F7B43A6B40 for ; Fri, 1 Oct 2010 21:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.317 X-Spam-Level: X-Spam-Status: No, score=-102.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, 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 rv9GlnN-n5M0 for ; Fri, 1 Oct 2010 21:54:47 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id 04F683A6D7E for ; Fri, 1 Oct 2010 21:54:46 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by QMTA11.westchester.pa.mail.comcast.net with comcast id Dgv71f0021uE5Es5BgvdYC; Sat, 02 Oct 2010 04:55:37 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta16.westchester.pa.mail.comcast.net with comcast id Dgvc1f00B2JQnJT3cgvdFq; Sat, 02 Oct 2010 04:55:37 +0000 From: "David Harrington" To: "'Ali C. Begen \(abegen\)'" , , "'TSV Dir'" References: <20100827154930.23394.79420.idtracker@localhost><04CAD96D4C5A3D48B1919248A8FE0D540D39EB01@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FA7CE@xmb-sjc-215.amer.cisco.com> Date: Sat, 2 Oct 2010 00:53:20 -0400 Message-ID: <44AFD509E30B4B80B78CC344ECC1A5E6@23FX1C1> 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.00.2900.5994 Thread-index: ActhzFP1FVdTT7ckQ4WL6hHo4fy9GAAFfT8AAAB0rSAAAF6DgA== In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540D4FA7CE@xmb-sjc-215.amer.cisco.com> Cc: fecframe-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [Fecframe] [IANA #394228] RE: LastCall: (SessionDescriptionProtocol (SDP) Elements for FEC Framework) toProposed Standard 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: Sat, 02 Oct 2010 04:54:48 -0000 Hi Ali, Thanks for responding. I probably should have questioned this more during AD Review. I did think it an odd design, but there was apparently WG consensus, so I didn't bother to raise my questions. My bad. When you say "someone wants to use it as a source flow in the fec framework", this is not very clear. The fec framework is an abstract description of how things fit together. Within the fec framework, we have multiple fec schemes. Is each fec scheme designed to protect specific types of source flows? When you say "someone wants to use it as a source flow in the fec framework", is the someone the editor of a fec scheme specification? is "it" a registered identifier? What exactly does the identifer identify? Does that identifier identify a specific fec scheme for a specific type of source flow? Would it make sense for a fec scheme specification document to register the specific relevant identifiers? Please try to be very explicit in your response, so I can understand this better. It might help to avoid using pronouns like "someone", "it", and phrases like "the ones we care about" I care about all standard protocols ;-) Which ones do you care about? David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Friday, October 01, 2010 11:48 PM > To: David Harrington; fecframe@ietf.org; TSV Dir > Cc: fecframe-chairs@tools.ietf.org; iesg@ietf.org > Subject: RE: [Fecframe] [IANA #394228] RE: > LastCall: > (SessionDescriptionProtocol (SDP) Elements for FEC Framework) > toProposed Standard > > One alternative is to register the ones we care about now, > and if a new protocol is defined in the future and then later > someone wants to use it as a source flow in the fec > framework, then, they register it with IANA. In other words, > the registration stays "on demand". > > One way or another, the flows of the modified source packets > have to be described in the SDP. So, a transport protocol > identifier is required. > > -acbegen > > > -----Original Message----- > > From: fecframe-bounces@ietf.org > [mailto:fecframe-bounces@ietf.org] On > > Behalf Of David Harrington > > Sent: Friday, October 01, 2010 11:39 PM > > To: fecframe@ietf.org; 'TSV Dir' > > Cc: fecframe-chairs@tools.ietf.org; iesg@ietf.org > > Subject: Re: [Fecframe] [IANA #394228] RE: > > LastCall: > > (SessionDescriptionProtocol > > (SDP) Elements for FEC Framework) toProposed Standard > > > > Hi fecframe, > > > > I didn't like this much when I did my AD review and I still don't. > > I think this puts tremendous load on IANA to do this for us > > automatically for every current and future registration. > > Can we please design a different approach to FEC registration. > > I think there must be a simpler manner to do this. > > > > TSVDIR, can you suggest a better approach for this? > > > > David Harrington > > Director, IETF Transport Area > > ietfdbh@comcast.net (preferred for ietf) > > dbharrington@huaweisymantec.com > > +1 603 828 1401 (cell) > > > > > -----Original Message----- > > > From: iesg-bounces@ietf.org > [mailto:iesg-bounces@ietf.org] On Behalf > > > Of Amanda Baber via RT > > > Sent: Friday, October 01, 2010 8:53 PM > > > Cc: fecframe-chairs@tools.ietf.org; abegen@cisco.com; > iesg@ietf.org > > > Subject: [IANA #394228] RE: Last > > > Call: (Session > > > DescriptionProtocol (SDP) Elements for FEC Framework) to Proposed > > > Standard > > > > > > Hi Ali, > > > > > > Just to make sure we understand what you're asking for: you want > > > this document to modify the registration procedures for the proto > > > registry to be modified so that for every current and future > > > registration -- RTP/AVP, vat, TCP, et al. -- IANA would also > > > automatically register FEC/RTP/AVP, FEC/vat, FEC/TCP, and so on? > > > > > > This sounds like a decision for the ADs. We're able do this > > > -- we'd just have to insert a note in the registry instructing > > > ourselves to do it -- but we can't think of any other registries > > > that behave this way. > > > > > > Thanks, > > > > > > Amanda > > > IANA > > > > > > On Thu Sep 23 19:55:01 2010, abegen@cisco.com wrote: > > > > Hi Amanda, > > > > > > > > We cleared the earlier issues with this draft. However, > during the > > > > IESG review something came up. This is about section 4.1. In > > > > addition to registering UDP/FEC, we also need several other > > > > registrations for FEC/ for the proto's listed > in the SDP > > > > registry. I wonder how we can do this effectively. A shortcut > > > > maybe? > > > > > > > > I am probably pushing the limit here. But I wonder whether we > > could > > > > define something here so that when a new proto is > > > registered in the > > > > future, FEC/ can also be automatically > registered based > > on > > > > this draft. > > > > > > > > I am about to revise this draft. I would appreciate if you > > > could tell > > > > me what I should put in section 8.1 regarding the above. > > > > > > > > Thanks in advance. > > > > > > > > -acbegen > > > > > > > > > -----Original Message----- > > > > > From: Amanda Baber via RT [mailto:drafts-lastcall@iana.org] > > > > > Sent: Friday, September 10, 2010 3:05 PM > > > > > Cc: Ali C. Begen (abegen); fecframe-chairs@tools.ietf.org; > > > > iesg@ietf.org > > > > > Subject: [IANA #386944] Last Call: > > > elements-08.txt> (Session Description Protocol (SDP) Elements > > for > > > > > FEC Framework) to Proposed Standard > > > > > > > > > > IESG: > > > > > > > > > > IANA has reviewed > > > draft-ietf-fecframe-sdp-elements-08.txt, which is > > > > > currently in Last Call, and has the following comments: > > > > > > > > > > IANA has questions about this document. > > > > > > > > > > IANA understands that, upon approval of this document, > > > there are two > > > > > IANA Actions that need to be completed. > > > > > > > > > > First, in the proto type subregistry of the Session > Description > > > > Protocol > > > > > (SDP) Parameters located at: > > > > > > > > > > http://www.iana.org/assignments/sdp-parameters > > > > > > > > > > a single new value is to be registered: > > > > > > > > > > Type SDP Name Reference > > > > > ----- ---------- ----------- > > > > > proto UDP/FEC [RFC-to-be] > > > > > > > > > > Second, in one of the att-field subregistries of the Session > > > > Description > > > > > Protocol (SDP) Parameters located at: > > > > > > > > > > http://www.iana.org/assignments/sdp-parameters > > > > > > > > > > three new attribute names are to be added as follows: > > > > > > > > > > SDP Attribute ("att-field"): > > > > > Attribute name: fec-source-flow > > > > > Long form: Pointer to FEC Source Flow Type of name: > > > att-field Type > > > > > of attribute: Media level Subject to charset: No > > > > > Purpose: Provide parameters for an FEC source flow > > > > > Reference: [RFC-to-be] > > > > > Values: See [RFC-to-be] > > > > > > > > > > SDP Attribute ("att-field"): > > > > > Attribute name: fec-repair-flow > > > > > Long form: Pointer to FEC Repair Flow Type of name: > > > att-field Type > > > > > of attribute: Media level Subject to charset: No > > > > > Purpose: Provide parameters for an FEC repair flow > > > > > Reference: [RFC-to-be] > > > > > Values: See [RFC-to-be] > > > > > > > > > > SDP Attribute ("att-field"): > > > > > Attribute name: repair-window > > > > > Long form: Pointer to FEC Repair Window Type of name: > > > att-field Type > > > > > of attribute: Media level Subject to charset: No > > > > > Purpose: Indicate the size of the repair window > > > > > Reference: [RFC-to-be] > > > > > Values: See [RFC-to-be] > > > > > > > > > > IANA has a question about these registrations. There are four > > att- > > > > field > > > > > registries: one for session level attributes, one for both > > session > > > > and > > > > > media level attributes, one for media level attributes > > > only, one for > > > > > source level, and a final one for attributes for > unknown levels. > > > > Which > > > > > of these subregistries are these three attribute names to be > > added > > > > to? > > > > > > > > > > After clarification, IANA understands that these are the only > > > > actions > > > > > required upon approval of the document. > > > > > > > > > > Thanks, > > > > > > > > > > Amanda Baber > > > > > IANA > > > > > > > > > > On Fri Aug 27 15:50:26 2010, noreply@ietf.org wrote: > > > > > > > > > > > > The IESG has received a request from the FEC Framework WG > > > > (fecframe) to > > > > > > consider the following document: > > > > > > - 'Session Description Protocol (SDP) Elements for FEC > > > Framework' > > > > > > as a > > > Proposed Standard > > > > > > > > > > > > The IESG plans to make a decision in the next few weeks, and > > > > solicits > > > > > > final comments on this action. Please send substantive > > > comments to > > > > the > > > > > > ietf@ietf.org mailing lists by 2010-09-10. > > > 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. > > > > > > > > > > > > The file can be obtained via > > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-fecframe-sdp-elements/ > > > > > > > > > > > > IESG discussion can be tracked via > > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-fecframe-sdp-elements/ > > > > > > > > > > > > > > > > > > No IPR declarations were found that appear related to this > > I-D. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe From abegen@cisco.com Sat Oct 2 04:34:13 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 5AB883A6C9B; Sat, 2 Oct 2010 04:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.552 X-Spam-Level: X-Spam-Status: No, score=-10.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 NDtbC6XpKwvc; Sat, 2 Oct 2010 04:34:11 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 153D13A6B6F; Sat, 2 Oct 2010 04:34:11 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMK1pkyrRN+J/2dsb2JhbACiPnGlYZwHghhZGoI5BIRRiHM X-IronPort-AV: E=Sophos;i="4.57,271,1283731200"; d="scan'208";a="263667244" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 02 Oct 2010 11:35:01 +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 o92BZ1Tu011659; Sat, 2 Oct 2010 11:35:01 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 2 Oct 2010 04:35:01 -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: Sat, 2 Oct 2010 04:34:55 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D4FA7F5@xmb-sjc-215.amer.cisco.com> In-Reply-To: <44AFD509E30B4B80B78CC344ECC1A5E6@23FX1C1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] [IANA #394228] RE: LastCall: (SessionDescriptionProtocol (SDP) Elements for FEC Framework) toProposed Standard Thread-Index: ActhzFP1FVdTT7ckQ4WL6hHo4fy9GAAFfT8AAAB0rSAAAF6DgAAPbPjw References: <20100827154930.23394.79420.idtracker@localhost><04CAD96D4C5A3D48B1919248A8FE0D540D39EB01@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FA7CE@xmb-sjc-215.amer.cisco.com> <44AFD509E30B4B80B78CC344ECC1A5E6@23FX1C1> From: "Ali C. Begen (abegen)" To: "David Harrington" , , "TSV Dir" X-OriginalArrivalTime: 02 Oct 2010 11:35:01.0461 (UTC) FILETIME=[D99F7850:01CB6225] Cc: fecframe-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [Fecframe] [IANA #394228] RE: LastCall: (SessionDescriptionProtocol (SDP) Elements for FEC Framework) toProposed Standard 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: Sat, 02 Oct 2010 11:34:14 -0000 Hi David, > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Saturday, October 02, 2010 12:53 AM > To: Ali C. Begen (abegen); fecframe@ietf.org; 'TSV Dir' > Cc: fecframe-chairs@tools.ietf.org; iesg@ietf.org > Subject: RE: [Fecframe] [IANA #394228] RE: = LastCall: = (SessionDescriptionProtocol > (SDP) Elements for FEC Framework) toProposed Standard >=20 > Hi Ali, >=20 > Thanks for responding. > I probably should have questioned this more during AD Review. I did > think it an odd design, but there was apparently WG consensus, so I > didn't bother to raise my questions. My bad. >=20 > When you say "someone wants to use it as a source flow in the fec > framework", this is not very clear. > The fec framework is an abstract description of how things fit > together. > Within the fec framework, we have multiple fec schemes. > Is each fec scheme designed to protect specific types of source flows? Right, framework draft explains the framework itself. The FEC schemes = may have individual requirements for the source (input) flows. In some = source flows, sequence numbers will already exist to allow the receiver = to identify them uniquely (like RTP). In other source flows (such as = UDP), there won't be a seqnum which means something needs to be added at = the end of the source packets (explicit source fec payload id). However, = once we do that, we cannot describe those packets as regular UDP packets = since it would be misleading. Instead, we use FEC/ in the SDP. = This way, a receiver that does not implement the framework will not be = able to parse FEC/ line and it will not try to use that flow. =20 > When you say "someone wants to use it as a source flow in the fec > framework", > is the someone the editor of a fec scheme specification? Suppose your source flow is UDP. And you wanna apply FEC on it. So, you = append the explicit source fec payload id. Now, in the SDP you should = use "FEC/UDP." But I think you can only do it if it has been registered = with IANA. It does not matter who does the registration. If an FEC = scheme draft registers it, others can use it as well since "FEC/UDP" = part is common (different FEC schemes will be identified based on their = encoding IDs anyway). So bottom line is, either the SDP draft registers it or an FEC scheme = draft that plans to use UDP flows as source flows registers it. Once it = is registered, other FEC schemes can use the same registration. > is "it" a registered identifier? > What exactly does the identifer identify? > Does that identifier identify a specific fec scheme for a specific > type of source flow? > Would it make sense for a fec scheme specification document to > register the specific relevant identifiers? I hope my answer above answers all these questions. FEC schemes are = identified by their encoding IDs not protocol identifiers. =20 > Please try to be very explicit in your response, so I can understand > this better. > It might help to avoid using pronouns like "someone", "it", and > phrases like "the ones we care about" > I care about all standard protocols ;-) Which ones do you care about? Sure. Certain protocols will unlikely to be used with FEC (e.g., TCP). = And for RTP and DCCP (which has its own seqnums), we don't need a new = identifier. So, to me UDP is the #1 candidate :) So we can do the = registration for UDP and leave the rest for future FEC scheme drafts. -acbegen PS tsv-dir emails seem to be bouncing since I am not a member, but = keeping their address in the to list just in case the moderator allows = these emails. =20 > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) >=20 > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Friday, October 01, 2010 11:48 PM > > To: David Harrington; fecframe@ietf.org; TSV Dir > > Cc: fecframe-chairs@tools.ietf.org; iesg@ietf.org > > Subject: RE: [Fecframe] [IANA #394228] RE: > > LastCall: > > (SessionDescriptionProtocol (SDP) Elements for FEC Framework) > > toProposed Standard > > > > One alternative is to register the ones we care about now, > > and if a new protocol is defined in the future and then later > > someone wants to use it as a source flow in the fec > > framework, then, they register it with IANA. In other words, > > the registration stays "on demand". > > > > One way or another, the flows of the modified source packets > > have to be described in the SDP. So, a transport protocol > > identifier is required. > > > > -acbegen > > > > > -----Original Message----- > > > From: fecframe-bounces@ietf.org > > [mailto:fecframe-bounces@ietf.org] On > > > Behalf Of David Harrington > > > Sent: Friday, October 01, 2010 11:39 PM > > > To: fecframe@ietf.org; 'TSV Dir' > > > Cc: fecframe-chairs@tools.ietf.org; iesg@ietf.org > > > Subject: Re: [Fecframe] [IANA #394228] RE: > > > LastCall: > > > (SessionDescriptionProtocol > > > (SDP) Elements for FEC Framework) toProposed Standard > > > > > > Hi fecframe, > > > > > > I didn't like this much when I did my AD review and I still don't. > > > I think this puts tremendous load on IANA to do this for us > > > automatically for every current and future registration. > > > Can we please design a different approach to FEC registration. > > > I think there must be a simpler manner to do this. > > > > > > TSVDIR, can you suggest a better approach for this? > > > > > > David Harrington > > > Director, IETF Transport Area > > > ietfdbh@comcast.net (preferred for ietf) > > > dbharrington@huaweisymantec.com > > > +1 603 828 1401 (cell) > > > > > > > -----Original Message----- > > > > From: iesg-bounces@ietf.org > > [mailto:iesg-bounces@ietf.org] On Behalf > > > > Of Amanda Baber via RT > > > > Sent: Friday, October 01, 2010 8:53 PM > > > > Cc: fecframe-chairs@tools.ietf.org; abegen@cisco.com; > > iesg@ietf.org > > > > Subject: [IANA #394228] RE: Last > > > > Call: (Session > > > > DescriptionProtocol (SDP) Elements for FEC Framework) to > Proposed > > > > Standard > > > > > > > > Hi Ali, > > > > > > > > Just to make sure we understand what you're asking for: you want >=20 > > > > this document to modify the registration procedures for the > proto > > > > registry to be modified so that for every current and future > > > > registration -- RTP/AVP, vat, TCP, et al. -- IANA would also > > > > automatically register FEC/RTP/AVP, FEC/vat, FEC/TCP, and so on? > > > > > > > > This sounds like a decision for the ADs. We're able do this > > > > -- we'd just have to insert a note in the registry instructing > > > > ourselves to do it -- but we can't think of any other registries >=20 > > > > that behave this way. > > > > > > > > Thanks, > > > > > > > > Amanda > > > > IANA > > > > > > > > On Thu Sep 23 19:55:01 2010, abegen@cisco.com wrote: > > > > > Hi Amanda, > > > > > > > > > > We cleared the earlier issues with this draft. However, > > during the > > > > > IESG review something came up. This is about section 4.1. > In > > > > > addition to registering UDP/FEC, we also need several other > > > > > registrations for FEC/ for the proto's listed > > in the SDP > > > > > registry. I wonder how we can do this effectively. A > shortcut > > > > > maybe? > > > > > > > > > > I am probably pushing the limit here. But I wonder whether we > > > could > > > > > define something here so that when a new proto is > > > > registered in the > > > > > future, FEC/ can also be automatically > > registered based > > > on > > > > > this draft. > > > > > > > > > > I am about to revise this draft. I would appreciate if you > > > > could tell > > > > > me what I should put in section 8.1 regarding the above. > > > > > > > > > > Thanks in advance. > > > > > > > > > > -acbegen > > > > > > > > > > > -----Original Message----- > > > > > > From: Amanda Baber via RT [mailto:drafts-lastcall@iana.org] > > > > > > Sent: Friday, September 10, 2010 3:05 PM > > > > > > Cc: Ali C. Begen (abegen); fecframe-chairs@tools.ietf.org; > > > > > iesg@ietf.org > > > > > > Subject: [IANA #386944] Last Call: > > > > elements-08.txt> (Session Description Protocol (SDP) > Elements > > > for > > > > > > FEC Framework) to Proposed Standard > > > > > > > > > > > > IESG: > > > > > > > > > > > > IANA has reviewed > > > > draft-ietf-fecframe-sdp-elements-08.txt, which is > > > > > > currently in Last Call, and has the following comments: > > > > > > > > > > > > IANA has questions about this document. > > > > > > > > > > > > IANA understands that, upon approval of this document, > > > > there are two > > > > > > IANA Actions that need to be completed. > > > > > > > > > > > > First, in the proto type subregistry of the Session > > Description > > > > > Protocol > > > > > > (SDP) Parameters located at: > > > > > > > > > > > > http://www.iana.org/assignments/sdp-parameters > > > > > > > > > > > > a single new value is to be registered: > > > > > > > > > > > > Type SDP Name Reference > > > > > > ----- ---------- ----------- > > > > > > proto UDP/FEC [RFC-to-be] > > > > > > > > > > > > Second, in one of the att-field subregistries of the Session > > > > > Description > > > > > > Protocol (SDP) Parameters located at: > > > > > > > > > > > > http://www.iana.org/assignments/sdp-parameters > > > > > > > > > > > > three new attribute names are to be added as follows: > > > > > > > > > > > > SDP Attribute ("att-field"): > > > > > > Attribute name: fec-source-flow > > > > > > Long form: Pointer to FEC Source Flow Type of name: > > > > att-field Type > > > > > > of attribute: Media level Subject to charset: No > > > > > > Purpose: Provide parameters for an FEC source flow > > > > > > Reference: [RFC-to-be] > > > > > > Values: See [RFC-to-be] > > > > > > > > > > > > SDP Attribute ("att-field"): > > > > > > Attribute name: fec-repair-flow > > > > > > Long form: Pointer to FEC Repair Flow Type of name: > > > > att-field Type > > > > > > of attribute: Media level Subject to charset: No > > > > > > Purpose: Provide parameters for an FEC repair flow > > > > > > Reference: [RFC-to-be] > > > > > > Values: See [RFC-to-be] > > > > > > > > > > > > SDP Attribute ("att-field"): > > > > > > Attribute name: repair-window > > > > > > Long form: Pointer to FEC Repair Window Type of name: > > > > att-field Type > > > > > > of attribute: Media level Subject to charset: No > > > > > > Purpose: Indicate the size of the repair window > > > > > > Reference: [RFC-to-be] > > > > > > Values: See [RFC-to-be] > > > > > > > > > > > > IANA has a question about these registrations. There are > four > > > att- > > > > > field > > > > > > registries: one for session level attributes, one for both > > > session > > > > > and > > > > > > media level attributes, one for media level attributes > > > > only, one for > > > > > > source level, and a final one for attributes for > > unknown levels. > > > > > Which > > > > > > of these subregistries are these three attribute names to be > > > added > > > > > to? > > > > > > > > > > > > After clarification, IANA understands that these are the > only > > > > > actions > > > > > > required upon approval of the document. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Amanda Baber > > > > > > IANA > > > > > > > > > > > > On Fri Aug 27 15:50:26 2010, noreply@ietf.org wrote: > > > > > > > > > > > > > > The IESG has received a request from the FEC Framework WG > > > > > (fecframe) to > > > > > > > consider the following document: > > > > > > > - 'Session Description Protocol (SDP) Elements for FEC > > > > Framework' > > > > > > > as a > > > > Proposed Standard > > > > > > > > > > > > > > The IESG plans to make a decision in the next few weeks, > and > > > > > solicits > > > > > > > final comments on this action. Please send substantive > > > > comments to > > > > > the > > > > > > > ietf@ietf.org mailing lists by 2010-09-10. > > > > 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. > > > > > > > > > > > > > > The file can be obtained via > > > > > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-fecframe-sdp-elements/ > > > > > > > > > > > > > > IESG discussion can be tracked via > > > > > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-fecframe-sdp-elements/ > > > > > > > > > > > > > > > > > > > > > No IPR declarations were found that appear related to this > > > I-D. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Fecframe mailing list > > > Fecframe@ietf.org > > > https://www.ietf.org/mailman/listinfo/fecframe From csp@csperkins.org Wed Oct 6 01:49: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 86F273A6EEC; Wed, 6 Oct 2010 01:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.351 X-Spam-Level: X-Spam-Status: No, score=-103.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 69is967FTW95; Wed, 6 Oct 2010 01:49:26 -0700 (PDT) Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by core3.amsl.com (Postfix) with ESMTP id 378B43A6E47; Wed, 6 Oct 2010 01:49:26 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1P3Phh-0005Ez-h6; Wed, 06 Oct 2010 08:50:25 +0000 Message-Id: <603215C3-7B2B-4D09-B73F-47911260A68E@csperkins.org> From: Colin Perkins To: Ali C. Begen (abegen) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540D4FA7F5@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 6 Oct 2010 09:16:33 +0100 References: <20100827154930.23394.79420.idtracker@localhost><04CAD96D4C5A3D48B1919248A8FE0D540D39EB01@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FA7CE@xmb-sjc-215.amer.cisco.com> <44AFD509E30B4B80B78CC344ECC1A5E6@23FX1C1> <04CAD96D4C5A3D48B1919248A8FE0D540D4FA7F5@xmb-sjc-215.amer.cisco.com> X-Mailer: Apple Mail (2.936) Cc: fecframe-chairs@tools.ietf.org, iesg@ietf.org, fecframe@ietf.org, TSV Dir Subject: Re: [Fecframe] [IANA #394228] RE: LastCall: (SessionDescriptionProtocol (SDP) Elements for FEC Framework) toProposed Standard 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, 06 Oct 2010 08:49:27 -0000 Hi, On 2 Oct 2010, at 12:34, Ali C. Begen (abegen) wrote: >> -----Original Message----- >> From: David Harrington [mailto:ietfdbh@comcast.net] >> Sent: Saturday, October 02, 2010 12:53 AM >> To: Ali C. Begen (abegen); fecframe@ietf.org; 'TSV Dir' >> Cc: fecframe-chairs@tools.ietf.org; iesg@ietf.org >> Subject: RE: [Fecframe] [IANA #394228] RE: LastCall:> fecframe-sdp-elements-08.txt> (SessionDescriptionProtocol >> (SDP) Elements for FEC Framework) toProposed Standard >> >> Hi Ali, >> >> Thanks for responding. >> I probably should have questioned this more during AD Review. I did >> think it an odd design, but there was apparently WG consensus, so I >> didn't bother to raise my questions. My bad. >> >> When you say "someone wants to use it as a source flow in the fec >> framework", this is not very clear. The fec framework is an >> abstract description of how things fit together. Within the fec >> framework, we have multiple fec schemes. Is each fec scheme >> designed to protect specific types of source flows? > > Right, framework draft explains the framework itself. The FEC > schemes may have individual requirements for the source (input) > flows. In some source flows, sequence numbers will already exist to > allow the receiver to identify them uniquely (like RTP). In other > source flows (such as UDP), there won't be a seqnum which means > something needs to be added at the end of the source packets > (explicit source fec payload id). However, once we do that, we > cannot describe those packets as regular UDP packets since it would > be misleading. Instead, we use FEC/ in the SDP. This way, a > receiver that does not implement the framework will not be able to > parse FEC/ line and it will not try to use that flow. > >> When you say "someone wants to use it as a source flow in the fec >> framework", is the someone the editor of a fec scheme specification? > > Suppose your source flow is UDP. And you wanna apply FEC on it. So, > you append the explicit source fec payload id. Now, in the SDP you > should use "FEC/UDP." But I think you can only do it if it has been > registered with IANA. It does not matter who does the registration. > If an FEC scheme draft registers it, others can use it as well since > "FEC/UDP" part is common (different FEC schemes will be identified > based on their encoding IDs anyway). > > So bottom line is, either the SDP draft registers it or an FEC > scheme draft that plans to use UDP flows as source flows registers > it. Once it is registered, other FEC schemes can use the same > registration. > >> is "it" a registered identifier? >> What exactly does the identifer identify? >> Does that identifier identify a specific fec scheme for a specific >> type of source flow? >> Would it make sense for a fec scheme specification document to >> register the specific relevant identifiers? > > I hope my answer above answers all these questions. FEC schemes are > identified by their encoding IDs not protocol identifiers. > >> Please try to be very explicit in your response, so I can understand >> this better. >> It might help to avoid using pronouns like "someone", "it", and >> phrases like "the ones we care about" >> I care about all standard protocols ;-) Which ones do you care about? > > Sure. Certain protocols will unlikely to be used with FEC (e.g., > TCP). And for RTP and DCCP (which has its own seqnums), we don't > need a new identifier. So, to me UDP is the #1 candidate :) So we > can do the registration for UDP and leave the rest for future FEC > scheme drafts. I'm also uncomfortable with the idea of automatic registration of SDP proto values, since it's not clear that they all make sense to use with FEC. What's the reason for this, rather than just registering them when needed? -- Colin Perkins http://csperkins.org/ From abegen@cisco.com Wed Oct 6 11:11:37 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 76E783A7031; Wed, 6 Oct 2010 11:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.551 X-Spam-Level: X-Spam-Status: No, score=-10.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 niC6mjX5WcXf; Wed, 6 Oct 2010 11:11:35 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D41BA3A6CB5; Wed, 6 Oct 2010 11:11:33 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJZYrEyrR7H+/2dsb2JhbACiS3GqR5w0ghpZglQEhFGIdw X-IronPort-AV: E=Sophos;i="4.57,292,1283731200"; d="scan'208";a="265525918" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 06 Oct 2010 18:12:34 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o96ICYeS011138; Wed, 6 Oct 2010 18:12:34 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Oct 2010 11:12:30 -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, 6 Oct 2010 11:11:54 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D4FB31C@xmb-sjc-215.amer.cisco.com> In-Reply-To: <603215C3-7B2B-4D09-B73F-47911260A68E@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] [IANA #394228] RE: LastCall: (SessionDescriptionProtocol (SDP) Elements for FEC Framework) toProposed Standard Thread-Index: ActlM4bQhaTurVVURKuoT8hi9WFgGgATfyTw References: <20100827154930.23394.79420.idtracker@localhost><04CAD96D4C5A3D48B1919248A8FE0D540D39EB01@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FA7CE@xmb-sjc-215.amer.cisco.com> <44AFD509E30B4B80B78CC344ECC1A5E6@23FX1C1> <04CAD96D4C5A3D48B1919248A8FE0D540D4FA7F5@xmb-sjc-215.amer.cisco.com> <603215C3-7B2B-4D09-B73F-47911260A68E@csperkins.org> From: "Ali C. Begen (abegen)" To: "Colin Perkins" X-OriginalArrivalTime: 06 Oct 2010 18:12:30.0934 (UTC) FILETIME=[0AAB3F60:01CB6582] Cc: fecframe-chairs@tools.ietf.org, iesg@ietf.org, fecframe@ietf.org, TSV Dir Subject: Re: [Fecframe] [IANA #394228] RE: LastCall: (SessionDescriptionProtocol (SDP) Elements for FEC Framework) toProposed Standard 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, 06 Oct 2010 18:11:37 -0000 > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Wednesday, October 06, 2010 4:17 PM > To: Ali C. Begen (abegen) > Cc: David Harrington; fecframe@ietf.org; TSV Dir; = fecframe-chairs@tools.ietf.org; iesg@ietf.org > Subject: Re: [Fecframe] [IANA #394228] RE: = LastCall: = (SessionDescriptionProtocol > (SDP) Elements for FEC Framework) toProposed Standard >=20 > Hi, >=20 > On 2 Oct 2010, at 12:34, Ali C. Begen (abegen) wrote: > >> -----Original Message----- > >> From: David Harrington [mailto:ietfdbh@comcast.net] > >> Sent: Saturday, October 02, 2010 12:53 AM > >> To: Ali C. Begen (abegen); fecframe@ietf.org; 'TSV Dir' > >> Cc: fecframe-chairs@tools.ietf.org; iesg@ietf.org > >> Subject: RE: [Fecframe] [IANA #394228] RE: LastCall: >> fecframe-sdp-elements-08.txt> (SessionDescriptionProtocol > >> (SDP) Elements for FEC Framework) toProposed Standard > >> > >> Hi Ali, > >> > >> Thanks for responding. > >> I probably should have questioned this more during AD Review. I did > >> think it an odd design, but there was apparently WG consensus, so I > >> didn't bother to raise my questions. My bad. > >> > >> When you say "someone wants to use it as a source flow in the fec > >> framework", this is not very clear. The fec framework is an > >> abstract description of how things fit together. Within the fec > >> framework, we have multiple fec schemes. Is each fec scheme > >> designed to protect specific types of source flows? > > > > Right, framework draft explains the framework itself. The FEC > > schemes may have individual requirements for the source (input) > > flows. In some source flows, sequence numbers will already exist to > > allow the receiver to identify them uniquely (like RTP). In other > > source flows (such as UDP), there won't be a seqnum which means > > something needs to be added at the end of the source packets > > (explicit source fec payload id). However, once we do that, we > > cannot describe those packets as regular UDP packets since it would > > be misleading. Instead, we use FEC/ in the SDP. This way, a > > receiver that does not implement the framework will not be able to > > parse FEC/ line and it will not try to use that flow. > > > >> When you say "someone wants to use it as a source flow in the fec > >> framework", is the someone the editor of a fec scheme = specification? > > > > Suppose your source flow is UDP. And you wanna apply FEC on it. So, > > you append the explicit source fec payload id. Now, in the SDP you > > should use "FEC/UDP." But I think you can only do it if it has been > > registered with IANA. It does not matter who does the registration. > > If an FEC scheme draft registers it, others can use it as well since > > "FEC/UDP" part is common (different FEC schemes will be identified > > based on their encoding IDs anyway). > > > > So bottom line is, either the SDP draft registers it or an FEC > > scheme draft that plans to use UDP flows as source flows registers > > it. Once it is registered, other FEC schemes can use the same > > registration. > > > >> is "it" a registered identifier? > >> What exactly does the identifer identify? > >> Does that identifier identify a specific fec scheme for a specific > >> type of source flow? > >> Would it make sense for a fec scheme specification document to > >> register the specific relevant identifiers? > > > > I hope my answer above answers all these questions. FEC schemes are > > identified by their encoding IDs not protocol identifiers. > > > >> Please try to be very explicit in your response, so I can = understand > >> this better. > >> It might help to avoid using pronouns like "someone", "it", and > >> phrases like "the ones we care about" > >> I care about all standard protocols ;-) Which ones do you care = about? > > > > Sure. Certain protocols will unlikely to be used with FEC (e.g., > > TCP). And for RTP and DCCP (which has its own seqnums), we don't > > need a new identifier. So, to me UDP is the #1 candidate :) So we > > can do the registration for UDP and leave the rest for future FEC > > scheme drafts. >=20 >=20 > I'm also uncomfortable with the idea of automatic registration of SDP > proto values, since it's not clear that they all make sense to use > with FEC. What's the reason for this, rather than just registering > them when needed? I guess the goal was when someone defined a new proto, they would not = necessarily be aware of the fec framework and later one wanted to use = that proto with fec framework, he would need a registration (which = requires a new spec).=20 But, I am pretty much fine with removing that part and simply = registering UDP for now. Unless anybody has any objections, I will = revise the draft and we can publish it? Any objections? -acbegen =20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 From abegen@cisco.com Sat Oct 9 08:35:46 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 D106D3A6868 for ; Sat, 9 Oct 2010 08:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 SofzvnUM2gAA for ; Sat, 9 Oct 2010 08:35:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id F41943A67EF for ; Sat, 9 Oct 2010 08:35:13 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0FAEcosEyrR7Ht/2dsb2JhbACDH5EqjSBbcZ47ihmSE4EigzF0BIRRiHc X-IronPort-AV: E=Sophos;i="4.57,308,1283731200"; d="scan'208";a="601571570" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 09 Oct 2010 15:36:16 +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 o99FaG8x004772 for ; Sat, 9 Oct 2010 15:36:16 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 9 Oct 2010 08:36:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sat, 9 Oct 2010 08:36:11 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D5BF354@xmb-sjc-215.amer.cisco.com> In-Reply-To: <20101009153240.08D203A68BE@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-fecframe-sdp-elements-10 Thread-Index: Actnx3cd312uDQ1MQomlDQgKJoPsWAAAAtsg References: <20101009153240.08D203A68BE@core3.amsl.com> From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 09 Oct 2010 15:36:16.0668 (UTC) FILETIME=[B66905C0:01CB67C7] Subject: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-sdp-elements-10 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: Sat, 09 Oct 2010 15:35:46 -0000 VGhpcyB2ZXJzaW9uIHNob3VsZCBhZGRyZXNzIGFsbCB0aGUgb3V0c3RhbmRpbmcgY29tbWVudHMg ZnJvbSB0aGUgSUVTRy4NCg0KRm9yIGRpZmYsIHBsZWFzZSBzZWU6DQpodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWZlY2ZyYW1lLXNkcC1lbGVtZW50cy8jaGlzdG9y eSANCg0KLWFjYmVnZW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElFVEYg SS1EIFN1Ym1pc3Npb24gVG9vbCBbbWFpbHRvOmlkc3VibWlzc2lvbkBpZXRmLm9yZ10gDQpTZW50 OiBTYXR1cmRheSwgT2N0b2JlciAwOSwgMjAxMCAxMTozMyBQTQ0KVG86IEFsaSBDLiBCZWdlbiAo YWJlZ2VuKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRm LWZlY2ZyYW1lLXNkcC1lbGVtZW50cy0xMCANCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtaWV0Zi1mZWNmcmFtZS1zZHAtZWxlbWVudHMtMTAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgQWxpIEJlZ2VuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9y eS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1pZXRmLWZlY2ZyYW1lLXNkcC1lbGVtZW50cw0KUmV2aXNp b246CSAxMA0KVGl0bGU6CQkgU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCBFbGVtZW50cyBm b3IgRkVDIEZyYW1ld29yaw0KQ3JlYXRpb25fZGF0ZToJIDIwMTAtMTAtMDkNCldHIElEOgkJIGZl Y2ZyYW1lDQpOdW1iZXJfb2ZfcGFnZXM6IDE5DQoNCkFic3RyYWN0Og0KVGhpcyBkb2N1bWVudCBz cGVjaWZpZXMgdGhlIHVzZSBvZiBTZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFApDQp0 byBkZXNjcmliZSB0aGUgcGFyYW1ldGVycyByZXF1aXJlZCB0byBzaWduYWwgdGhlIEZvcndhcmQg RXJyb3INCkNvcnJlY3Rpb24gKEZFQykgRnJhbWV3b3JrIENvbmZpZ3VyYXRpb24gSW5mb3JtYXRp b24gYmV0d2VlbiB0aGUNCnNlbmRlcihzKSBhbmQgcmVjZWl2ZXIocykuICBUaGlzIGRvY3VtZW50 IGFsc28gcHJvdmlkZXMgZXhhbXBsZXMgdGhhdA0Kc2hvdyB0aGUgc2VtYW50aWNzIGZvciBncm91 cGluZyBtdWx0aXBsZSBzb3VyY2UgYW5kIHJlcGFpciBmbG93cw0KdG9nZXRoZXIgZm9yIHRoZSBh cHBsaWNhdGlvbnMgdGhhdCBzaW11bHRhbmVvdXNseSB1c2UgbXVsdGlwbGUNCmluc3RhbmNlcyBv ZiB0aGUgRkVDIEZyYW1ld29yay4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdC4NCg0KDQo= From root@core3.amsl.com Sat Oct 9 08:45:23 2010 Return-Path: X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6AFFE3A687E; Sat, 9 Oct 2010 08:45:04 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101009154517.6AFFE3A687E@core3.amsl.com> Date: Sat, 9 Oct 2010 08:45:01 -0700 (PDT) Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-sdp-elements-10.txt 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: Sat, 09 Oct 2010 15:45:23 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FEC Framework Working Group of the IETF. Title : Session Description Protocol Elements for FEC Framework Author(s) : A. Begen Filename : draft-ietf-fecframe-sdp-elements-10.txt Pages : 19 Date : 2010-10-09 This 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). This document also provides examples that show the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-sdp-elements-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-fecframe-sdp-elements-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-09083238.I-D@ietf.org> --NextPart-- From wwwrun@rfc-editor.org Thu Oct 14 10:12:32 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 56A693A6B95; Thu, 14 Oct 2010 10:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.045 X-Spam-Level: X-Spam-Status: No, score=-102.045 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, 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 qNokZLf0+zMH; Thu, 14 Oct 2010 10:12:29 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 1D3DC3A6B77; Thu, 14 Oct 2010 10:12:27 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BF611E06FD; Thu, 14 Oct 2010 10:13:45 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20101014171345.BF611E06FD@rfc-editor.org> Date: Thu, 14 Oct 2010 10:13:45 -0700 (PDT) Cc: fecframe@ietf.org, rfc-editor@rfc-editor.org Subject: [Fecframe] RFC 6015 on RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC) 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: Thu, 14 Oct 2010 17:12:32 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6015 Title: RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC) Author: A. Begen Status: Standards Track Stream: IETF Date: October 2010 Mailbox: abegen@cisco.com Pages: 31 Characters: 65399 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-fecframe-interleaved-fec-scheme-09.txt URL: http://www.rfc-editor.org/rfc/rfc6015.txt This document defines a new RTP payload format for the Forward Error Correction (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP. The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The 1-D interleaved parity code offers a good protection against bursty packet losses at a cost of reasonable complexity. The new payload format defined in this document should only be used (with some exceptions) as a part of the Digital Video Broadcasting-IPTV (DVB- IPTV) Application-layer FEC specification. [STANDARDS-TRACK] This document is a product of the FEC Framework Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From root@core3.amsl.com Wed Oct 20 22:45:33 2010 Return-Path: X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D0C3B3A6994; Wed, 20 Oct 2010 22:45:07 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101021054518.D0C3B3A6994@core3.amsl.com> Date: Wed, 20 Oct 2010 22:45:07 -0700 (PDT) Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-sdp-elements-11.txt 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: Thu, 21 Oct 2010 05:45:37 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FEC Framework Working Group of the IETF. Title : Session Description Protocol Elements for FEC Framework Author(s) : A. Begen Filename : draft-ietf-fecframe-sdp-elements-11.txt Pages : 19 Date : 2010-10-20 This 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). This document also provides examples that show the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-sdp-elements-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-fecframe-sdp-elements-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-20224454.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Fri Oct 22 06:51:48 2010 Return-Path: X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 29CBC28C0D7; Fri, 22 Oct 2010 06:51:47 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20101022135148.29CBC28C0D7@core3.amsl.com> Date: Fri, 22 Oct 2010 06:51:48 -0700 (PDT) Cc: fecframe chair , Internet Architecture Board , fecframe mailing list , RFC Editor Subject: [Fecframe] Protocol Action: 'Session Description Protocol Elements for FEC Framework' to Proposed Standard 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: Fri, 22 Oct 2010 13:51:48 -0000 The IESG has approved the following document: - 'Session Description Protocol Elements for FEC Framework ' as a Proposed Standard This document is the product of the FEC Framework Working Group. The IESG contact persons are David Harrington and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-sdp-elements-11.txt 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. Personnel Document Shepherd - Greg Shepherd Responsible Area Director - David Harrington (ietfdbh@comcast.net) 'The IANA Expert for the registries in this document is Ali Begen mailto:abegen@cisco.com ' From gjshep@gmail.com Tue Oct 26 10:12:08 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 425273A69C4 for ; Tue, 26 Oct 2010 10:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.765 X-Spam-Level: X-Spam-Status: No, score=-102.765 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, 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 t8+qkfOLLLYI for ; Tue, 26 Oct 2010 10:12:05 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B07423A69A6 for ; Tue, 26 Oct 2010 10:12:03 -0700 (PDT) Received: by fxm9 with SMTP id 9so3806845fxm.31 for ; Tue, 26 Oct 2010 10:13:50 -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=EC2Ni98ht41wfs51bhhwMV33JjigdjjdyMTHdr4O3wY=; b=MxFx21zhwPzlsNNfYFJ8iPX6ZlUoUtGF6qCNLMCfnT9ozihIKw1abwQVtrknf+gyAN X5sKj8okX7XTfzqjdgRZz9N43c2xcq/mVEMrBoeunR4jtGBa2mGHPLdbpfGDTO6BIZnh sfQnailN+1HicoG7zRcugtlkgbM42wHqilucA= 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=qNkDAuIWT9r7GHao3K//zGAQ8jLD0ZqWOtAuMzWHKNFSXr8nPYBgmlmjS/CPHjrS5Z Lz2DGVfvpUdYoe1sEu7ISQh2Fz3A8gO1AkKNsBa5KOVXUtuox320wsNoGz34cLz7JP1T VpQfzYr7FUF9iT3aTlMmxBTFVTIOBcG9HdNUc= MIME-Version: 1.0 Received: by 10.223.86.143 with SMTP id s15mr1093536fal.44.1288113230771; Tue, 26 Oct 2010 10:13:50 -0700 (PDT) Received: by 10.223.116.204 with HTTP; Tue, 26 Oct 2010 10:13:50 -0700 (PDT) Date: Tue, 26 Oct 2010 10:13:50 -0700 Message-ID: From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Fecframe] Call For Agenda Items 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, 26 Oct 2010 17:12:08 -0000 *, Please send all agenda items my way soon so we can get it published before we fly out. Getting close now.. We have the bulk of our drafts moved to pub req with only a couple left. This may be our last meeting if all goes well, but one more after this at the most is my expectation. Thanks, Greg From stewe@stewe.org Fri Oct 29 09:56: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 21F403A6800; Fri, 29 Oct 2010 09:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 tjEe6honV-nv; Fri, 29 Oct 2010 09:56:39 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 085EB3A67F3; Fri, 29 Oct 2010 09:56:36 -0700 (PDT) Received: from [192.168.1.108] (unverified [24.5.132.232]) by stewe.org (SurgeMail 3.9e) with ESMTP id 8650-1743317 for multiple; Fri, 29 Oct 2010 18:57:41 +0200 User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Fri, 29 Oct 2010 09:57:34 -0700 From: Stephan Wenger To: , , , , Message-ID: Thread-Topic: MPEG liaison statements received Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3371191060_918748" X-Originating-IP: 24.5.132.232 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.132.232) was found in the spamhaus database. http://www.spamhaus.net Cc: Gonzalo.Camarillo@ericsson.com, rjsparks@nostrum.com Subject: [Fecframe] MPEG liaison statements received 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: Fri, 29 Oct 2010 16:56:40 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3371191060_918748 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi all, The IETF has received from MPEG two liaison statements for our information. No actions from the IETF side are requested or required. Both statements will appear shortly on the IETF's liaison website https://datatracker.ietf.org/liaison/ n11632 informs us that their http streaming project has reached the Committee Draft" (CD) approval level. n11633 informs us that the joint IPTV project with the ITU Q13/16 has also reached CD level. Some of you may remember those assorted IPTV workshops of the ITU and MPEG in 2008 and 2009; this is the outcome of the project started back then. In contrast to n11632, n11633 contains the CD text of four future standards in winword format. For those unaware of ISO's approval process, a CD is the first step in a five (?) step approval process that ultimately ends in an International Standard (IS). At CD level, the key architectural design decisions are frozen, but other technical input is still possible. In IETF terms, it's probably a maturity level that a WG I-D has after a couple of iterations. Regards, Stephan --B_3371191060_918748 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi all,

=
The IETF has received from MPEG two liaison statements for our informat= ion.  No actions from the IETF side are requested or required.  Bo= th statements will appear shortly on the IETF's liaison website https://datatracker.ietf.org/liaison= /

n11632 informs us that their http streaming p= roject has reached the Committee Draft" (CD) approval level.  

n11633 informs us that the joint IPTV project with the ITU = Q13/16 has also reached CD level.  Some of you may remember those assor= ted IPTV workshops of the ITU and MPEG in 2008 and 2009; this is the outcome= of the project started back then.  In contrast to n11632, n11633 conta= ins the CD text of four future standards in winword format.

For those unaware of ISO's approval process, a CD is the first step= in a five (?) step approval process that ultimately ends in an Internationa= l Standard (IS).  At CD level, the key architectural design decisions a= re frozen, but other technical input is still possible.  In IETF terms,= it's probably a maturity level that a WG I-D has after a couple of iteratio= ns.

Regards,
Stephan

= --B_3371191060_918748--