Re: [I2nsf] Last Call: <draft-ietf-i2nsf-consumer-facing-interface-dm-26.txt> (I2NSF Consumer-Facing Interface YANG Data Model) to Proposed Standard

[tom petch <[e-mail]>]

On 15/03/2023 11:32, tom petch wrote:
> On 02/03/2023 14:16, The IESG wrote:
>>
>> The IESG has received a request from the Interface to Network Security
>> Functions WG (i2nsf) to consider the following document: - 'I2NSF
>> Consumer-Facing Interface YANG Data Model'
>>    <draft-ietf-i2nsf-consumer-facing-interface-dm-26.txt> as Proposed
>> Standard

Belatedly I notice another area of divergence which makes the set of 
documents incoherent and that is with threats.

This I-D uses 'ioc' as a basis' from which is derived

      identity stix {
      identity misp {
      identity openioc {
      identity iodef {

Earlier versions used threaat feed with

      identity signature-yara {
      identity signature-snort {
      identity signature-suricata {

and the capability I-D, with the RFC Editor, has

      identity content-security-control {

from which are derived

      identity ips {
     identity anti-virus {

which give rise to

      identity signature-set {
      identity exception-signature {

and

      identity detect {
      identity exception-files {

I am unclear how the capabilities which can be configured in this I-D 
are specified with the YANG identity of the capability I-D.  A sentence 
or two in this I-D explaining the relationship might clarify.

Tom Petch


> This is one of a set of seven or so documents, one of which (framework)
> made RFC8329 six years ago, the others are waiting on MISSREF and then
> there is this one.  It would be good to get these out as RFC.
>
> A problem I have seen with them is ideas changing with them, evolving,
> so that the I-D are out of step.  As this is the last, this might be the
> place to address this.
>
> I have not had time, in the tsunami of I-D prior to IETF submission
> cut-off, to review this thoroughly but do see a divergence in the
> treatment of location.  This used to be geo-ip, RFC8179, as is mentioned
> in RFC8329 and that is still referenced in e.g. nsf-facing.  This I-D
> now uses country/region/city which is fine except for documents like
> 'capability' in the RFC-Editor Q which references RFC8179.  The
> technically correct solution might be to update 'capability' etc but I
> think that the time for that is past.  I put in some effort a few years
> ago to get them in line but no sooner had I done so than they diverged
> again after comments by other reviewers so I think that keeping them in
> line is a never ending task.
>
> What this I-D perhaps could do is to mention this divergence in
> treatment.  I will look some more to see where else they have diverged
> but not before the end of thie Last Call.
>
> In passing, I note that the SIP example uses what might be genuine
> addresses.
>
> Tom Petch
>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final
>> comments on this action. Please send substantive comments to the
>> [e-mail] mailing lists by 2023-03-16. Exceptionally,
>> comments may
>> be sent to [e-mail] instead. In either case, please retain the
>> beginning
>> of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>     This document describes an information model and the corresponding
>>     YANG data model for the Consumer-Facing Interface of the Security
>>     Controller in an Interface to Network Security Functions (I2NSF)
>>     system in a Network Functions Virtualization (NFV) environment.  The
>>     information model defines various types of managed objects and the
>>     relationship among them needed to build the flow policies from users'
>>     perspective.  This information model is based on the "Event-
>>     Condition-Action" (ECA) policy model defined by a capability
>>     information model for I2NSF, and the YANG data model is defined for
>>     enabling different users of a given I2NSF system to define, manage,
>>     and monitor flow policies within an administrative domain (e.g., user
>>     group).
>>
>>
>>
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-consumer-facing-interface-dm/
>>
>>
>>
>> The following IPR Declarations may be related to this I-D:
>>
>>     https://datatracker.ietf.org/ipr/3554/
>>     https://datatracker.ietf.org/ipr/3604/
>>     https://datatracker.ietf.org/ipr/5749/
>>     https://datatracker.ietf.org/ipr/5694/
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> IETF-Announce mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>> .
>>