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: "Parthasarathi R" <[email-masked]>
Date: Mon, 4 Nov 2013 22:45:26 +0530

Sm,

Please read inline.

Thanks
Partha/Muthu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of SM
> Sent: Thursday, October 31, 2013 9:07 AM
> To: [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
> 
> At 06:17 30-10-2013, The IESG wrote:
> >The IESG has received a request from the Multiparty Multimedia Session
> >Control WG (mmusic) to consider the following document:
> >- 'Offer/Answer Considerations for G723 Annex A and G729 Annex B'
> >   <draft-ietf-mmusic-sdp-g723-g729-04.txt> as Proposed Standard
> >
> >The IESG plans to make a decision in the next few weeks, and solicits
> >final comments on this action. Please send substantive comments to the
> >[email-masked] mailing lists by 2013-11-27. Exceptionally, comments may
> be
> 
> I read this draft quickly.  According to the 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."
> 
> RFC 4856 is about media type registration of payload formats. 
<Partha> Agreed </Partha>

 The
> IESG approval mentioned that the document "specify the procedure to
> register RTP payload formats as audio, video or other media subtype
> names".  The RFC does not specify the AnnexA parameter for G723. 

<Partha> Agreed. RFC4856 describes AnnexA parameter for G723. </Partha>

 I
> took a quick look at the RFCs being referenced.  They are about media
> type registrations.  It is doubtful whether they even qualify for
> Proposed Standard.
<Partha> RFC4856 is published as proposed standard in IETF </Partha>

> 
> The premise on which the work in this draft is built is lacking.
<Partha> The premise on which the work in this draft is already well
described in the abstract itself </Partha>

  The
> draft mentions
> G723 Annex A without providing any reference to the
> specification. 
<Partha> G723 annexa SDP attribute is defined in RFC 4856. </Partha>

 In my opinion the draft needs more work for it to be
> a Proposed Standard.  
<Partha> Could you please list the work which has to be done for this draft
</Partha>

It doesn't look like there has been any
> discussion about whether there are IPR issues affecting
> implementations.
> 

<Partha> The authors are not aware of any IPR related to this issue. This
has been communicated to MMUSIC WG Chairs </Partha>

> Regards,
> -sm
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 19 Nov 2013 23:57:32 +0530

Sm,

I have clarified all your below queries. Could you please let me know in
case you still see any specific issue with the draft.

Thanks
Partha

> Behalf Of Parthasarathi R
> Sent: Monday, November 04, 2013 10:45 PM
> To: 'SM'; [email-masked]

---

From: SM <[email-masked]>
Date: Tue, 19 Nov 2013 11:27:07 -0800

Hi Partha,

I forgot to mention that I am not subscribed to the MMUSIC mailing list.

>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

---

From: "Parthasarathi R" <[email-masked]>
Date: Mon, 25 Nov 2013 01:49:39 +0530

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 24 Nov 2013 12:55:14 -0800

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

---

From: SM <[email-masked]>
Date: Fri, 29 Nov 2013 00:21:59 -0800

Hi Partha,
>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".

>RFC type. If you think that RFC 4856 status is wrong, Let us discuss in the

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

>mention ITU codec specification.

In my opinion, reading the corresponding codec specification is 
required to understand what the draft proposes.

Regards,
-sm

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 29 Nov 2013 23:45:46 +0530

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

2) 
<snip2>
> 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. 

Thanks
Partha

---

From: "Parthasarathi R" <[email-masked]>
Date: Sat, 30 Nov 2013 00:04:34 +0530

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

> Sent: Friday, November 29, 2013 1:52 PM
> To: Parthasarathi R
> Cc: [email-masked]; Flemming Andreasen; Ari Keränen

---

From: SM <[email-masked]>
Date: Sat, 30 Nov 2013 00:54:13 -0800

Hi Ari,

I read the PROTO write-up.  There isn't any answer to the following question:

At 10:34 29-11-2013, Parthasarathi R wrote:
>to the original doc  it should not be a BCP.
>

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