Re: [xrblock] [Technical Errata Reported] RFC6958 (4424)

[Varun Singh <[e-mail]>]

Hi Qin,

Just to confirm: was the intention to use 12 bits and not 16 bits?
Additionally, are there any implementations of the block, if so what size
are they using?

Cheers,
Varun.
On Jul 28, 2015 5:33 AM, "Qin Wu" <[e-mail]> wrote:

> I confirm the following inconsistency issue pointed out by Varun,
> Instead of changing packet format "Number of bursts", I would suggest to
> Just change definition of "Number of bursts" and define it as 12 bits
> length field as follows:
> Original text:
> "
>   Number of Bursts: 16 bits
>
>     The number of bursts in the period of the report (Interval or
>     Cumulative).
>
>     The measured value is an unsigned value.  If the measured value
>     exceeds 0xFFFD, the value 0xFFFE MUST be reported to indicate
>     an over-range measurement.  If the measurement is unavailable,
>     the value 0xFFFF MUST be reported.
> "
> Corrected Text:
> "
>   Number of Bursts: 12 bits
>
>     The number of bursts in the period of the report (Interval or
>     Cumulative).
>
>     The measured value is an unsigned value.  If the measured value
>     exceeds 0xFFD, the value 0xFFE MUST be reported to indicate
>     an over-range measurement.  If the measurement is unavailable,
>     the value 0xFFF MUST be reported.
> "
> In this case, we don't need to add "Reserve" field at the end for any
> padding.
> Thanks.
>
> -Qin
> -----邮件原件-----
> 发件人: RFC Errata System [mailto:[e-mail]]
> 发送时间: 2015年7月21日 19:46
> 收件人: [e-mail]; [e-mail];
> [e-mail]; Qin Wu; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> 抄送: [e-mail]; [e-mail]; [e-mail]
> 主题: [Technical Errata Reported] RFC6958 (4424)
>
> The following errata report has been submitted for RFC6958, "RTP Control
> Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric
> Reporting".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6958&eid=4424
>
> --------------------------------------
> Type: Technical
> Reported by: Varun Singh <[e-mail]>
>
> Section: 3.1
>
> Original Text
> -------------
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |            Packets Lost in Bursts             |    Total...   |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       | ...Packets Expected in Bursts |    Number of Bursts   | Sum of|
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                ...Squares of Burst Durations (ms-squared)     |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Corrected Text
> --------------
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |            Packets Lost in Bursts             |    Total...
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>            Packets Expected in Bursts |        Number of Bursts       |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                Sum of Squares of Burst Durations (ms-squared)
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        ...    |                    reserved                           |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Notes
> -----
> The packet format on Section 3.1 shows 12 bits,  however section 3.2
> defines the "Number of bursts" as a 16 bits length field.
>
> Relevant text from Section 3.2 pasted below:
>
>   Number of Bursts: 16 bits
>
>     The number of bursts in the period of the report (Interval or
>     Cumulative).
>
>     The measured value is an unsigned value.  If the measured value
>     exceeds 0xFFFD, the value 0xFFFE MUST be reported to indicate
>     an over-range measurement.  If the measurement is unavailable,
>     the value 0xFFFF MUST be reported.
>
> Instructions:
> -------------
> This erratum 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.
>
> --------------------------------------
> RFC6958 (draft-ietf-xrblock-rtcp-xr-burst-gap-loss-12)
> --------------------------------------
> Title               : RTP Control Protocol (RTCP) Extended Report (XR)
> Block for Burst/Gap Loss Metric Reporting
> Publication Date    : May 2013
> Author(s)           : A. Clark, S. Zhang, J. Zhao, Q. Wu, Ed.
> Category            : PROPOSED STANDARD
> Source              : Metric Blocks for use with RTCPs Extended Report
> Framework RAI
> Area                : Real-time Applications and Infrastructure
> Stream              : IETF
> Verifying Party     : IESG
>
> _______________________________________________
> xrblock mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xrblock
>