[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf
Subject:    RE: Secdir telechat review of draft-ietf-i2nsf-framework-08
From:       Linda Dunbar <linda.dunbar () huawei ! com>
Date:       2017-10-25 15:47:56
Message-ID: 4A95BA014132FF49AE685FAB4B9F17F66AFC51D9 () sjceml521-mbs ! china ! huawei ! com
[Download RAW message or body]

Daniel, 

Thank you for your time reviewing this document. Obviously you 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 [mailto:dafranke@akamai.com] 
Sent: Tuesday, October 24, 2017 5:49 PM
To: secdir@ietf.org
Cc: i2nsf@ietf.org; draft-ietf-i2nsf-framework.all@ietf.org; ietf@ietf.org
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.


[prev in list] [next in list] [prev in thread] [next in thread]