From fecframe-bounces@ietf.org Wed Apr 04 11:45:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7fp-0004k7-SH; Wed, 04 Apr 2007 11:45:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7fp-0004k2-E1 for fecframe@ietf.org; Wed, 04 Apr 2007 11:45:25 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ7fn-0003u6-3M for fecframe@ietf.org; Wed, 04 Apr 2007 11:45:25 -0400 Received: by ug-out-1314.google.com with SMTP id 72so677631ugd for ; Wed, 04 Apr 2007 08:45:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=tJX/IxyXPrV6QGumvrenbv0dagJ/U1hBNmdoGADKym0zYaBGYtmwsjen1QKI4wbHLX+bZaMe4239LK9YMxJ8N/+QjDmH0836PA9a0B9XimK6pffLoumncyrhXrfmW3pPB8EAESOboiwO76iwS/lR0yBqdrvBPtn+yUQyQOqMYCU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=D7FgYaUkLfZ6gMkr2zF+D2eH6fRlLRm/GgvpEqz6hGidYeIa8P8bFZcZxXfqoV13d/kpezZRJbbjyU8lv0tNjuRaQLJv1uTk/BHIIgEE2RM55Wx7SoucjLt/pf6EYOC5wWVSycIIh3DWYs7hNEmDPadTaAdbwvyBtCfXADh7DEI= Received: by 10.78.138.6 with SMTP id l6mr120473hud.1175701521517; Wed, 04 Apr 2007 08:45:21 -0700 (PDT) Received: by 10.78.14.18 with HTTP; Wed, 4 Apr 2007 08:45:21 -0700 (PDT) Message-ID: <38c19b540704040845p1c226f2bt219fbf99bbd4db4c@mail.gmail.com> Date: Wed, 4 Apr 2007 08:45:21 -0700 From: "Greg Shepherd" To: fecframe@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Subject: [Fecframe] Minutes X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1245852905==" Errors-To: fecframe-bounces@ietf.org --===============1245852905== Content-Type: multipart/alternative; boundary="----=_Part_20676_22362754.1175701521428" ------=_Part_20676_22362754.1175701521428 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline *, Here are the minutes from Prague. Please review them for sanity before I post them later this week. Mark presenting FECframe document update: - requirement status is frozen, no comments since ietf67 - open issues: - Fec scheme requirements - Most requirements can be likely imported from RMT - Lorenzo: feedback from RMT: good to have this scheme definition to have good quality of resulting FEC drafts later on - Q: are there any transport specific considerations - considered: UDP and DCCP - Rajiv Asati: L4 ? Yes. - Q: has RTP been cnsidered ? Currently arbitrary flow across UDP - includes of course RTP (on top of RTP). A: nothing specific to RTP currently. RTP is on top of UDP. Other groups (DVB) have tried to do this. Pro and Cons of trying to be specific to RTP. - James Wendel/Microsoft: RTP is also a framework in itself. there are fields in RTP obvious you wold want to exploit. RTP is for time critical flows. Some impact on semantics too. - Greg/Mark: Specific FEC scheme could rely on existing RTP fields and not need to add them to it's own header. ALso backward compatible - Lorenzo: Hybrid scheme possible ? (Header format that is flexible to be optimized with RTP as payload vs. non RTP payload). Mark: Mostly documentation issue. - CMagnus: (didn't understand what he said) - Lorenzo: Add permanent piece of header and optional header only present when payload is not RTP. - Magnus: probably not useful from complexity perspective. - sdp elements... description of properties of toolkit of SDP elements to be used in content delivery protocols. Not normative, but indicidual FEC schemes may choose to use them. - transport protocol identifiers for FEC repair flows - Association of source flows to repair flow - FEC-scheme specific configuration - Greg: Rosetta stone draft needed describing where information is being pulled in from (RMT specs, etc..) - Rajiv: Why SDP ? Mark: Not manadated, optional. - SPD requires coordination with mmusic, avt and rmt. Next Steps: - Streaming Content Delivery Protocol. Need to defne a specific protocol, maybe based on SDP toolkit, provide explicit example cases. Have an example of a concrete example of how to use the framework. - Greg/Mark: separate document from Framework. - (Unnamed) Proposal: Just use XOR as a simple example - Lorenzo: What plans to take from what RMT did ? - Mark: Could be lot of reuse of RMT work. Maybe just a few pages spec in FEC frame and refer to an algorithm defined in RMT. - Mark: Do we want to systematically pull in RMT ? Probably not, leave it up to proponents of individual schemes. - Lorenzo: IANA registration defined ? - Mark: not yet. Probably in future. Three choices: - Dfine when signaling of FEC is defined - Do same thing as RMT did (signaling independent code space) - Directly clone/reuse RMT defined code space. - Rajiv: Preferred solution to reuse work from RMT - Magnus: Only 256 code points in RMT definition. Maybe too little. Especially with dynamic mapping. Thanks, Greg ------=_Part_20676_22362754.1175701521428 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline *,

