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

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Mon, 2 Dec 2013 13:51:15 +0000

|Media type registrations are usually published as Informational RFCs.  
|I suggest publishing draft-ietf-mmusic-sdp-g723-g729-04 as an Information RFC.

Registered audio media types are listed here:
http://www.iana.org/assignments/media-types/audio

As you can see most of them are described in Standards Track RFCs, so your observation is incorrect.

Muthu

|-----Original Message-----
|From: mmusic [mailto:[email-masked]] On Behalf Of SM
|Sent: Saturday, November 30, 2013 2:24 PM
|To: Ari Keränen
|Cc: Flemming Andreasen (fandreas); [email-masked]
|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 Ari,
|
|I read the PROTO write-up.  There isn't any answer to the following question:
|
|   "Why is this the proper type of RFC?"
|
|At 10:34 29-11-2013, Parthasarathi R wrote:
|>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.
|
|According to the message quoted above:
|
|   (a) Cullen said that the document should either be an update or a bis to
|       the original document.
|
|   (b)  Robert said that BCP was certainly wrong.
|
|   (c) The draft was submitted as "Standards track" as that was the
|       instructions given by the WG Chairs and Area Director.
|
|There isn't any explanation.  Media type
|registrations are usually published as
|Informational RFCs.  I suggest publishing
|draft-ietf-mmusic-sdp-g723-g729-04 as an Information RFC.
|
|Regards,
|-sm
|
|_______________________________________________
|mmusic mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/mmusic

---

From: Ari Keränen <[email-masked]>
Date: Mon, 2 Dec 2013 17:28:25 +0200

Hi,

As Partha & Muthu already mentioned, there was discussion and a 
consensus call on the type of the document and the consensus was that PS 
is the correct type. Admittedly the proto write-up could have been a bit 
more elaborate on that.

Cheers,
Ari

On 11/30/13 10:54 AM, SM wrote:
> Hi Ari,
>
> I read the PROTO write-up.  There isn't any answer to the following
> question:
>
>    "Why is this the proper type of RFC?"
>
> At 10:34 29-11-2013, Parthasarathi R wrote:
>> 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.
>
> According to the message quoted above:
>
>    (a) Cullen said that the document should either be an update or a bis to
>        the original document.
>
>    (b)  Robert said that BCP was certainly wrong.
>
>    (c) The draft was submitted as "Standards track" as that was the
>        instructions given by the WG Chairs and Area Director.
>
> There isn't any explanation.  Media type registrations are usually
> published as Informational RFCs.  I suggest publishing
> draft-ietf-mmusic-sdp-g723-g729-04 as an Information RFC.
>
> Regards,
> -sm
>

---

From: Stephen Casner <[email-masked]>
Date: Mon, 2 Dec 2013 08:52:05 -0800 (PST)

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:[email-masked]]
> > Sent: Wednesday, November 20, 2013 12:57 AM
> > To: Parthasarathi R
> > Cc: [email-masked]
> > 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:
> >
> > The answer provided is:
> >   "Proposed Standard.  The title page notes the document as Standards
> > Track"
> >
> > That does not answer the question.
> >
> > Regards,
> > -sm
>

---

From: SM <[email-masked]>
Date: Tue, 03 Dec 2013 01:10:28 -0800

Hi Stephen,
>What other status would be more appropriate for that ?

There was an assumption that the status chosen for some previous RFC 
is correct.  The problem might have been with RFC 3555.  It is better 
not to look at the details of those old RFCs too closely. :-)

>payload format of G723 and G729, which in turn refers to the ITU

My short response would be yes.  Please note that I did not verify 
all the details.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Tue, 03 Dec 2013 01:13:41 -0800

Hi Muthu,
>so your observation is incorrect.

I was referring to media type registrations for IANA action.  That is 
different from the intended status.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Tue, 03 Dec 2013 01:44:32 -0800

Hi Ari,
At 07:28 02-12-2013, Ari Keränen wrote:
>As Partha & Muthu already mentioned, there was 
>discussion and a consensus call on the type of 
>the document and the consensus was that PS is 
>the correct type. Admittedly the proto write-up 
>could have been a bit more elaborate on that.

