Re: [AVTCORE] [Technical Errata Reported] RFC3711 (3420)

Robert Sparks <rjsparks@nostrum.com> Fri, 22 March 2013 15:27 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 EB99521F8E10 for <avt@ietfa.amsl.com>; Fri, 22 Mar 2013 08:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.539
X-Spam-Level:
X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, 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 Rzk4lTfwXW7u for <avt@ietfa.amsl.com>; Fri, 22 Mar 2013 08:27:03 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B8C4F21F8E65 for <avt@ietf.org>; Fri, 22 Mar 2013 08:27:02 -0700 (PDT)
Received: from unnumerable.tekelec.com ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2MFQVA7024150 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 22 Mar 2013 10:26:31 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
Message-ID: <514C7827.3030503@nostrum.com>
Date: Fri, 22 Mar 2013 10:26:31 -0500
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Karl Norrman <karl.norrman@ericsson.com>
References: <20121128143149.E05F3B1E004@rfc-editor.org> <33E51946CDE71249AF9D86CE4D8966B40213AC@ESESSMB203.ericsson.se>
In-Reply-To: <33E51946CDE71249AF9D86CE4D8966B40213AC@ESESSMB203.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Received-SPF: pass (shaman.nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism)
X-Mailman-Approved-At: Sun, 24 Mar 2013 08:09:10 -0700
Cc: "even.roni@huawei.com" <even.roni@huawei.com>, "avt@ietf.org" <avt@ietf.org>, "elisabetta.carrara@ericsson.com" <elisabetta.carrara@ericsson.com>, "mbaugher@cisco.com" <mbaugher@cisco.com>, Mats Näslund <mats.naslund@ericsson.com>, "matthias.schertler@gmx.net" <matthias.schertler@gmx.net>
Subject: Re: [AVTCORE] [Technical Errata Reported] RFC3711 (3420)
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: Fri, 22 Mar 2013 15:27:04 -0000

Using the criteria at 
<http://www.ietf.org/iesg/statement/errata-processing.html> I recommend
putting this into Hold For Document Update.

( I could make an argument for Reject, given the text in 3550 is very 
clear, but a working group can make that decision if 3771 is ever revised).

On 11/28/12 9:13 AM, Karl Norrman wrote:
> Hello!
>
> I always considered the padding count to be part of the padding itself and hence it would be included in the encrypted portion.  However, the proposed errata below makes the text more explicit on this point.  So, if it can avoid some interoperability problems I'm all for accepting it.
>
> BR
> Karl
>
>
>> -----Original Message-----
>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
>> Sent: den 28 november 2012 15:32
>> To: mbaugher@cisco.com; elisabetta.carrara@ericsson.com;
>> mcgrew@cisco.com; Mats Näslund; Karl Norrman; Gonzalo
>> Camarillo; rjsparks@nostrum.com;
>> keith.drage@alcatel-lucent.com; even.roni@huawei.com
>> Cc: matthias.schertler@gmx.net; avt@ietf.org;
>> rfc-editor@rfc-editor.org
>> Subject: [Technical Errata Reported] RFC3711 (3420)
>>
>>
>> The following errata report has been submitted for RFC3711,
>> "The Secure Real-time Transport Protocol (SRTP)".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=3711&eid=3420
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Matthias Schertler <matthias.schertler@gmx.net>
>>
>> Section: 3.1.
>>
>> Original Text
>> -------------
>>     The "Encrypted Portion" of an SRTP packet consists of the
>> encryption    of the RTP payload (including RTP padding when
>> present) of the    equivalent RTP packet.
>>
>> Corrected Text
>> --------------
>>     The "Encrypted Portion" of an SRTP packet consists of the
>> encryption    of the RTP payload (including RTP padding and
>> RTP pad count when present)    of the equivalent RTP packet.
>>
>> Notes
>> -----
>> In Figure 1 "RTP padding" and "RTP pad count" are different
>> things. The text should use the same terminology in order to
>> make clear that the padding count is encrypted.
>>
>> Instructions:
>> -------------
>> This errata is currently posted as "Reported". If necessary,
>> please use "Reply All" to discuss whether it should be
>> verified or rejected. When a decision is reached, the
>> verifying party (IESG) can log in to change the status and
>> edit the report, if necessary.
>>
>> --------------------------------------
>> RFC3711 (draft-ietf-avt-srtp-09)
>> --------------------------------------
>> Title               : The Secure Real-time Transport Protocol (SRTP)
>> Publication Date    : March 2004
>> Author(s)           : M. Baugher, D. McGrew, M. Naslund, E.
>> Carrara, K. Norrman
>> Category            : PROPOSED STANDARD
>> Source              : Audio/Video Transport
>> Area                : Real-time Applications and Infrastructure
>> Stream              : IETF
>> Verifying Party     : IESG