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

[Paul Kyzivat <[e-mail]>]

Note that "standards track" is what is used for *drafts* that are 
intended to become standards. IIUC, this is changed to Proposed Standard 
when the draft is published as an RFC.

	Thanks,
	Paul

On 11/24/13 12:19 PM, Parthasarathi R wrote:
> 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
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>