Thanks for the response.  In my humble opinion it 
is not worth the effort to look into the details 
of the process if that can be avoided.

Regards,
-sm

---

From: Stephen Casner <[email-masked]>
Date: Tue, 3 Dec 2013 20:46:19 -0800 (PST)

On Tue, 3 Dec 2013, SM wrote:

> There was an assumption that the status chosen for some previous RFC is
> correct.  The problem might have been with RFC 3555.  It is better not to look
> at the details of those old RFCs too closely. :-)

Since I am the author of the RFCs listed above, I dispute that.  I
assert that standards track is correct for all of these.  There is
nothing about them that is merely a "best current practice".

                                                        -- Steve

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 4 Dec 2013 06:28:38 +0000

|I was referring to media type registrations for IANA action. That is
|different from the intended status.

Sorry, not clear to me. Can you provide some examples?

Also, draft-ietf-mmusic-sdp-g723-g729-04 doesn't need any IANA action (see the IANA Considerations section). So, why should it be published as an Informational RFC?

Muthu 

|-----Original Message-----
|From: SM [mailto:[email-masked]]
|Sent: Tuesday, December 03, 2013 2:44 PM
|To: Muthu Arul Mozhi Perumal (mperumal); Ari Keränen
|Cc: Flemming Andreasen (fandreas); [email-masked]
|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 Muthu,
|At 05:51 02-12-2013, Muthu Arul Mozhi Perumal (mperumal) wrote:
|>|Media type registrations are usually published as Informational RFCs.
|>|I suggest publishing draft-ietf-mmusic-sdp-g723-g729-04 as an
|>Information RFC.
|>
|>Registered audio media types are listed here:
|>http://www.iana.org/assignments/media-types/audio
|>
|>As you can see most of them are described in Standards Track RFCs,
|>so your observation is incorrect.
|
|I was referring to media type registrations for IANA action.  That is
|different from the intended status.
|
|Regards,
|-sm

---

From: Ari Keränen <[email-masked]>
Date: Wed, 4 Dec 2013 15:14:59 +0200

Hi SM,

On 12/3/13 11:44 AM, SM wrote:
>> consensus call on the type of the document and the consensus was that
>> PS is the correct type. Admittedly the proto write-up could have been
>> a bit more elaborate on that.
>
> Thanks for the response.  In my humble opinion it is not worth the
> effort to look into the details of the process if that can be avoided.

Makes sense. I think it's best we go forward with the document using the 
current type.

Cheers,
Ari

---

From: SM <[email-masked]>
Date: Wed, 04 Dec 2013 08:11:17 -0800

Hi Muthu,
>Sorry, not clear to me. Can you provide some examples?

As an example:

   "The reproduction of the [RFC4695] IANA considerations 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 IANA 
>action (see the IANA Considerations section). So, why should it be 
>published as an Informational RFC?

The issue (using the word loosely) is that the draft is referring to 
a registration request in Section 1.1 of RFC 4856 which is about IANA 
Considerations.  My argument is that the working group has not 
provide an explanation about why the proposal should be published on 
the Standards Track.  Instead of objecting to the publication as a 
RFC I suggested publishing the proposal as an Informational RFC.

Regards,
-sm

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 4 Dec 2013 17:08:18 +0000

Hi SM,

|-----Original Message-----
|From: SM [mailto:[email-masked]]
|Sent: Wednesday, December 04, 2013 9:41 PM
|To: Muthu Arul Mozhi Perumal (mperumal); Ari Keränen
|Cc: Flemming Andreasen (fandreas); [email-masked]
|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 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 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 IANA
|>action (see the IANA Considerations section). So, why should it be
|>published as an Informational RFC?
|
|The issue (using the word loosely) is that the draft is referring to
|a registration request in Section 1.1 of RFC 4856 which is about IANA
|Considerations.  

Yes, is referring to that section of RFC4856. However, the issue is not the registration itself -- it is to do with the missing offer/answer considerations for the registered media parameters that impact interoperability. As an example, RFC4352 registers AMR-WB+ and then describes the offer/answer model considerations for the parameters it registers. 

|My argument is that the working group has not
|provide an explanation about why the proposal should be published on
|the Standards Track.  Instead of objecting to the publication as a
|RFC I suggested publishing the proposal as an Informational RFC.

I don't think publishing it as an Informational RFC would improve interoperability.

Muthu

|
|Regards,
|-sm

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 4 Dec 2013 19:27:17 +0000

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 registrations are used. An IANA registration, per se, cannot contain any normative 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 all created by draft-ietf-mmusic-sdp-g723-g729, I suspect it is to RFC 3551 as these are the documents that actually specify such media types can be used 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

> From: mmusic [mailto:[email-masked]] On Behalf Of 
> Muthu Arul Mozhi Perumal (mperumal)
> Sent: 04 December 2013 17:08
> To: SM; Ari Keränen
> Cc: Flemming Andreasen (fandreas); [email-masked]
> 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 SM,
> 
> |Subject: RE: [MMUSIC] Last Call: 
> |<draft-ietf-mmusic-sdp-g723-g729-04.txt> (Offer/Answer 
> Considerations 
> |>Also, draft-ietf-mmusic-sdp-g723-g729-04 doesn't need any 
> IANA action 
> |>(see the IANA Considerations section). So, why should it be 
> published 
> |>as an Informational RFC?
> |
> |The issue (using the word loosely) is that the draft is 
> referring to a 
> |registration request in Section 1.1 of RFC 4856 which is about IANA 
> |Considerations.
> 
> Yes, is referring to that section of RFC4856. However, the 
> issue is not the registration itself -- it is to do with the 
> missing offer/answer considerations for the registered media 
> parameters that impact interoperability. As an example, 
> RFC4352 registers AMR-WB+ and then describes the offer/answer 
> model considerations for the parameters it registers. 
> 
> |My argument is that the working group has not provide an explanation 
> |about why the proposal should be published on the Standards Track.  
> |Instead of objecting to the publication as a RFC I suggested 
> publishing 
> |the proposal as an Informational RFC.
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: SM <[email-masked]>
Date: Wed, 04 Dec 2013 16:03:01 -0800

Hi Muthu,
At 09:08 04-12-2013, Muthu Arul Mozhi Perumal (mperumal) wrote:
>Yes, is referring to that section of RFC4856. However, the issue is 
>not the registration itself -- it is to do with the missing 
>offer/answer considerations for the registered media parameters that 
>impact interoperability. As an example, RFC4352 registers AMR-WB+ 
>and then describes the offer/answer model considerations for the 
>parameters it registers.

I'll comment below.

>I don't think publishing it as an Informational RFC would improve 

I was looking forward to read the above argument. :-)

The Introduction section of draft-ietf-mmusic-sdp-g723-g729-04 
mentions an issue which can affect interoperability.  It's a valid 
argument for choosing Standards Track.

I quote part of a message [1] from Keith Drage:

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

That describes the problem the proposal tries to solve.  The proposal 
probably has to have some RFC 2119 key words (re. 
interoperability).  In my opinion the interoperability question does 
not fit in RFC 4856.  The issue is where to put the missing 
offer/answer considerations.  I took a quick look at several related 
RFCs and could not find the answer.  I suggest looking into what 
Keith Drage suggested.

The registration is a separate issue.  In simple terms, a person can 
take a look at the registry and find the appropriate specification 
where the media parameters are defined.

Maybe you could work from where the protocol is specified, explain 
the interoperability issue and propose the solution.  I have not been 
able to determine whether a registration update is needed.  I'll 
suggest reading RFC 4855.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/mmusic/current/msg12856.html

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 5 Dec 2013 04:13:46 +0000

I see your point.

