Re: [AVTCORE] Pete Resnick's Discuss on draft-ietf-avtcore-srtp-vbr-audio-03: (with DISCUSS)

Robert Sparks <rjsparks@nostrum.com> Tue, 01 November 2011 15:50 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F491F0C44; Tue, 1 Nov 2011 08:50:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ow7nwSYAaBgb; Tue, 1 Nov 2011 08:50:39 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6288C11E80AB; Tue, 1 Nov 2011 08:50:30 -0700 (PDT)
Received: from [192.168.2.105] (pool-173-74-105-241.dllstx.fios.verizon.net [173.74.105.241]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pA1FoSUL080731 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Nov 2011 10:50:29 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Robert Sparks <rjsparks@nostrum.com>
In-Reply-To: <20111031132810.20293.12093.idtracker@ietfa.amsl.com>
Date: Tue, 01 Nov 2011 10:50:28 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <9AA22A68-6D9C-4709-964A-24693B7EE8DA@nostrum.com>
References: <20111031132810.20293.12093.idtracker@ietfa.amsl.com>
To: Pete Resnick <presnick@qualcomm.com>
X-Mailer: Apple Mail (2.1084)
Received-SPF: pass (nostrum.com: 173.74.105.241 is authenticated by a trusted mechanism)
Cc: draft-ietf-avtcore-srtp-vbr-audio@tools.ietf.org, avtcore-chairs@tools.ietf.org, IETF AVTCORE WG <avt@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [AVTCORE] Pete Resnick's Discuss on draft-ietf-avtcore-srtp-vbr-audio-03: (with DISCUSS)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Nov 2011 15:50:40 -0000

AVTCORE Working Group:

Pete is making an argument that the text in this document could be published as Standards Track. We've walked through the normative statements
in the document together and I see his argument. My only concern is whether there is any intent in the document to tell operators of existing deployments
to go change their configuration right away to avoid the security issues the document describes. Pete rightly points out that, as written, the document is 
providing guidance to new implementers, not to current operators.

Does anyone believe moving this to the Standards Track is the wrong thing to do?
Do you think the document needs to say anything more strongly about current deployments?

RjS


On Oct 31, 2011, at 8:28 AM, Pete Resnick wrote:

> Pete Resnick has entered the following ballot position for
> draft-ietf-avtcore-srtp-vbr-audio-03: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I don't see how this is remotely a BCP. This should be on the standards track. It is specifying all sorts of implementation parameters that are clearly testable, may have interoperability implications, and may change over time as we get implementation experience. (E.g., the length of the overhang period may be something that we specify differently, whether VAD is used or not may have interoperability implications, etc.). This discussion would have normally happened in the context of a security considerations section of a base protocol document and would have gone along the standards track with the base protocol. The fact that it is being published separately shouldn't change its treatment.
> 
> 
> 
>