[I2nsf] AD Review of draft-ietf-i2nsf-capability-05

[Roman Danyliw <[e-mail]>]

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.