Hi!
The following is my AD review of draft-ietf-i2nsf-capability-05:
== [ Process feedback
(1) The I2NSF charter states "The working group will decide later whether the
information model needs to be published as an RFC". The shepherd write-up does
not capture WG deliberation on choosing to publish this document. Can this
please be added.
(2) What is the rational for this draft being standards track? For a standards
track information model, I would expected normative references to content
needed by the data models. However, the data models that would be implement
this IM only reference it as informational.
==[ High level feedback
(More specific pointers to all of these are in the detailed feedback)
** The document discusses a lot different models -- CapIM, capability
information model, ECA policy model, capability model, meta-model, external
information model. It would be helpful to define upfront the relationship
between these components.
** The CapIM also appears to have multiple use cases. The text seems to
fluidly move between the ideas of a Policy Rule and the capability being
advertised by the NSF. Being clear up front and organizing the text around
these uses would be helpful.
** At times it wasn't clear if what was being described is an element of the
CapIM or a properties of the system that would be consuming it.
** The mechanics of integrating external models wasn't clear to me
** Finally, explaining these models relative to the I2NSF
architecture/terminology would be very helpful - i.e., the I2NSF reference
architecture in Figure 1 of RFC8329, and the I2NSF Policy Rule.
==[ Detailed feedback
(3) Abstract. Whatever markup generated this text oddly placed the Abstract
after the Copyright notice and status of this memo statement. The abstract
should be first. Can you please rearrange the text.
(4) Please resolve these additional IDnits:
** The document seems to lack an Introduction section.
(A line matching the expected section header was found, but with an
unexpected indentation:
' 1. Introduction' )
** The document seems to lack a Security Considerations section.
(A line matching the expected section header was found, but with an
unexpected indentation:
' 5. Security Considerations' )
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** There are 4 instances of too long lines in the document, the longest one
being 13 characters in excess of 72.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
(5) Section 1. It struck me as unusual that Section 1 and early parts of 2,
don't explain this information model (IM) in terms of the I2NSF architecture.
Is there a reason for that? IMO, it would make the text a lot clearer to state
that this IM is used for particular I2NSF interfaces and avoid the defining
what NSFs need. Without it, the text isn't clear on the link between "Security
Capabilities" and the I2NSF architecture.
(6) Section 1. Per the opening paragraph of "The rapid development of
virtualized systems .... Examples include ...":
-- Sentence #2 doesn't seem to support sentence #1. What is the link between
IoT devices and virtualization?
-- what are residential access users?
(7) Section 1. Expand NSF on first use.
(8) Section 1. Editorial. s/over the given network traffic/on the network
traffic/
(9) Section 1. Editorial.
s/Security Capabilities describe the functions that Network Security Functions
(NSFs) are available to provide for security policy enforcement purposes./
Security Capabilities describe the functionality that Network Security
Functions (NSFs) are able to provide for security policy enforcement purposes./
(10) Section 1. Per "Security Capabilities are independent of the actual
security control mechanisms that will implement them":
-- this seems redundant to the content of the next paragraph.
-- in this context is a security control mechanism an NSF? Or something new?
(11) Section 1. Per "Every NSF SHOULD be described with the set of
capabilities it offers", it seems odd for an IM document to place this required
as it doesn't actually specify the solution (as this would be a data model)
(12) Section 1. Expand "ECA model" on first use.
(13) Section 3. The first paragraph, "A Capability Information Model (CapIM),
is a ..." and the fifth paragraph, "The CapIM is intended ...", appear to
restate many of the same things. Recommend their consolidation.
(14) Section 3. Editorial. s/This enables the precise/It enables the precise/
(15) Section 3. How the paragraphs 2 - 4 of this section inform the model
design isn't clear to me. I don't think they are needed.
(16) Section 3. Per paragraph 6, "This includes enabling ...", I don't follow
how this text informs the design.
(17) Section 3.1. Editorially splitting the Design Principles and the ECA
Policy Model into different section might helpful readability.
(18) Section 3.1. Abstraction. This principal has already been mentioned twice
between in Section 1 ("Security Capabilities enable security functionality to
be described in a vendor-neutral manner") and Section 3 ("Capabilities MUST be
defined in a vendor- and technology-independent manner"). Perhaps it only
needs to be said here?
(19) Section 3.1. Advertisement and Execution. How does the existence of a
"dedicated, well-known interface" influence the design of the information
model? Is it that certain meta-data is needed (or not)? These seem like
properties of the I2NSF architecture.
(20) Section 3.1. Automation and Scalability. How this text informs the design
of the IM isn't clear. It seems to describe the properties of the end system
using the IM. I would have expected the text to describe how this translates
into the data fields in the IM.
(21) Section 3.1. Per "Based on the above principles, this document defines a
capability model ...", per the draft's title, I thought this document was
describing an information model? What is the link between the capability model
and IM?
(22) Section 3.1., Per the paragraph that starts with "Furthermore, when an
unknown threat ...", I don't understand how this text informs the design or
specification of the IM?
(23) Section 3.1., "This document specifies a metadata model what MAY be used
to further describe and/or prescribe ...", per the draft's title, I thought
this document was describing an information model. What is the relationship
between the metadata model and the IM.
(24) Section 3.1, Per "The ECA policy model in [RFC8329] is used as the basis
for the design of the capability model..." - what is the relationship between
an ECA policy model, a capability model, CapIM and an "I2NSF Policy Rule".
(25) Section 3.1. Per "The "Event-Condition-Action" (ECA) policy model in
[RFC8329] is used as the basis for the design of the capability model", seems
circular. RFC8329 explicitly states that "The above concept [ECA] is described
in detail in I2NSF-CAPABILITIES". However, the language here appears to be
more specific and descriptive - it seems like the more specific descriptions is
normatively citing the more general text.
(26) Section 3.1. The text definition Event, Condition and Action is
cut-and-paste from the terminology document (draft-ietf-i2nsf-terminology).
The subsequent paragraph of "An I2NSF Policy Rule ..." is also very similar to
the terminology draft. Why is it duplicated here again?
(27) Section 3.1. What is the relationship between a policy model and a policy
rule?
(28) Section 3.1. Per the definition of the I2NSF Policy Rule of "I2NSF Policy
Rule is made up of three Boolean clauses ...", this definition is inconsistent
with draft-ietf-i2nsf-terminology which suggests that it is "three clauses
(Event, Condition, and Action). The Event and Condition clauses are Boolean
clauses, while the Action clause consists of a set of one or more I2NSF
Actions."
(29) Section 3.1. Where is the specification for the business logic? What is
the "algebra" by which to combine the ECA clauses and related Boolean logic,
with this metadata?
(30) Section 3.1. I found this example of meta-data confusing because it isn't
explained until Section 3.3. I'd recommending moving it or providing a forward
reference.
(31) Section 3.2. Provide a citation for I2NSF NSF-Facing Interface when it is
used.
(32) Section 3.2, Per Step 2 - 4, how is the CapIM relevant here. It seems
like these steps are describing internal processing that occurs on the I2NSF
Network Operator Management Systems/Controller based on the information
exchanged through the interfaces using the CapIM.
(33) Section 3.2., Per Step 4, What does it mean to "creates or uses one or
more data models from the CapIM to manage the NSFs" - the CapIM has data models?
(34) Section 3.2. Where does the "external ECA information Model" come from?
(35) Section 3.3. Per "Capabilities are typically used to represent NSF
functions", why "typically"? Are there instances where capabilities are not
NSF functions?
(36) Section 3.3, Per "Capabilities are objects, and hence, can be used ...",
perhaps it might be clearer to say "Capabilities are modeled as objects ..."
(37) Section 3.3. Per "The I2NSF CapIM refines a predefined (and external)
metadata model; the application of I2NSF Capabilities is done by refining a
predefined (and external) ECA Policy Rule information model that defines how to
use, manage , or otherwise manipulate a set of capabilities."
-- where do the external models come from?
-- what does it mean to refine the model? Does it add need elements to the
model, redefine semantics?
-- what does it mean to apply the I2NSF capability?
(38) Section 3.3., Per "When the I2NSF policy engine receives a set of events
...", what is the "I2NSF policy engine"? From where does it get the events?
It would be helpful to define it in terms of the I2NSF reference model per
Figure 1 of RFC8329? It isn't defined in the terminology draft either.
(39) Section 3.3., Per "Condition clauses are logical formulas that combine one
or more conditions that evaluate to a Boolean ...", this seems like the same
definition as Section 3.1. Does this need to be said again?
(40) Section 3.3. Per "The values in the condition clause are built on values
received or owned by the NSF", what does it mean to "own" the value?
(41) Section 3.3, Per the discussion of resolution strategies, I recommend
being more explicit that these are the "meta-data" elements (is that right?).
IMO, it would be clearer to define the I2NSF Policy Rule upfront as consisting
of the three clauses + meta data.
(42) Section 3.3. Per "Resolution strategies may use ... 'external data'", is
this external data different than meta-data? This isn't clear.
(43 Section 3.3.1. I'm missing something basic because it isn't clear to me
how to use this section as normative guidance to implement this information
model.
-- The applicability of the MEF Policy model was not clear to me (what was the
guidance from this example)
-- The OO guidance isn't clear - first an example show how an
I2NSFECAPolicyRule sub-classes MCMECAPolicyRule. However slightly later, the
text suggest the CapIM uses the decorator pattern (which wouldn't be
sub-classing). I appreciate that these were different Figures, but what is
the relationship?
-- I can't seem to find the I2NSF specific bits being added with the decorator
pattern.
-- Figure 2 lists a number of I2NSF specific classes, but the role and
fields/members of each isn't clear.
(44) Section 3.4. How an implementer would use this section isn't clear
(45) Section 3.4.1. What is the relationship between defining a "matched
policy rule" (the first part of this section) and a list of properties that
characterize the capabilities of the NSF (the other half of this section)?
Furthermore, what is the relationship (and significance of enumerating this
list) relative to the CapIM?
(46) Section 3.4.1. Per "The concept of a 'matched' policy rule is defined as
...", is a "policy rule" the same as an "I2NSF policy rule"?
(47) Section 3.4.1. Typo. s/that to characterize/that characterize/
(48) Section 3.4.2, Per "Conflicts theoretically compromise the correct
functioning of devices (as happened for routers several year ago).",
-- what does the parenthetical comment about an event several years ago mean?
-- this conflict doesn't seem to compromise the device functionality (they are
only doing what they were configured), rather is seems like there is a emergent
undesirable behavior
(49) Section 3.4.2. This section refers to "an additional processes that
decides that action to be applied".
-- What is that process?
-- On what I2NSF architectural component does it get executed?
(50) Section 3.4.2 The text cites that a firewall might have a default
behavior if there aren't specific rules. Perhaps this is semantics, but isn't
a default behavior just a very general rule? I don't understand the guidance
being provide relative to "default behavior" (as suggested by the section
title) with this example.
(51) Section 3.4.2. Per the constructs RSc and Dc being "introduced [as]
another security capability", what do these mean relative to the CapIM? Are
they part of the CapIM or configuration items for the processing?
(52) Section 3.4.3. What kind of regex (e.g., PCRE? POSIX?)
(53) Section 3.4.3. What is a "high-level policy processing system" relative
to the I2NSF Reference architecture?
(54) Section 3.4.4. This section notes that the CapIM can describe both
generic functions and specific products? Is there any guidance to provide on
how to do that?
(55) Section 3.4.4. What is meant by "these will be described later in a
revision of this draft"?
(56) Section 3.4.6. How does this section on capability algebra fit into the
CapIM? Does CapIM encode the algebra or is this text intended to demonstrate
how an I2NSF node (which one?) would/could process the CapIM?
(57) Section 3.4.6. Per "Assigning capabilities to a large number of NSFs can
be a complex (and boring) operation) ...", the use of "boring" seems pejorative
and not germane to motivating the subsequent algebra.
(58) Section 4. What is the re-organization suggested by "Nevertheless, a
partial re-organization of the data models already produced by the WG is
expected"?
(59) Section 4. Per "Currently (A survey on the existing data models in the
I2NSF world with a couple of lines about it and a list of things that can be
inherited).", what does this parenthetic statement mean?
(60) Section 4. Per "The CapIM can benefit ...", can this intent of this
sentence be clarified. It reads to me that its identifying deficiencies in the
CapIM but it isn't clear how implementers would use this information.
(61) Section 4. Could the intent of the last three paragraphs, "Knowing all of
the actions ..."/"On the other hand ..."/"Finally, Events are too ...", be
clarified. It reads to me that they are saying actually enumerating all of the
things that would appear in the data model would be a very long list so it
won't be done. However, "resolution strategies", "condition clauses" and
"evaluation methods" that will be used by the data models is a shorter list, so
they can be listed. I'm not sure how this helps implementers with the
"practical use of the CapIM". What would they do with this information? If
anything, I would see this as a design approach covered earlier.
(62) Section 8. IDNits is flagging all of these references in valid due to a
formatting issue. Can you please look into what might be happening - if it is
a bug in idnits, let me know.
(63) Section 8.1. Normative References. RFC3198, RFC8192 and RFC8329 are
normative references to an informational document. These downrefs is not noted
in the shepherd report. Can this please be updated pending resolution of the
following:
-- IMO, RFC8192 seems informative
-- RFC3198 is cited but doesn't appear to be used (it can be dropped)
(64) Section 8.2. Can you please provide a more detailed pointer for [MCM] and
[PDO]. I got as far as the MEF website but couldn't find these references.
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
