Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-13.txt

[Magnus Westerlund <[e-mail]>]

Hi,

Looking at the changes.

Section 7.1.1:
Regarding: c=IN IP4 233.252.0.1/127
Isn't keeping it as an unicast address a better approach here?

Note that https://tools.ietf.org/html/rfc5737 do have unicast ranges
which you can pick an address from.

I don't think there are any issues in itself with having a multicast
address here. However, people may get ideas, especially with both 7.1.1
and 7.1.2 using multicast.

Otherwise it appears that you have addressed those ID-nits you need to
address.

Cheers

Magnus


On 2018-12-11 20:02, Giridhar Mandyam wrote:
> Please note that I cleared out as many nits as I thought made sense.  Current nit check showed zero errors, but a few warnings and comments.  I also updated the avtext-rid reference.
>
> I modified the abstract slightly as inclusion of references violated RFC 7322, Sec. 4.3.   As a result, I removed those references from the abstract and added a sentence in the Introduction that provided the references.
>
> -Giri Mandyam
>
> -----Original Message-----
> From: payload <[e-mail]> On Behalf Of [e-mail]
> Sent: Tuesday, December 11, 2018 10:56 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-13.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Audio/Video Transport Payloads WG of the IETF.
>
>         Title           : RTP Payload Format for Flexible Forward Error Correction (FEC)
>         Authors         : Mo Zanaty
>                           Varun Singh
>                           Ali Begen
>                           Giridhar Mandyam
> 	Filename        : draft-ietf-payload-flexible-fec-scheme-13.txt
> 	Pages           : 41
> 	Date            : 2018-12-11
>
> Abstract:
>    This document defines new RTP payload formats for the Forward Error
>    Correction (FEC) packets that are generated by the non-interleaved
>    and interleaved parity codes from source media encapsulated in RTP.
>    These parity codes are systematic codes, where a number of FEC repair
>    packets are generated from a set of source packets from one or more
>    source RTP streams.  These FEC repair packets are sent in a
>    redundancy RTP stream separate from the source RTP stream(s) that
>    carries the source packets.  RTP source packets that were lost in
>    transmission can be reconstructed using the source and repair packets
>    that were received.  The non-interleaved and interleaved parity codes
>    which are defined in this specification offer a good protection
>    against random and bursty packet losses, respectively, at a cost of
>    decent complexity.  The RTP payload formats that are defined in this
>    document address scalability issues experienced with the earlier
>    specifications, and offer several improvements.  Due to these
>    changes, the new payload formats are not backward compatible with
>    earlier specifications, but endpoints that do not implement this
>    specification can still work by simply ignoring the FEC repair
>    packets.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-scheme/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-13
> https://datatracker.ietf.org/doc/html/draft-ietf-payload-flexible-fec-scheme-13
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-flexible-fec-scheme-13
>
>
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> payload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/payload
>
> _______________________________________________
> payload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/payload
>

-- 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------