Re: [codec] 3 week WGLC on draft-ietf-codec-requirements-02

Mary Barnes <mary.ietf.barnes@gmail.com> Wed, 26 January 2011 00:08 UTC

Return-Path: <mary.ietf.barnes@gmail.com>
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 33A663A68E7 for <codec@core3.amsl.com>; Tue, 25 Jan 2011 16:08:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.322
X-Spam-Level:
X-Spam-Status: No, score=-103.322 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 Syt-b03cG80U for <codec@core3.amsl.com>; Tue, 25 Jan 2011 16:08:05 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 967413A68AB for <codec@ietf.org>; Tue, 25 Jan 2011 16:08:05 -0800 (PST)
Received: by gxk27 with SMTP id 27so2279238gxk.31 for <codec@ietf.org>; Tue, 25 Jan 2011 16:11:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=j9xbJug9F8DJgxAR6XHsTNEs1F84IlyilssWDaNh8ho=; b=l5uecBJgjNMZ8RQDRpkXIzEnNf1BdOBouX8XCuhjgYFQkn8+JJb3tGkE+dcoBPByIQ 7nHbYAzq3RV6f22t/6YuZCw/CChm5IqXZKpkDrxYExy58dxMYq+v+67ML/5QJ6s2rAd9 SViiocfcFKt5ieZawE+sk3lJTe7oM9XnSUX1A=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qDPM5tzpDXZoGnuSt21H9tOODsVhIM76RZTQWInqVuQzNx0bqQOG5hHS4vRhZ8tjsT AU35NK6p6C8gRhOhGUY/RFpHfVevl0dDip1u6btJ6KKw1j8CEttn6jlUZTcdhRjce9na EwFNKr5DPM1NZIWUO6bw7oIsNZOs2YWHVCGj8=
MIME-Version: 1.0
Received: by 10.236.95.143 with SMTP id p15mr889600yhf.9.1296000664052; Tue, 25 Jan 2011 16:11:04 -0800 (PST)
Received: by 10.236.95.35 with HTTP; Tue, 25 Jan 2011 16:11:03 -0800 (PST)
In-Reply-To: <A444A0F8084434499206E78C106220CA05FCA0D993@MCHP058A.global-ad.net>
References: <4D3AD6EA.5020607@jdrosen.net> <000001cbbad6$4f44aea0$edce0be0$@uni-tuebingen.de> <AANLkTi=xTwet-toobezTZAsitgdTnTrMCHDD3OqChxF7@mail.gmail.com> <001001cbbc02$c6acf010$5406d030$@uni-tuebingen.de> <4D3E0676.1040704@octasic.com> <AANLkTimPKb03YjdBWVcJU1UFpFRWcXAiuvzJL4yV8YRq@mail.gmail.com> <A444A0F8084434499206E78C106220CA05FCA0D993@MCHP058A.global-ad.net>
Date: Tue, 25 Jan 2011 18:11:03 -0600
Message-ID: <AANLkTi=ibEg59aE9gU6zFhg_T1MuWBcmnxyZ1b0mCnN3@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: "Elwell, John" <john.elwell@siemens-enterprise.com>
Content-Type: multipart/alternative; boundary="0023547c895b35a3aa049ab4ab34"
Cc: "codec@ietf.org" <codec@ietf.org>, Stephen Botzko <stephen.botzko@gmail.com>
Subject: Re: [codec] 3 week WGLC on draft-ietf-codec-requirements-02
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: Wed, 26 Jan 2011 00:08:07 -0000

John,

Sorry for the confusion - yes the one document I noted was the guidelines.
(There was no link to the doc in the Last call announcement, so I went to WG
page and was looking at the other documents as well).

However, the same comment does apply to the requirements - i.e., it should
be informational. There is a perenniel debate as to whether RFC 2119
language applies to informational documents - the RFC 2119 abstract
references only standards track documents and notes that the language (i.e.,
the words in CAPS) should be used sparingly as required for interoperability
or to limit behavior that has the potential to cause problems.  I interpret
that to mean that it does not apply to requirements.

I agree with you that clearly enumerating requirements is a good idea and
should be standard practice.

Thanks,
Mary.

