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

Linda Dunbar <> Wed, 25 October 2017 15:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5039813F406; Wed, 25 Oct 2017 08:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GvwBPiKq8dH6; Wed, 25 Oct 2017 08:47:08 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2759F13F3EE; Wed, 25 Oct 2017 08:47:07 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id DYK95145; Wed, 25 Oct 2017 15:46:59 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 25 Oct 2017 16:46:58 +0100
Received: from ([]) by ([]) with mapi id 14.03.0361.001; Wed, 25 Oct 2017 08:46:53 -0700
From: Linda Dunbar <>
To: Daniel Franke <>, "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: Secdir telechat review of draft-ietf-i2nsf-framework-08
Thread-Index: AQHTTRpBCbU9DO58mU+SEAnkR5GapKL0s9MQ
Date: Wed, 25 Oct 2017 15:46:52 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59F0B1F8.0036, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: c4b6b41609fe2910d8d2a82d98c850a6
Archived-At: <>
Subject: Re: [secdir] Secdir telechat review of draft-ietf-i2nsf-framework-08
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Oct 2017 15:47:10 -0000


Thank you for your time reviewing this document. Obviously our opinions on the value of publication are different from the WG consensus. 
The draft-ietf-i2nsf-framework describes the framework that glues together multiple detailed drafts describing different aspects of Interface to Network Security functions, such as   draft-ietf-i2nsf-capability-00, 	
draft-abad-i2nsf-sdn-ipsec-flow-protection-03, draft-hares-i2nsf-capability-data-model-04, draft-kim-i2nsf-nsf-facing-interface-data-model-03, etc. 

In addition, several recent industry initiatives are referencing I2NSF to guide their next step work. Such as ONUG (Open Network User Group) Software Defined Security Services and Linux Foundation’s OSC (Open Security Controller).  This is one example that IETF is leading the industry.
Without publishing draft-ietf-i2nsf-framework, it is not easy for the industry other initiatives to utilize the specifications (in many pieces) published by IETF. 

Linda Dunbar

-----Original Message-----
From: Daniel Franke [] 
Sent: Tuesday, October 24, 2017 5:49 PM
Subject: Secdir telechat review of draft-ietf-i2nsf-framework-08

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 comments.

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.