Re: [codec] #5: Mention DTMF in requirements

"Christian Hoene" <hoene@uni-tuebingen.de> Fri, 02 April 2010 17:43 UTC

Return-Path: <hoene@uni-tuebingen.de>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B33DA3A6B5F for <codec@core3.amsl.com>; Fri, 2 Apr 2010 10:43:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.469
X-Spam-Level:
X-Spam-Status: No, score=-4.469 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzQ88epm-JWW for <codec@core3.amsl.com>; Fri, 2 Apr 2010 10:43:26 -0700 (PDT)
Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id B46683A6B61 for <codec@ietf.org>; Fri, 2 Apr 2010 10:34:15 -0700 (PDT)
Received: from hoeneT60 ([178.2.210.31]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o32HYeOo015325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Apr 2010 19:34:46 +0200
From: Christian Hoene <hoene@uni-tuebingen.de>
To: 'stephen botzko' <stephen.botzko@gmail.com>
References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <h2i6e9223711004020749u48c533eaq720b89f374cfbe9f@mail.gmail.com>
In-Reply-To: <h2i6e9223711004020749u48c533eaq720b89f374cfbe9f@mail.gmail.com>
Date: Fri, 02 Apr 2010 19:34:39 +0200
Message-ID: <000301cad28a$ca0c6450$5e252cf0$@de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrSc7yO/mr9S2ynRJyVELLOmqrCkQAFWVMg
Content-Language: de
X-AntiVirus-Spam-Check: failed (checked by Avira MailGate: version: 3.0.0-4; spam filter version: unknown; host: mx05)
X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.210; VDF: 7.10.6.23; host: mx05); id=10834-kf9GZn
Cc: codec@ietf.org
Subject: Re: [codec] #5: Mention DTMF in requirements
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Apr 2010 17:43:27 -0000

Hi Stephan,

Comments inline:


---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of Tübingen 
Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532 
http://www.net.uni-tuebingen.de/

From: stephen botzko [mailto:stephen.botzko@gmail.com] 
Sent: Friday, April 02, 2010 4:50 PM
To: Christian Hoene
Cc: Michael Knappe; stpeter@stpeter.im; codec@ietf.org
Subject: Re: [codec] #5: Mention DTMF in requirements

(a) "MUST NOT" means that it must fail.  Perhaps you meant "need not" or "might not"?

CH: Yes, I meant need not (or the German „muss nicht“)

(b) SHOULD is commonly used in establishing requirements, and it certainly was used in MARTINI and other working groups at IETF77 in
requirements presentations with no confusion. It has a clear meaning in the requirements context (desirable but not essential) and I
see no reason to avoid its use at this phase.  There will certainly be other things that are "nice to have", and it is appropriate
to track them and consider them in the selection/standardization process.

CH: Better? "The codec SHOULD support the transmission DTMF at most transmission conditions."

I agree that language about DTMF might not need to be in the final RFC.  Though if DTMF quality is known to be inadequate, it
probably makes sense to tell people that.

CH: Agreed. The limits of the codec shall be clearly stated.

I also agree to the obvious comment that DTMF detection methods are out of scope.

CH: Agreed.  

CH: Isn't time to include the MUST requirement for DTMF testing and SHOULD requirement for transmission support into the
requirements document. 
Then, we could close issue #5 and continue with other things.

 Christian