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

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

>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

---

From: Glen Zorn <[email-masked]>
Date: Mon, 26 Nov 2012 07:34:49 +0700

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"
 > <[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
 >
 >
 >> draft-ietf-xrblock-rtcp-xr-burst-gap-discard-06. For background on
 >> SDP directorate, please see the FAQ at
 >> 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.
 >>
 >> 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.
 >>
 >> - 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.
 >>
 >> 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.
 >
 >
 > [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
 > [email-masked] https://www.ietf.org/mailman/listinfo/xrblock

---

From: Shida Schubert <[email-masked]>
Date: Mon, 26 Nov 2012 13:44:36 +0900

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:

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