On Tue, Jan 25, 2011 at 4:02 AM, Elwell, John <
john.elwell@siemens-enterprise.com> wrote:

> Mary,
>
> I am confused which document we are talking about. The subject indicates
> the requirements document, but your quoted text "suggested process" seems to
> come from the guidelines document.
>
> The situation with the requirements document
> (draft-ietf-codec-requirements-02) is that it is intended as Standards Track
> but contains no RFC 2119 language (as far as I can see, e.g., no "MUST"
> statements, and no reference to RFC 2119).
>
> I think it should indeed be Informational, but this does not prevent us
> having normative statements in which the codec specification that this WG
> produces is the subject, e.g., "The codec MUST ..." This would make it much
> easier to pick out the actual requirements and to measure the resulting
> codec specification against those requirements. Some WGs adopt the practice
> of numbering requirements, for easy reference.
>
> John
>
> > -----Original Message-----
> > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]
> > On Behalf Of Mary Barnes
> > Sent: 24 January 2011 23:25
> > To: Jean-Marc Valin
> > Cc: codec@ietf.org; Stephen Botzko
> > Subject: Re: [codec] 3 week WGLC on draft-ietf-codec-requirements-02
> >
> > The document is currently specified as Standards Track, thus
> > the use of RFC 2119 language is entirely appropriate.
> > However, ISTM that the document should really just be
> > Informational, in particular given the language in the
> > introduction that this document defines a "suggested
> > process", as opposed to a process that is required for codec
> > development.
> >
> >
> > Regards,
> > Mary.
> >
> >
> > On Mon, Jan 24, 2011 at 5:08 PM, Jean-Marc Valin
> > <jean-marc.valin@octasic.com> wrote:
> >
> >
> >       Christian,
> >
> >       I actually responded to the last comments you made a
> > while ago (oct 2010). One issue I pointed out was your use of
> > RFC2119 keywords, which (AFAIK) aren't appropriate for a
> > requirements draft (the requirements aren't a standard). So
> > statements like "Any codec specified by the IETF MUST be well
> > specified", besides stating the obvious, are inappropriate.
> >
> >       There were also comments that just did not belong to
> > this draft, such as the section on collaboration with other
> > WGs. Collaboration is not a characteristic of a codec. So
> > essentially, I merged the uncontroversial suggestion, but
> > that's all I could do. As far as I'm aware, there's nothing
> > in the current draft that goes against the consensus of the
> > WG. If there are, please point to specific issues and to
> > statements made by others (not just you) asking for the change.
> >
> >       Cheers,
> >
> >              Jean-Marc
> >
> >
> >       On 11-01-24 03:10 PM, Christian Hoene wrote:
> >
> >
> >               Christian - perhaps you could post a list of
> > the issues you see that
> >               haven't been addressed?
> >
> >               */[Christian Hoene] No Stephen, these issues
> > have been written down in
> >               previous emails, drafts and issues in the Trac.
> > They can be read by anybody
> >               anytime. Thus, I do not see any benefit of
> > repeating them again if the
> >               editors continue to ignore any input. Indeed,
> > they did not improve the
> >               draft despite sound technical reasons. /*
> >
> >               */Even if somebody is not fully involved in the
> > technical details: It is
> >               very odd that despite many hundreds emails and
> > many discussions since
> >               starting this WG the editors have not updated
> > the draft beside minor
> >               changes such as the boilerplate and typos. /*
> >
> >               */Even if the lack of any update was not
> > intentionally, the editors missed
> >               to do their job because they were too lazy or
> > rather too busy doing other
> >               thinks./*
> >
> >               */I would be sad if all the fruitful
> > discussions here and all the good
> >               contributions of many industry experts should
> > have been in vain. Even if
> >               not all requirements can be met by Opus, a
> > proper requirements document may
> >               be relevant for future solutions or other SDOs./*
> >
> >
> >               */CH/*
> >
> >
> >
> >
> >               _______________________________________________
> >               codec mailing list
> >               codec@ietf.org
> >               https://www.ietf.org/mailman/listinfo/codec
> >
> >
> >
> >       _______________________________________________
> >       codec mailing list
> >       codec@ietf.org
> >       https://www.ietf.org/mailman/listinfo/codec
> >
> >
> >
> >
>