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

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Nov 2012 10:42:37 -0500

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

---

From: Qin Wu <[email-masked]>
Date: Wed, 21 Nov 2012 16:07:41 +0800

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

Regards!
-Qin
----- Original Message ----- 
From: "Paul Kyzivat" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Tuesday, November 20, 2012 11:42 PM
Subject: [MMUSIC] SDP Directorate review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-06

>    defined in [RFC3611] for unilateral "rtcp-xr" attribute parameters

[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.
"

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Nov 2012 09:29:10 -0500

Hi Qin,

What you propose is fine with me.

	Thanks,
	Paul

On 11/21/12 3:07 AM, Qin Wu wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>