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 <[e-mail]>]

Hi Partha,
At 12:19 24-11-2013, Parthasarathi R wrote:
>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.

The minutes of the IETF 84 does not show a lengthy discussion.  The 
message about the WG decision from the WG Chairs says "I support this".

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

I reordered the above paragraph as it is related to the comment I 
made above.  It is mentioned about that the authors believe that RFC 
4856 is the correct type.  There isn't any explanation about why the 
authors think so.  I do not see any response to my previous comment ( 
http://www.ietf.org/mail-archive/web/mmusic/current/msg12778.html ).

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

In my opinion, reading the corresponding codec specification is 
required to understand what the draft proposes.

Regards,
-sm