[secdir] secdir review of draft-ietf-dime-diameter-cmd-iana-01.txt

"Carl Wallace" <CWallace@cygnacom.com> Fri, 18 September 2009 18:49 UTC

Return-Path: <cwallace@cygnacom.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21C113A68BE; Fri, 18 Sep 2009 11:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.03
X-Spam-Level:
X-Spam-Status: No, score=-3.03 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599]
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 e801kR30r1Bh; Fri, 18 Sep 2009 11:49:11 -0700 (PDT)
Received: from p03c11o141.symantecmail.net (p03c11o141.symantecmail.net [208.65.144.84]) by core3.amsl.com (Postfix) with ESMTP id DC57F3A6B84; Fri, 18 Sep 2009 11:49:04 -0700 (PDT)
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o141.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 856d3ba4.87493552.88500.00-010.p03c11o141.symantecmail.net (envelope-from <cwallace@cygnacom.com>); Fri, 18 Sep 2009 12:50:00 -0600 (MDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Fri, 18 Sep 2009 14:49:58 -0400
Message-ID: <FAD1CF17F2A45B43ADE04E140BA83D48CD7CF2@scygexch1.cygnacom.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: secdir review of draft-ietf-dime-diameter-cmd-iana-01.txt
Thread-Index: Aco4kNH88gnA1/o1Txubi8Bd+XmFYQ==
From: Carl Wallace <CWallace@cygnacom.com>
To: secdir@ietf.org, iesg@ietf.org, dromasca@avaya.com, Hannes.Tschofenig@gmx.net
X-Spam: [F=0.2000000000; S=0.200(2009090401)]
X-MAIL-FROM: <cwallace@cygnacom.com>
X-SOURCE-IP: [65.242.48.5]
Subject: [secdir] secdir review of draft-ietf-dime-diameter-cmd-iana-01.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 18 Sep 2009 18:49:13 -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 document relaxes the requirements in the IANA considerations
section of RFC 3588 to allow a chunk of the possible command code space
to be vendor specific instead of requiring IETF review of all possible
command codes.  The security considerations section is probably fine
as-is but might benefit from addition of some discussion regarding
consequences of reusing command codes (interoperability problems are
mentioned in the introduction).  A few nits are below.

- The first sentence of the abstract (and introduction) is difficult to
parse.  
- In the Introduction, change "the conditions, which" to "the conditions
that" and change "were causes" to "were caused".
- The document states that it "aligns the extensibility rules for
Diameter command codes with those defined for Diameter application
identifiers".  Since the values are not aligned and there's no mention
of "extensibility rules" elsewhere in this document nor in 3588, I
suggest something like: "This document changes the allocation rules for
Diameter command codes to support usage of vendor specific command
codes, similar to the allocation of vendor specific application
identifiers."   
- It might be worth noting that this draft updates RFC 3588 independent
of its pending successor (or maybe this draft should be informational if
it is really only providing a preview of 3588bis).