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

SM <sm@resistor.net> Sat, 30 November 2013 23:19 UTC

Return-Path: <sm@resistor.net>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91461AE4AE for <mmusic@ietfa.amsl.com>; Sat, 30 Nov 2013 15:19:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.441
X-Spam-Level:
X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, MIME_8BIT_HEADER=0.3, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqBZ-6JgrhxH for <mmusic@ietfa.amsl.com>; Sat, 30 Nov 2013 15:19:17 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A2A1AE4AD for <mmusic@ietf.org>; Sat, 30 Nov 2013 15:19:17 -0800 (PST)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rAUNJ3vE025481; Sat, 30 Nov 2013 15:19:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1385853551; bh=SXrlpoTPLN4VBS4KqlMPp0j9O+5lbc/Ua4oyNIxfjgk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0gr1M0Tzp8rKTY0N1bYDMDPU5KN0EWbcJEuCAQTldPUrpNdTGLOsq2Ib8ftPmjR90 +zqS+w0Fu/dh9QAv6ori9h4iKlzmajn3XRgCP5skX4fkosnS+Cc5ARl/yZwqTjbqE8 eYHcrQu8YZseWpsqhl3zHTXEZc8bS71N9W676vpI=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1385853551; i=@resistor.net; bh=SXrlpoTPLN4VBS4KqlMPp0j9O+5lbc/Ua4oyNIxfjgk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cY0rWe9vZzoXrGY9ZbFBGVaAxURqIXXXtCLgYh16IIphWxo9gbJMAgT8H11pAQlpk lR4mEN5In5W3aPwjg99lWLXABdOL3CErrQ3EwK9uvOK1qCmoeCVN46aT9MuL1/WTaw ix3JfVOM+2W1VeA9VYtWx3Ov/sPHPglPs9vav3uE=
Message-Id: <6.2.5.6.2.20131130003721.0d65a980@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 30 Nov 2013 00:54:13 -0800
To: Ari Keränen <ari.keranen@ericsson.com>
From: SM <sm@resistor.net>
In-Reply-To: <016d01ceed31$aa7a1130$ff6e3390$@co.in>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Cc: Flemming Andreasen <fandreas@cisco.com>, 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
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Nov 2013 23:19:19 -0000

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