[Dime] AD review of draft-ietf-dime-local-keytran-09

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Mon, 16 May 2011 14:14 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E6BE06AD for <dime@ietfa.amsl.com>; Mon, 16 May 2011 07:14:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.385
X-Spam-Level:
X-Spam-Status: No, score=-103.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1PkE8YSwCNn for <dime@ietfa.amsl.com>; Mon, 16 May 2011 07:14:30 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id CDB52E0699 for <dime@ietf.org>; Mon, 16 May 2011 07:14:30 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao4HABww0U2HCzI1/2dsb2JhbACYDY4Jd6d4g1kCmzWGGQSUXYor
X-IronPort-AV: E=Sophos;i="4.64,374,1301889600"; d="scan'208";a="280157614"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 16 May 2011 10:14:30 -0400
X-IronPort-AV: E=Sophos;i="4.64,374,1301889600"; d="scan'208";a="652429848"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 16 May 2011 10:14:29 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 16 May 2011 16:14:28 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A04031E5369@307622ANEX5.global.avaya.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: AD review of draft-ietf-dime-local-keytran-09
Thread-Index: AcwT05Fma3l2DkipR/GWj6GKnfHFjg==
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: dime@ietf.org
Subject: [Dime] AD review of draft-ietf-dime-local-keytran-09
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 May 2011 14:14:31 -0000

Hi, 

I have reviewed draft-ietf-dime-local-keytran-09. The document is in
good shape, I have a small number of issues which seem simple to respond
and fix if necessary, so I suggest that you do it before submitting the
document to IETF Last Call. 

Technical Issues are marked T and Editorial issues are marked E. 

Technical:

T1: Is there any special reason for skipping decimal value (4) in the
enumeration in Section 3.1.1? If there is none I suggest to move RSA-KEM
from (5) to (4). 

T2: Are there any special recommendations for the experts who will be in
charge in the future with the "Expert Review" policy as per [RFC5226]
for AVP types? For example is it recommended to assign AVPs only for
cryptographic key material defined in IETF standard track documents? 

T3. In section  5.2: 

   'once values have been assigned, they MUST NOT be deleted, replaced,
modified or deprecated.' 

It is not clear why we do not allow for values to be deprecated.
Assuming that a cryptographic delivery method was deprecated, why would
not marking the AVP as deprecated be allowed, as long as the value
cannot be deleted, replaced or modified? 

Editorial: 

E1: Why is RSA-KEM not expanded and explained in Section 2.2. -
Technical Terms and Acronyms?


Thanks and Regards,

Dan