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

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 20 November 2012 15:42 UTC

Message-ID: <50ABA4ED.5070103@alum.mit.edu>
Date: Tue, 20 Nov 2012 10:42:37 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: "mmusic@ietf.org" <mmusic@ietf.org>, draft-ietf-xrblock-rtcp-xr-burst-gap-discard@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [MMUSIC] SDP Directorate review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-06
Precedence: list

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.

It may be useful to provide an expanded explanation.

	Regards,
	Paul Kyzivat

[MMUSIC] SDP Directorate review of draft-ietf-xrb… Paul Kyzivat
Re: [MMUSIC] SDP Directorate review of draft-ietf… Qin Wu
Re: [MMUSIC] SDP Directorate review of draft-ietf… Paul Kyzivat