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

[Qin Wu <[e-mail]>]

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

Regards!
-Qin
----- Original Message ----- 
From: "Paul Kyzivat" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
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