Re: [xrblock] [MMUSIC] SDP Directorate review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-06

Qin Wu <bill.wu@huawei.com> Wed, 21 November 2012 08:08 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8713021F874A; Wed, 21 Nov 2012 00:08:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.589
X-Spam-Level:
X-Spam-Status: No, score=-4.589 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqZ7aAi0gFCI; Wed, 21 Nov 2012 00:07:57 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7547D21F873A; Wed, 21 Nov 2012 00:07:56 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMZ71220; Wed, 21 Nov 2012 08:07:55 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 21 Nov 2012 08:07:18 +0000
Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 21 Nov 2012 08:07:49 +0000
Received: from w53375 (10.138.41.149) by szxeml404-hub.china.huawei.com (10.82.67.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 21 Nov 2012 16:07:42 +0800
Message-ID: <E59BB5794CE34A2E85FD6A4F8E1B6D34@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, <mmusic@ietf.org>, <draft-ietf-xrblock-rtcp-xr-burst-gap-discard@tools.ietf.org>
References: <50ABA4ED.5070103@alum.mit.edu>
Date: Wed, 21 Nov 2012 16:07:41 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Originating-IP: [10.138.41.149]
X-CFilter-Loop: Reflected
Cc: xrblock@ietf.org
Subject: Re: [xrblock] [MMUSIC] SDP Directorate review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-06
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 21 Nov 2012 08:08:01 -0000

Hi, Paul:
Thank for your valuable comments, please see my reply inline below.

Regards!
-Qin
----- Original Message ----- 
From: "Paul Kyzivat" <pkyzivat@alum.mit.edu>
To: <mmusic@ietf.org>rg>; <draft-ietf-xrblock-rtcp-xr-burst-gap-discard@tools.ietf.org>
Sent: Tuesday, November 20, 2012 11:42 PM
Subject: [MMUSIC] SDP Directorate review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-06


>I am the assigned SDP directorate reviewer for 
> draft-ietf-xrblock-rtcp-xr-burst-gap-discard-06. For background on SDP 
> directorate, please see the FAQ at 
> <http://www.ietf.org/iesg/directorate/sdp.html>.
> 
> Please wait for direction from your document shepherd or AD before 
> posting a new version of the draft.
> 
> * Summary:
> 
> The SDP syntax defined in this draft is trivial and fine.
> It exercises a defined extension point in RFC3611. That RFC defines an 
> IANA registry for new values using this extension point. This document 
> nominally supplies the information called for when registering. However, 
> the semantics for processing the new syntax is underspecified, and needs 
> to be further elaborated.
> 
> * New SDP information elements:
> 
> Section 5 of this draft augments the SDP attribute "rtcp-xr" defined in 
> RFC3611, providing an additional value: "brst-gap-dscrd".
> 
> * Technical Issues:
> 
> RFC3611 establishes an IANA registry for new values, and requires that 
> the following information be supplied when registering a new value:
> 
>    -  Contact information of the one doing the registration, including
>       at least name, address, and email.
> 
>    -  An Augmented Backus-Naur Form (ABNF) [2] definition of the
>       parameter, in accordance with the "format-ext" definition of
>       Section 5.1.
> 
>    -  A description of what the parameter represents and how it shall be
>       interpreted, both normally and in Offer/Answer.
> 
> The first two of the above are properly supplied. But the offer/answer 
> behavior is insufficiently specified. ("When SDP is used in offer-answer 
> context, the SDP Offer/Answer usage defined in [RFC3611] applies.")
> 
> RFC3611 states:
> 
>    Each "rtcp-xr" parameter belongs to one of two categories.  The first
>    category, the unilateral parameters, are for report blocks that
>    simply report on the RTP stream and related metrics.  The second
>    category, collaborative parameters, are for XR blocks that involve
>    actions by more than one party in order to carry out their functions.
> 
> It then goes on to give different offer/answer procedures for each 
> category of parameter. The reference in *this* draft ("the SDP 
> Offer/Answer usage defined in [RFC3611] applies") is insufficient 
> because there is no indication in this draft whether the new value is a 
> "unilateral" or "collaborative" parameter.
> 
> The draft needs to be revised to address this issue. I *think* this new 
> parameter is a "unilateral" parameter. If so, it MAY be sufficient to 
> revise section 5.2 as follows:
> 
> OLD:
>    When SDP is used in offer-answer context, the SDP Offer/Answer usage
>    defined in [RFC3611] applies.
> 
> NEW:
>    When SDP is used in offer-answer context, the SDP Offer/Answer usage
>    defined in [RFC3611] for unilateral "rtcp-xr" attribute parameters
>    applies.

[Qin]: Thank you for digging deeper into SDP offer answer usage for burst gap discard.
I fully agree with you that the new value we defined here is "unilateral" parameter. 
And your proposed change looks reasonable to me. Thanks.

 
> It may be useful to provide an expanded explanation.

[Qin]: Maybe we can append one more sentence to your proposed change to say:
"
For detailed usage in Offer/Answer for unilateral parameter, refer to section 5.2 of RFC3611.
"

> Regards,
> Paul Kyzivat