Re: [MMUSIC] Last Call: <draft-ietf-mmusic-sdp-g723-g729-04.txt> (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard

Sm,

Please read inline.

Thanks
Partha/Muthu

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of SM
> Sent: Thursday, October 31, 2013 9:07 AM
> To: mmusic@ietf.org
> Subject: Re: [MMUSIC] Last Call: <draft-ietf-mmusic-sdp-g723-g729-
> 04.txt> (Offer/Answer Considerations for G723 Annex A and G729 Annex B)
> to Proposed Standard
> 
> At 06:17 30-10-2013, The IESG wrote:
> >The IESG has received a request from the Multiparty Multimedia Session
> >Control WG (mmusic) to consider the following document:
> >- 'Offer/Answer Considerations for G723 Annex A and G729 Annex B'
> >   <draft-ietf-mmusic-sdp-g723-g729-04.txt> as Proposed Standard
> >
> >The IESG plans to make a decision in the next few weeks, and solicits
> >final comments on this action. Please send substantive comments to the
> >ietf@ietf.org mailing lists by 2013-11-27. Exceptionally, comments may
> be
> 
> I read this draft quickly.  According to the Abstract:
> 
>    "RFC4856 describes the annexa parameter for G723 and the annexb
>     parameter for G729, G729D and G729E. However, the specification
> does
>     not describe the offerer and answerer behavior when the value of
> the
>     annexa or annexb parameter does not match in the Session
> Description
>     protocol(SDP) offer and answer.  This document provides the offer/
>     answer considerations for these parameters and updates RFC4856."
> 
> RFC 4856 is about media type registration of payload formats. 
<Partha> Agreed </Partha>

 The
> IESG approval mentioned that the document "specify the procedure to
> register RTP payload formats as audio, video or other media subtype
> names".  The RFC does not specify the AnnexA parameter for G723. 

<Partha> Agreed. RFC4856 describes AnnexA parameter for G723. </Partha>

 I
> took a quick look at the RFCs being referenced.  They are about media
> type registrations.  It is doubtful whether they even qualify for
> Proposed Standard.
<Partha> RFC4856 is published as proposed standard in IETF </Partha>

> 
> The premise on which the work in this draft is built is lacking.
<Partha> The premise on which the work in this draft is already well
described in the abstract itself </Partha>

  The
> draft mentions
> G723 Annex A without providing any reference to the
> specification. 
<Partha> G723 annexa SDP attribute is defined in RFC 4856. </Partha>

 In my opinion the draft needs more work for it to be
> a Proposed Standard.  
<Partha> Could you please list the work which has to be done for this draft
</Partha>

It doesn't look like there has been any
> discussion about whether there are IPR issues affecting
> implementations.
> 

<Partha> The authors are not aware of any IPR related to this issue. This
has been communicated to MMUSIC WG Chairs </Partha>

> Regards,
> -sm
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic