From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>,
 SM <sm@resistor.net>,
 =?iso-8859-1?Q?Ari_Ker=E4nen?= <ari.keranen@ericsson.com>
Thread-Topic: [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
Thread-Index: AQHO8LoXkRyXUSEDek6KFCcciV8mvppENbmy///+6QCAABkmUA==
Date: Wed, 4 Dec 2013 19:27:17 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B0F23CB@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com>
 <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net>
 <00a101ced981$77414d60$65c3e820$@co.in>
 <00ab01cee555$05f53560$11dfa020$@co.in>
 <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net>
 <003301cee952$852cd120$8f867360$@co.in>
 <6.2.5.6.2.20131129000812.0bdaa088@resistor.net>
 <016d01ceed31$aa7a1130$ff6e3390$@co.in>
 <6.2.5.6.2.20131130003721.0d65a980@resistor.net>
 <E721D8C6A2E1544DB2DEBC313AF54DE22436AD4D@xmb-rcd-x02.cisco.com>
 <6.2.5.6.2.20131203011102.0db5d8c0@resistor.net>
 <E721D8C6A2E1544DB2DEBC313AF54DE2243737E1@xmb-rcd-x02.cisco.com>
 <6.2.5.6.2.20131204072722.0e064590@resistor.net>
 <E721D8C6A2E1544DB2DEBC313AF54DE22437429E@xmb-rcd-x02.cisco.com>
In-Reply-To: <E721D8C6A2E1544DB2DEBC313AF54DE22437429E@xmb-rcd-x02.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Flemming Andreasen \(fandreas\)" <fandreas@cisco.com>,
 "mmusic@ietf.org" <mmusic@ietf.org>
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
Precedence: list

I think the problem here originates with RFC 4856.

All RFC 4856 does is create IANA registrations within SDP.

It does not contain any requirements, except by implication, of how those r=
egistrations are used. An IANA registration, per se, cannot contain any nor=
mative requirements, all it is a list of assigned values.

As such for the scope that RFC 4856 seeks to cover, it should not have been=
 standards track.

As it is now specified I do not believe draft-ietf-mmusic-sdp-g723-g729-04.=
txt updates RFC 4856. It does not change any of the IANA registrations, and=
 that is pretty much all the scope of RFC 4856. If there is an update at al=
l created by draft-ietf-mmusic-sdp-g723-g729, I suspect it is to RFC 3551 a=
s these are the documents that actually specify such media types can be use=
d within the SDP. However my preference would be to not have this document =
do any update.

I do believe draft-ietf-mmusic-sdp-g723-g729 normatively impacts the usage =
of SDP in offer / answer usage and as such should be standards track.

I believe the abstract of draft-ietf-mmusic-sdp-g723-g729 could be improved=
 to reflect this.

Regards

Keith


> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of=20
> Muthu Arul Mozhi Perumal (mperumal)
> Sent: 04 December 2013 17:08
> To: SM; Ari Ker=E4nen
> Cc: Flemming Andreasen (fandreas); mmusic@ietf.org
> Subject: Re: [MMUSIC] Last Call:=20
> <draft-ietf-mmusic-sdp-g723-g729-04.txt> (Offer/Answer=20
> Considerations for G723 Annex A and G729 Annex B) to Proposed Standard
>=20
> Hi SM,
>=20
> |-----Original Message-----
> |From: SM [mailto:sm@resistor.net]
> |Sent: Wednesday, December 04, 2013 9:41 PM
> |To: Muthu Arul Mozhi Perumal (mperumal); Ari Ker=E4nen
> |Cc: Flemming Andreasen (fandreas); mmusic@ietf.org
> |Subject: RE: [MMUSIC] Last Call:=20
> |<draft-ietf-mmusic-sdp-g723-g729-04.txt> (Offer/Answer=20
> Considerations=20
> |for G723 Annex A and G729 Annex B) to Proposed Standard
> |
> |Hi Muthu,
> |At 22:28 03-12-2013, Muthu Arul Mozhi Perumal (mperumal) wrote:
> |>Sorry, not clear to me. Can you provide some examples?
> |
> |As an example:
> |
> |   "The reproduction of the [RFC4695] IANA considerations=20
> section appears
> |    directly below.
> |
> |    This section makes a series of requests to IANA.  The IANA has
> |    completed registration/assignments of the below requests."
> |
> |Please note that I picked one at random.
> |
> |>Also, draft-ietf-mmusic-sdp-g723-g729-04 doesn't need any=20
> IANA action=20
> |>(see the IANA Considerations section). So, why should it be=20
> published=20
> |>as an Informational RFC?
> |
> |The issue (using the word loosely) is that the draft is=20
> referring to a=20
> |registration request in Section 1.1 of RFC 4856 which is about IANA=20
> |Considerations.
>=20
> Yes, is referring to that section of RFC4856. However, the=20
> issue is not the registration itself -- it is to do with the=20
> missing offer/answer considerations for the registered media=20
> parameters that impact interoperability. As an example,=20
> RFC4352 registers AMR-WB+ and then describes the offer/answer=20
> model considerations for the parameters it registers.=20
>=20
> |My argument is that the working group has not provide an explanation=20
> |about why the proposal should be published on the Standards Track. =20
> |Instead of objecting to the publication as a RFC I suggested=20
> publishing=20
> |the proposal as an Informational RFC.
>=20
> I don't think publishing it as an Informational RFC would=20
> improve interoperability.
>=20
> Muthu
>=20
> |
> |Regards,
> |-sm
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> =