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

Sm,

<Snip> 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".
</Snip>

The draft-ietf-mmusic-sdp-g723-g729-04.txt related minutes of IETF84 is
given below for your reference:

"draft-muthu-mmusic-offer-answer-g723-g729-00.txt - Parthasarathi Ravindran

Hadriel had clarifying questions on the proposed solution.

Christer asked why this isn’t addressed by change to the document that
defined this payload (RFC 4856), to include the o/a considerations. IOW do a
bis of that document. Cullen said this should either be an update or a bis
to the original doc – it should not be a BCP.

Jonathan agreed with doing a bis. Roni said that when discussed in PAYLOAD
WG (with many of same people) they suggested bringing it to MMUSIC and doing
as BCP. Robert said BCP is almost certainly wrong. 

Chairs noted that nobody disagrees there is an issue. Chairs will discuss
with PAYLOAD WG chairs and ADs about what the proper process should be for
resolving and documenting it."

The related link is
http://www.ietf.org/proceedings/84/minutes/minutes-84-mmusic. The draft is
submitted as "Standards track" as per WG chairs & AD instructions after the
meeting and the relevant link is
http://www.ietf.org/mail-archive/web/mmusic/current/msg09590.html. 

Your other comments are related to RFC 4856 and I have initiated in the mail
thread to discuss those comments separately.

Thanks
Partha

> -----Original Message-----
> From: SM [mailto:[e-mail]]
> Sent: Friday, November 29, 2013 1:52 PM
> To: Parthasarathi R
> Cc: [e-mail]; Flemming Andreasen; Ari Keränen
> 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,
> 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