Re: [MMUSIC] RFC 4856 is in the correct RFC category - Errata query? [was RE: Last Call: <draft-ietf-mmusic-sdp-g723-g729-04.txt> (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard]

[Stephen Casner <[e-mail]>]

On Fri, 29 Nov 2013, Parthasarathi R wrote:

> Hi Casner/Ari/Flemming,
>
> As part of draft-ietf-mmusic-sdp-g723-g729-04 draft last call comments, the
> following comments from sm are relevant to RFC 4856 category
>
> 1)
> <snip1>
> 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. :-)
> </snip1>
>
> The authors of draft-ietf-mmusic-sdp-g723-g729-04 (Muthu & Myself) are of
> the opinion that RFC 4856 is in the correct category as it describes about
> codec like G.723 and G.729.

I believe the status of RFC 4856 is correct.  It updates RFC 3555 to
define and register the media types for the RTP profile RFC 3551.
What other status would be more appropriate for that ?

> 2)
> <snip2>
> draft-ietf-mmusic-sdp-g723-g729-04 mentions G723 Annex A and G729
> > Annex B.  There aren't any references for them.
> </snip2>
>
> draft-ietf-mmusic-sdp-g723-g729-04 updates RFC 4856 w.r.t offer/answer(O/A)
> mechanism of G723 Annex A and G729 Annex B. RFC 4856 does not have reference
> for G723 Annex A and G729 Annex B. IMO if the codec reference has to be
> mentioned,  it has to be mentioned in RFC 4856 and not required in
> draft-ietf-mmusic-sdp-g723-g729-04 as it updates only O/A of RFC 4856.

RFC 4856 is not a specification of any payload format; it refers to
other documents that specify the payload formats (and SDP usage).  It
only specifies how a MIME media type is used to refer to a payload
format that carries an encoding.  RFC 4856 refers to RFC 3551 for the
payload format of G723 and G729, which in turn refers to the ITU
Recommendations.

If the draft is providing more details about how the packetizations of
G723 and G729 should be negotiated and used, then the draft is
updating RFC 3551.

                                                        -- Steve

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