Our opinion was that an RFC that specifies the mapping of media type parameters with SDP and registers the media types with IANA should also describe its usage, especially with the offer/answer model (e.g, RFC435). In that sense we thought draft-ietf-mmusic-sdp-g723-g729 is an update to RFC4856.

Your opinion is that they should be delinked -- one RFC can register the media types and another RFC can describe the usage for the registered media types independently. I am fine with that. The abstract and introduction in draft-ietf-mmusic-sdp-g723-g729 can easily be changed to reflect it.

----------------------------------------------------------------------
Current Abstract:
   RFC4856 describes the annexa parameter for G723 and the annexb
   parameter for G729, G729D and G729E. However, the specification does
   not describe the offerer and answerer behavior when the value of the
   annexa or annexb parameter does not match in the Session Description
   protocol(SDP) offer and answer.  This document provides the offer/
   answer considerations for these parameters and updates RFC4856.

New Abstract:
   There are no specifications that describe the offerer and answerer 
   behavior when the value of the annexa parameter of G729 or the annexb 
   parameter of G729, G729D and G729E does not match in the Session 
   Description protocol(SDP) offer and answer. This document provides the 
   offer/answer considerations for these parameters.

Current Introduction:
   [RFC4856] describes the annexa parameter for G723 as follows:

      annexa: indicates that Annex A, voice activity detection, is used
      or preferred.  Permissible values are "yes" and "no" (without the
      quotes); "yes" is implied if this parameter is omitted.

   Also, [RFC4856] describes the annexb parameter for G729, G729D and
   G729E as follows:

      annexb: indicates that Annex B, voice activity detection, is used
      or preferred.  Permissible values are "yes" and "no" (without the
      quotes); "yes" is implied if this parameter is omitted.

   However, it does not have any normative statement for the case where
   the value of this parameter does not match in the SDP [RFC4566] offer
   and answer.  For example, if the offer has G729 with annexb=yes and
   the answer has G729 with annexb=no, it can be interpreted in two
   different ways:
   o  The offerer and answerer proceed as if G729 is negotiated with
      annexb=yes, or
   o  The offerer and answerer proceed as if G729 is negotiated with
      annexb=no.

   Since [RFC4856] does not state it clearly, various implementations
   have interpreted the offer/answer in their own ways, resulting in a
   different codec being chosen to call failure, when the parameter
   value does not match in the offer and answer.

   [RFC3264] requires SDP extensions that define new fmtp parameters to
   specify their proper interpretation in offer/answer.  But, [RFC4856]
   does not specify it for the Annex A flavor of G723 and the Annex B
   flavors of G729, G729D and G729E.

   This document describes the offer/answer considerations for these
   parameters and provides the necessary clarifications.

New Introduction:
   [RFC4856] describes the annexa parameter for G723 as follows:

      annexa: indicates that Annex A, voice activity detection, is used
      or preferred.  Permissible values are "yes" and "no" (without the
      quotes); "yes" is implied if this parameter is omitted.

   Also, [RFC4856] describes the annexb parameter for G729, G729D and
   G729E as follows:

      annexb: indicates that Annex B, voice activity detection, is used
      or preferred.  Permissible values are "yes" and "no" (without the
      quotes); "yes" is implied if this parameter is omitted.

   However, there is no specification describing the case where the value 
   of this parameter does not match in the SDP [RFC4566] offer and answer.  
   For example, if the offer has G729 with annexb=yes and the answer has 
   G729 with annexb=no, it can be interpreted in two different ways:
   o  The offerer and answerer proceed as if G729 is negotiated with
      annexb=yes, or
   o  The offerer and answerer proceed as if G729 is negotiated with
      annexb=no.

   Since this is not clearly stated, various implementations have interpreted 
   the offer/answer in their own ways, resulting in a different codec being 
   chosen to call failure, when the parameter value does not match in the 
   offer and answer.

   [RFC3264] requires SDP extensions that define new fmtp parameters to
   specify their proper interpretation in offer/answer. This document 
   describes the offer/answer considerations for these parameters and provides 
   the necessary clarifications.
----------------------------------------------------------------------

Do they address your concerns?

