[secdir] Secdir telechat review of draft-ietf-i2nsf-framework-08

Daniel Franke <dafranke@akamai.com> Tue, 24 October 2017 22:48 UTC

Return-Path: <dafranke@akamai.com>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4184813A658; Tue, 24 Oct 2017 15:48:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Daniel Franke <dafranke@akamai.com>
To: <secdir@ietf.org>
Cc: i2nsf@ietf.org, draft-ietf-i2nsf-framework.all@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150888532124.4802.13758793569414682089@ietfa.amsl.com>
Date: Tue, 24 Oct 2017 15:48:41 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/SERekZUf40G0Uh8Q9bOgHRyzczU>
Subject: [secdir] Secdir telechat review of draft-ietf-i2nsf-framework-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 24 Oct 2017 22:48:41 -0000

Reviewer: Daniel Franke
Review result: Not Ready

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

This document is too broad and too vague for any reasonable security review to
be possible. It expresses a desire to define a framework which satisfies
certain requirements and use cases, but does not actually define anything
concrete. At its most specific, the document gives parametricity constraints
that future definitions must satisfy, such as being agnostic to network
topology. This doesn't give me much to go on.

The security considerations section is brief, calling out the need for access
control and for protecting the confidentiality and integrity of data. Again,
with so few specifics, there's not much more to be said.

I do not think it is useful to anyone to publish this document as an RFC, not
even an informational one. It is perfectly fine, when specifying an intricate
suite of protocols, to have a separate document that gives a broad
architectural overview of them all without delving into the specifics necessary
for implementation. RFC 4251, which outlines the SSH protocol, is a good
example of this. But, crucially, RFC 4251 was published simultaneously with
4252-4256, which provided all those specifics. This document has nothing
similar as a companion; everything it describes is simply aspirational. I do
not see any value in publishing an RFC full of unfulfilled aspirations.