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

["Parthasarathi R" <[e-mail]>]

Hi SM,

Thanks for the clarification that the draft solution is fine for you. The
issue/clarification required is w.r.t the type of RFC and the reference to
the original codec (ITU) specification.

Please note that the original publication of the draft was done as "BCP"
(http://tools.ietf.org/html/draft-muthu-mmusic-offer-answer-g723-g729-00).
It was discussed in length during IETF-84 and the draft was submitted as
"standards track" as per WG decision (
http://www.ietf.org/mail-archive/web/mmusic/current/msg09590.html).
Including Flemming & Ari in this mail thread explicitly.

As far as the reference is considered, this draft aims at offer/answer
mechanism for SDP attributes which are described as part of RFC 4856 and the
corresponding codec ITU specification is supposed to be referenced in RFC
4856 only. I could not understand the logic why this specification has to
mention ITU codec specification. 

Apart from this, we (The authors) consider that RFC 4856 is in the correct
RFC type. If you think that RFC 4856 status is wrong, Let us discuss in the
separate mail thread. 

Thanks
Partha

> -----Original Message-----
> From: SM [mailto:[e-mail]]
> Sent: Wednesday, November 20, 2013 12:57 AM
> To: Parthasarathi R
> Cc: [e-mail]
> 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
> 
> Hi Partha,
> 
> I forgot to mention that I am not subscribed to the MMUSIC mailing
> list.
> 
> At 10:27 19-11-2013, Parthasarathi R wrote:
> >I have clarified all your below queries. Could you please let me know
> in
> >case you still see any specific issue with the draft.
> 
> In my humble opinion RFC 4856 is more about a media type registration
> request instead of a technical specification about
> interoperability.  It is mentioned in Section 1 of that RFC that it
> updates the media type registrations.  The fact that RFC 4856 is
> published as a Proposed Standard does not mean that it is the correct
> status.  There are a lot of oddities in the IETF Stream.  I prefer
> not to ask about those oddities. :-)
> 
> draft-ietf-mmusic-sdp-g723-g729-04 mentions G723 Annex A and G729
> Annex B.  There aren't any references for them.  The problem with the
> draft is that it builds upon RFC 4856 instead of the technical
> specification where the protocol is specified.  Is G723 Annex A and
> G729 Annex B needed to implement what the draft tries to do?  In my
> opinion, yes.
> 
> The document shepherd write-up has the following question:
> 
>    "Why is this the proper type of RFC?"
> 
> The answer provided is:
> 
>   "Proposed Standard.  The title page notes the document as Standards
> Track"
> 
> That does not answer the question.
> 
> Regards,
> -sm