Re: [secdir] SecDir review of draft-ietf-ccamp-assoc-info-03

"Adrian Farrel" <adrian@olddog.co.uk> Sun, 13 May 2012 21:08 UTC

Return-Path: <adrian@olddog.co.uk>
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 66EF121F84DE; Sun, 13 May 2012 14:08:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.517
X-Spam-Level:
X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599]
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 Dj4bDR+C7eno; Sun, 13 May 2012 14:08:49 -0700 (PDT)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id A475421F84A5; Sun, 13 May 2012 14:08:48 -0700 (PDT)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q4DL8Z46000494; Sun, 13 May 2012 22:08:39 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q4DL8YiW000480 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 13 May 2012 22:08:34 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Yoav Nir'" <ynir@checkpoint.com>, <ietf@ietf.org>, <secdir@ietf.org>, <draft-ietf-ccamp-assoc-info@tools.ietf.org>
References: <329567CB-2EC4-4D9A-8E52-5D9D22C24417@checkpoint.com>
In-Reply-To: <329567CB-2EC4-4D9A-8E52-5D9D22C24417@checkpoint.com>
Date: Sun, 13 May 2012 22:08:34 +0100
Message-ID: <007d01cd314c$8f990c60$aecb2520$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFQj/2ZSa0yZlPsIw/HdQ+ygAHEMZfBePeQ
Content-Language: en-gb
Subject: Re: [secdir] SecDir review of draft-ietf-ccamp-assoc-info-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Sun, 13 May 2012 21:08:49 -0000

Thanks Yoav,

RFC Editor note entered for your observation.

Adrian

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Yoav
> Nir
> Sent: 13 May 2012 07:47
> To: ietf@ietf.org list; secdir@ietf.org;
draft-ietf-ccamp-assoc-info@tools.ietf.org
> Subject: SecDir review of draft-ietf-ccamp-assoc-info-03
> 
> Hi,
> 
> 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.
> 
> The document does not define any new procedures or mechanisms, and
> mentions this fact three times throughout the document. It formalizes an email
> by Adrian Farrel clarifying the procedures for processing an ASSOCIATION
object
> on a path message.
> 
> The security considerations section repeats that the document does not define
> new procedures, and concludes that no security considerations are added. This
is
> not a valid deduction, as clarification often involves prohibiting
non-functional or
> insecure interpretation of the original document text. However, in this case
the
> clarification is not about such insecure configurations, so the document is
fine.
> 
> One textual comment, though: section 2.2 near the bottom of page #5 lists 3
> possible values for association ID. The second option is "The LSP ID of the
LSP
> protecting an LSP". This is not clear. I suggest rewording as "The LSP ID of
the
> protecting LSP" without an indefinite "an LSP".
> 
> Yoav=