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

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

Hi Tom,
I have addressed your comments on I2NSF Consumer-Facing Interface:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-27

I attach a revision letter to explain how I have addressed your comments on
the revision.

Thanks.

Best Regards,
Paul


On Sat, Mar 18, 2023 at 12:54 AM tom petch <[e-mail]> wrote:

> 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
> >> .
> >>
>
> _______________________________________________
> I2nsf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2nsf
>