Re: LC reviews: draft-brenner-dime-peem

"Joel M. Halpern" <jmh@joelhalpern.com> Sun, 06 January 2008 21:32 UTC

Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBd6u-0006qS-K9; Sun, 06 Jan 2008 16:32:48 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBd6s-0006jB-JM; Sun, 06 Jan 2008 16:32:46 -0500
Received: from bender-mail.tigertech.net ([64.62.209.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBd6q-0001KB-Lu; Sun, 06 Jan 2008 16:32:46 -0500
Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id BF7A17DDC; Sun, 6 Jan 2008 13:32:43 -0800 (PST)
Received: from [192.168.0.100] (pool-71-240-224-250.fred.east.verizon.net [71.240.224.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 541327DC1; Sun, 6 Jan 2008 13:32:40 -0800 (PST)
Message-ID: <478148F3.5060109@joelhalpern.com>
Date: Sun, 06 Jan 2008 16:32:35 -0500
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: gen-art@ietf.org
References: <F66D7286825402429571678A16C2F5EE0135EACE@zrc2hxm1.corp.nortel.com>
In-Reply-To: <F66D7286825402429571678A16C2F5EE0135EACE@zrc2hxm1.corp.nortel.com>
X-Enigmail-Version: 0.95.6
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net
X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on bender.tigertech.net
X-Spam-Status: No, hits=3.4 tagged_above=-999.0 required=7.0 tests=RCVD_IN_SORBS_DUL, SPF_NEUTRAL
X-Spam-Level: ***
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: mrbrenner@alcatel-lucent.com, dromasca@avaya.com, Mary Barnes <mary.barnes@nortel.com>, ietf@ietf.org
Subject: Re: LC reviews: draft-brenner-dime-peem
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.


Document: Diameter Polic Processing Application
Reviewer: Joel M. Halpern
Review Date:  6-January-2008
IETF LC End Date: 17-January-2008
IESG Telechat date: N/A

Summary: This document is nearly ready for publication as an information 
  RFC.
	The first of the two comments below is probably primarily the IESG's 
concern, although it affects the IETF last call.
	The second comment is a more general issue.

Comments:
	This document requests assignment of a Diameter Command Code.
	As this requires "IETF Consensus" additional care may be needed to 
ensure that the Last Call produces clarity on the required consensus. 
It would seem appropriate for the last call announcement to have 
indicated this requirement.  It is difficult to claim "IETF Consensus" 
from the typical non-response to IETF last call for informational documents.

	It seems exceedingly unlikely that the protocol exchanges to support a 
separate policy processing application introduce no new security issues 
compared with the Diameter base protocol in the assumed Diameter 
deployment.  Obviously, as I am not performing a full review of the 
PEM-1 protocol, I can not assert that there are or are not security 
implications, but it would seem that there are likely to be such.  I 
would be less concerned, but examination of the PEM-1 specification did 
not show the existence of a security discussion which could be taken to 
serve in lieu of such a section.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf