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

[Paul Kyzivat <[e-mail]>]

Hi Qin,

What you propose is fine with me.

	Thanks,
	Paul

On 11/21/12 3:07 AM, Qin Wu wrote:
> 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
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>