Subject: [I2nsf] I-D Action: draft-ietf-i2nsf-consumer-facing-interface-dm-14.txt

From: [email-masked]
Date: Sat, 21 Aug 2021 17:58:15 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Interface to Network Security Functions WG of the IETF.

        Title           : I2NSF Consumer-Facing Interface YANG Data Model
        Authors         : Jaehoon (Paul) Jeong
                          Chaehong Chung
                          Tae-Jin Ahn
                          Rakesh Kumar
                          Susan Hares
	Filename        : draft-ietf-i2nsf-consumer-facing-interface-dm-14.txt
	Pages           : 60
	Date            : 2021-08-21

Abstract:
   This document describes an information model and a YANG data model
   for the Consumer-Facing Interface between an Interface to Network
   Security Functions (I2NSF) User and Security Controller in an 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 interface.  The
   information model is based on the "Event-Condition-Action" (ECA)
   policy model defined by a capability information model for I2NSF, and
   the data model is defined for enabling different users of a given
   I2NSF system to define, manage, and monitor security policies for
   specific flows within an administrative domain.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-consumer-facing-interface-dm/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-consumer-facing-interface-dm-14

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: tom petch <[email-masked]>
Date: Fri, 27 Aug 2021 11:56:45 +0000

From: I2nsf <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: 22 August 2021 01:58

I do like consistency as I have said before and this I-D seems out of line with others which for me makes it more error prone for users, implementers.

The other I-D of the four (capability, nsf facing, monitoring,) use identity of transport-protocl, application-protocol) which seems fine.  This does not, using layer-4-protocol, layer-7-protocol.  I think that this should come in line.  In passing, I think that layer 7 is not right - the protocols are layers 5 and 6 and 7.

Also, for the application protocols, this adds nat, drops sftp imap compared to capability which I take as my base reference and perhaps should include those two.

This I-D lacks an identity event but derives from security-event-type four identity which seem close to but not the same as content-security-control in capability and nsf-facing; and the -type suffix seems redundant.

I am still digesting the latest revisions.

Tom Petch

Abstract:

_______________________________________________
I2nsf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2nsf

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Sun, 29 Aug 2021 19:26:04 +0900

Hi Tom,
I will address your comments on the synchronization for Consumer-Facing
Interface Data Model with other Interface Data Models.

Thanks.

Best Regards,
Paul

On Fri, Aug 27, 2021 at 8:57 PM tom petch <[email-masked]> wrote:

> I do like consistency as I have said before and this I-D seems out of line
> with others which for me makes it more error prone for users, implementers.
>
> The other I-D of the four (capability, nsf facing, monitoring,) use
> identity of transport-protocl, application-protocol) which seems fine.
> This does not, using layer-4-protocol, layer-7-protocol.  I think that this
> should come in line.  In passing, I think that layer 7 is not right - the
> protocols are layers 5 and 6 and 7.
>
> Also, for the application protocols, this adds nat, drops sftp imap
> compared to capability which I take as my base reference and perhaps should
> include those two.
>
> This I-D lacks an identity event but derives from security-event-type four
> identity which seem close to but not the same as content-security-control
> in capability and nsf-facing; and the -type suffix seems redundant.
>
>         Filename        :
> draft-ietf-i2nsf-consumer-facing-interface-dm-14.txt
>         Pages           : 60
>         Date            : 2021-08-21
>
> Abstract:

---

From: tom petch <[email-masked]>
Date: Tue, 31 Aug 2021 10:45:30 +0000

From: Mr. Jaehoon Paul Jeong <[email-masked]>
Sent: 29 August 2021 11:26

Hi Tom,
I will address your comments on the synchronization for Consumer-Facing Interface Data Model with other Interface Data Models.

<tp>
Paul

Some more thoughts on consumer-facing

References in the module are good but they need to be in the I-D references as well  I think that you need to add
RFC768
RFC792
RFC793
RFC3261
RFC4340
RFC4443
rfc793bis
IANA ICMP parameters (URL)
IANA ICMPv6 parameters (URL)

In the YANG module http: needs to be https: (I have seen an AD raise a DISCUSS on this!)

continent
I am curious about the source for this.  In the world of natural history, Oceania is very different from Australasia which presumably you treat as one; a reference would be good for this choice of continents (there is an international standard. for natural history)

inet:ipv4-address and inet:ipv6address, as opposed to the nozone variants,  include the zone after the address per se.  Is the use of this deliberate?

container period{
lacks a space

Security Considerations
YANG Guidelines specifies a template for  these with references which I think should be followed.

Tom Petch

Thanks.

Best Regards,
Paul

On Fri, Aug 27, 2021 at 8:57 PM tom petch <[email-masked]<mailto:[email-masked]>> wrote:
From: I2nsf <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: 22 August 2021 01:58

Tom Petch

Abstract:

_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 31 Aug 2021 21:06:00 +0900

Hi Tom,
Thanks for your additional comments.

Patrick and I will address your comments on the revision.

Thanks.

Best Regards,
Paul

On Tue, Aug 31, 2021 at 7:45 PM tom petch <[email-masked]> wrote:

> References in the module are good but they need to be in the I-D
> references as well  I think that you need to add
> RFC768
> RFC792
> RFC793
> RFC3261
> RFC4340
> RFC4443
> rfc793bis
> I am curious about the source for this.  In the world of natural history,
> Oceania is very different from Australasia which presumably you treat as
> one; a reference would be good for this choice of continents (there is an
> international standard. for natural history)
>
> inet:ipv4-address and inet:ipv6address, as opposed to the nozone
> variants,  include the zone after the address per se.  Is the use of this
> deliberate?
>
> container period{
> lacks a space
>
> Security Considerations
> From: I2nsf <[email-masked]<mailto:[email-masked]>> on
> behalf of [email-masked]<mailto:[email-masked]> <
> [email-masked]<mailto:[email-masked]>>