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

Glen Zorn <glenzorn@gmail.com> Mon, 26 November 2012 00:34 UTC

Return-Path: <glenzorn@gmail.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 B376C21F8668 for <xrblock@ietfa.amsl.com>; Sun, 25 Nov 2012 16:34:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level:
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-1]
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 T1UJSFCn3T3I for <xrblock@ietfa.amsl.com>; Sun, 25 Nov 2012 16:34:57 -0800 (PST)
Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id F277D21F8666 for <xrblock@ietf.org>; Sun, 25 Nov 2012 16:34:53 -0800 (PST)
Received: by mail-da0-f44.google.com with SMTP id z20so1875935dae.31 for <xrblock@ietf.org>; Sun, 25 Nov 2012 16:34:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=wwtxfZK2t7Mq0T9jgLBReQlSNvjc05iRDjifJuCU9xs=; b=Qnq8ZwnooFI2GT7VoWtkbAdT0H6WDgYXDPd82qiLeWu1/EXsi8K0LDJHN756BBs1nt IM2Co1jJXWL5f1wtVgCAO3xvBxc6m5I6MpwoUg0sYY+vkbHNZeiW3D0Ev4Ecid7h4xd1 CGAP4K3+U4nmgqZ68KDc754lBlQgliaSO2fCkMcKm2ztdBvcgC8sNYJRiJz2b6slXxM9 v7DU6HuzSpA0qxtnsATZFBF2IHJ0/BIEDldhueVIxr9Rfb7cLwEco9SM6kdF6gkRdnsr /nU8hI9NJDReVymthUeHdR4vlHuUvSoYC17hSGEWWeX33M0nIZYLNYqvbGeok00bMAQm zNRg==
Received: by 10.68.137.167 with SMTP id qj7mr32197924pbb.148.1353890093668; Sun, 25 Nov 2012 16:34:53 -0800 (PST)
Received: from [192.168.0.102] (ppp-171-96-18-67.revip8.asianet.co.th. [171.96.18.67]) by mx.google.com with ESMTPS id bh9sm7721004pab.12.2012.11.25.16.34.50 (version=SSLv3 cipher=OTHER); Sun, 25 Nov 2012 16:34:52 -0800 (PST)
Message-ID: <50B2B929.6090403@gmail.com>
Date: Mon, 26 Nov 2012 07:34:49 +0700
From: Glen Zorn <glenzorn@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2
MIME-Version: 1.0
To: xrblock-chairs <xrblock-chairs@tools.ietf.org>
References: <50ABA4ED.5070103@alum.mit.edu> <E59BB5794CE34A2E85FD6A4F8E1B6D34@china.huawei.com>
In-Reply-To: <E59BB5794CE34A2E85FD6A4F8E1B6D34@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-xrblock-rtcp-xr-burst-gap-discard@tools.ietf.org, Paul Kyzivat <pkyzivat@alum.mit.edu>, 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: Mon, 26 Nov 2012 00:34:57 -0000

On 11/21/2012 03:07 PM, Qin Wu wrote:

Does this mean that the draft has progressed to IETF LC?  Normally, 
that's when the various directorates chime in...however, the document 
status on the WG Web page only says "I-D Exists" even though both this 
draft and draft-ietf-xrblock-rtcp-xr-burst-gap-loss apparently completed 
WGLC some time ago.

> 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
 > _______________________________________________ xrblock mailing list
 > xrblock@ietf.org https://www.ietf.org/mailman/listinfo/xrblock