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

Qin Wu <bill.wu@huawei.com> Tue, 28 July 2015 02:18 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387DB1A21B0 for <xrblock@ietfa.amsl.com>; Mon, 27 Jul 2015 19:18:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.422
X-Spam-Level:
X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEHPBt-XsckV for <xrblock@ietfa.amsl.com>; Mon, 27 Jul 2015 19:18:56 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708831A0158 for <xrblock@ietf.org>; Mon, 27 Jul 2015 19:18:52 -0700 (PDT)
Received: from 172.18.9.243 (EHLO lhreml402-hub.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPK89747; Mon, 27 Jul 2015 21:18:51 -0500 (CDT)
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 28 Jul 2015 03:18:49 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.10]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 28 Jul 2015 10:18:42 +0800
From: Qin Wu <bill.wu@huawei.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>, "alan.d.clark@telchemy.com" <alan.d.clark@telchemy.com>, "zhangyx@sttri.com.cn" <zhangyx@sttri.com.cn>, "zhaojing@sttri.com.cn" <zhaojing@sttri.com.cn>, "ben@nostrum.com" <ben@nostrum.com>, "alissa@cooperw.in" <alissa@cooperw.in>, "dromasca@avaya.com" <dromasca@avaya.com>, "shida@ntt-at.com" <shida@ntt-at.com>
Thread-Topic: [Technical Errata Reported] RFC6958 (4424)
Thread-Index: AQHQw6tc5J+nlvpVyUO6uPH12Iu+X53wLgvQ
Date: Tue, 28 Jul 2015 02:18:41 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA847D1F1B@nkgeml501-mbs.china.huawei.com>
References: <20150721114549.E36FA180204@rfc-editor.org>
In-Reply-To: <20150721114549.E36FA180204@rfc-editor.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.180]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/xrblock/k701Sk_wOVnBUpufBEFqpoQ0p7I>
X-Mailman-Approved-At: Mon, 27 Jul 2015 19:33:27 -0700
Cc: "varun.singh@iki.fi" <varun.singh@iki.fi>, "xrblock@ietf.org" <xrblock@ietf.org>
Subject: Re: [xrblock] [Technical Errata Reported] RFC6958 (4424)
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <xrblock.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xrblock>, <mailto:xrblock-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xrblock/>
List-Post: <mailto:xrblock@ietf.org>
List-Help: <mailto:xrblock-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xrblock>, <mailto:xrblock-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jul 2015 02:18:59 -0000

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:rfc-editor@rfc-editor.org] 
发送时间: 2015年7月21日 19:46
收件人: alan.d.clark@telchemy.com; zhangyx@sttri.com.cn; zhaojing@sttri.com.cn; Qin Wu; ben@nostrum.com; alissa@cooperw.in; dromasca@avaya.com; shida@ntt-at.com
抄送: varun.singh@iki.fi; xrblock@ietf.org; rfc-editor@rfc-editor.org
主题: [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 <varun.singh@iki.fi>

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