[secdir] SECDIR review of draft-ietf-avtcore-avp-codecs-02

Radia Perlman <radiaperlman@gmail.com> Thu, 06 June 2013 13:14 UTC

Return-Path: <radiaperlman@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB0E21F99D2; Thu, 6 Jun 2013 06:14:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 1FjAKgAqx359; Thu, 6 Jun 2013 06:14:19 -0700 (PDT)
Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 36D8621F99C3; Thu, 6 Jun 2013 06:14:19 -0700 (PDT)
Received: by mail-la0-f42.google.com with SMTP id eb20so2563568lab.15 for <multiple recipients>; Thu, 06 Jun 2013 06:14:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=6yVmIZlypMuBkZ5ZbiHlhKIU1Ir7e/Srg6qPOZ20ais=; b=aK2MzPona90hnLXDxCve8YPPSZl0F1wJ4cA+/3F6x07r0JuuVts2qY3v62iYCeisAY Xgrlxr8eP+hLx7cfR3eZhpM5lDoMTh0PhhCTUn6Yg81VpJDa6I9ZWTlDB5Vsrb6WXgIb 2qfes/KZ7fDvPhK9SMKl1uWtKsuOdv2BSJyE/aVOiuPKmJwgR3Z+uwOQbdQqVpJoT40p saU1eKRmXxVfwzeo+B4Qd64LgoR7MmqIdA3/dtnEX7M6PYtm8XqNf9v72F3elcXZ1YHR oJEZexJpzf/BA/8cwnpnobmJhfp7yt+wUZAf2TDGUCcY2PQURs6WgV4NXcO8MkFGuHNN hEYA==
MIME-Version: 1.0
X-Received: by 10.112.142.73 with SMTP id ru9mr17256869lbb.22.1370524457975; Thu, 06 Jun 2013 06:14:17 -0700 (PDT)
Received: by 10.112.69.8 with HTTP; Thu, 6 Jun 2013 06:14:17 -0700 (PDT)
Date: Thu, 06 Jun 2013 06:14:17 -0700
Message-ID: <CAFOuuo4iQPc=2=QSoqXNJPYUoFqV6cfGbeBxO9zHwFyy=p5FwA@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: secdir@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-avtcore-avp-codecs@tools.ietf.org
Content-Type: multipart/alternative; boundary="001a11c36c7a79454504de7c1746"
Subject: [secdir] SECDIR review of draft-ietf-avtcore-avp-codecs-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 13:14:20 -0000

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This is a completely harmless editorial update of another document (RFC
3551] to replace the paragraph

   Audio applications operating under this profile SHOULD, at a minimum,
   be able to send and/or receive payload types 0 (PCMU) and 5 (DVI4).
   This allows interoperability without format negotiation and ensures
   successful negotiation with a conference control protocol.


 with


   Audio applications operating under this profile SHOULD, at a minimum,
   be able to send and/or receive payload type 0 (PCMU).  This allows
   interoperability without format negotiation and ensures successful
   negotiation with a conference control protocol.  Some environments
   REQUIRE support for PCMU.


There are certainly no security implications (as correctly noted in this draft).


My only question is...shouldn't this be an actual updated document,
rather than a tiny document saying "replace this paragraph with this
other paragraph"?  Surely we wouldn't make this document an RFC rather
than simply replacing RFC 3551 with an updated RFC?


Radia