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

Shida Schubert <shida@ntt-at.com> Mon, 26 November 2012 04:44 UTC

Return-Path: <shida@ntt-at.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 2F04C21F8661 for <xrblock@ietfa.amsl.com>; Sun, 25 Nov 2012 20:44:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Level:
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
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 ejcvbtxXGjzF for <xrblock@ietfa.amsl.com>; Sun, 25 Nov 2012 20:44:43 -0800 (PST)
Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 8918321F8628 for <xrblock@ietf.org>; Sun, 25 Nov 2012 20:44:43 -0800 (PST)
Received: from [118.109.76.216] (port=54565 helo=[192.168.11.6]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from <shida@ntt-at.com>) id 1TcqYh-0000At-Jq; Sun, 25 Nov 2012 22:44:39 -0600
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: Shida Schubert <shida@ntt-at.com>
In-Reply-To: <50B2B929.6090403@gmail.com>
Date: Mon, 26 Nov 2012 13:44:36 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <521F13FD-42AC-46A6-AF0D-381FBD0CF935@ntt-at.com>
References: <50ABA4ED.5070103@alum.mit.edu> <E59BB5794CE34A2E85FD6A4F8E1B6D34@china.huawei.com> <50B2B929.6090403@gmail.com>
To: Glen Zorn <glenzorn@gmail.com>
X-Mailer: Apple Mail (2.1283)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator465.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ntt-at.com
X-BWhitelist: yes
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([192.168.11.6]) [118.109.76.216]:54565
X-Source-Auth: shida.schubert+tingle.jp
X-Email-Count: 1
X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t
Cc: xrblock-chairs <xrblock-chairs@tools.ietf.org>, draft-ietf-xrblock-rtcp-xr-burst-gap-discard@tools.ietf.org, Paul Kyzivat <pkyzivat@alum.mit.edu>, xrblock <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 04:44:44 -0000

Hi Glen;

 No the draft hasn't progressed to IETF LC yet. 

 We have requested reviews of 4 drafts that completed 
WGLC by directorates, although Dan and I were talking 
about putting the two *-gap drafts through another WGLCs. 

 As review by directorates can have a significant impact 
on the drafts, I felt that it is better to request the reviews earlier 
than later. 

 I am working on proto-writeup for the two discard drafts and 
Dan will be taking on the two *gap drafts. 

 Regards
  Shida

On Nov 26, 2012, at 9:34 AM, Glen Zorn wrote:

> 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
> 
>