Muthu

|-----Original Message-----
|From: DRAGE, Keith (Keith) [mailto:[email-masked]]
|Sent: Thursday, December 05, 2013 12:57 AM
|To: Muthu Arul Mozhi Perumal (mperumal); SM; Ari Keränen
|Cc: Flemming Andreasen (fandreas); [email-masked]
|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
|
|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 registrations are used. An
|IANA registration, per se, cannot contain any normative 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 all created by draft-ietf-mmusic-sdp-g723-g729, I suspect it is to RFC 3551 as
|these are the documents that actually specify such media types can be used 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:[email-masked]] On Behalf Of
|> Muthu Arul Mozhi Perumal (mperumal)
|> Sent: 04 December 2013 17:08
|> To: SM; Ari Keränen
|> Cc: Flemming Andreasen (fandreas); [email-masked]
|> 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 SM,
|>
|> |-----Original Message-----
|> |From: SM [mailto:[email-masked]]
|> |Sent: Wednesday, December 04, 2013 9:41 PM
|> |To: Muthu Arul Mozhi Perumal (mperumal); Ari Keränen
|> |Cc: Flemming Andreasen (fandreas); [email-masked]
|> |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 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
|> 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
|> IANA action
|> |>(see the IANA Considerations section). So, why should it be
|> published
|> |>as an Informational RFC?
|> |
|> |The issue (using the word loosely) is that the draft is
|> referring to a
|> |registration request in Section 1.1 of RFC 4856 which is about IANA
|> |Considerations.
|>
|> Yes, is referring to that section of RFC4856. However, the
|> issue is not the registration itself -- it is to do with the
|> missing offer/answer considerations for the registered media
|> parameters that impact interoperability. As an example,
|> RFC4352 registers AMR-WB+ and then describes the offer/answer
|> model considerations for the parameters it registers.
|>
|> |My argument is that the working group has not provide an explanation
|> |about why the proposal should be published on the Standards Track.
|> |Instead of objecting to the publication as a RFC I suggested
|> publishing
|> |the proposal as an Informational RFC.
|>
|> I don't think publishing it as an Informational RFC would
|> improve interoperability.
|>
|> Muthu
|>
|> |
|> |Regards,
|> |-sm
|>
|> _______________________________________________
|> mmusic mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/mmusic
|>

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 5 Dec 2013 04:36:46 +0000

Hi SM,

|-----Original Message-----
|From: SM [mailto:[email-masked]]
|Sent: Thursday, December 05, 2013 5:33 AM
|To: Muthu Arul Mozhi Perumal (mperumal); Ari Keränen
|Cc: Flemming Andreasen (fandreas); [email-masked]
|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 Muthu,
|At 09:08 04-12-2013, Muthu Arul Mozhi Perumal (mperumal) wrote:
|>Yes, is referring to that section of RFC4856. However, the issue is
|>not the registration itself -- it is to do with the missing
|>offer/answer considerations for the registered media parameters that
|>impact interoperability. As an example, RFC4352 registers AMR-WB+
|>and then describes the offer/answer model considerations for the
|>parameters it registers.
|
|I'll comment below.
|
|>I don't think publishing it as an Informational RFC would improve
|>interoperability.
|
|I was looking forward to read the above argument. :-)
|
|The Introduction section of draft-ietf-mmusic-sdp-g723-g729-04
|mentions an issue which can affect interoperability.  It's a valid
|argument for choosing Standards Track.

We are on the same page here..

|
|I quote part of a message [1] from Keith Drage:
|
|   "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."
|
|That describes the problem the proposal tries to solve.  

And here as well..

|The proposal probably has to have some RFC 2119 key words (re.
|interoperability).  In my opinion the interoperability question does
|not fit in RFC 4856.  The issue is where to put the missing
|offer/answer considerations.  I took a quick look at several related
|RFCs and could not find the answer.  I suggest looking into what
|Keith Drage suggested.

Apparently, we have different opinions here. But, I don't see an issue with your/Kieth's opinion. I just responded to Kieth with the proposed changes to abstract and introduction.