Here are the minutes from Prague. Please review them for sanity before I post them later this week.

Mark presenting FECframe document update:
  - requirement status is frozen, no comments since ietf67
  - open issues:

    - Fec scheme requirements

      - Most requirements can be likely imported from RMT

      - Lorenzo: feedback from RMT: good to have this scheme definition
        to have good quality of resulting FEC drafts later on

    - Q: are there any transport specific considerations
      - considered: UDP and DCCP
      - Rajiv Asati: L4 ? Yes.
      - Q: has RTP been cnsidered ? Currently arbitrary flow across
        UDP - includes of course RTP (on top of RTP). A: nothing specific
    to RTP currently. RTP is on top of UDP. Other groups (DVB) have
    tried to do this. Pro and Cons of trying to be specific to RTP.
      - James Wendel/Microsoft: RTP is also a framework in itself.
        there are fields in RTP obvious you wold want to exploit. RTP
    is for time critical flows. Some impact on semantics too.
      - Greg/Mark: Specific FEC scheme could rely on existing RTP fields
        and not need to add them to it's own header. ALso backward compatible
      - Lorenzo: Hybrid scheme possible ? (Header format that is flexible
        to be optimized with RTP as payload vs. non RTP payload).
    Mark: Mostly documentation issue.
      - CMagnus: (didn't understand what he said)
      - Lorenzo: Add permanent piece of header and optional header
        only present when payload is not RTP.
      - Magnus: probably not useful from complexity perspective.

    - sdp elements...
      description of properties of toolkit of SDP elements to be used
      in content delivery protocols. Not normative, but indicidual FEC
      schemes may choose to use them.
        - transport protocol identifiers for FEC repair flows
        - Association of source flows to repair flow
        - FEC-scheme specific configuration
      - Greg: Rosetta stone draft needed describing where information is
        being pulled in from (RMT specs, etc..)
      - Rajiv: Why SDP ? Mark: Not manadated, optional.
      - SPD requires coordination with mmusic, avt and rmt.

 Next Steps:
   - Streaming Content Delivery Protocol. Need to defne a specific protocol,
     maybe based on SDP toolkit, provide explicit example cases. Have
     an example of a concrete example of how to use the framework.
     - Greg/Mark: separate document from Framework.
     - (Unnamed) Proposal: Just use XOR as a simple example

 - Lorenzo: What plans to take from what RMT did ?
  - Mark: Could be lot of reuse of RMT work. Maybe just a few pages spec
    in FEC frame and refer to an algorithm defined in RMT.
  - Mark: Do we want to systematically pull in RMT ? Probably not,
    leave it up to proponents of individual schemes.
 - Lorenzo: IANA registration defined ?
  - Mark: not yet. Probably in future. Three choices:
    - Dfine when signaling of FEC is defined
    - Do same thing as RMT did (signaling independent code space)
    - Directly clone/reuse RMT defined code space.
  - Rajiv: Preferred solution to reuse work from RMT
  - Magnus: Only 256 code points in RMT definition. Maybe too little.
    Especially with dynamic mapping.

Thanks,
Greg
------=_Part_20676_22362754.1175701521428-- --===============1245852905== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe --===============1245852905==-- From fecframe-bounces@ietf.org Wed Apr 11 11:41:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbexL-0004Px-7L; Wed, 11 Apr 2007 11:41:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbexK-0004Ps-64 for fecframe@ietf.org; Wed, 11 Apr 2007 11:41:58 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbexJ-0006Xr-Kd for fecframe@ietf.org; Wed, 11 Apr 2007 11:41:58 -0400 Received: by ug-out-1314.google.com with SMTP id 72so124591ugd for ; Wed, 11 Apr 2007 08:41:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=nJJRGT/4RxwaTWoapZPsUyK7T9DR+9/SdMqV7YFC5PhOg0sAk6+UbAFLT3BAZeOh/cWygZ9frRJVTlqv4VKiDrZKSabEufeTfCvgWWNdU8cKAvyObNTx7XDq3YbGSlbJ1a1WmDLZy44B7S4jOlD2o9BH8sTcMeDShBWnruXR7ak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=seZSsfAq1dYkcqgS/CMJYGKcFKKiCDd64FP1yl7xpojr9OcJ1XMg8OZA6GnEjW1ES7rCqI/5lraoMxmVl3CzJXmG8DukBlRB3ZfZ8PBYg9eQ5TMq7nJypsIpUWYeV1ZUEpw2bxtthMCG9cekorgGCYwiXDRDA2FB/OTK+TwY3nA= Received: by 10.78.171.20 with SMTP id t20mr151148hue.1176306116418; Wed, 11 Apr 2007 08:41:56 -0700 (PDT) Received: by 10.78.43.3 with HTTP; Wed, 11 Apr 2007 08:41:56 -0700 (PDT) Message-ID: <38c19b540704110841idd7589epf7e82fcb47b8592c@mail.gmail.com> Date: Wed, 11 Apr 2007 08:41:56 -0700 From: "Greg Shepherd" To: fecframe@ietf.org In-Reply-To: <38c19b540704040845p1c226f2bt219fbf99bbd4db4c@mail.gmail.com> MIME-Version: 1.0 References: <38c19b540704040845p1c226f2bt219fbf99bbd4db4c@mail.gmail.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Subject: [Fecframe] Fwd: Minutes X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1170648798==" Errors-To: fecframe-bounces@ietf.org --===============1170648798== Content-Type: multipart/alternative; boundary="----=_Part_9370_17552786.1176306116358" ------=_Part_9370_17552786.1176306116358 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Again? Greg ---------- Forwarded message ---------- From: Greg Shepherd Date: Apr 4, 2007 8:45 AM Subject: Minutes To: fecframe@ietf.org *, Here are the minutes from Prague. Please review them for sanity before I post them later this week. Mark presenting FECframe document update: - requirement status is frozen, no comments since ietf67 - open issues: - Fec scheme requirements - Most requirements can be likely imported from RMT - Lorenzo: feedback from RMT: good to have this scheme definition to have good quality of resulting FEC drafts later on - Q: are there any transport specific considerations - considered: UDP and DCCP - Rajiv Asati: L4 ? Yes. - Q: has RTP been cnsidered ? Currently arbitrary flow across UDP - includes of course RTP (on top of RTP). A: nothing specific to RTP currently. RTP is on top of UDP. Other groups (DVB) have tried to do this. Pro and Cons of trying to be specific to RTP. - James Wendel/Microsoft: RTP is also a framework in itself. there are fields in RTP obvious you wold want to exploit. RTP is for time critical flows. Some impact on semantics too. - Greg/Mark: Specific FEC scheme could rely on existing RTP fields and not need to add them to it's own header. ALso backward compatible - Lorenzo: Hybrid scheme possible ? (Header format that is flexible to be optimized with RTP as payload vs. non RTP payload). Mark: Mostly documentation issue. - CMagnus: (didn't understand what he said) - Lorenzo: Add permanent piece of header and optional header only present when payload is not RTP. - Magnus: probably not useful from complexity perspective. - sdp elements... description of properties of toolkit of SDP elements to be used in content delivery protocols. Not normative, but indicidual FEC schemes may choose to use them. - transport protocol identifiers for FEC repair flows - Association of source flows to repair flow - FEC-scheme specific configuration - Greg: Rosetta stone draft needed describing where information is being pulled in from (RMT specs, etc..) - Rajiv: Why SDP ? Mark: Not manadated, optional. - SPD requires coordination with mmusic, avt and rmt. Next Steps: - Streaming Content Delivery Protocol. Need to defne a specific protocol, maybe based on SDP toolkit, provide explicit example cases. Have an example of a concrete example of how to use the framework. - Greg/Mark: separate document from Framework. - (Unnamed) Proposal: Just use XOR as a simple example - Lorenzo: What plans to take from what RMT did ? - Mark: Could be lot of reuse of RMT work. Maybe just a few pages spec in FEC frame and refer to an algorithm defined in RMT. - Mark: Do we want to systematically pull in RMT ? Probably not, leave it up to proponents of individual schemes. - Lorenzo: IANA registration defined ? - Mark: not yet. Probably in future. Three choices: - Dfine when signaling of FEC is defined - Do same thing as RMT did (signaling independent code space) - Directly clone/reuse RMT defined code space. - Rajiv: Preferred solution to reuse work from RMT - Magnus: Only 256 code points in RMT definition. Maybe too little. Especially with dynamic mapping. Thanks, Greg ------=_Part_9370_17552786.1176306116358 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Again?

Greg

---------- Forwarded message ----------
From: Greg Shepherd <gjshep@gmail.com>
Date: Apr 4, 2007 8:45 AM
Subject: Minutes
To: fecframe@ietf.org

*,

Here are the minutes from Prague. Please review them for sanity before I post them later this week.

Mark presenting FECframe document update:
  - requirement status is frozen, no comments since ietf67
  - open issues:

    - Fec scheme requirements

      - Most requirements can be likely imported from RMT

      - Lorenzo: feedback from RMT: good to have this scheme definition
        to have good quality of resulting FEC drafts later on

    - Q: are there any transport specific considerations
      - considered: UDP and DCCP
      - Rajiv Asati: L4 ? Yes.
      - Q: has RTP been cnsidered ? Currently arbitrary flow across
        UDP - includes of course RTP (on top of RTP). A: nothing specific
    to RTP currently. RTP is on top of UDP. Other groups (DVB) have
    tried to do this. Pro and Cons of trying to be specific to RTP.
      - James Wendel/Microsoft: RTP is also a framework in itself.
        there are fields in RTP obvious you wold want to exploit. RTP
    is for time critical flows. Some impact on semantics too.
      - Greg/Mark: Specific FEC scheme could rely on existing RTP fields
        and not need to add them to it's own header. ALso backward compatible
      - Lorenzo: Hybrid scheme possible ? (Header format that is flexible
        to be optimized with RTP as payload vs. non RTP payload).
    Mark: Mostly documentation issue.
      - CMagnus: (didn't understand what he said)
      - Lorenzo: Add permanent piece of header and optional header
        only present when payload is not RTP.
      - Magnus: probably not useful from complexity perspective.

    - sdp elements...
      description of properties of toolkit of SDP elements to be used
      in content delivery protocols. Not normative, but indicidual FEC
      schemes may choose to use them.
        - transport protocol identifiers for FEC repair flows
        - Association of source flows to repair flow
        - FEC-scheme specific configuration
      - Greg: Rosetta stone draft needed describing where information is
        being pulled in from (RMT specs, etc..)
      - Rajiv: Why SDP ? Mark: Not manadated, optional.
      - SPD requires coordination with mmusic, avt and rmt.

 Next Steps:
   - Streaming Content Delivery Protocol. Need to defne a specific protocol,
     maybe based on SDP toolkit, provide explicit example cases. Have
     an example of a concrete example of how to use the framework.
     - Greg/Mark: separate document from Framework.
     - (Unnamed) Proposal: Just use XOR as a simple example

 - Lorenzo: What plans to take from what RMT did ?
  - Mark: Could be lot of reuse of RMT work. Maybe just a few pages spec
    in FEC frame and refer to an algorithm defined in RMT.
  - Mark: Do we want to systematically pull in RMT ? Probably not,
    leave it up to proponents of individual schemes.
 - Lorenzo: IANA registration defined ?
  - Mark: not yet. Probably in future. Three choices:
    - Dfine when signaling of FEC is defined
    - Do same thing as RMT did (signaling independent code space)
    - Directly clone/reuse RMT defined code space.
  - Rajiv: Preferred solution to reuse work from RMT
  - Magnus: Only 256 code points in RMT definition. Maybe too little.
    Especially with dynamic mapping.

Thanks,
Greg
 ------=_Part_9370_17552786.1176306116358-- --===============1170648798== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe --===============1170648798==-- From fecframe-bounces@ietf.org Thu Apr 12 17:50:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc7BX-0007Z3-8u; Thu, 12 Apr 2007 17:50:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc7BW-0007YX-GM for fecframe@ietf.org; Thu, 12 Apr 2007 17:50:30 -0400 Received: from hu-out-0506.google.com ([72.14.214.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc7BW-0007DT-6O for fecframe@ietf.org; Thu, 12 Apr 2007 17:50:30 -0400 Received: by hu-out-0506.google.com with SMTP id 38so600836huc for ; Thu, 12 Apr 2007 14:50:29 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=eZbRlbsx7XNc6ecXxCMAIh07jd0jFWASOe5wBcNEsLBAkxzNpavS+hQ5zk3rjrFnHHvbcnulxm+D30DBMUNEK2ayY8AjGP9uONpnhZLJFBuMhQlqOpj2OuLGUw/bcMLnwQghnnID/+fRujVPu6Yyo3K7CV87PAXofj+hnPOuy0c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=IdccMByVxy7fAWnd7tURYDru98awDWCrFCh0ZiNwhIUeJNFA9iqLMQNbURuQQ15qe3iTLKDB0ZsZ+r7f0V3m2JEKyX/gssyfu3fV2gGyMYBnZF0PL4EEj5rSvu2wlDN4VH0VxZxac54oH3Qsu/y6Nyvnoyg9neF7r39uf9T4bmc= Received: by 10.78.123.4 with SMTP id v4mr528268huc.1176414628811; Thu, 12 Apr 2007 14:50:28 -0700 (PDT) Received: by 10.78.43.3 with HTTP; Thu, 12 Apr 2007 14:50:28 -0700 (PDT) Message-ID: <38c19b540704121450k611cfa11ic3ff20deee967849@mail.gmail.com> Date: Thu, 12 Apr 2007 14:50:28 -0700 From: "Greg Shepherd" To: fecframe@ietf.org, rmt@ietf.org, mmusic@ietf.org, avt@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [Fecframe] Request For FEC Schemes X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1786286986==" Errors-To: fecframe-bounces@ietf.org --===============1786286986== Content-Type: multipart/alternative; boundary="----=_Part_30859_12924349.1176414628761" ------=_Part_30859_12924349.1176414628761 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Greetings, >From the 68th IETF meeting in Prague, the FECFrame working group came away with some action items which we need to get to in order stay on track with our milestones: 1) Streaming Content Delivery Protocol Define specific protocol elements for signalling the use of FEC SDP, in particular, requires coordination with mmusic, avt and rmt - thus the current distribution. Call for volunteers to participate as the part of a Design Team. 2) Call for FEC Schemes: Like the RMT FEC Building Block, we should define the requirements that FECFRAME FEC Schemes should meet; Data elements that must be defined Procedures that must be defined Format for FEC Scheme specifications If you're interested enough to be on this list, and/or interested enough to attend the WG meetings, then you must be interested enough to see this through to functional result - please step-up. Thanks, Greg ------=_Part_30859_12924349.1176414628761 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Greetings,

From the 68th IETF meeting in Prague, the FECFrame working group came away with some action items which we need to get to in order stay on track with our milestones:

1) Streaming Content Delivery Protocol
       Define specific protocol elements for signalling the use of FEC
       SDP, in particular, requires coordination with mmusic, avt and rmt - thus the current distribution.
       Call for volunteers to participate as the part of a Design Team.


2) Call for FEC Schemes:

     Like the RMT FEC Building Block, we should define the requirements that FECFRAME FEC Schemes should meet;
          Data elements that must be defined
          Procedures that must be defined
          Format for FEC Scheme specifications

If you're interested enough to be on this list, and/or interested enough to attend the WG meetings, then you must be interested enough to see this through to functional result - please step-up.

Thanks,
Greg

------=_Part_30859_12924349.1176414628761-- --===============1786286986== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe --===============1786286986==--