Re: [AVTCORE] [Technical Errata Reported] RFC4585 (3313)

[Magnus Westerlund <[e-mail]>]

WG,

I have reviewed this errata and it appears correct. I would recommend
that it is approved. Additional views on this? Please provide any
feedback within a week, after that I will instruct the ADs to approve
this errata.

Cheers

Magnus

On 2012-08-11 16:57, RFC Errata System wrote:
> 
> The following errata report has been submitted for RFC4585,
> "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=4585&eid=3313
> 
> --------------------------------------
> Type: Technical
> Reported by: Mo Zanaty <[e-mail]>
> 
> Section: 4.2
> 
> Original Text
> -------------
>       rtcp-fb-ack-param  = SP "rpsi"
>                          / SP "app" [SP byte-string]
>                          / SP token [SP byte-string]
>                          / ; empty
> 
> 
> Corrected Text
> --------------
>       rtcp-fb-ack-param  = SP "rpsi"
>                          / SP "app" [SP byte-string]
>                          / SP token [SP byte-string]
> 
> 
> Notes
> -----
> RFC 4585 defines and allows generic NACK (with no further parameters) but not generic ACK (which always requires further parameters). Section 4.2 says:
> ...
>       Parameters MUST be provided to further distinguish different types
>       of positive acknowledgement feedback.
> ...
>       The feedback type "nack", without parameters, indicates use of the
>       Generic NACK feedback format as defined in Section 6.2.1.
> ...
> The ABNF incorrectly allows nothing after "ack", implying that generic ACK is valid. Even the approved errata, which replaces the invalid empty alternate with optional [], still allows nothing after "ack". Note that recent interest in RTP congestion control (e.g. RMCAT BOF) may lead to defining a standard ACK.
> 
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC4585 (draft-ietf-avt-rtcp-feedback-11)
> --------------------------------------
> Title               : Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)
> Publication Date    : July 2006
> Author(s)           : J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey
> Category            : PROPOSED STANDARD
> Source              : Audio/Video Transport
> Area                : Real-time Applications and Infrastructure
> Stream              : IETF
> Verifying Party     : IESG
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------