|
|The registration is a separate issue.  In simple terms, a person can
|take a look at the registry and find the appropriate specification
|where the media parameters are defined.

Same as above..

|Maybe you could work from where the protocol is specified, explain
|the interoperability issue and propose the solution.  

I am not sure if you have read daft-ietf-mmusic-sdp-g723-g729 fully, but the interoperability issue and the proposed solution is the crux of the draft -- this was also the focus of discussions in the WG and we didn't pay much attention to whether it really is an update to RFC4856 -:)

|I have not been able to determine whether a registration update is needed.  
|I'll suggest reading RFC 4855.

RFC4855 has no suggestions on that.

Muthu

|
|Regards,
|-sm
|
|1. http://www.ietf.org/mail-archive/web/mmusic/current/msg12856.html

---

From: SM <[email-masked]>
Date: Wed, 04 Dec 2013 20:54:01 -0800

Hi Muthu,
At 20:13 04-12-2013, Muthu Arul Mozhi Perumal (mperumal) wrote:
>I see your point.
>
>Our opinion was that an RFC that specifies the mapping of media type 
>parameters with SDP and registers the media types with IANA should 
>also describe its usage, especially with the offer/answer model 
>(e.g, RFC435). In that sense we thought 
>draft-ietf-mmusic-sdp-g723-g729 is an update to RFC4856.
>
>Your opinion is that they should be delinked -- one RFC can register 
>the media types and another RFC can describe the usage for the 
>registered media types independently. I am fine with that. The 
>abstract and introduction in draft-ietf-mmusic-sdp-g723-g729 can 
>easily be changed to reflect it.

Yes, but you can have both in one RFC.  The registration can be 
requested in the IANA Considerations section.

>---------------------------------------------------------------------
>Current Abstract:

I suggest removing "there are no specifications ..." and explain what 
the document specifies.

>       quotes); "yes" is implied if this parameter is omitted.

The above starts with RFC 4856.  I suggest starting with the RFC 4566 
followed by the RFC 3264 text (I did not verify the reference).  You 
can then specify the fmtp parameters for Annex A, etc.  Once you have 
done that, verify whether there are some registry requirements and 
add text for that in a IANA Considerations section.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Wed, 04 Dec 2013 23:17:34 -0800

Hi Muthu,
At 20:36 04-12-2013, Muthu Arul Mozhi Perumal (mperumal) wrote:
>I am not sure if you have read daft-ietf-mmusic-sdp-g723-g729 fully, 
>but the interoperability issue and the proposed solution is the crux 
>of the draft -- this was also the focus of discussions in the WG and 
>we didn't pay much attention to whether it really is an update to RFC4856 -:)

I read the draft and I did somewhat of the reverse. :-)  I was 
puzzled about why the draft was updating that RFC to address an 
interoperability issue.

>RFC4855 has no suggestions on that.

Yes. :-(

Regards,
-sm

---

From: Stephen Casner <[email-masked]>
Date: Thu, 5 Dec 2013 00:22:18 -0800 (PST)

On Wed, 4 Dec 2013, DRAGE, Keith (Keith) wrote:

> It does not contain any requirements, except by implication, of how
> those registrations are used. An IANA registration, per se, cannot
> contain any normative requirements, all it is a list of assigned
> values.
>

I disagree.  Establishing the media type registrations is a valid part
of the standardization process.  I believe there are other examples of
standard track documents written for the purpose of IANA
registrations, such as 3575, 4002, 4355, 4415, although there are also
a number of others that are BCP.

None of that is relevant to the current I-D, though.

> 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 all created by
> draft-ietf-mmusic-sdp-g723-g729, I suspect it is to RFC 3551 as
> these are the documents that actually specify such media types can
> be used within the SDP. However my preference would be to not have
> this document do any update.

Exactly.  That is what I said in my email reply on Monday.

> I do believe draft-ietf-mmusic-sdp-g723-g729 normatively impacts the
> track.

Right.

                                                        -- Steve